What Olite Checks
The public list of issues Olite is isolating today.
Olite is a lightweight verification scanner for public websites. It is designed to isolate concrete accessibility, privacy, consent, and basic security issues that teams can review and act on quickly.
This page is the public issue catalog. It is meant to show what the product actually surfaces today, and it also gives us a clear starting point for future explainers and blog articles.
It is also now the main public explainer hub for how Olite thinks about accessibility, privacy, consent, and lightweight security checks, so the older standalone Compliance Foundations summary is no longer needed as a separate route.
The fuller internal framing lives in the repository docs: issue catalogand compliance foundations.
Method
How Olite isolates issues
- Static DOM review for markup, labels, titles, and semantics
- Visible public-page review for privacy, policy, and consent cues
- Rendered browser checks in desktop reviews for keyboard, accessibility-tree, and interaction behavior
- Lightweight evidence such as selectors, snippets, and page-level location summaries
This is an automation-oriented review workflow, not legal advice, not certification, and not a guarantee that every issue on a site has been found.
Foundations
The public logic behind the checks
- Accessibility checks start with semantic HTML, labels, headings, landmarks, and other structure the browser can expose programmatically
- Rendered accessibility checks go one step further by sampling post-hydration state, focus movement, and interactive patterns that affect assistive technology
- Privacy checks focus on visible policy, rights, opt-out, cookie, and tracking signals that can be observed from a public page
- Consent coverage is intentionally narrower and avoids claiming that a visible banner alone proves compliant behavior
- Security coverage is baseline-only and is meant to surface obvious public-web weaknesses, not replace a real security review
The goal is to separate strong observable checks from softer guidance, and to be explicit about which findings come from static markup, which come from rendered browser evidence, and which still need deeper manual review.
Accessibility
Current static accessibility issues
These are the current accessibility issues Olite can isolate directly from markup and document structure.
- Missing page title
- Missing html lang attribute
- Missing main landmark
- Multiple h1 headings detected
- Images missing alt text
- Placeholder-only form fields
- Inputs missing visible or programmatic labels
- Weak heading structure signals
- Buttons without accessible names
- Links without accessible names
- Potential focus order override from positive tabindex
- Iframes missing title attributes
Rendered Accessibility
Current desktop-only rendered checks
These checks currently come from the local desktop workflow, where Olite can inspect the page after render, sample keyboard movement, and approximate assistive-technology-relevant structure and interaction behavior.
- Focusable elements hidden from view after render
- Rendered skip link target missing
- Skip link did not change focus or route after activation
- Accessibility tree may not expose the primary page structure
- Critical controls may lack accessible names after render
- Critical controls may expose weak accessible names after render
- Validation feedback may not be announced clearly after interaction
- Dialog interaction may not move and return focus predictably
- Disclosure interaction may not expose state predictably
- Tab interaction may not expose selected state and panel content predictably
- Keyboard tab progression could not be established after render
- Keyboard focus appears stalled during early tab progression
AT Approximation
Why these rendered checks relate to screen-reader behavior
Olite's newer rendered checks are not claiming to run a real screen reader. They are checking the browser signals that assistive technology depends on, such as accessibility-tree structure, accessible names, focus movement, and exposed state changes.
For the full explanation, read What Is AT Approximation In Accessibility Testing?.
Privacy
Current public-page privacy issues
These issues focus on visible policy, rights, opt-out, cookie, and tracking signals that can be observed from a public page.
- Privacy policy link could not be verified
- Tracking signals without visible cookie wording
- Cookie banner without obvious reject or manage controls
- No obvious privacy rights request path detected
- No obvious sale or sharing opt-out path detected
- Limited visible US privacy rights cues
- No visible Global Privacy Control cue detected
- No obvious privacy or cookie policy links detected
- Email capture without visible privacy cues
Privacy Signals
Where browser privacy signals fit
Olite's public privacy checks are intentionally separate from deeper runtime verification. A visible privacy notice or cookie banner is only the first layer. Browser-originated signals such as Global Privacy Control become more meaningful when the product can compare site behavior with and without that signal present.
For the dedicated explainer, read What Is Global Privacy Control?.
Consent
Current consent issue
Consent coverage is intentionally narrow in the current product and focuses on visible email capture cues.
- Email capture without visible consent signals
Security
Current baseline security issues
These are lightweight public-web checks, not a full security audit. They are included because they often reveal obvious weaknesses quickly.
- Limited security header coverage
- Page is not served over HTTPS
- Forms submit to insecure HTTP targets