Accessibility evaluation and checks

Contents

Overview

This section explains how the LRO framework supports accessibility in practice. Many LRO practices (content-first delivery, progressive enhancement, graceful degradation, stability, and user control) also remove common accessibility barriers.

The aim is to help teams translate LRO guidance into inclusive outcomes by:

• describing the accessibility impact of each practice and principle (who benefits and how)
• linking to the relevant LRO sections where the practice is explained, applied, or validated.

Why does this matter for LRO?

Low-resource conditions often create the same failure modes that block access for users with disabilities and those who use assistive technology: blank screens, missing semantics, broken controls, unpredictable UI, and experiences that are not feasible to use.

Treating accessibility as a core concern inside LRO helps ensure that:

• Core content and tasks remain available even when JavaScript, media, or third-party services fail
• The experience is predictable and controllable (reduced cognitive load and fewer interaction errors)
• "Access" includes the ability to use a service in real-world constraints, not only the ability to perceive it

Accessibility practices

Semantic structure and operability

LRO repeatedly emphasises HTML-first delivery, avoiding JS-only shells, and using semantic elements. This directly supports accessibility fundamentals such as robust content interpretation by assistive technologies, predictable keyboard access, and a usable page when scripts fail.

Accessibility impact

• Stronger semantics, better navigation: headings, lists, and landmarks enable jump navigation in screen readers (by heading, region, or list), reducing time and effort to find content.
• Native controls are more reliable: real button, link, and input elements come with built-in keyboard support and accessibility APIs. Replacing them with clickable divs increases the likelihood of WCAG failures.
• Less ARIA risk: when semantics are correct, ARIA is used sparingly and appropriately, reducing the risk of incorrect roles or states that confuse assistive technologies.
• Improves robustness across environments: older browsers, reader modes, and some assistive-technology combinations interpret semantic HTML more consistently than custom JS-rendered UI.
• Supports WCAG robust outcomes in practice and reduces common failures against name, role, and value expectations.

Related LRO sections:

• Progressive Enhancement → Implementation guidance
• Core Content First Strategy → Implementing the content-first strategy

Core content first

Accessibility impact

• Screen reader and Braille display users benefit because page structure (headings, landmarks, and lists) is available immediately, enabling fast orientation and navigation rather than waiting for client-side rendering.
• Users who use a keyboard to navigate benefit when core interactions (navigation, basic forms, and primary buttons) exist as real HTML controls from the start. They can tab and operate controls even if enhancements do not load.
• Users with cognitive or learning disabilities can benefit from early clarity: visible page title, headings, summaries, and predictable navigation reduce uncertainty during slow loads.
• Users using assistive technology on slow networks avoid a common failure mode in which a screen reader announces very little while the UI displays a spinner.
• Supports WCAG outcomes indirectly by improving robustness and operability when enhancements do not load.

Related LRO sections:

• Core Content First Strategy
• Rendering strategies

Progressive enhancement

Progressive enhancement supports accessibility because it treats advanced styling and interactivity as optional. The baseline experience remains usable with keyboard, without JavaScript, on older browsers, and under constrained bandwidth.

Accessibility impact

• Compatibility with assistive technologies improves because the baseline relies on native HTML semantics first. ARIA and complex JS widgets become additive rather than required.
• Reduced risk of JS-required traps: when enhancements fail, users can still read content, navigate, and complete primary tasks.
• More predictable focus and interaction: a baseline built with real links, buttons, and forms reduces focus-order bugs and custom event-handling issues that often break keyboard and switch access.
• Encourages better separation of concerns (HTML, CSS, JS), which tends to reduce regressions that impact keyboard navigation, navigability, and compatibility.

Related LRO sections:

• Progressive Enhancement
• Rendering strategies and LRO impact

Graceful degradation

Graceful degradation reduces the impact of partial failures on accessibility. If a widget, API call, or third-party dependency breaks, users should still be able to access core content and complete essential tasks.

