Standards Explorer
50+ WCAG rules with impact assessments. Filter by severity, compliance level, and remediation strategy for digital accessibility compliance.
Use the explorer below to filter through our supported accessibility rules. Cards indicate the WCAG compliance level and the severity of a failure.
Contrast (minimum)
Text and images of text must have a contrast ratio of at least 4.5:1 (3:1 for large text).
Critical for users with low vision. Affects readability for all users in varying lighting conditions.
▶ Show Technical Details
Use tools like WebAIM Contrast Checker to verify contrast. Adjust color choices or add background opacity to achieve correct contrast.
- Gray text on white background (#777 on #FFF)
- Light blue links without underline
- Placeholder text with too low contrast
import { Button } from '@holmdigital/components'; // Bad: Poor contrast <button style={{ background: '#777', color: '#999' }}>Click me</button> // Good: Use accessible component <Button variant="primary">Click me</Button>Keyboard
All functionality must be accessible via keyboard.
Critical for users with motor disabilities and screen reader users.
▶ Show Technical Details
Use semantic HTML elements (button, a, input) instead of div/span with click handlers. Ensure tabindex is used correctly.
- Using div/span for clickable elements
- Custom dropdown menus without keyboard support
- Modal dialogs that trap focus incorrectly
// Bad: Div with onClick <div onClick={handleClick}>Click Me</div> // Good: Button element <button onClick={handleClick}>Click Me</button> // Best: Use HolmDigital component import { Button } from '@holmdigital/components'; <Button onClick={handleClick}>Click Me</Button>Non-text content
All images must have descriptive alternative text.
Critical for screen reader users to access visual information.
▶ Show Technical Details
Add alt attributes to all img elements. For decorative images, use alt="". For informative images, concisely describe the content.
- Missing alt text entirely
- Alt text that just says 'image' or 'icon'
- Filename as alt text (e.g. 'IMG_1234.jpg')
- Decorative images with unnecessary description
// Bad: Msising alt <img src="logo.png" /> // Good: Descriptive alt <img src="logo.png" alt="HolmDigital Logo" /> // Good: Decorative image <img src="decoration.png" alt="" role="presentation" />
Labels or instructions
Form fields must have clear labels or instructions.
Critical for users to successfully use e-services and submit information.
▶ Show Technical Details
Use label elements linked to input via for/id. For complex forms, use fieldset and legend. Use aria-describedby for extra instructions.
- Only placeholder without label
- Label and input not linked via for/id
- Error messages without aria-describedby
- Required fields not clearly marked
import { FormField } from '@holmdigital/components'; // Bad: No label <input type="text" placeholder="Name" /> // Good: With label <label htmlFor="name">Name:</label> <input type="text" id="name" /> // Best: Use HolmDigital component <FormField label="Name" type="text" required helpText="Enter your full name" />Page titled
Each web page must have a descriptive title.
Important for screen reader navigation and SEO.
▶ Show Technical Details
Use the title element in head. The title should be unique for each page and describe its purpose. Format: 'Page Name - Site Name'.
- Same title on all pages
- Title not updating in SPAs
- Too long or too short title
- Title missing entirely
// Bad: Generic title <title>Page</title> // Good: Descriptive title <title>Contact Us - HolmDigital</title> // React/Next.js import Head from 'next/head'; <Head> <title>Contact Us - HolmDigital</title> </Head>
Info and relationships
Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.
Fundamental for all assistive technology navigation.
▶ Show Technical Details
Use semantic HTML: <header>, <nav>, <main>, <footer>, <h1>-<h6>, <ul>/ <ol>, <table>. Do not use visual styles to create 'fake' headings or lists.
- Using bold text instead of <h1>-<h6>
- Using <br> for lists instead of <ul>
- Tables for layout
Use of color
Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.
Crucial for color blind users.
▶ Show Technical Details
Complement color with text, icons, or underlining. E.g. links must have underlines or another visual marker besides color. Error messages need text/icon, not just a red border.
- Links that only differ by color from body text
- Error messages only marked with red color
- Graphs where only color distinguishes data points
Reflow
Content must be presentable without requiring scrolling in two dimensions down to 320px width.
Critical for low vision users who zoom in heavily.
▶ Show Technical Details
Use responsive design (CSS Media Queries, Flexbox, Grid). Avoid fixed widths in pixels. Ensure tables and images scale correctly.
- Fixed widths on containers
- Tables that are not responsive
- Images wider than the screen
Non-text contrast
The visual presentation of user interface components and graphical objects must have a contrast ratio of at least 3:1 against adjacent colors.
Important for distinguishing interactive elements.
▶ Show Technical Details
Applies to buttons, input borders, icons, and focus indicators. Ensure all interactive elements are clearly visible against the background.
- Grayed out buttons with too low contrast
Text spacing
Content or functionality must not be lost when the user changes text spacing (line height, paragraph spacing, etc.).
Important for readability during adaptations.
▶ Show Technical Details
Avoid fixed heights on text containers. Let containers grow with content. Test with text spacing bookmarklet.
- Fixed line height in pixels
- Text container that does not grow
Content on hover or focus
Content shown on hover/focus (e.g. tooltips) must be Dismissable, Hoverable, and Persistent.
Important for users with magnification and motor difficulties.
▶ Show Technical Details
Ensure tooltips do not disappear when moving mouse from trigger to the tooltip itself. Allow ESC to dismiss.
- Tooltips that cannot be reached with mouse
- Menus that close too easily
- Content that cannot be dismissed without moving focus
Captions (prerecorded)
Captions must be provided for all prerecorded audio content in synchronized media.
Critical for deaf and hard of hearing users.
▶ Show Technical Details
Use the <track> element with WebVTT files for HTML5 video. For social media embeds, ensure captions are enabled.
- Auto-generated captions that satisfy no one
- Captions missing entirely
- Captions burned into video (not accessible for search/translation)
Audio description (prerecorded)
Audio description must be provided for all prerecorded video content.
Critical for blind video users.
▶ Show Technical Details
Either as a separate audio track, an alternative version of the video, or (if 'talking heads') ensuring all info is conveyed by audio.
- Information shown only visually (graphics, text signs) without being mentioned in audio
Orientation
Content must not restrict its view and operation to a single display orientation, unless a specific orientation is essential.
Important for users who cannot rotate their device.
▶ Show Technical Details
Do not lock screen to portrait or landscape via CSS or JS manifest. Use CSS media queries to handle layout changes.
- Apps/sites that rotate interface 90 degrees against user will
Identify input purpose
The purpose of each input field collecting information about the user can be programmatically determined.
Reduces cognitive load and motor requirements.
▶ Show Technical Details
Use the 'autocomplete' attribute on input fields for personal data (name, email, tel, address etc.).
- Missing autocomplete attribute
- Incorrect autocomplete value
- Turning off autocomplete (autocomplete='off') unnecessarily
No keyboard trap
If focus can be moved to a component of the page using a keyboard interface, then focus can be moved away from that component using only a keyboard interface.
Critical: The user gets stuck and must restart the browser.
▶ Show Technical Details
Be careful with JS widgets that trap focus (e.g. modal windows). Ensure there is always a way out (e.g. ESC or shift+tab).
- Custom widgets that loop focus infinitely
- Embedded third-party components (maps, chats) without exit
Character key shortcuts
If a keyboard shortcut consists of only one character (letter, number, symbol), there must be a way to turn it off or remap it, or it must only be active on focus.
Important to avoid accidental activation.
▶ Show Technical Details
Avoid single-key shortcuts if possible. If needed, ensure they do not conflict with voice control or accidental typing.
- Gmail-like shortcuts that are on by default without option to disable
Timing adjustable
If a time limit (session, reading time) is set, the user must be able to turn off, adjust, or extend it.
Critical to avoid losing entered data.
▶ Show Technical Details
Provide a warning before the session expires with an 'Extend session' button. The time limit must be at least 20 seconds.
- Logout without warning
- Time limits that cannot be extended
Pause, stop, hide
For moving, blinking, or scrolling content that starts automatically and lasts more than 5 seconds, there must be a way to pause, stop, or hide it.
Important for cognitive accessibility.
▶ Show Technical Details
Applies to carousels (sliders), auto-updating news feeds, animated backgrounds. Add a clear pause button.
- Image carousels without pause button
- Animated backgrounds that cannot be turned off
Three flashes or below threshold
Content must not flash more than three times per second (can cause seizures).
Critical safety risk.
▶ Show Technical Details
Avoid rapid flashing in video and animations. Use tools to measure flash frequency (PEAT).
- Stroboscopic effects in video
- Misuse of blinking error messages
Bypass blocks
There must be a way to skip blocks of content that are repeated on multiple pages (e.g. navigation).
Important for efficient navigation.
▶ Show Technical Details
Implement a 'Skip to Main Content' link at the top of the page that becomes visible on focus. Use semantic landmarks (<main>, <nav>).
- Missing skip-link
- Skip-link broken (does not move focus correctly)
- Landmarks missing
Focus order
Focus order must be logical and follow meaning/structure.
Critical for keyboard navigation and understanding.
▶ Show Technical Details
Match DOM order with visual order. Avoid tabindex greater than 0. Manage focus manually in modals and menus.
- Focus jumps illogically
- Menus in wrong order
- Modal closes and focus returns to top of page
Link purpose (in context)
The purpose of each link can be understood from the link text alone or from the link text together with its context.
Important for efficient navigation.
▶ Show Technical Details
Avoid 'Read more' or 'Click here'. Write descriptive link texts. Use aria-label if visual space is limited but more info is needed.
- Lots of 'Read more' links
- Links that don't say where they lead
Multiple ways
There must be more than one way to find a web page within a set of web pages.
Facilitates different navigation strategies.
▶ Show Technical Details
At least two of: Menu, Search, Sitemap, Links in content.
- Missing search on sites with many pages
Headings and labels
Headings and labels must describe topic or purpose.
Important for cognitive accessibility.
▶ Show Technical Details
Write clear, descriptive headings that give meaning to the content below them. Form labels must be understandable.
- Cryptic headings
- Labels that don't match what needs to be filled in
Focus visible
Any user interface operable by keyboard must have a visible focus indicator.
Critical: Without visible focus, the keyboard user doesn't know where they are.
▶ Show Technical Details
Never remove outline with CSS (outline: none) without replacing it with a clear visual indicator. Ensure contrast of focus ring is sufficient (see 1.4.11).
- outline: none in CSS reset
- Custom buttons missing :focus style
Language of page
The default human language of each web page must be programmatically determinable.
Critical for screen reader users.
▶ Show Technical Details
Set the 'lang' attribute on the <html> element. E.g., <html lang='en'> for English.
- Lang attribute missing
- Wrong language code (e.g. 'en' on a Swedish page)
Language of parts
The human language of each passage or phrase in the content must be programmatically determinable.
Important for correct pronunciation.
▶ Show Technical Details
Use the lang attribute on elements that differ from the page's main language. E.g. <span lang='fr'>Bonjour</span>.
- Foreign quotes in text without markup
On focus
When a component receives focus, it must not initiate a change of context.
Important for predictability.
▶ Show Technical Details
Do not open new windows, submit forms, or move focus automatically just because user tabs to a field.
- Dropdowns that navigate immediately upon selection (without 'Go' button)
- Forms that auto-submit on last field focus
On input
Changing the setting of any component does not automatically cause a change of context unless the user has been advised of the behavior before using the component.
Important for predictability.
▶ Show Technical Details
Inform the user that selection in a list reloads the page. Preferably, add a button to confirm the choice.
- Checkboxes that reload page immediately
- Filtering that moves focus
Consistent navigation
Navigational mechanisms that are repeated on multiple Web pages occur in the same relative order each time they are repeated.
Facilitates learning.
▶ Show Technical Details
Main menu should look the same and be in the same place on all pages. Search function as well.
- Menus that change place or order on different pages
Consistent identification
Components that have the same functionality within a set of Web pages are identified consistently.
Reduces cognitive load.
▶ Show Technical Details
Don't call search 'Search' on one page and 'Find' on another. Use the same icon for the same function.
- Inconsistent naming
- Different icons for print/download
Error identification
If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text.
Critical for error handling.
▶ Show Technical Details
Show error message close to the field. Link with aria-describedby or include in label. Do not just color the field red.
- 'Invalid value' without explanation
- Error message not visible to screen readers
Error suggestion
If an input error is automatically detected and suggestions for correction are known, then the suggestions are provided to the user.
Facilitates correction.
▶ Show Technical Details
If date format is wrong, show required format (YYYY-MM-DD). Offer spelling suggestions for search ('Did you mean...?').
- Only saying 'Error' without saying how to fix it
Error prevention (legal, financial, data)
For Web pages that cause legal commitments or financial transactions, users must be able to: Reverse, Check, or Confirm.
Critical to avoid serious consequences of mistakes.
▶ Show Technical Details
Offer a summary page before final submission with ability to edit.
- Direct purchase without confirmation
- Submission of binding contracts without review
Parsing
Update: From WCAG 2.2 this criterion is removed/obsolete, but in WCAG 2.1/EN 301 549 it applies: IDs must be unique, elements correctly nested.
Technical hygiene factor.
▶ Show Technical Details
Validate HTML. Ensure id attributes are unique on the page. Close all tags correctly.
- Duplicate IDs
- Broken HTML structure
Name, role, value
For all components, name and role can be programmatically determined. Values can be set programmatically.
Absolutely critical for compatibility.
▶ Show Technical Details
Use native HTML elements when possible. If custom components are used, ARIA (role, aria-label, aria-valuenow) must be used correctly.
- Div buttons without role
- Custom checkboxes without aria-checked
- Missing accessible name
import { ProgressBar } from '@holmdigital/components'; // Bad: Div without role <div style={{ width: '50%' }}>50%</div> // Good: Accessible Component <ProgressBar value={50} label="Loading..." />Status messages
Statusmeddelanden ska kunna presenteras för användaren utan att motta fokus (via skärmläsare).
Provides feedback to users without sight.
▶ Show Technical Details
Använd aria-live regioner (polite/assertive) eller role='status'/'alert' för meddelanden som dyker upp dynamiskt (t.ex. 'Sparat', 'Sökning klar').
- Silent updates of cart/search results
- Toast notifications not being announced
import { LiveRegion } from '@holmdigital/components'; // Assertive for errors <LiveRegion politeness="assertive">Error: Failed to save.</LiveRegion> // Polite for status updates <LiveRegion politeness="polite">Saved successfully.</LiveRegion>Info and relationships
The page must have exactly one 'main' landmark.
▶ Show Technical Details
Use the <main> element once per page to identify the main content. Avoid having multiple <main> without unique labels, or missing it entirely.
- Using <div id='main'> instead of <main>
- Having multiple <main> elements
Info and relationships
The page must have a level 1 heading (<h1>).
▶ Show Technical Details
Ensure there is exactly one <h1> describing the page's unique content.
- Starting headings at <h2>
- Using logo as the only <h1> without text
Info and relationships
Headings must follow a logical order (h1 -> h2 -> h3).
▶ Show Technical Details
Do not skip heading levels (e.g. directly from h1 to h3).
- Using h3 for styling instead of structure
Info and relationships
The banner (<header>) must be at the top level.
▶ Show Technical Details
Do not place <header> inside another landmark if it is the page's main banner.
- Nesting header inside main
Info and relationships
The page must have only one 'banner' landmark (usually <header>).
▶ Show Technical Details
Ensure you only have one <header> at the top level.
- Having header both at top and bottom
Info and relationships
Landmarks must have unique roles or labels.
▶ Show Technical Details
If you have multiple <nav> elements, give them unique 'aria-label' (e.g., 'Main Menu', 'Footer Menu').
- Multiple nav elements without aria-label
Info and relationships
All content on the page must be contained within landmarks (regions).
▶ Show Technical Details
Ensure all content is inside <main>, <header>, <nav>, <footer>, or <aside>.
- Content directly in <body> without container
- Using too many landmarks
Audio description (prerecorded)
Prerecorded video content must have audio description if visual information is critical.
▶ Show Technical Details
Provide an alternative audio track or version describing what happens visually.
- Video missing audio description despite important visual info
How we determine Impact
Our impact scoring model is derived from the ACT Rules Format.
Global Frameworks
While Europe is our primary focus, the HolmDigital Standards engine includes mapping for major international accessibility laws:
USA (Section 508 & ADA)
Full support for Rehabilitation Act and ADA standards for government and public accommodations.
Canada (AODA)
Alignment with the Accessibility for Ontarians with Disabilities Act and federal requirements.
UK (PSBAR)
Specific terminology and reporting requirements for the UK Public Sector Bodies Regulations.
EN 301 549
The foundational technical standard for all European digital accessibility legislation.
The Law Layer
The @holmdigital/standards package acts as the regulatory brain. It doesn't just check technical WCAG criteria; it maps them to legal requirements.
import { getNationalLawByFramework } from '@holmdigital/standards'; // Case: Public Sector in Sweden const law = getNationalLawByFramework('WAD', 'SE'); // -> { id: 'dos-lagen', name: 'Lag (2018:1937) om tillgänglighet...', ... }Manual Verification Checks (ICT)
These checks cover requirements that cannot be fully automated (e.g., hardware interaction, documentation quality). They are mapped to EN 301 549 chapters and are essential for full accessibility compliance (including DOS-lagen). See our Compliance Guide for more details.
Auditory output
Where ICT provides auditory output, the auditory output shall be available without requiring the use of hearing.
For public terminals (e.g. ticket machines) auditory output must be available for screen reader functionality.
Tactilely discernible parts
Where ICT has physical controls, these must be tactilely discernible.
Important for self-service terminals in the public sector.
Operable parts discernibility
Where ICT has operable parts, these must be visually discernible.
Also applies to touch screens on public terminals.
Non-text content (non-web documents)
Non-web documents shall satisfy WCAG 2.1 Success Criterion 1.1.1.
PDF documents and E-books (EPUB) must have alt-text. MTM supervises e-books compliance.
Keyboard (non-web documents)
Non-web documents shall be navigable by keyboard.
PDF forms and E-book navigation must be operable via keyboard/reading systems.
Document titled (non-web documents)
Non-web documents shall have a title.
PDF documents must have title set in document properties.
Object information (software)
Software shall expose object information to assistive technology.
Mobile apps from public authorities must work with iOS VoiceOver and Android TalkBack.
Authoring tool accessibility (software)
If the software is an authoring tool, it must support accessible content creation.
CMS used by authorities must encourage/require accessible content.
Accessibility and compatibility features
Product documentation shall describe accessibility features.
Accessibility statement must include information about accessibility features. Applies to public sector (DOS-law), private actors (Accessibility Act), and E-book distributors.
Accessible documentation
Product documentation shall be accessible.
Help pages and user guides must be accessible. Critical for e-commerce and banking services under the Accessibility Act.
Information on accessibility and compatibility features
Support services shall be knowledgeable about accessibility features.
Support services (helpdesk/technical support) must be able to assist users with disabilities. Applies to all actors covered by the Accessibility Act.
Accessible support services
Support services shall be accessible.
Support channels must be accessible. Private actors offering services to consumers must ensure their support is inclusive.
Ready to audit your site?
Get started with our automated testing suite in minutes.
Installation Guide →