Accessibility impact

• Prevents single-point failures that can block access entirely (for example, one broken chart script preventing a whole page from rendering).
• Maintains task completion: if enhanced filtering fails, users can still browse paginated results; if a map fails, users can still access addresses or locations in text.
• Supports error recovery: clear fallbacks and non-blocking errors reduce confusion for screen reader users and users with cognitive disabilities.
• Improves reliability for assistive-technology users by preventing third-party widgets from introducing focus traps, unlabeled controls, or inconsistent keyboard behavior.

Related LRO sections:

• Graceful Degradation
• Third-party libraries usage strategy

Accessible media

The images and media strategy includes explicit accessibility guidance: ensure content makes sense without images or video; provide appropriate alt text; provide captions and transcripts; avoid sensory-only instructions.

Accessibility impact

• Text alternatives keep meaning available when media fails: when images, embeds, or video do not load, users can still understand the content and complete the task.
• Alt text and null alt reduce friction for screen reader and Braille users: meaningful images need concise alt text; decorative images should use null alt to avoid adding noise or slowing navigation.
• Captions and transcripts support many contexts and needs, including users who rely on text alternatives to audio.
• Complex images (charts or diagrams) need a text equivalent: provide the underlying data, a summary, or a structured description.
• Avoiding sensory-only instructions supports users who cannot perceive color, position, or shape and improves clarity for everyone.

Multimedia content guidelines

• Decide the role of each image (informative, functional, decorative, complex) and choose the appropriate alternative.
• Do not put essential content only in images (including text in images). If an image is required, repeat key information in text.
• Provide captions for video with speech and transcripts for audio or video.
• Avoid auto-playing media and heavy embeds by default. Let users opt in to load or play.
• Keep instructions independent of media. Avoid references such as "see the image above" as the only guidance.
• Ensure media controls are operable: play, pause, volume, captions toggle, and fullscreen should be usable without relying on a mouse.

Related LRO sections:

• Images and media strategy

Predictable layouts

Layout shifts (CLS) create real usability and accessibility problems, including mis-clicks, loss of reading position, increased cognitive load, and frustration, especially when pages load slowly.

Accessibility impact

• Motor accessibility: reduces accidental activation when targets move (mis-click or mis-tap), supporting users with tremor or limited precision.
• Cognitive accessibility: reduces disorientation and helps maintain reading comprehension (content does not jump away).
• Screen magnification users: when zoomed in, small shifts are amplified. Stability prevents losing the current line or region.
• Keyboard users: late-inserted banners or embeds can unexpectedly change tab order or push focused elements. Reserving space and avoiding top inserts reduce focus disruption.

Related LRO sections:

• Layout stability (CLS)

User control and transparency

Giving users control over data-heavy features is an inclusion mechanism. It reduces hidden costs that effectively exclude users on limited data plans or unstable connectivity. Transparency and choice also support trust and comprehension.

Accessibility impact

• Equitable access: users can choose to avoid features that would otherwise be inaccessible due to cost, bandwidth, or device limits.
• Reduced cognitive load: clear file sizes and warnings prevent unexpected waits and confusion.
• More resilient alternative paths: offering lite views, lower-quality media, or CSV exports can provide accessible formats for assistive-technology users and low-resource users alike.
• Aligns with inclusive practice: users control their experience rather than the system assuming max bandwidth and max device capability.

Related LRO sections:

• Data Transparency & User Control

Avoiding patterns that become barriers at scale

Several anti-patterns flagged in LRO are also common accessibility failure points: SPA-only architectures with blank initial states, infinite scrolling for large datasets, no pagination, unbounded API calls, and heavy third-party scripts.

Accessibility impact

• SPA or CSR-only blank shell patterns can break reading order, reduce discoverability for assistive technologies, and make pages unusable when JavaScript fails.
• Infinite scroll can be difficult for keyboard and screen reader users to manage (harder to reach footer/help content, difficult to maintain position, inconsistent announcements).
• No pagination and huge tables can overwhelm cognition and devices. Paginated, chunked content is easier to navigate.
• Heavy third-party scripts often introduce inaccessible UI (unlabeled controls, focus traps) and unpredictable performance.

Related LRO sections:

• Anti-patterns

Accessibility Evaluation workflow

The workflow adapts accessibility evaluations to the goals of the LRO framework: keeping core tasks usable and understandable under real-world constraints while supporting inclusive access across different needs and ways of interacting. It combines automated checks, human-led review, and usability testing with feedback from participants who use assistive technologies and other access supports.

It is designed to help teams answer four questions:

• Where do we start?
• What are we testing? (scope and key flows)
• What are we aiming for? (acceptance target and support matrix)
• How do we keep it from regressing? (repeatable checks and reporting)

Why it matters: when barriers are found late, fixes typically take longer and cost more to implement. This can push teams toward interim solutions rather than durable improvements.

Plan the evaluation

Define the acceptance target

• Goal: align on the definition of accessible enough for an evaluation of a product or service.
• Decisions to record: target WCAG level (usually WCAG 2.2 AA), any additional organizational or legal requirements, and what is in scope (new features vs full product).
• Why it matters: without a shared target, prioritization and sign-off criteria can vary across roles.

Select support matrix (browsers and assistive tech)

• Goal: support consistent, repeatable results by testing browser and assistive-technology combinations users rely on.
• Define: desktop and mobile browser coverage, plus assistive-technology baseline.
• Why it matters: accessibility behavior can differ significantly across combinations.

Map the scope

• Goal: cover the real product experience end-to-end.
• Capture: critical user journeys, reused pages and components (header, nav, footer, search, global alerts), and role-based or conditional UI.
• Why it matters: spot checks can miss issues that appear only in complete user journeys.

Prepare an accessibility statement or update plan

• Goal: provide transparency and a feedback route.
• Include: targeted standard, test coverage (browsers and assistive technologies), and known limitations.
• Why it matters: user feedback surfaces barriers that tools and internal testing miss.

Run the evaluation

Report findings and plan improvements

Document findings

• Goal: make issues actionable for design, content, and engineering.
• Include: steps to reproduce, expected vs actual behavior, affected users, environment, severity, and recommended fix approach.

Prioritize by user impact

• Task completion blockers
• Keyboard and screen reader failures
• Readability and cognitive load barriers
• Enhancements

Make it continuous

• Goal: keep accessibility from resetting after releases.
• Practices: CI checks on key templates, design review checkpoints, component standards, periodic audits, and a feedback loop.

Measuring Accessibility Progress

Accessibility Maturity Model: establish clear benchmarks to track accessibility progress and support continuous improvement.

Testing under real constraints

LRO repeatedly recommends testing with slow networks, low-end devices, and failure modes (JS and CSS disabled, timeouts). This is a practical accessibility mindset: test the experience users actually have, not the one we assume they have.

• Reveals real failure modes that become accessibility barriers (timeouts, missing content, broken focus, partial rendering)
• Helps ensure experiences remain usable when assistive technologies and constrained networks combine
• Encourages teams to validate that fallback paths are present and usable, with clear messaging, functional navigation, and accessible error handling

Related LRO sections:

• Progressive Enhancement → Checklist
• Rendering strategies → Do / Don’t

Further reading

Images and text alternatives

• WAI Images Tutorial
• Alt text Decision Tree

Audio and video accessibility

• Accessible audio and video content

WCAG

• WCAG overview

Page structure and semantics

• WAI Page Structure tutorial

Keyboard and screen readers

• Keyboard accessibility
• Using screen readers

Useful background

• How People with Disabilities Use the Web

Other sources

• Approachable Accessibility: Planning for Success by Martine Dowden and Michael Dowden
• W3C WAI - Evaluating Web Accessibility Overview
• W3C WAI - Accessibility Statements
• Web Accessibility Evaluation Tool List