[
{
"rule_id": "aria-progressbar-name",
"standard_code": "1.1.1",
"Notes": null,
"issue_severity": "serious",
"wcag_version_number": 2,
"wcag_level": "A",
"affected_disabilities_json": "Blind | Low vision | Cognitive",
"help": "ARIA progressbar nodes must have an accessible name",
"title": "ARIA progress bars lack descriptive labels for screen readers",
"dev_help": "1. Add an `aria-label` attribute to the `progressbar` element with a descriptive name, e.g., `File upload progress:
elements must have alternate text",
"title": " elements lack text alternatives for media content",
"dev_help": "1. Provide alternative text within the element: Include text content between the opening and closing `` tags. This text will be displayed if the object cannot be rendered. Example: `A logo image `. 2. Use the `alt` attribute (when appropriate): For simple images embedded with ``, the `alt` attribute can be used similar to the ` elements have alternate text",
"layman_help": "If a website has a video or picture that you can't see or play, there should be a description of what it is. Imagine someone telling you what's happening in the video or what the picture shows. That's what the website needs to provide. Make sure that the description accurately explains the picture or video. Try using a tool that reads the website aloud to check if the description makes sense.",
"passed_title": "Object elements have text alternatives.",
"dev_description": "The element is used to embed multimedia content or another resource into an HTML document. When an element is used, it's crucial to provide alternative text within the element or via the `alt` attribute for assistive technologies. This ensures that users who cannot see the embedded object, or whose browsers cannot process it, still receive meaningful information about its purpose or content. If the object conveys important information, its alternative representation must convey the same information.",
"layman_description": "Imagine a website uses a special picture format or video that your browser can't understand, or you can't see. The `` tag is like saying, 'Here's something that might not work for everyone.' To help, websites need to provide a text description (like a caption) that explains what the picture or video is about. This way, if you can't see or use the embedded content, you still understand what it's trying to show you. Without this description, you'd miss out on important information.",
"how_to_test": null
},
{
"rule_id": "role-img-alt",
"standard_code": "1.1.1",
"Notes": null,
"issue_severity": "serious",
"wcag_version_number": 2,
"wcag_level": "A",
"affected_disabilities_json": "Blind | Low vision | Cognitive",
"help": "[role=\"img\"] elements must have an alternative text",
"title": "Elements with role=\"img\" are missing accessible names",
"dev_help": "1. For images with `role=\"img\"`, add an `aria-label` attribute containing a concise description of the image's content and function.\n Example: `
`.\n 2. Alternatively, use `aria-labelledby` to reference existing text on the page that describes the image.\n Example: `Company Logo
`.\n 3. If the image is purely decorative, apply `aria-hidden=\"true\"` to the element to hide it from assistive technologies.\n Example: `
`.\n 4. If the `role=\"img\"` is applied to an ` elements with an img role must have an alternative text",
"title": "SVG images are missing accessible names or text alternatives",
"dev_help": "1. Use the `` element: Add a `<title>` element as the first child of the `<svg>` element, containing a descriptive text. Example: `<svg role=\"img\"><title>Company Logo ... `. \n 2. Use `aria-labelledby`: Reference a visible text element using the `aria-labelledby` attribute. Ensure the referenced element contains a meaningful description. Example: `Company Logo ... `. \n 3. Use `aria-label`: Add an `aria-label` attribute to the `` element with a concise description. Example: ` ... `. \n Choose the method that best suits the context and provides the most appropriate and accessible description for the image.",
"help_url": "https://dequeuniversity.com/rules/axe/4.10/svg-img-alt?application=axeAPI",
"description": "Ensure elements with an img, graphics-document or graphics-symbol role have an accessible text",
"layman_help": "If a picture is important to understanding what's on the page, make sure it has a text description for people who can't see it. You can do this by:\n 1. Adding a short text inside the picture's code that describes what it is (using ``).\n 2. Pointing to a nearby text that describes the picture (using `aria-labelledby`).\n 3. Adding a short description directly to the picture's code (using `aria-label`).\n This way, everyone can understand what the picture is about, even if they can't see it.",
"passed_title": "SVG images have accessible names or text alternatives.",
"dev_description": "Ensure that `<svg>` elements with `role=\"img\"`, `role=\"graphics-document\"`, or `role=\"graphics-symbol\"` have an accessible text alternative. This can be achieved through the use of the `<title>` element as the first child of the `<svg>` element, the `aria-labelledby` attribute referencing a visible text, or the `aria-label` attribute providing a concise description. This rule is crucial for providing screen reader users with meaningful information about the image.",
"layman_description": "If a picture or graphic on a website is important (it has role as `img`, `graphics-document` or `graphics-symbol`), people who can't see the picture need a way to understand what it is. This means the picture needs a text description that screen readers can read aloud. Without this description, users with blindness or low vision will miss out on the information conveyed by the picture or graphic. It's like showing someone a picture and not telling them what it is; they're left completely in the dark.",
"how_to_test": null
},
{
"rule_id": "input-image-alt",
"standard_code": "1.1.1",
"Notes": null,
"issue_severity": "critical",
"wcag_version_number": 2,
"wcag_level": "A",
"affected_disabilities_json": "Blind | Low vision | Cognitive",
"help": "Image buttons must have alternate text",
"title": "Image buttons are missing descriptive alt text",
"dev_help": "1. Check if the `<input type=\"image\">` element has an `alt` attribute.\n 2. If the `alt` attribute is missing, add it.\n 3. Ensure the `alt` attribute accurately describes the function of the button. For example:\n - If the image submits a form, use `alt=\"Submit\"`.\n - If the image is a search button, use `alt=\"Search\"`.\n - If the image is purely decorative, use `alt=\"\"`.\n 4. Verify that the alternative text is meaningful and provides context for the button's action.\n \n\n Example:\n `<input type=\"image\" src=\"search.png\" alt=\"Search\" />`\n `<input type=\"image\" src=\"decorative.png\" alt=\"\" />`",
"help_url": "https://dequeuniversity.com/rules/axe/4.10/input-image-alt?application=axeAPI",
"description": "Ensure <input type=\"image\"> elements have alternate text",
"layman_help": "If you can't see the image used as a button, there needs to be a text description that tells you what the button does. Make sure the picture has a description that explains the button's action, like 'Submit' for a submit button or 'Search' for a search button. If the picture is just for decoration and doesn't do anything, it still needs a blank description so your screen reader knows to ignore it.",
"passed_title": "Image buttons have descriptive alt text for screen readers.",
"dev_description": "<input type=\"image\"> elements are used to create image-based form submission buttons. These elements must have an `alt` attribute that provides a text alternative describing the button's function. This ensures that users who cannot see the image (e.g., screen reader users) understand the button's purpose. An empty `alt` attribute (`alt=\"\"`) is acceptable only if the image is purely decorative and its function is conveyed elsewhere on the page.",
"layman_description": "If a website uses a picture as a button, people who can't see the picture need to know what the button does. This is done by adding a description (called 'alt text') to the picture. Without this description, someone using a screen reader won't know what happens when they click the button, making it impossible for them to use that part of the website. For example, if a magnifying glass icon is used as a search button, the alt text should say 'Search'.",
"how_to_test": null
},
{
"rule_id": "image-alt",
"standard_code": "1.1.1",
"Notes": null,
"issue_severity": "critical",
"wcag_version_number": 2,
"wcag_level": "A",
"affected_disabilities_json": "Blind | Low vision | Cognitive",
"help": "Images must have alternate text",
"title": "Images are missing descriptive alt text",
"dev_help": "1. Identify meaningful images: Determine which `<img>` elements convey important information.\n 2. Add descriptive `alt` text: For meaningful images, add an `alt` attribute that accurately and concisely describes the image's content. Example: `<img src=\"product.jpg\" alt=\"Close-up of a red coffee mug with a white logo\">`.\n 3. Mark decorative images: For decorative images, add an empty `alt` attribute: `<img src=\"border.gif\" alt=\"\">` or use `role=\"presentation\"`: `<img src=\"border.gif\" role=\"presentation\">`.\n 4. Avoid redundant alt text: Do not repeat the same information in the `alt` text that is already present in the surrounding text.\n 5. Ensure linked images have alt text: If an image is a link, the `alt` text should describe the destination of the link. Example: `<a href=\"/products\"><img src=\"products_icon.png\" alt=\"View all products\"></a>`.\n 6. Test with a screen reader: Use a screen reader to verify that the `alt` text is read correctly and provides a good user experience.",
"help_url": "https://dequeuniversity.com/rules/axe/4.10/image-alt?application=axeAPI",
"description": "Ensure <img> elements have alternate text or a role of none or presentation",
"layman_help": "1. Check your images: Look at each image on the website.\n 2. Describe important images: If an image helps you understand something, write a short description of it in the 'alt text' box. Imagine you're describing the image to someone who can't see it.\n 3. Mark decorative images: If an image is just for decoration and doesn't add any meaning, leave the 'alt text' box empty.\n 4. Test your website: Use tools that simulate how visually impaired people browse the web, to make sure the image descriptions make sense.",
"passed_title": "Images have descriptive alt text.",
"dev_description": "Ensure that all `<img>` elements have appropriate `alt` attributes. If an image conveys meaningful content, the `alt` attribute should provide a concise text alternative. If an image is purely decorative and adds no information, it should have an empty `alt` attribute (`alt=\"\"`) or a `role=\"presentation\"` attribute. Using `role=\"none\"` is also acceptable, although less common. Avoid using the image as the only content within a link or button without providing accessible names.",
"layman_description": "Every image on a website should have a text description (called 'alt text') that explains what the image is about. If the image is important for understanding the content, the alt text helps people who can't see the image (like those using screen readers) understand what they're missing. If the image is just for decoration and doesn't add any meaning, it should be marked as decorative so screen readers can skip it. Without proper alt text, people with visual impairments might not understand the website's content or might get confused.",
"how_to_test": null
},
{
"rule_id": "aria-meter-name",
"standard_code": "1.1.1",
"Notes": null,
"issue_severity": "serious",
"wcag_version_number": 2,
"wcag_level": "A",
"affected_disabilities_json": "Blind | Low vision | Cognitive",
"help": "ARIA meter nodes must have an accessible name",
"title": "ARIA meter elements lack descriptive labels for screen readers",
"dev_help": "1. Identify the ARIA `meter` element: Locate the `<meter>` element in your HTML that is missing an accessible name.\n 2. Add an `aria-label` attribute: The simplest solution is to add an `aria-label` attribute with a descriptive name. For example: `<meter value=\"75\" min=\"0\" max=\"100\" aria-label=\"Disk usage\">75%</meter>`\n 3. Use `aria-labelledby`: If the label text already exists elsewhere on the page, use the `aria-labelledby` attribute to associate the meter with that text. For example: `<span id=\"disk-usage-label\">Disk usage:</span> <meter value=\"75\" min=\"0\" max=\"100\" aria-labelledby=\"disk-usage-label\">75%</meter>`\n 4. Ensure the name is accurate and descriptive: The accessible name should clearly and accurately describe what the meter represents. Avoid vague or ambiguous labels.",
"help_url": "https://dequeuniversity.com/rules/axe/4.10/aria-meter-name?application=axeAPI",
"description": "Ensure every ARIA meter node has an accessible name",
"layman_help": "1. Find the battery or progress indicator on the webpage that's not properly labeled.\n 2. Add a clear label to it, like 'Battery Level' or 'Download Progress.' This label should be easily understandable.\n 3. Make sure the label is linked to the indicator so that screen readers can read it aloud. This can be done by technically linking the label using a special code or just making sure the label is right next to the indicator.\n 4. Double-check that the label is accurate. For example, if it's showing hard drive space, the label should say 'Hard Drive Space' and not something confusing.",
"passed_title": "ARIA meter elements have descriptive labels for purpose.",
"dev_description": "This rule checks that all ARIA `meter` elements have an accessible name. The accessible name provides a programmatically determined text alternative that describes the purpose of the meter. Without an accessible name, users of assistive technologies like screen readers will not understand the meter's function or the information it conveys. An accessible name can be provided using attributes like `aria-label`, `aria-labelledby`, or the element's content if it's appropriately structured.",
"layman_description": "Imagine a dashboard showing how much battery is left on your device. If this battery indicator (which is technically called a 'meter' on websites) doesn't have a clear label, like 'Battery Level,' someone using a screen reader won't know what the meter represents. They'll just hear 'meter' with a number, but not understand what the number means. This rule ensures that every meter has a descriptive label so everyone, including people using screen readers, understands what the meter is showing. This is especially important for users with visual impairments or cognitive disabilities who rely on screen readers to understand the content on a page.",
"how_to_test": null
},
{
"rule_id": "audio-caption",
"standard_code": "1.2.1",
"Notes": null,
"issue_severity": "critical",
"wcag_version_number": 2,
"wcag_level": "A",
"affected_disabilities_json": "deaf | deafBlind",
"help": "<audio> elements must have a captions track",
"title": "Audio-only and video-only content lack transcripts or descriptions",
"dev_help": "1. Identify Audio Content: Locate all `<audio>` elements on your webpage.\n 2. Create Captions: Transcribe the audio content, including speech and important non-speech sounds, into a caption file (e.g., using a .vtt or .srt format).\n 3. Add `<track>` Element: Include a `<track>` element within the `<audio>` element to link to the caption file. Set the `kind` attribute to `captions`, the `srclang` attribute to the language code (e.g., `en` for English), and the `src` attribute to the URL of the caption file. Also, include the `label` attribute which will be displayed in the menu for selecting the captions.\n \n 4. Synchronize Captions: Ensure the captions are accurately synchronized with the audio using timestamps in the caption file.\n 5. Test: Verify that the captions display correctly and are synchronized with the audio playback. Use a media player that supports captions to test.",
"help_url": "https://dequeuniversity.com/rules/axe/4.10/audio-caption?application=axeAPI",
"description": "Ensure <audio> elements have captions",
"layman_help": "1. Check if there is any audio on the website. \n 2. If there's audio, make sure there are text captions that show what's being said and any important sounds. \n 3. The captions should be synchronized with the audio, so the text appears at the right time. \n 4. If you can't hear the audio, you should still be able to understand everything by reading the captions.",
"passed_title": "Audio-only and video-only content have transcripts or descriptions.",
"dev_description": "Ensure that all `<audio>` elements have captions available. Captions should accurately transcribe the spoken content and include relevant sound effects and other non-speech audio information necessary to understand the content. The captions should be synchronized with the audio. This can be achieved by using the `<track>` element within the `<audio>` element, or by providing a link to a caption file (e.g., .vtt or .srt).",
"layman_description": "Imagine you're watching a video, but you can't hear the sound. Captions are like subtitles for audio. This rule means that if a website has audio, it needs to provide text captions of what's being said and any important sounds, like music or sound effects. This allows people who are deaf or hard of hearing to understand the audio content. Without captions, they would miss out on important information.",
"how_to_test": null
},
{
"rule_id": "video-caption",
"standard_code": "1.2.2",
"Notes": null,
"issue_severity": "critical",
"wcag_version_number": 2,
"wcag_level": "A",
"affected_disabilities_json": "deaf | deafBlind | Cognitive",
"help": "<video> elements must have captions",
"title": "Prerecorded videos are missing captions",
"dev_help": "1. Add a `<track>` element inside the `<video>` element. The `src` attribute of the `<track>` element should point to a valid captions file (e.g., a VTT file). Set the `kind` attribute to `captions` and the `srclang` attribute to the language of the captions (e.g., `en` for English). Add the `label` attribute to provide a user-friendly name for the captions.\n 2. Ensure the captions file is properly formatted and synchronized with the audio. Use a tool to create or edit the captions file, such as Subtitle Edit or Amara.\n 3. Test the video with captions enabled to ensure they are displayed correctly and are accurately conveying the audio content. Example:",
"help_url": "https://dequeuniversity.com/rules/axe/4.10/video-caption?application=axeAPI",
"description": "Ensure <video> elements have captions",
"layman_help": "To fix this, add words on the screen (captions) to the video. These captions should show everything that's being said and any important sounds. Make sure the words match the sound and appear at the right time. You can use a special program to create these captions and then add them to the video so everyone can read along.",
"passed_title": "Prerecorded videos have captions.",
"dev_description": "All video content must have synchronized captions that accurately convey the dialogue, sound effects, and other relevant auditory information. This ensures that users who are deaf or hard of hearing can understand the video content. Captions should be properly synchronized with the audio and should clearly identify speakers when necessary. If captions are missing or inaccurate, users who rely on them will not be able to fully access the information presented in the video.",
"layman_description": "Imagine watching a video without being able to hear anything. Captions are like subtitles for people who can't hear. They show the words and sounds in the video so everyone can understand what's happening. If a video doesn't have captions, people who are deaf or have hearing problems will miss out on important information and won't be able to enjoy the video fully. They won't know what the people are saying or what the important sounds are.",
"how_to_test": null
},
{
"rule_id": "nonaxe-audio-description-or-media-alternative-prerecorded",
"standard_code": "1.2.3",
"Notes": null,
"issue_severity": "moderate",
"wcag_version_number": 2,
"wcag_level": "A",
"affected_disabilities_json": "Blind | Low vision | deaf | Cognitive",
"help": "Provide a description of the visual content in videos.",
"title": "Prerecorded videos lack audio descriptions or text alternatives",
"dev_help": "1. For video-only content, create a text transcript that includes all relevant visual information, including actions, settings, and any on-screen text. 2. For audio-only content, provide a text transcript. 3. If creating an audio description, ensure it is synchronized with the video and clearly describes the relevant visual information without overlapping essential dialogue or audio. 4. Consider providing a media alternative such as an audio described version of the video alongside the original. Ensure the media alternative is easily discoverable by all users. For example, include a link to the transcript or alternative media directly below the video.",
"help_url": "https://www.w3.org/WAI/WCAG22/Understanding/audio-description-or-media-alternative-prerecorded.html",
"description": "Prerecorded videos can be understood by more people.",
"layman_help": "If a video doesn't have sound, write down everything that's happening so people can read it. If it's just sound, write that down too. If you're describing the video with sound, make sure it lines up with what's happening on screen and doesn't talk over important parts. Make sure these descriptions are easy to find, like right below the video.",
"passed_title": "Prerecorded videos have audio descriptions or text alternatives.",
"dev_description": "For prerecorded video-only content (videos with no audio track), or prerecorded audio-only content, an alternative for time-based media is provided that presents equivalent information. This typically involves providing a text transcript or an audio description. The primary goal is to ensure that users who cannot see the video or hear the audio still have access to the same information and functionality.",
"layman_description": "If a video is pre-recorded, and doesn't have any sound, or if it's just sound (audio only), there needs to be a way for everyone to understand it. This usually means providing a written version (like subtitles for the deaf or hard of hearing) or describing what's happening in the video using audio (for people who are blind). Imagine watching a video and not being able to hear; you'd miss everything! This rule makes sure that people with hearing or sight problems don't miss out on important information.",
"how_to_test": "1. Find your media: Locate all prerecorded video and audio-only content on your website.\n 2. For Videos:\n i. Play the video. Does it have important visual information (actions, settings, characters, on-screen text) that isn't explained in the main audio track?\n ii. If yes, look for an option in the video player controls to turn on \"Audio Description\" (sometimes labeled AD). Listen to see if it describes the key visual parts during pauses.\n iii. If there's no audio description, look for a link or text section nearby labeled \"Transcript,\" \"Text Alternative,\" or \"Screenplay\".\n iv. Read this text alternative. Does it include all spoken words and descriptions of important visuals and sounds?\n 3. For Audio-Only:\n i. Look for a link or text section nearby labeled \"Transcript\" or \"Text Alternative\".\n ii. Read the transcript. Does it include all spoken words and descriptions of any important non-speech sounds (like music or sound effects that add meaning)?\n 4. Evaluate: Check if the provided audio description or text alternative accurately captures the full meaning and essential information presented in the original media. Is it easy for someone who can't see or hear the original to understand what's happening?"
},
{
"rule_id": "nonaxe-captions-live",
"standard_code": "1.2.4",
"Notes": null,
"issue_severity": "critical",
"wcag_version_number": 2,
"wcag_level": "AA",
"affected_disabilities_json": "deaf | deafBlind",
"help": "Provide synchronized text for audio content in real-time videos.",
"title": "Live videos are missing captions",
"dev_help": "1. Use a real-time captioning service: Employ a professional captioning service or automatic speech recognition (ASR) software that can generate captions in real-time during the live broadcast.\n 2. Ensure synchronization: Verify that captions are accurately synchronized with the audio. Captions should appear on the screen at the same time the corresponding words are spoken.\n 3. Provide speaker identification: If multiple speakers are present, identify each speaker in the captions (e.g., \"[Host] Welcome to the show...\").\n 4. Describe relevant sounds: Include descriptions of important non-speech sounds, such as music, laughter, or sound effects, within the captions (e.g., \"[Applause]\", \"[Upbeat music playing]\").\n 5. Test and monitor: Regularly test the captions during live broadcasts to ensure accuracy and synchronization. Monitor user feedback to address any issues promptly.\n Example: <video controls><track src=\"captions_live.vtt\" kind=\"captions\" srclang=\"en\" label=\"English\"></video>",
"help_url": "https://www.w3.org/WAI/WCAG22/Understanding/captions-live.html",
"description": "Live videos have captions.",
"layman_help": "If you're showing a live video online, make sure to add captions. You can hire someone to type the words being spoken in real-time, or use special computer programs that do it automatically. The captions should appear on the screen at the same time the words are spoken. If there are different people talking, say who's talking in the captions. Also, describe any important sounds that aren't words, like music or applause, so everyone knows what's happening.",
"passed_title": "Live videos have captions.",
"dev_description": "Ensure that live video content includes synchronized captions. Captions must be provided in real-time, accurately transcribing spoken words and identifying relevant sounds. This ensures users with hearing impairments can access the information conveyed in the video. The captions should be correctly timed with the audio and should provide context when necessary, such as speaker identification or descriptions of important non-speech sounds.",
"layman_description": "Imagine watching a live news broadcast or a live concert online, but you can't hear the audio. If there are no captions, you'll miss everything that's being said and any important sounds. This is what it's like for someone who is deaf or hard of hearing. Captions are like subtitles for live videos, showing the words being spoken and describing important sounds, so everyone can understand what's happening.",
"how_to_test": "1. Access the live event: Join the live webcast, stream, or meeting.\n 2. Look for captions: Find the caption controls (often a \"CC\" button or an option in the settings menu).\n 3. Turn captions on.\n 4. Watch and listen: As people speak during the live event, watch the captions.\n i. Are the captions appearing in sync with the speech, without too much delay?\n ii. Do they accurately represent what is being said?"
},
{
"rule_id": "nonaxe-audio-description-prerecorded",
"standard_code": "1.2.5",
"Notes": null,
"issue_severity": "moderate",
"wcag_version_number": 2,
"wcag_level": "AA",
"affected_disabilities_json": "Blind | Low vision",
"help": "Provide a synchronized spoken description of the visual content in videos.",
"title": "Prerecorded videos are missing audio descriptions",
"dev_help": "1. Identify all significant visual information in the video (actions, scene changes, graphics, etc.). 2. Write an audio description script that narrates these visual elements clearly and concisely. Ensure the descriptions do not overlap with existing dialogue or crucial audio. 3. Integrate the audio description into the video in one of the following ways: a) Add the audio descriptions during existing pauses in dialogue (described video). b) Create a separate audio-described version of the video. c) Provide a text transcript of the video including descriptions. 4. Ensure the audio description is synchronized with the video so it accurately reflects the visual content as it occurs. Example: Instead of showing a character entering a room, the audio description would state: 'John enters the brightly lit room, looking worried.'",
"help_url": "https://www.w3.org/WAI/WCAG22/Understanding/audio-description-prerecorded.html",
"description": "Videos can be played with audio descriptions.",
"layman_help": "Think of someone explaining what's happening in the video out loud, describing the important things you can see. You can either add this explanation during quiet parts of the video, create a separate version of the video with the explanations, or provide a written description of the video's events. This makes the video understandable for people who can't see it.",
"passed_title": "Prerecorded videos have audio descriptions.",
"dev_description": "Ensure that prerecorded video content provides audio descriptions that narrate important visual information, including actions, scene changes, and graphics, so that users who cannot see the video can understand the content. If providing audio descriptions is not feasible, provide an alternative such as a transcript or an audio-described version of the video.",
"layman_description": "Imagine watching a video without being able to see it. Audio descriptions are like a narrator who tells you what's happening on the screen – who is doing what, what the scenery looks like, and any other important visual details. This helps people who are blind or have low vision understand the video content. Without audio descriptions, they'd miss out on vital information and might not be able to follow the story or understand the message.",
"how_to_test": "1. Find prerecorded videos: Locate any prerecorded video content on your webpage.\n 2. Look for audio track options: Check the video player's controls or settings menu. Is there an option to select different audio tracks?\n 3. Select Audio Description: Look for a track labeled \"Audio Description,\" \"AD,\" or similar. If found, select it.\n 4. Listen and verify: Play the video with the audio description track enabled. Listen carefully during pauses in the main dialogue or sound.\n - Does the narrator describe key visual elements (actions, characters, scene changes, on-screen text) that you wouldn't know about just from listening to the main audio?\n - Is the description helpful for understanding the full context of the video?\n 5. Evaluate: If a prerecorded video lacks an audio description option, or if the description provided doesn't cover the essential visual information, it fails this check."
},
{
"rule_id": "nonaxe-sign-language-prerecorded",
"standard_code": "1.2.6",
"Notes": null,
"issue_severity": "moderate",
"wcag_version_number": 2,
"wcag_level": "AAA",
"affected_disabilities_json": "deaf",
"help": "Provide sign language interpretation for audio content in existing videos.",
"title": "Prerecorded videos lack sign language interpretation",
"dev_help": "1. Identify videos that contain audio content.\n 2. Create a sign language interpretation for the audio content of each video.\n 3. Embed the sign language interpretation within the video player so that it is synchronized with the original audio and video.\n 4. Ensure the sign language interpretation is clear and easy to understand.\n 5. Provide controls to allow users to toggle the sign language interpretation on or off.\n Example: \n <video controls>\n <source src=\"video.mp4\" type=\"video/mp4\">\n <track src=\"sign-language.vtt\" kind=\"captions\" srclang=\"en\" label=\"Sign Language\">\n Your browser does not support the video tag.\n </video>",
"help_url": "https://www.w3.org/WAI/WCAG22/Understanding/sign-language-prerecorded.html",
"description": "Videos can be accompanied by sign language.",
"layman_help": "Make sure every video has a person signing what's being said. This helps people who can't hear understand the video. The signing should happen at the same time as the video and sound. There should be a way to turn the signing on and off if you don't need it.",
"passed_title": "Prerecorded videos have sign language interpretation.",
"dev_description": "WCAG 1.2.6 (Sign Language): Where video is used, provide sign language interpretation for synchronized media. This ensures that individuals who are deaf can access the information presented in the video. The sign language interpretation must be synchronized with the audio and video content, appearing within the same video player or as a separate, linked video. This allows deaf users to understand the content by watching the sign language interpretation.",
"layman_description": "If a video is shown, it should also have a person signing what's being said. This helps people who are deaf understand the video. Imagine watching a news report but you can't hear. If there's someone signing, you can still understand what's going on.",
"how_to_test": "1. Find media: Locate any prerecorded video or audio-only content on your webpage that includes spoken language.\n 2. Look for interpretation:\n - In the video: Check if there is a sign language interpreter visible within the video frame itself (often in a corner or alongside the main speaker) \n - Separate option: Look for an option in the media player controls or alongside the content to enable a separate, synchronized video stream showing a sign language interpreter.\n 3. Verify content: If an interpretation is present, confirm that it accurately conveys the meaning of the spoken content and synchronizes well with the original media.\n 4. Evaluate: If prerecorded media with audio does not offer a sign language interpretation (either integrated or as a separate option), it fails this Level AAA check."
},
{
"rule_id": "nonaxe-extended-audio-description-prerecorded",
"standard_code": "1.2.7",
"Notes": "Extended audio description for videos. Can pause the video if description requires more time\nFail if the narrator doesn’t explain the video in detail so that a blind user is not able to understand it\nPass if the audio description explains the situation in detail\n\nUsed when standard audio descriptions can’t fit between dialogue\n\nSolution: Pause the video and insert extra narration to describe visuals\n\nTypically delivered via a separate version of the video",
"issue_severity": "minor",
"wcag_version_number": 2,
"wcag_level": "AAA",
"affected_disabilities_json": "Blind | Low vision",
"help": "Provide extended spoken descriptions of the visual content in videos.",
"title": "Prerecorded videos lack extended audio descriptions where needed",
"dev_help": "1. Identify video content lacking sufficient audio pauses for effective audio descriptions.\n 2. Create an extended audio description version of the video. This can be done by:\n a. Adding pauses to the video to allow more detailed audio description to be inserted.\n b. Providing a separate audio track with extended audio descriptions that can be played alongside the video.\n 3. Ensure the user can easily access and activate the extended audio description version. This might involve:\n a. Providing a clear link or button labeled 'Extended Audio Description'.\n b. Offering the extended audio description version as an alternative video file.\n Example: If a scene shows a character entering a room and interacting with objects, and the original audio only says 'He entered the room', the extended audio description might say 'He entered a dimly lit room, carefully stepping over scattered toys. He then reaches out and touches a vase on a nearby table.'",
"help_url": "https://www.w3.org/WAI/WCAG22/Understanding/extended-audio-description-prerecorded.html",
"description": "Videos can be played with more detailed audio descriptions.",
"layman_help": "1. Watch the video and ask yourself: Does the narrator describe everything important happening on the screen in enough detail, especially for someone who can't see it? Are there enough pauses in the audio for these descriptions?\n 2. If not, you need to create a version with extra descriptions. You can do this by:\n a. Adding pauses to the video so the narrator can describe things more fully.\n b. Creating a separate audio track with extra descriptions that can be played with the video.\n 3. Make sure it's easy to find and use this extra-description version. For example, add a button that says 'Watch with Audio Descriptions' or offer it as a separate video option.",
"passed_title": "Prerecorded videos have extended audio descriptions when needed.",
"dev_description": "WCAG 1.2.7 (Extended Audio Description (Prerecorded)) requires that prerecorded video content provides extended audio descriptions when the pauses in the original audio are insufficient to allow audio descriptions to convey the sense of the video. This means that if a video has important visual information and the existing audio track doesn't have natural pauses long enough to insert descriptions that explain what's happening visually, an extended audio description version should be provided. This might involve pausing the video to allow more detailed audio description to be added, or a separate audio track with such descriptions.",
"layman_description": "Imagine watching a video where important things are happening visually, but the narrator doesn't explain them well enough or quickly enough for someone who can't see the screen. WCAG 1.2.7 makes sure that if the video doesn't have enough pauses in the audio to explain what's happening visually, there's a way to watch the video with extra descriptions. This is like having someone describe the scene in detail, even if it means the video needs to pause to allow for a longer explanation. This helps people with visual impairments fully understand and enjoy the video content.",
"how_to_test": "1. Identify complex videos: Find prerecorded videos on your site that have a lot of visual information happening quickly or where there are very few natural pauses in the dialogue or main audio.\n 2. Check standard AD first: Confirm if a standard audio description (as required by SC 1.2.5) is provided and if it adequately describes the essential visual content within the existing pauses.\n 3. Look for an \"Extended\" version: If the standard pauses seem too short to convey all necessary visual details, look for an alternative version of the video or a setting specifically labeled \"Extended Audio Description\" or similar.\n 4. Test the extended version: If an extended version is available, play it.\n - Does the video pause at points where significant visual information needs description?\n - Is a more detailed audio description provided during these pauses?\n - Does the video then resume smoothly?\n 5. Evaluate: If a video needs more description time than the natural pauses allow, but no extended audio description version is provided, it fails this Level AAA check."
},
{
"rule_id": "nonaxe-media-alternative-prerecorded",
"standard_code": "1.2.8",
"Notes": "For prerecorded video with audio\n\nProvide a full text alternative that describes:\n\nAll dialogue, Visual content, Sounds, music, and context & Scene changes and actions\n\n✅ Usually a detailed HTML transcript\n✅ Covers everything someone would see or hear\n\nGoal: Let users read the full experience of the video without needing to see or hear it.",
"issue_severity": "minor",
"wcag_version_number": 2,
"wcag_level": "AAA",
"affected_disabilities_json": "Blind | Low vision | Cognitive",
"help": "Provide a text equivalent for all content in videos.",
"title": "Prerecorded media lacks a full text alternative",
"dev_help": "1. Identify all significant visual information in the video that is not conveyed through the existing audio.\n 2. Record a separate audio track that describes these visual elements (e.g., \"The protagonist enters the room, looking worried.\").\n 3. Synchronize the audio description with the video so that it plays during pauses in dialogue or when there are no other important sounds.\n 4. Provide the audio description directly in the video, or as a separate audio track that users can select.\n 5. If audio description is not feasible, provide a text transcript that includes detailed descriptions of the visual elements. For example, if a character points to a map, the transcript should describe the map's key features and location.\n Example: For a cooking video, the audio description should describe the texture and color of food when the chef prepares and plates the dish.",
"help_url": "https://www.w3.org/WAI/WCAG22/Understanding/media-alternative-prerecorded.html",
"description": "Precorded videos can be understood by more people.",
"layman_help": "1. Watch the video and think about what's happening visually that someone who can't see wouldn't understand.\n 2. Add someone talking during the video, describing the important visual parts. It's like having a friend explain what's happening on screen.\n 3. Make sure the descriptions happen when nobody else is talking, so they don't overlap.\n 4. You can either add these descriptions directly into the video or have a separate audio track people can turn on.\n 5. If adding audio descriptions is too hard, write a text version of the video. Describe what's happening visually, so people can read it instead.",
"passed_title": "Prerecorded media have full text alternatives.",
"dev_description": "For prerecorded video content, provide audio descriptions of important visual information, including actions, gestures, scene changes, and on-screen text, so that users who are blind or have low vision can understand the content. If providing audio description is not feasible, provide a text transcript that includes the same information.",
"layman_description": "Imagine watching a movie where important things happen on screen, but no one describes them. People who can't see the screen (blind or low vision) would miss out on crucial parts of the story. This rule says that videos should have someone describing these visual elements so that everyone can understand what's happening, even if they can't see it. Think of it as someone explaining the visuals to them.",
"how_to_test": "1. Find prerecorded videos: Locate any prerecorded video content on your webpage.\n 2. Look for the text alternative: Check near the video player for a clearly labeled link, such as \"Text alternative for this video,\" \"Full text version,\" or \"Transcript and Description\".\n 3. Review the alternative: Open the text alternative and read it carefully.\n 4. Compare with the video: Does the text alternative accurately describe all essential information presented in the video? This includes:\n - All dialogue/narration?\n - Descriptions of important visual elements (actions, scenes, characters, expressions, on-screen text)?\n - Descriptions of important non-speech sounds (music, sound effects)?\n - Is it presented logically, following the video's sequence?\n - If the video includes interactive elements (like links or questions), does the text alternative provide an equivalent way to access them?\n 5. Evaluate: If a prerecorded video lacks a comprehensive text alternative covering all these aspects, it fails this Level AAA check."
},
{
"rule_id": "nonaxe-audio-only-live",
"standard_code": "1.2.9",
"Notes": "For live audio-only content (e.g. radio, live podcast)\n\nMust provide a real-time text version\n\nEx: CART service or live transcription feed\n\n✅ Required for deaf or hard of hearing users\n❌ A transcript after the event does not meet this requirement\n\nGoal: Allow users to follow live spoken content through synchronized text.",
"issue_severity": "minor",
"wcag_version_number": 2,
"wcag_level": "AAA",
"affected_disabilities_json": "deaf | deafBlind | Cognitive",
"help": "Provide a text equivalent for live audio-only content.",
"title": "Live audio-only content lacks a text description",
"dev_help": "1. Provide real-time captions for the live audio stream. These captions should accurately reflect the spoken content and any relevant sound effects. Consider using a professional captioning service for accuracy. 2. Offer a text transcript of the live audio. This transcript should be updated regularly to reflect the ongoing conversation. 3. Ensure the captions or transcript are easily discoverable and accessible from the same page or interface as the live audio stream. Example:",
"help_url": "https://www.w3.org/WAI/WCAG22/Understanding/audio-only-live.html",
"description": "Live audio can be understood by more people.",
"layman_help": "If you are making a live podcast or radio show available online, you should also provide captions or a written version (transcript) of what is being said. This way, people who cannot hear can still understand the content. Think of it as adding subtitles to a movie. You can either type out what is being said as it's happening (captions), or provide a complete written document of everything said after the show.",
"passed_title": "Live audio-only content has text descriptions.",
"dev_description": "WCAG 1.2.9 (Audio-only (Live)): A live audio-only presentation conforms to WCAG success criteria. Developers must ensure that live audio-only content, such as a podcast or live radio broadcast, provides an alternative for users who cannot hear the audio. This typically involves providing captions or a text transcript of the audio content. Without this alternative, deaf or hard of hearing users will be unable to access the information being presented.",
"layman_description": "Imagine listening to a live radio show or a podcast. If there are no captions or a written version (transcript) available, people who are deaf or hard of hearing can't understand what's being said. This rule ensures that live audio content is accessible to everyone, including those who can't hear the audio. It is like providing subtitles on a TV show, but for audio.",
"how_to_test": "1. Access the live audio: Go to the webpage or platform where the live audio-only content is being broadcast.\n 2. Look for text alternative: Search the page for a section displaying live text captions or a transcript that updates as the audio plays. This might be in a dedicated panel next to the audio player or linked nearby.\n 3. Watch and listen (and read): Observe the text feed while the live audio is playing.\n - Is the text updating in real-time or very close to it?\n - Does the text accurately reflect what is being said?\n - Does it include descriptions of important non-speech sounds?\n 4. Evaluate: If live audio-only content is presented without a synchronized, accurate text alternative, it fails this Level AAA check."
},
{
"rule_id": "th-has-data-cells",
"standard_code": "1.3.1",
"Notes": "Table headers should properly mention the scope (row/col)\nProvide id to the headers for complex table so that the table data can be associated with the header",
"issue_severity": "serious",
"wcag_version_number": 2,
"wcag_level": "A",
"affected_disabilities_json": "Blind | Low vision | Cognitive",
"help": "Table headers in a data table must refer to data cells",
"title": "Table header cells (<th>) are not associated with data cells",
"dev_help": "1. For simple tables, use the `scope` attribute on `<th>` elements to indicate whether the header applies to the column (`scope='col'`) or row (`scope='row'`).\n Example: `<th scope='col'>Name</th>`\n 2. For complex tables, use the `headers` attribute on `<td>` elements to associate them with the corresponding `<th>` elements via their `id` attributes. Each `<td>` element should list all the `id`s of the headers that apply to it.\n Example:\n \n 3. When using ARIA roles `role='columnheader'` or `role='rowheader'`, use `aria-describedby` to link the header cell with the data cells it describes. The `aria-describedby` attribute should point to the `id` of the header element.\n Example:\n \n 4. Ensure that every `<th>` element or element with `role='columnheader'` or `role='rowheader'` has a corresponding data cell associated with it.",
"help_url": "https://dequeuniversity.com/rules/axe/4.10/th-has-data-cells?application=axeAPI",
"description": "Ensure that <th> elements and elements with role=columnheader/rowheader have data cells they describe",
"layman_help": "1. If you have a simple table, make sure each heading says if it's labeling a column or a row.\n 2. If you have a complicated table, connect each piece of data to the heading that explains it. Think of it like labeling each item in a box with the name of the box.\n 3. If you're using special computer code to help describe the table, double-check that everything is connected properly. Make sure that every heading has data associated with it. This way, everyone can easily understand the table's information.",
"passed_title": "Table header cells (<th>) are associated with data cells.",
"dev_description": "This rule verifies that table header cells ( `<th>` elements) and elements with `role='columnheader'` or `role='rowheader'` are correctly associated with the data cells they describe. A proper association is crucial for assistive technologies to accurately convey the table structure and relationships to users. This association is typically achieved through the correct use of table markup, including `scope` attributes on `<th>` elements, or `aria-describedby` attributes when using ARIA roles. When a header cell is not correctly associated with its data cells, users of assistive technologies may not understand the context or meaning of the data presented in the table.",
"layman_description": "Imagine a spreadsheet where the headings tell you what each column or row means. This rule makes sure those headings are clearly connected to the right data in the table, especially for people who can't see the screen well. If the headings aren't linked correctly, it's like having labels that don't match the items – confusing for everyone, but particularly difficult for someone using a screen reader because they rely on these connections to understand the information.",
"how_to_test": null
},
{
"rule_id": "td-has-header",
"standard_code": "1.3.1",
"Notes": "Table data should be associated with a table header so that screen reader users can associate the data to the headers\nDo not use (invisible) table for layout\nUse for empty cells",
"issue_severity": "critical",
"wcag_version_number": 2,
"wcag_level": "A",
"affected_disabilities_json": "Blind | Low vision | Cognitive",
"help": "Non-empty <td> elements in larger <table> must have an associated table header",
"title": "Data cells (<td>) are not correctly associated with header cells",
"dev_help": "1. Use `<th>` elements for all table headers. 2. For simple tables, use the `scope` attribute on `<th>` elements to define the scope (e.g., `<th scope=\"col\">` for column headers, `<th scope=\"row\">` for row headers). 3. For complex tables, use the `headers` attribute on `<td>` elements to explicitly associate data cells with their corresponding headers (e.g., `<td headers=\"header1 header2\">`). Ensure that the `id` attributes on `<th>` elements match the values used in the `headers` attributes on `<td>` elements. 4. Do not use tables for layout. Use CSS for page layout. 5. If a table cell is intentionally empty, insert ` ` and ensure it still has appropriate header associations. Example:",
"help_url": "https://dequeuniversity.com/rules/axe/4.10/td-has-header?application=axeAPI",
"description": "Ensure that each non-empty data cell in a <table> larger than 3 by 3 has one or more table headers",
"layman_help": "If a website has a big table (like a spreadsheet), make sure each piece of information in the table has a clear title or label. This can be done by adding special tags to the table. Imagine each column and row has a heading that describes what the information is about. If you were building this table, make sure each cell (box) of information is clearly linked to its heading. This helps everyone, especially people using screen readers, understand what the table is about. If a cell is empty, make sure it is still linked to its headers.",
"passed_title": "Data cells (<td>) are correctly associated with header cells.",
"dev_description": "Ensure that each non-empty data cell in a `<table>` larger than 3x3 is associated with one or more table headers using the `<th>` element or the `headers` attribute on `<td>` elements. For tables with complex data relationships, use the `scope` attribute on `<th>` elements to define the scope of the header (e.g., `row`, `col`, `rowgroup`, `colgroup`). Avoid using tables for layout purposes; instead, use CSS for structuring content. Empty data cells should be indicated using ` ` or a similar non-breaking space if necessary, but should still be associated with headers. Verify that the relationships between data cells and headers are logical and clear.",
"layman_description": "Imagine a large spreadsheet-like table on a website. If you can't see the table well (or at all), it's like trying to understand a maze without knowing where you are or where you're going. This rule makes sure that every piece of information in the table has a clear label or heading. This helps people who use screen readers (which read the website aloud) to understand what each piece of data means. Without these labels, it's like reading random numbers and words with no context, making the table completely confusing, especially for people who are blind or have trouble understanding complex layouts. It is like reading a phone book where the names and phone numbers are not properly aligned.",
"how_to_test": null
},
{
"rule_id": "aria-required-parent",
"standard_code": "1.3.1",
"Notes": null,
"issue_severity": "critical",
"wcag_version_number": 2,
"wcag_level": "A",
"affected_disabilities_json": "Blind | Low vision | Cognitive | Mobility",
"help": "Certain ARIA roles must be contained by particular parents",
"title": "ARIA roles are used outside of required parent elements",
"dev_help": "1. Identify the ARIA role that is causing the error. The error message will indicate which role has an incorrect parent.\n 2. Consult the ARIA specification to determine the valid parent roles for the identified role.\n 3. Modify the HTML structure to ensure the element with the ARIA role is nested within a valid parent element. For example, if an element has `role='option'` but is not within an element with `role='listbox'`, `role='menu'`, or `role='tree'`, you must move the `option` element inside one of these valid parent elements.\n \n\n Example:\n Incorrect:\n \n Correct:",
"help_url": "https://dequeuniversity.com/rules/axe/4.10/aria-required-parent?application=axeAPI",
"description": "Ensure elements with an ARIA role that require parent roles are contained by them",
"layman_help": "Think of it like this: if you are creating a list of items, make sure all the list items are actually inside the list! If a list item is floating somewhere outside the list container, a screen reader might not recognize it as a part of the list. To fix this, put the item inside the correct container. So, if you have a menu option, ensure that option is inside the menu itself. Ask your website developer or designer to check the code and make sure that elements are correctly nested within their parent elements.",
"passed_title": "ARIA roles are used only within required parent elements.",
"dev_description": "This rule verifies that ARIA roles requiring specific parent roles are correctly nested within those parent roles. ARIA (Accessible Rich Internet Applications) roles define the type of user interface element. Some ARIA roles are designed to function only within a particular parent-child relationship. For example, an element with `role='option'` must be contained within an element with `role='listbox'`, `role='menu'`, or `role='tree'`. Failing to adhere to these structural requirements can cause assistive technologies to misinterpret the structure of the page, leading to accessibility issues.",
"layman_description": "Imagine a website as a building with different rooms (elements). Some elements need to be inside specific rooms to work correctly. For instance, if you have a list of options (like in a drop-down menu), each option (like 'apple', 'banana', 'orange') needs to be inside the container representing the drop-down list itself. If the option is not correctly placed inside the list, screen readers or other assistive technologies will not understand the options belong to that specific list. This creates a poor experience for people using assistive technology, such as screen readers, as they may not be able to navigate or understand parts of the page. Example: A menu option should be inside a menu to work correctly.",
"how_to_test": null
},
{
"rule_id": "td-headers-attr",
"standard_code": "1.3.1",
"Notes": null,
"issue_severity": "serious",
"wcag_version_number": 2,
"wcag_level": "A",
"affected_disabilities_json": "Blind | Low vision | Cognitive",
"help": "Table cells that use the headers attribute must only refer to cells in the same table",
"title": "Data cells are not linked to headers using the headers attribute",
"dev_help": "1. Identify tables using the `headers` attribute. \n 2. For each `<td>` element using the `headers` attribute, verify that all `id` values referenced in the `headers` attribute exist as `id` values on `<th>` elements within the same table. \n 3. Ensure that the relationships established by the `headers` attribute are logically correct and accurately reflect the table's structure. \n Example: \n \n In this example, the `headers` attribute of the `<td>` elements correctly reference the `id` values of the corresponding `<th>` elements within the same table.",
"help_url": "https://dequeuniversity.com/rules/axe/4.10/td-headers-attr?application=axeAPI",
"description": "Ensure that each cell in a table that uses the headers attribute refers only to other cells in that table",
"layman_help": "1. Find tables on the webpage that use special connections to link data to headings. These connections help assistive technology read the table correctly.\n 2. Check that all the links for each piece of data point to the correct headings in that same table. Make sure the links aren't pointing to headings in a different table.\n 3. Correct any wrong links, ensuring that all data is correctly linked to its heading within the table. This will help people using assistive technology understand the table correctly.",
"passed_title": "The headers attribute associates <td> with corresponding <th>.",
"dev_description": "Ensure that each cell in a table that uses the `headers` attribute refers only to other cells within the same table. The `headers` attribute establishes relationships between data cells (`<td>`) and header cells (`<th>`). Incorrect or cross-table references can lead to misinterpretation of the table's content by assistive technologies.",
"layman_description": "Imagine a spreadsheet where you use column and row headings to understand the data. This rule makes sure that if a table uses special links to connect data to those headings, all the links stay within the same table. If the links point to the wrong place, like a different table, people using screen readers or other assistive technology will get confused and might not understand the table's information correctly. It's like labeling the rows and columns of your spreadsheet wrong; then, it becomes confusing for everyone.",
"how_to_test": null
},
{
"rule_id": "aria-hidden-body",
"standard_code": "1.3.1",
"Notes": null,
"issue_severity": "critical",
"wcag_version_number": 2,
"wcag_level": "A",
"affected_disabilities_json": "Blind | Low vision | Cognitive | Mobility",
"help": "aria-hidden=\"true\" must not be present on the document body",
"title": "aria-hidden on <body> hides all content from assistive technologies",
"dev_help": "1. Remove the `aria-hidden=\"true\"` attribute from the `<body>` element. \n 2. If the intention was to hide specific sections of the page, ensure that only those sections are targeted with `aria-hidden=\"true\"`, and not the entire `<body>`.\n Example:",
"help_url": "https://dequeuniversity.com/rules/axe/4.10/aria-hidden-body?application=axeAPI",
"description": "Ensure aria-hidden=\"true\" is not present on the document body.",
"layman_help": "To fix this, you need to find the setting that's hiding the page and remove it. If the goal was to hide only specific things, make sure only those specific things are hidden, not the whole page.",
"passed_title": "The <body> element does not have aria-hidden=\"true\".",
"dev_description": "The `aria-hidden=\"true\"` attribute on the `<body>` element hides the entire content of the page from assistive technologies, such as screen readers. This prevents users who rely on these technologies from accessing any information or functionality on the page. This is almost always an error, as the main content should always be accessible.",
"layman_description": "Imagine someone using a screen reader to navigate a website. If the website developer accidentally puts a setting that hides the entire page from the screen reader, the user won't be able to hear or access anything on the site. This rule makes sure that important setting isn't active on the main section of the page, ensuring everyone can use the website.",
"how_to_test": null
},
{
"rule_id": "listitem",
"standard_code": "1.3.1",
"Notes": null,
"issue_severity": "serious",
"wcag_version_number": 2,
"wcag_level": "A",
"affected_disabilities_json": "Blind | Low vision | Cognitive | Mobility",
"help": "<li> elements must be contained in a <ul> or <ol>",
"title": "List items are not correctly nested within semantic list containers",
"dev_help": "1. Verify that all `<li>` elements are nested within a `<ul>`, `<ol>`, or `<menu>` element.\n 2. If an `<li>` element is found outside of a list container, refactor the code to use appropriate semantic HTML elements such as `<p>`, `<div>`, or `<span>` depending on the content's purpose. Use CSS to style the elements to match the desired presentation.\n Example:\n Incorrect:\n `<li class=\"nav-item\">Home</li>`\n Correct:\n `<ul><li>Home</li></ul>`",
"help_url": "https://dequeuniversity.com/rules/axe/4.10/listitem?application=axeAPI",
"description": "Ensure <li> elements are used semantically",
"layman_help": "1. Check if list items are used inside the list. List items (`<li>`) should only be used inside bullet point lists (`<ul>`) or numbered lists (`<ol>`).\n 2. If you find list items being used outside of a list, change them to another type of element like a `<div>` or `<p>`. Then, adjust the styling using CSS to make it look how it should. For example, If a list item is used for navigation, make sure it is inside a `<ul>` or `<ol>`.",
"passed_title": "List items are nested in semantic list containers.",
"dev_description": "Ensure that `<li>` elements are used semantically within `<ul>`, `<ol>`, or `<menu>` elements. `<li>` elements should only be used to represent items in a list. Using `<li>` elements outside of their intended context can confuse assistive technologies and impact the structure and navigation of the content. Semantic HTML provides meaning to the content and enables assistive technologies to correctly interpret and present the content to users with disabilities.",
"layman_description": "Make sure list items are correctly identified. List items (`<li>`) should always be inside proper lists (like bullet points `<ul>` or numbered lists `<ol>`). If you use list items for anything other than actual lists, it can confuse people using assistive technology like screen readers. These tools rely on the structure of the page to help people navigate and understand content. Using `<li>` elements incorrectly can make it harder for someone using a screen reader to understand the content.",
"how_to_test": null
},
{
"rule_id": "table-fake-caption",
"standard_code": "1.3.1",
"Notes": null,
"issue_severity": "serious",
"wcag_version_number": 2,
"wcag_level": "A",
"affected_disabilities_json": "Blind | Low vision | Cognitive",
"help": "Data or header cells must not be used to give caption to a data table.",
"title": "Data tables lack <caption> elements for proper titles",
"dev_help": "1. Identify data tables with captions: Locate all `<table>` elements on the page that have a descriptive title or summary.\n 2. Add the `<caption>` element: If a caption is missing, add it as the first child element of the `<table>`.\n 3. Ensure proper association: Verify that the `<caption>` element is correctly placed within the `<table>` tags, e.g., `<table><caption>Sales Figures for Q3 2024</caption>...</table>`.\n 4. Validate the code: Use an HTML validator to confirm that the `<caption>` element is properly nested and semantically correct.",
"help_url": "https://dequeuniversity.com/rules/axe/4.10/table-fake-caption?application=axeAPI",
"description": "Ensure that tables with a caption use the <caption> element.",
"layman_help": "1. Check if any tables on the website have a title or explanation.\n 2. If a table has a title, make sure it's clearly connected to the table. This usually involves adding the title right at the beginning of the table's code, using special tags.\n 3. If a table doesn't have a title but needs one to explain what it's about, add a short, descriptive title at the beginning of the table.",
"passed_title": "Data tables use <caption> elements for titles.",
"dev_description": "Ensure that all data tables using a caption element have the `<caption>` tag properly associated with the `<table>` element. The `<caption>` element provides a descriptive title or explanation for the table's content. This ensures that screen reader users and others can quickly understand the purpose and structure of the table.",
"layman_description": "If a table on a website has a title or summary (called a caption), this title must be clearly linked to the table. Imagine a table showing sales figures. The caption might be 'Sales Figures for Q3 2024.' Without a properly linked caption, people using screen readers (software that reads the screen aloud) might not understand what the table is about, making it difficult for them to grasp the information presented. This is like reading a book without a title or chapter headings.",
"how_to_test": null
},
{
"rule_id": "list",
"standard_code": "1.3.1",
"Notes": null,
"issue_severity": "serious",
"wcag_version_number": 2,
"wcag_level": "A",
"affected_disabilities_json": "Blind | Low vision | Cognitive",
"help": "<ul> and <ol> must only directly contain <li>, <script> or <template> elements",
"title": "Lists are not using proper semantic markup (<ul>, <ol>, <dl>)",
"dev_help": "1. Use <ul> for unordered lists (bullet points).\n 2. Use <ol> for ordered lists (numbered).\n 3. Ensure each list item is wrapped in an <li> tag.\n 4. Verify that list items are directly nested within <ul> or <ol>.\n \n\n Example of correct usage:\n \n\n \n \n\n Avoid:",
"help_url": "https://dequeuniversity.com/rules/axe/4.10/list?application=axeAPI",
"description": "Ensure that lists are structured correctly",
"layman_help": "If you are creating content for a website, make sure that when you create a list, you use the list features in your content editor. For bulleted lists, use the bullet point option. For numbered lists, use the numbered list option. This will make it easier for everyone to read and understand the content, especially for people who use assistive technologies.",
"passed_title": "Lists use proper <ul>, <ol>, or <dl> semantic markup.",
"dev_description": "Ensure that lists (ordered and unordered) are structured correctly using appropriate HTML list elements (<ul>, <ol>, <li>). The use of semantic HTML for lists allows assistive technologies to properly convey the structure and relationships between list items to users. Avoid using non-list elements (e.g., <div>, <p>) styled with CSS to mimic lists, as this can confuse assistive technology users. List items should be contained within list elements.",
"layman_description": "Imagine reading a recipe where the ingredients are listed without bullet points or numbers, just scattered in a paragraph. It would be hard to follow, right? Similarly, for people using screen readers (software that reads the screen aloud), if lists on a website aren't properly marked as lists, the screen reader can't announce them as lists. This makes it difficult for people with visual impairments or cognitive disabilities to understand the information and follow the content's flow. So, make sure all lists are properly formatted.",
"how_to_test": null
},
{
"rule_id": "p-as-heading",
"standard_code": "1.3.1",
"Notes": null,
"issue_severity": "serious",
"wcag_version_number": 2,
"wcag_level": "A",
"affected_disabilities_json": "Low vision | Cognitive",
"help": "Styled <p> elements must not be used as headings",
"title": "Headings use <p> tags instead of semantic heading elements",
"dev_help": "1. Replace <p> elements styled to look like headings with proper <h1> to <h6> heading elements.\n 2. Use CSS to style the heading elements as needed to match the design.\n \n\n Example:\n \n\n Instead of:\n <p style=\"font-size: 1.2em; font-weight: bold;\">Introduction</p>\n \n\n Use:\n <h2>Introduction</h2>\n \n\n Then, use CSS to style the <h2> element:\n h2 { font-size: 1.2em; font-weight: bold; }",
"help_url": "https://dequeuniversity.com/rules/axe/4.10/p-as-heading?application=axeAPI",
"description": "Ensure bold, italic text and font-size is not used to style <p> elements as a heading",
"layman_help": "1. Change the text that looks like a heading to use proper heading tags. These are like <h1>, <h2>, and so on. Your website developer can help you with this.\n 2. If you want the heading to look a certain way (like a particular size or font), use the website's styling options (CSS) to change how the heading tag looks. This keeps the structure clear for everyone.",
"passed_title": "Headings use semantic <h1>–<h6> elements instead of <p>.",
"dev_description": "Ensure that bold, italic text, and font-size styling are not used as the sole means to style <p> elements as headings. Headings should be marked up semantically using <h1> to <h6> elements. Using CSS to style <p> elements to look like headings can confuse assistive technology users and negatively impact the document's structure and navigation. It also impacts users who have custom stylesheets.",
"layman_description": "Don't make regular text paragraphs look like headings just by making them bold, italic, or bigger. Use proper heading tags (like <h1>, <h2>) for headings. If you only change the appearance of paragraph text, people using screen readers or other assistive technologies might not understand the page structure correctly, and it can be harder for everyone to navigate the content. For example, if a visually impaired person uses a screen reader and the heading is just bolded text, the screen reader will not recognize it as a heading.",
"how_to_test": null
},
{
"rule_id": "dlitem",
"standard_code": "1.3.1",
"Notes": null,
"issue_severity": "serious",
"wcag_version_number": 2,
"wcag_level": "A",
"affected_disabilities_json": "Blind | Low vision | Cognitive",
"help": "<dt> and <dd> elements must be contained by a <dl>",
"title": "Definition list items are missing <dt> and <dd> elements",
"dev_help": "1. Identify any instances where `<dt>` and `<dd>` elements are not enclosed within a `<dl>` element.\n 2. Wrap the related `<dt>` and `<dd>` elements within a `<dl>` element.\n \n\n Example of incorrect usage:\n \n \n\n Example of correct usage:",
"help_url": "https://dequeuniversity.com/rules/axe/4.10/dlitem?application=axeAPI",
"description": "Ensure <dt> and <dd> elements are contained by a <dl>",
"layman_help": "If you see a list of terms and definitions on a webpage, make sure they are properly grouped. Think of it like putting ingredients for a recipe together in a bowl. The 'definition list' tag is like the bowl that holds everything together. If the terms and definitions aren't in this 'bowl' (the definition list), a screen reader won't know they belong together. Ask the website developer to put the special 'definition list' tag around the terms and their definitions to make it easier for everyone to understand.",
"passed_title": "Definition list items use both <dt> and <dd> correctly.",
"dev_description": "The `<dt>` (definition term) and `<dd>` (definition description) elements should always be contained within a `<dl>` (definition list) element. This semantic structure provides crucial context for assistive technologies, enabling them to correctly interpret and convey the relationships between terms and their definitions. When `<dt>` and `<dd>` elements are used outside of a `<dl>`, the semantic meaning is lost, potentially causing confusion for users relying on screen readers or other assistive technologies. This rule ensures proper use of semantic HTML to create accessible definition lists.",
"layman_description": "Imagine a glossary or a dictionary where you have terms and their meanings. On a website, these are often marked up using special tags. This rule says that if you're using the tags for 'term' and 'definition', they must always be wrapped inside a 'definition list' tag. If they aren't, it's like writing a glossary without a title or clear structure. This can confuse people who use screen readers because the software won't understand how the terms and definitions are related. It's important to correctly group terms and definitions so everyone can understand the information easily.",
"how_to_test": null
},
{
"rule_id": "aria-required-children",
"standard_code": "1.3.1",
"Notes": null,
"issue_severity": "critical",
"wcag_version_number": 2,
"wcag_level": "A",
"affected_disabilities_json": "Blind | Low vision | Cognitive | Mobility",
"help": "Certain ARIA roles must contain particular children",
"title": "ARIA roles are missing required child elements",
"dev_help": "1. Identify the element with the ARIA role that requires specific child roles (e.g., 'listbox', 'radiogroup', 'menu'). 2. Check if the required child roles are present within the element (e.g., 'option' for 'listbox', 'radio' for 'radiogroup', 'menuitem' for 'menu'). 3. If the required child roles are missing, add them using appropriate HTML elements and ARIA roles. For example, if you have `<div role='listbox'></div>`, add `<div role='option'>Option 1</div>` inside the listbox. 4. Validate that the ARIA attributes are correctly applied and that the elements function as expected with assistive technologies. Example: `<ul role='menu'><li role='menuitem'>File</li></ul>`",
"help_url": "https://dequeuniversity.com/rules/axe/4.10/aria-required-children?application=axeAPI",
"description": "Ensure elements with an ARIA role that require child roles contain them",
"layman_help": "If a website element is supposed to be a certain kind of thing, like a 'menu', it needs to have all the right pieces, like 'menu items'. If it's missing those pieces, it's like a puzzle with missing parts. To fix this, add the missing pieces. If it's a menu, make sure it has menu items. If it's a list, make sure it has list items. This helps everyone understand and use the website correctly.",
"passed_title": "ARIA roles include all required child elements.",
"dev_description": "This rule verifies that elements with specific ARIA roles that require particular child roles actually contain those required child roles. For example, if an element has the role 'listbox', it should contain elements with the role 'option'. Similarly, a 'radiogroup' should contain 'radio' elements. Failure to provide the necessary child roles can lead to assistive technologies misinterpreting the structure and content, rendering the element inaccessible. The check ensures semantic correctness and proper interaction for users of assistive technologies.",
"layman_description": "Imagine a menu on a website. To work correctly for everyone, especially people using screen readers, the menu needs to be properly organized. This means if you say something is a 'menu', it must contain 'menu items'. If the 'menu' is missing its 'menu items', a person using a screen reader might not understand what they are looking at or how to use it. This rule makes sure that when something is labeled as a specific type of element (like a menu), it has all the necessary parts to work correctly for everyone, especially those with disabilities.",
"how_to_test": null
},
{
"rule_id": "definition-list",
"standard_code": "1.3.1",
"Notes": null,
"issue_severity": "serious",
"wcag_version_number": 2,
"wcag_level": "A",
"affected_disabilities_json": "Blind | Low vision | Cognitive",
"help": "<dl> elements must only directly contain properly-ordered <dt> and <dd> groups, <script>, <template> or <div> elements",
"title": "Definition lists are not structured with <dl>, <dt>, and <dd>",
"dev_help": "1. Verify that each `<dt>` element within a `<dl>` has at least one associated `<dd>` element.\n 2. Ensure that `<dl>` elements are used semantically for term-definition lists and not for layout purposes.\n 3. If a term doesn't have a definition, consider providing a placeholder definition or restructuring the content.\n Example:\n \n Incorrect Example:",
"help_url": "https://dequeuniversity.com/rules/axe/4.10/definition-list?application=axeAPI",
"description": "Ensure <dl> elements are structured correctly",
"layman_help": "If you see a list of terms and definitions on a website, make sure that each term actually has a definition. If a term is missing its definition, let the website owners know so they can fix it. A properly structured list will make it easier for everyone, especially people with visual impairments who use screen readers, to understand the content.",
"passed_title": "Definition lists correctly use <dl>, <dt>, and <dd> elements.",
"dev_description": "Ensure that definition lists (`<dl>`) are structured correctly. Each term (`<dt>`) should be paired with at least one corresponding definition (`<dd>`). A `<dl>` element should contain one or more `<dt>` elements, each followed by one or more `<dd>` elements. Avoid using `<dl>` for purposes other than marking up term-definition lists, as this can confuse assistive technologies.",
"layman_description": "Definition lists are used to present terms and their corresponding definitions. Imagine a glossary or a list of questions with their answers. This rule ensures that these lists are properly structured on websites. Each term should have at least one definition associated with it. If a definition list isn't structured correctly (for example, a term is missing its definition), people using screen readers might not understand the relationship between the term and its meaning, making it difficult for them to understand the content.",
"how_to_test": null
},
{
"rule_id": "nonaxe-meaningful-sequence",
"standard_code": "1.3.2",
"Notes": null,
"issue_severity": "moderate",
"wcag_version_number": 2,
"wcag_level": "A",
"affected_disabilities_json": "Blind | Low vision | Cognitive | Mobility",
"help": "Use code to preserve meaningful content order.",
"title": "Content does not follow a meaningful reading sequence",
"dev_help": "1. Review the HTML structure to ensure it follows a logical order.\n 2. Use semantic HTML elements (e.g., `<header>`, `<nav>`, `<main>`, `<article>`, `<aside>`, `<footer>`, `<h1>` to `<h6>`, `<p>`, `<ul>`, `<ol>`) to define content structure.\n 3. Check the reading order with CSS disabled to ensure the content still makes sense.\n 4. If CSS is used to reorder content, ensure the original HTML source order is still logical, or use ARIA to redefine relationships (though modifying the source order is preferable).\n 5. Use the 'tab' key to navigate the website and ensure focus order is logical.\n 6. Test with a screen reader to verify the reading order.\n Example: Instead of using CSS to visually place a sidebar before the main content, ensure the `<aside>` element comes before the `<main>` element in the HTML, or use ARIA landmarks if the visual order differs from the logical order for a specific reason.",
"help_url": "https://www.w3.org/WAI/WCAG22/Understanding/meaningful-sequence.html",
"description": "The order of content can be understood by more people.",
"layman_help": "1. Think about how you want someone to read the information on the page – like telling a story.\n 2. Make sure the important information comes first.\n 3. If you have different sections (like a sidebar), make sure they are in a logical order.\n 4. Imagine reading the page with your eyes closed (like a screen reader user) - does it still make sense?\n 5. Try using only the 'tab' key on your keyboard to move around the page. Does it go where you expect it to go?\n If not, you may need to change the order of the information on the page so that it is easier for everyone to understand.",
"passed_title": "Content follows a meaningful reading sequence.",
"dev_description": "Ensure that the order of content is logical and meaningful when linearised, such as when CSS is disabled, or when using a screen reader. This means the sequence of content should make sense even when presented in a single column. Use semantic HTML elements to define the structure of the content (e.g., headings, paragraphs, lists). ARIA attributes like `aria-labelledby` or `aria-describedby` can clarify relationships between elements when semantic HTML is insufficient. CSS should not be the only method used to convey the order of content. Content should be structured so that assistive technologies can present it in a predictable and logical way.",
"layman_description": "Imagine reading a book where the sentences are all mixed up. It would be very hard to understand, right? This rule is about making sure the information on a website is in a logical order. This is important for people who use screen readers (software that reads the website aloud) because they hear the content in the order it appears in the code. Also, people with cognitive disabilities might find it difficult to understand if the content is disorganized. If the order is wrong, it can be confusing and frustrating for them to navigate the website. It also affects people who cannot use a mouse and rely on keyboard navigation, as the keyboard focus should follow a logical path through the content.",
"how_to_test": "1. Simulate Reading Order: \n - Using a Screen Reader (Recommended): Start at the top of the page and listen as the screen reader reads through the content. Does it read headings, paragraphs, lists, images, links, etc., in an order that makes sense based on the visual layout? \n - Using Keyboard Navigation (Tab Key): Press the Tab key repeatedly to move through only the interactive elements (links, buttons, form fields). While this doesn't check the reading order of all content, it helps verify the focus order for interactive elements. Does the focus move logically (e.g., top to bottom, left to right in English)? Use Shift + Tab to move backward.\n - Using Browser Tools/Extensions: Some browser developer tools or accessibility extensions can visualize the reading order or DOM order, which often corresponds to the screen reader order.\n 2. Compare Visual vs. Reading Order: Does the sequence experienced through assistive technology match the visual layout and intended reading flow? \n 3. Look for Issues: Pay attention to:\n - Content presented in columns: Does the reading order go down one column before moving to the next, or does it jump confusingly across columns?\n - Source code order vs. visual layout (CSS positioning): Content might look like it's in one place visually but exist elsewhere in the code, affecting the reading order.\n 4. Evaluate: If the reading order doesn't follow a logical sequence that matches the visual presentation and preserves the meaning of the content, it fails this check."
},
{
"rule_id": "nonaxe-sensory-characteristics",
"standard_code": "1.3.3",
"Notes": null,
"issue_severity": "moderate",
"wcag_version_number": 2,
"wcag_level": "A",
"affected_disabilities_json": "Cognitive | Low vision | Blind",
"help": "Describe controls by name, not just by appearance or location.",
"title": "Instructions rely only on shape, size, or location cues",
"dev_help": "1. Avoid Sensory-Only Instructions: Do not rely solely on sensory characteristics like color, shape, size, or sound to convey information or instructions.\n 2. Provide Textual Alternatives: Offer textual descriptions or labels that provide the same information conveyed through sensory characteristics. For example, instead of saying 'Click the green button,' say 'Click the green button labeled 'Submit''.\n 3. Use ARIA Attributes: If sensory characteristics are unavoidable, use ARIA attributes to provide additional context and meaning. For instance, `aria-describedby` can link a description to an element that clarifies its purpose without relying on color alone.\n 4. Ensure Sufficient Contrast: When color is used, ensure sufficient color contrast between the text and background, as defined by WCAG guidelines.\n 5. Test with Assistive Technologies: Always test your content with screen readers and other assistive technologies to ensure that instructions are conveyed effectively.",
"help_url": "https://www.w3.org/WAI/WCAG22/Understanding/sensory-characteristics.html",
"description": "Instructions are understandable by more people.",
"layman_help": "1. Don't Just Rely on Sight or Sound: When you give instructions, don't only talk about colors, shapes, or sounds. Some people might not be able to see or hear these things.\n 2. Use Words to Describe Things: If you say 'Click the blue button,' also say something like 'Click the button that says 'Submit''. This way, even if someone can't see the color, they know which button to click.\n 3. Make Sure Colors Stand Out: If you use colors, make sure they're easy to see. For example, don't use light gray text on a white background.\n 4. Test with Others: Ask someone who uses a screen reader (a program that reads the screen aloud) to try using your website or app. This will help you make sure that your instructions are clear for everyone.",
"passed_title": "Instructions do not rely solely on sensory characteristics.",
"dev_description": "WCAG 1.3.3 (Sensory Characteristics): Instructions provided for understanding and operating content should not rely solely on sensory characteristics of components such as shape, size, visual location, orientation, or sound. This means that if you're instructing a user, you can't rely on them being able to see a certain color, hear a sound, or understand the shape of an object. Provide alternative ways for users to understand the content if they cannot perceive these characteristics.",
"layman_description": "Imagine trying to follow instructions that say, 'Click the blue button on the right.' What if you're colorblind and can't tell which button is blue? Or what if you're blind and can't see the button at all? This rule means instructions should be clear for everyone, no matter how they perceive the world. Instructions shouldn't only rely on things like color, sound, or location, as these senses may not be accessible to everyone.",
"how_to_test": "1. Scan for sensory-based instructions: Read through your webpage content. Look for instructions or descriptions that rely only on:\n - Shape: \"Click the triangle icon.\"\n - Size: \"Find the largest heading.\"\n - Visual Location: \"Use the menu on the left.\"\n - Orientation: \"Turn your phone sideways.\"\n - Sound: \"Wait for the confirmation chime.\"\n 2. Check for alternatives: For each instance found, determine if the instruction also includes non-sensory information or multiple sensory cues. Examples:\n - Is the \"triangle icon\" also labeled with text (e.g., \"Next Page\")?\n - Is the \"menu on the left\" also identifiable by a heading like \"Main Navigation\"?\n - Is the \"confirmation chime\" accompanied by a visible message like \"Success!\"?\n 3. Use text identification: Ensure instructions refer to elements by their visible text label (like a button's text or a section's heading) whenever possible, as this is easily discoverable by assistive technologies.\n 4. Evaluate: If instructions rely only on a single sensory characteristic (shape, size, location, orientation, or sound) without providing an alternative way to identify the target, the check fails."
},
{
"rule_id": "css-orientation-lock",
"standard_code": "1.3.4",
"Notes": null,
"issue_severity": "serious",
"wcag_version_number": 2.1,
"wcag_level": "AA",
"affected_disabilities_json": "Mobility | Low vision | Cognitive",
"help": "CSS Media queries must not lock display orientation",
"title": "Content does not work in both portrait and landscape views",
"dev_help": "1. Identify any content or functionality that is locked to a specific display orientation.\n 2. Remove any CSS or JavaScript code that forces a particular orientation.\n 3. Ensure that the website or application responds appropriately to changes in orientation.\n 4. Test the content in both portrait and landscape orientations to verify that all functionality is available and content is readable.\n Example: Avoid using CSS like `screen.orientation.lock('portrait');` or similar JavaScript methods that prevent orientation changes.",
"help_url": "https://dequeuniversity.com/rules/axe/4.10/css-orientation-lock?application=axeAPI",
"description": "Ensure content is not locked to any specific display orientation, and the content is operable in all display orientations",
"layman_help": "1. Check if the website or app forces you to hold your device in a certain way (like only upright).\n 2. If it does, the developers need to remove the setting that locks the screen.\n 3. The website or app should automatically adjust when you turn your device.\n 4. Try using the website or app in both positions (upright and sideways) to make sure everything works correctly.",
"passed_title": "Content functions correctly in portrait and landscape.",
"dev_description": "Ensure that content and functionality are operable and viewable in all display orientations (portrait or landscape), unless a specific orientation is essential. Locking content to a single display orientation can create accessibility barriers for users with motor impairments, low vision, or cognitive disabilities who rely on specific orientations for optimal use.",
"layman_description": "Imagine someone who uses a wheelchair with a mounted device or someone with low vision who finds it easier to view content in a specific screen orientation. If a website or app forces a particular orientation (like only allowing portrait mode), it can be very difficult or impossible for these users to access the content. This rule makes sure that websites and apps work properly no matter how someone holds their device, unless there's a very good reason for it to be fixed.",
"how_to_test": null
},
{
"rule_id": "autocomplete-valid",
"standard_code": "1.3.5",
"Notes": null,
"issue_severity": "serious",
"wcag_version_number": 2.1,
"wcag_level": "AA",
"affected_disabilities_json": "Cognitive | Mobility | Low vision",
"help": "autocomplete attribute must be used correctly",
"title": "Input purpose is not specified programmatically for form fields",
"dev_help": "1. Identify the purpose of the form field: Determine what type of information the field is requesting (e.g., name, email, address). \n 2. Choose an appropriate `autocomplete` value: Use a valid `autocomplete` value that matches the field's purpose. Refer to the HTML specification for a list of valid values (e.g., `name`, `email`, `address-level1`, `postal-code`).\n 3. Apply the `autocomplete` attribute to the input element: Add the `autocomplete` attribute to the `<input>`, `<textarea>`, or `<select>` element and set its value accordingly.\n 4. Test with assistive technologies: Verify that the `autocomplete` attribute is correctly interpreted by browsers and assistive technologies.\n \n\n Example:",
"help_url": "https://dequeuniversity.com/rules/axe/4.10/autocomplete-valid?application=axeAPI",
"description": "Ensure the autocomplete attribute is correct and suitable for the form field",
"layman_help": "1. When filling out a form, think about what kind of information is being asked for in each box (like your name, email, or address).\n 2. Use the right 'remembering' code for each box. For example, use the 'name' code for your name box, 'email' code for your email box, and 'address' code for your address box. \n 3. Add this 'remembering' code to the form's programming, so the website knows what kind of information to remember for each box.\n 4. Check to make sure this 'remembering' feature works correctly on different browsers and devices.",
"passed_title": "Form fields have programmatic input purpose specifications.",
"dev_description": "The `autocomplete` attribute on form fields provides instructions to the browser on how to pre-fill the field. Using appropriate and valid `autocomplete` values can significantly improve the user experience, especially for users with cognitive or motor impairments. Incorrect or missing `autocomplete` attributes can force users to manually enter information that could have been automatically populated, leading to frustration and potential errors. This rule checks that the `autocomplete` attribute is present, valid, and semantically appropriate for the form field's purpose. For example, a name field should use `autocomplete='name'`, and an email field should use `autocomplete='email'.",
"layman_description": "Imagine filling out a form online, and the website remembers your address or name and fills it in for you automatically. That's what the `autocomplete` feature does. This rule makes sure that websites use this feature correctly. If it's not used right, people with disabilities, especially those who have trouble remembering things or typing, will have a much harder time filling out the form. It forces them to type everything manually, which can be frustrating and lead to mistakes. Making sure the `autocomplete` feature is used correctly helps everyone fill out forms more easily and quickly.",
"how_to_test": null
},
{
"rule_id": "nonaxe-identify-purpose",
"standard_code": "1.3.6",
"Notes": null,
"issue_severity": "moderate",
"wcag_version_number": 2.1,
"wcag_level": "AAA",
"affected_disabilities_json": "Cognitive | Low vision | Mobility",
"help": "Use code to indicate the meaning of all controls and other key information, where available.",
"title": "Purpose of user interface components is not specified programmatically",
"dev_help": "1. Use semantic HTML elements (e.g., `<button>`, `<nav>`, `<aside>`) that inherently convey their purpose.\n 2. For custom UI components, use ARIA attributes (e.g., `aria-label`, `aria-labelledby`, `aria-describedby`, `role`) to define the purpose and state of the component.\n 3. Provide text alternatives for icons using the `alt` attribute for `<img>` tags or `aria-label` for icon fonts or SVGs.\n 4. Ensure that the purpose of each region on the page (e.g., main content, navigation, banner) is programmatically identifiable using landmark roles (e.g., `<main role=\"main\">`, `<nav role=\"navigation\">`).\n Example: `<button aria-label=\"Close\">X</button>`",
"help_url": "https://www.w3.org/WAI/WCAG22/Understanding/identify-purpose.html",
"description": "It is easier to operate and navigate content.",
"layman_help": "1. Use clear and descriptive labels for all buttons, links, and other interactive elements.\n 2. If you use icons, make sure they have text labels or descriptions that explain what they do.\n 3. Divide the page into logical sections, like a main content area, a navigation menu, and a sidebar, and make sure each section has a clear heading or label.\n 4. Test your website with assistive technologies, like screen readers, to make sure the purpose of each element is clear.",
"passed_title": "UI components have programmatic purpose specifications.",
"dev_description": "Ensure that the purpose of User Interface components, icons, and regions can be programmatically determined by assistive technologies or is available in text. This allows users to understand the function of elements and navigate content effectively. For example, the purpose of an icon must be programmatically exposed (using ARIA attributes or semantic HTML) so that assistive technologies can convey its meaning to users.",
"layman_description": "Make sure it's easy to figure out what each button, icon, or section on a website or app is for. This helps people who have trouble understanding layouts or using a mouse or keyboard. Imagine if icons on a website didn't have labels and you had to guess what each one did; that would be frustrating. This rule makes sure everything has a clear purpose, so everyone can use the site without confusion.",
"how_to_test": "1. Use Browser Developer Tools: Right-click on different key areas of the page (header, navigation, main content area, sidebars, forms, common input fields like name/address) and select \"Inspect\" or \"Inspect Element\".\n 2. Check for Semantic HTML: Look at the HTML code for these areas. Are appropriate HTML5 elements used to convey purpose? Examples:\n - <nav> for navigation blocks.\n - <main> for the primary content of the page.\n - <aside> for complementary content (like sidebars).\n - <header>, <footer> for page header and footer.\n - <form> for forms.\n - <input> with appropriate type attributes (e.g., type=\"search\", type=\"email\", type=\"tel\").\n 3. Check for ARIA Landmarks: If generic elements like <div> are used for major regions, look for ARIA role attributes that define their purpose. Examples:\n - role=\"navigation\"\n - role=\"main\"\n - role=\"complementary\" (for aside)\n - role=\"banner\" (for header)\n - role=\"contentinfo\" (for footer)\n - role=\"search\"\n 4. Check Input Field Purpose (Autocomplete): For form fields collecting common user information (name, address, email, phone, etc.), check if the autocomplete attribute is used with appropriate values (e.g., autocomplete=\"name\", autocomplete=\"street-address\", autocomplete=\"email\"). This helps assistive technology identify the expected data type.\n 5. Evaluate: The page passes if common regions and controls use appropriate semantic HTML or ARIA roles to clearly identify their purpose, and standard input fields use the autocomplete attribute correctly. The absence of these semantic markers makes it harder for assistive technology to enable personalization and understand the page structure, thus failing the check."
},
{
"rule_id": "link-in-text-block",
"standard_code": "1.4.1",
"Notes": null,
"issue_severity": "serious",
"wcag_version_number": 2,
"wcag_level": "A",
"affected_disabilities_json": "Low vision | Color Blindness | Cognitive",
"help": "Links must be distinguishable without relying on color",
"title": "Color is used as the only visual cue to convey information",
"dev_help": "1. Check the contrast ratio between link text and surrounding text. While not strictly required by this rule, sufficient contrast is always good practice. 2. Ensure that links have a visual indicator beyond just color. This is commonly achieved by: a. Adding an underline to links (e.g., `a { text-decoration: underline; }`). b. Changing the font-weight on hover or focus (e.g., `a:hover, a:focus { font-weight: bold; }`). c. Adding an icon next to the link. 3. Test your design with a color blindness simulator to ensure links are still distinguishable for users with color vision deficiencies. Example:",
"help_url": "https://dequeuniversity.com/rules/axe/4.10/link-in-text-block?application=axeAPI",
"description": "Ensure links are distinguished from surrounding text in a way that does not rely on color",
"layman_help": "To make links easier to see: 1. Make sure links have something other than just a different color to show they are links, like an underline. 2. If the link changes when you hover over it, that can also help. If you can't tell colors apart, you'll still know what to click.",
"passed_title": "Color is not the only visual cue conveying information.",
"dev_description": "Ensure that links are visually distinguishable from surrounding non-link text without relying solely on color. This typically involves providing an additional visual cue, such as an underline, a change in font-weight, or an icon. This ensures that users who cannot perceive color differences can still identify links.",
"layman_description": "Links should be easily identifiable on a webpage, even if you can't see colors properly. Imagine if all the words on a page were blue, and some of them were links. If you couldn't tell the difference between shades of blue, you wouldn't know which words you could click on. To fix this, links should have something else to show they are links, like an underline.",
"how_to_test": null
},
{
"rule_id": "nonaxe-reflow",
"standard_code": "1.4.10",
"Notes": null,
"issue_severity": "moderate",
"wcag_version_number": 2.1,
"wcag_level": "AA",
"affected_disabilities_json": "Low vision | Cognitive | Mobility",
"help": "Make lines of text reflow within the viewport.",
"title": "Content needs two-way scrolling and loses info on small screens",
"dev_help": "1. Use relative units like percentages, ems, rems, or viewport units (vw, vh) for width and height properties instead of fixed units like pixels.\n Example: `width: 100%;` or `width: 50vw;`\n 2. Avoid using `min-width` and `max-width` properties that can restrict content from reflowing properly. If you must use them, ensure that the maximum width is large enough to accommodate a 400% zoom level or text resize.\n 3. Use CSS media queries to adjust the layout and font sizes for different screen sizes and zoom levels. This allows you to create a responsive design that adapts to various viewport sizes.\n Example: `@media (max-width: 600px) { / Styles for smaller screens / }`\n 4. Test your website at 400% zoom level or 200% text resize in different browsers to ensure that the content reflows correctly and no information is lost or truncated.\n 5. Use flexible layout techniques like Flexbox or Grid to create layouts that automatically reflow and adapt to different screen sizes.\n Example (Flexbox): `.container { display: flex; flex-wrap: wrap; }`\n Example (Grid): `.container { display: grid; grid-template-columns: repeat(auto-fit, minmax(200px, 1fr)); }`",
"help_url": "https://www.w3.org/WAI/WCAG22/Understanding/reflow.html",
"description": "Content can be enlarged without increasing line length.",
"layman_help": "1. Make sure the website automatically adjusts to different screen sizes. Think of it like clothing that stretches to fit different body sizes.\n 2. Avoid setting fixed widths for content areas. Instead, let them expand or shrink as needed. It's like using elastic waistbands instead of rigid belts.\n 3. Use special instructions (media queries) to tell the website how to rearrange itself when the screen gets smaller or when someone zooms in.\n 4. Test the website by zooming in to 400% to see if you need to scroll left and right. If you do, something needs to be fixed.\n 5. Design the website with flexible layouts (like Flexbox or Grid) so that the content can easily move around and adjust to fit the screen, no matter how zoomed in it is.",
"passed_title": "Content reflows to avoid two-dimensional scrolling.",
"dev_description": "Content should be structured so that when the viewport is zoomed to 400% (or the text is resized to 200% in browsers that support text resizing), the content reflows to fit the viewport without requiring horizontal scrolling. Information should not be lost, and functionality should remain operable. Avoid fixed-width layouts that force horizontal scrolling at high zoom levels. Use relative units (e.g., percentages, ems, rems, or viewport units) for widths and other dimensions to allow content to adapt to different screen sizes and zoom levels. Ensure that text containers expand to accommodate larger text sizes without overlapping or truncation.",
"layman_description": "Imagine trying to read a website, but when you zoom in to make the text bigger, parts of the content disappear off the side of the screen, forcing you to scroll left and right constantly to read each line. This rule ensures that when you zoom in (up to 400%), the website content rearranges itself to fit your screen without making you scroll horizontally. This is especially helpful for people with low vision or cognitive disabilities, as it allows them to comfortably read and navigate the site without struggling with horizontal scrolling. If a website doesn't follow this rule, it makes it unnecessarily difficult for people who need larger text or zoomed-in views to access the information.",
"how_to_test": "1. Simulate Narrow Width: Choose one of these methods:\n i. Method A: Adjust Browser Width: On a desktop browser, make the window very narrow (aim for roughly 320px wide). You can use browser developer tools for exact sizing if needed.\n ii. Method B: Use Browser Zoom: On a desktop browser, zoom the page view in to 400%. (Hold Ctrl and press '+', or Cmd and '+').\n iii. Method C: Use Device Mode: Use browser developer tools to simulate a small mobile device (like an iPhone SE, which is 320px wide).\n 2. Check for Horizontal Scrolling: In this narrow view or zoomed-in state:\n i. Read through the main text content. Do you need to scroll horizontally (left/right) to read full lines of text?\n ii. Look at buttons, links, and form fields. Can you see and use them without scrolling horizontally?\n 3. Identify Exceptions: Note any content that inherently requires two dimensions (maps, data tables, specific diagrams). Is horizontal scrolling only confined to these specific components, while the rest of the page reflows?\n 4. Evaluate:\n - Pass: All content reflows to fit the narrow width (e.g., into a single column). No horizontal scrolling is needed to read text or use controls, except potentially within specific components like maps or data tables.\n - Fail: You need to scroll horizontally back and forth to read lines of text or access controls that aren't part of an excepted component type."
},
{
"rule_id": "nonaxe-non-text-contrast",
"standard_code": "1.4.11",
"Notes": null,
"issue_severity": "moderate",
"wcag_version_number": 2.1,
"wcag_level": "AA",
"affected_disabilities_json": "Low vision | Color Blindness | Cognitive",
"help": "Ensure meaningful visual cues achieve 3:1 against the background.",
"title": "Non-text elements lack sufficient contrast against adjacent colors",
"dev_help": "1. Identify all non-text content providing information or functionality (e.g., icons, graphical controls, charts). 2. Use a color contrast analyzer tool to verify that the contrast ratio between the non-text content and its adjacent background is at least 3:1. 3. If the contrast ratio is insufficient, adjust the colors of the non-text content or background to meet the 3:1 ratio. Example: If a gray icon (#767676) on a slightly lighter gray background (#808080) fails the contrast check, change the icon to a darker shade of gray or the background to a lighter shade to achieve sufficient contrast.",
"help_url": "https://www.w3.org/WAI/WCAG22/Understanding/non-text-contrast.html",
"description": "Important visual information meets the same minimum contrast required for larger text.",
"layman_help": "1. Check if important visual elements like icons and buttons are easy to see against their background. 2. If they seem hard to distinguish, the contrast might not be strong enough. 3. Change the colors of these elements or the background to make them stand out more clearly. For example, make a dark icon on a light background, or a light icon on a dark background.",
"passed_title": "Non-text elements have sufficient contrast against adjacent colors.",
"dev_description": "Ensure that all non-text contrast elements, such as icons, graphical controls, and charts, have a contrast ratio of at least 3:1 against adjacent colors. This ensures that users with low vision or color deficiencies can distinguish these elements. This rule applies to any visual information required to understand or operate the content. For purely decorative graphics, this rule does not apply.",
"layman_description": "Important visual information, like icons or buttons, needs to be clearly visible. This means they must stand out enough from the background so people with low vision or color blindness can easily see and understand them. If the contrast isn't strong enough, these elements can be difficult or impossible to see, making it hard to use the website or app. Imagine a gray button on a slightly darker gray background – it might look fine to some, but be invisible to others.",
"how_to_test": "1. Identify key non-text visuals: Look for:\n - UI Components: Borders/outlines of input fields, buttons, checkboxes, radio buttons, dropdown arrows, sliders, etc.\n - Component States: Visual indicators of state (e.g., the check in a checkbox, the dot in a selected radio button, the focus outline around an active element).\n - Graphical Objects: Icons that convey information (not purely decorative ones). Important parts of charts, graphs, or diagrams needed for understanding (e.g., pie slices, axis lines, bars).\n 2. Use a Contrast Tool: Select a color contrast analyzer tool (many browser extensions or standalone tools are available). Ensure it can measure contrast for non-text elements or allow you to use an eyedropper tool.\n 3. Measure Contrast: For each identified element:\n - Use the tool's eyedropper to select the color of the element itself (e.g., the color of the input border, the icon color, the pie slice color).\n - Use the eyedropper to select the color of the immediate adjacent background.\n - Calculate the contrast ratio.\n 4. Verify Ratio: Check if the contrast ratio is at least 3:1.\n 5. Check Focus Indicators: Specifically use the Tab key to navigate through interactive elements. Check that the focus indicator (the outline or highlight that appears) has a 3:1 contrast ratio against the background it sits on.\n 6. Check Boundaries: For adjacent colors in graphics (like slices in a pie chart), check that the contrast between the adjacent colors is at least 3:1, OR that there is a border line between them that itself has 3:1 contrast against both colors.\n 7. Evaluate: If any essential UI component, state indicator, graphical object, or focus indicator fails to meet the 3:1 contrast ratio against its adjacent background, the check fails."
},
{
"rule_id": "avoid-inline-spacing",
"standard_code": "1.4.12",
"Notes": null,
"issue_severity": "serious",
"wcag_version_number": 2.1,
"wcag_level": "AA",
"affected_disabilities_json": "Low vision | Cognitive",
"help": "Inline text spacing must be adjustable with custom stylesheets",
"title": "Text becomes unreadable or content is lost when spacing is increased",
"dev_help": "1. Use relative units (em, rem, %) for line-height, letter-spacing, word-spacing, and margin properties instead of absolute units (px).\n 2. Test that text spacing can be adjusted using browser developer tools by simulating user stylesheets.\n 3. Avoid using !important in CSS rules related to text spacing, as it can prevent users from overriding the styles.\n Example:\n Correct: `p { line-height: 1.5em; letter-spacing: 0.1em; }`\n Incorrect: `p { line-height: 20px; letter-spacing: 2px; }`",
"help_url": "https://dequeuniversity.com/rules/axe/4.10/avoid-inline-spacing?application=axeAPI",
"description": "Ensure that text spacing set through style attributes can be adjusted with custom stylesheets",
"layman_help": "1. The website should be built so that the spacing around the words and lines can be made bigger or smaller.\n 2. You should be able to change the spacing in your browser's settings or by using a special tool that changes the way the website looks.\n 3. The website creators shouldn't block you from making these changes.",
"passed_title": "Text remains readable and intact when spacing increases.",
"dev_description": "Ensure that text spacing properties (line height, letter spacing, word spacing, and paragraph spacing) defined through CSS can be overridden or adjusted by users via custom stylesheets. This allows users with low vision or cognitive disabilities to customize text presentation for improved readability and comprehension. Avoid using fixed units (e.g., pixels) that prevent scaling. Use relative units (e.g., em, rem, percentages) for text spacing.",
"layman_description": "Make sure that the spacing between lines, letters, words, and paragraphs on a website can be easily changed by users. Some people with low vision or reading difficulties need to adjust this spacing to make the text easier to read. If the website prevents them from changing the spacing, it can be very difficult or impossible for them to read the content.",
"how_to_test": null
},
{
"rule_id": "nonaxe-content-on-hover-or-focus",
"standard_code": "1.4.13",
"Notes": null,
"issue_severity": "minor",
"wcag_version_number": 2.1,
"wcag_level": "AA",
"affected_disabilities_json": "Low vision | Cognitive | Attention Deficit",
"help": "If hover or focus causes content changes, ensure interaction is predictable.",
"title": "Hover or focus content is not dismissible or persistently visible",
"dev_help": "1. Ensure auto-appearing content is dismissable via a clear and accessible control (e.g., a close button) without moving focus.\n 2. If content disappears automatically, provide users with the ability to adjust the timeout duration or extend the visibility of the content.\n 3. Avoid using animations or transitions that can be distracting or cause discomfort.\n 4. Test with users who have cognitive or visual impairments to ensure the implementation is effective and accessible.\n Example: A notification banner appearing at the top of the screen should have a prominent 'Close' button. Alternatively, the user should be able to configure how long such banners remain visible.",
"help_url": "https://www.w3.org/WAI/WCAG22/Understanding/content-on-hover-or-focus.html",
"description": "More users can perceive and dismiss non-persistent content.",
"layman_help": "1. Make sure any pop-up messages have a clear 'Close' button that's easy to see and click.\n 2. If messages disappear on their own, give people a way to make them stay longer.\n 3. Avoid making things flash or move too much, as it can be distracting.\n 4. Ask someone with vision or learning difficulties to try it out and see if it works well for them.",
"passed_title": "Content triggered by hover or focus is dismissible and hoverable.",
"dev_description": "Content that appears and disappears automatically (such as notifications, alerts, or updates) must be dismissable or persistent enough to allow users sufficient time to perceive and interact with it. This ensures users, particularly those with visual or cognitive impairments, are not disadvantaged by time-sensitive content changes they cannot control. Specifically, automatically appearing content should either be dismissable by the user without moving focus, or the user has control over the timeout duration before the content disappears.",
"layman_description": "Imagine a message popping up on your screen that disappears quickly. If you have trouble reading fast or get easily distracted, you might miss it. This rule says that such messages should either stay long enough for everyone to read them or allow you to close them yourself, so you don't miss important information. This is especially helpful for people with low vision or those who need more time to process information.",
"how_to_test": "1. Find Trigger Elements: Identify anything on the page that makes additional content appear when you hover the mouse over it or land on it using the Tab key (e.g., tooltips on icons, navigation menus that expand on hover, information pop-ups).\n 2. Test Dismissible:\n - Trigger the extra content (hover or focus).\n - Press the Esc key.\n - Check: Does the extra content disappear? It should. (Alternative methods like clicking outside might also dismiss it, but Esc is a common requirement for keyboard users).\n 3. Test Hoverable (for Mouse Use):\n - Use your mouse to hover over the trigger element to make the extra content appear.\n - Carefully move your mouse pointer directly from the trigger element onto the extra content that popped up.\n - Check: Does the extra content stay visible when your mouse is over it? It should not disappear.\n 4. Test Persistent:\n - Trigger the extra content (hover or focus).\n - Leave your mouse hovering over the trigger or the extra content, or keep keyboard focus on the trigger.\n - Check: Does the content stay visible without automatically vanishing after a short timeout? It should remain until you actively dismiss it (e.g., press Esc, click away, move focus/hover away from both the trigger and the popup).\n 5. Evaluate: If the extra content fails any of these tests (not dismissible via keyboard, disappears when you try to hover onto it, or vanishes too quickly), it fails this check."
},
{
"rule_id": "no-autoplay-audio",
"standard_code": "1.4.2",
"Notes": null,
"issue_severity": "moderate",
"wcag_version_number": 2,
"wcag_level": "A",
"affected_disabilities_json": "deaf | Cognitive | Attention Deficit",
"help": "<video> or <audio> elements must not play automatically",
"title": "Controls to pause, stop, or mute background audio are not provided",
"dev_help": "1. Check all `<video>` and `<audio>` elements on the page for the `autoplay` attribute.\n 2. If `autoplay` is present, verify the audio duration that plays automatically. If it's more than 3 seconds, implement a control mechanism (e.g., a pause/play button, a mute button) that is easily accessible.\n 3. Ensure the control mechanism is keyboard accessible and clearly labeled for screen reader users. Example: `<button aria-label=\"Mute audio\">Mute</button>`.\n 4. Consider avoiding autoplay altogether and requiring user interaction to initiate audio playback for a better user experience.\n 5. Test with assistive technologies like screen readers to ensure the control mechanism is properly announced and functional.",
"help_url": "https://dequeuniversity.com/rules/axe/4.10/no-autoplay-audio?application=axeAPI",
"description": "Ensure <video> or <audio> elements do not autoplay audio for more than 3 seconds without a control mechanism to stop or mute the audio",
"layman_help": "1. Check if any videos or audio clips on the webpage start playing sound automatically.\n 2. If they do, see if the sound plays for more than 3 seconds.\n 3. If it plays for longer, make sure there's a button or some way to stop the sound or turn it off. It should be easy to find and use. Think of a pause or mute button.\n 4. If you are having trouble stopping the sound or turning it off, contact the website owner and ask them to fix it.",
"passed_title": "Background audio has controls to pause, stop, or mute.",
"dev_description": "Ensure that any video or audio element on a webpage does not automatically start playing audio for more than 3 seconds. If audio autoplays for longer than 3 seconds, a mechanism must be provided to pause, stop, or mute the audio. This is essential to prevent unexpected and disruptive audio that can be particularly problematic for users with cognitive impairments or those using assistive technologies.",
"layman_description": "Imagine visiting a website and suddenly loud music or speech starts playing without you pressing any button. It's annoying, right? For people who are easily distracted or have trouble processing sounds, this can be overwhelming. Also, if someone uses a screen reader, the unexpected audio can interfere with the screen reader's output, making it hard to use the website. This rule says that if audio plays automatically for more than 3 seconds, there must be an easy way to stop it or turn it off.",
"how_to_test": null
},
{
"rule_id": "color-contrast",
"standard_code": "1.4.3",
"Notes": null,
"issue_severity": "serious",
"wcag_version_number": 2,
"wcag_level": "AA",
"affected_disabilities_json": "Low vision | Color Blindness | Cognitive",
"help": "Elements must meet minimum color contrast ratio thresholds",
"title": "Text and images of text do not meet minimum contrast ratios",
"dev_help": "1. Identify text elements: Use browser developer tools to identify all text elements on the page, including text within images.\n 2. Determine foreground and background colors: Use a color picker tool to determine the exact hexadecimal color codes for both the text and background.\n 3. Calculate the contrast ratio: Use a contrast checker tool (online or browser extension) to calculate the contrast ratio between the foreground and background colors. Ensure the tool used adheres to WCAG 2.2 standards for contrast calculation.\n 4. Verify compliance: Check if the contrast ratio meets the minimum requirements:\n * 4.5:1 for normal-sized text (typically less than 18pt if not bold, or less than 14pt if bold)\n * 3:1 for large text (typically 18pt and larger if not bold, or 14pt and larger if bold)\n 5. Adjust colors (if needed): If the contrast ratio is insufficient, adjust the foreground or background colors to achieve the required contrast ratio. Consider using a contrast checker tool that allows you to adjust colors and preview the contrast ratio in real-time.\n 6. Verify color adjustments: After adjusting colors, recalculate the contrast ratio to ensure it now meets the minimum requirements.\n 7. Test with users: If possible, test the color combinations with users who have low vision or color blindness to ensure readability.\n Example: If you have the text color `#A9A9A9` (dark grey) on a background color `#FFFFFF` (white), the contrast ratio is only 2.3:1, which fails the 4.5:1 requirement. To fix this, you could change the text color to `#000000` (black), which provides a contrast ratio of 21:1.",
"help_url": "https://dequeuniversity.com/rules/axe/4.10/color-contrast?application=axeAPI",
"description": "Ensure the contrast between foreground and background colors meets WCAG 2 AA minimum contrast ratio thresholds",
"layman_help": "1. Check the Colors: See if the text stands out clearly from the background. If the text and background colors are too similar, it will be hard to read.\n 2. Use a Contrast Checker: Imagine a tool that tells you if the colors are different enough. There are tools online that can check the 'contrast' between the text and the background.\n 3. Make Changes: If the contrast isn't good enough, change either the text color or the background color. Make the text darker or the background lighter (or vice-versa) so the text pops out.\n 4. Ask Someone Else: Get someone else to check if the text is easy to read, especially if they have vision problems. It's always good to get another opinion!\n For example: If the text is light gray on a white background, it's hard to see. Change the text to black or a darker gray so it's easier to read.",
"passed_title": "Text and images of text meet minimum contrast ratios.",
"dev_description": "Ensure that the contrast ratio between text (and images of text) and its background meets the minimum contrast ratio thresholds specified in WCAG 2.2 Level AA (4.5:1 for normal text, 3:1 for large text). This rule applies to all text content that is necessary to understand the information being presented. Exceptions may apply to logos, incidental text, or decorative text that doesn't convey meaning.",
"layman_description": "Make sure the text on a website is easy to read against its background. If there isn't enough contrast (difference) between the text and the background colors, it can be very difficult, especially for people with low vision or color blindness, to read the text. Imagine trying to read light gray text on a white background – it would be straining! This rule ensures sufficient contrast so that everyone can read the content comfortably.",
"how_to_test": null
},
{
"rule_id": "meta-viewport",
"standard_code": "1.4.4",
"Notes": null,
"issue_severity": "critical",
"wcag_version_number": 2,
"wcag_level": "AA",
"affected_disabilities_json": "Low vision | Mobility | Cognitive",
"help": "Zooming and scaling must not be disabled",
"title": "Text cannot be resized up to 200% without loss of content or functionality",
"dev_help": "1. Locate the `<meta name=\"viewport\">` tag in the `<head>` section of your HTML.\n 2. Remove `user-scalable=no` or `user-scalable=0`.\n 3. If `maximum-scale` is present, ensure it's set to a value greater than 1.0 or remove it entirely to allow unrestricted scaling.\n \n\n Example of an incorrect viewport meta tag:\n `<meta name=\"viewport\" content=\"width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no\">`\n \n\n Example of a correct viewport meta tag:\n `<meta name=\"viewport\" content=\"width=device-width, initial-scale=1.0\">`\n \n\n Another example of a correct viewport meta tag:\n `<meta name=\"viewport\" content=\"width=device-width, initial-scale=1.0, maximum-scale=5.0\">`",
"help_url": "https://dequeuniversity.com/rules/axe/4.10/meta-viewport?application=axeAPI",
"description": "Ensure <meta name=\"viewport\"> does not disable text scaling and zooming",
"layman_help": "To fix this, the website needs to allow you to zoom in and make the text bigger. If you can't zoom or increase the text size, tell the website owner that they need to change a setting called the 'viewport' to allow zooming. They need to remove anything that says 'user-scalable=no' or set a large 'maximum-scale' value in the website's code.",
"passed_title": "Text can be resized up to 200% without loss of function.",
"dev_description": "Ensure that the `<meta name=\"viewport\">` tag in the `<head>` section of your HTML document does not disable text scaling and zooming. Specifically, avoid setting `user-scalable=no` or `maximum-scale` to a small value (e.g., 1.0). Disabling these features prevents users from adjusting the text size or zooming in to improve readability, which is crucial for users with low vision or those who prefer larger text sizes.",
"layman_description": "Imagine trying to read a website, but the text is too small. Normally, you'd zoom in or make the text bigger in your browser settings. This rule makes sure that websites don't block you from doing that. Some websites have settings that prevent you from zooming or increasing the text size. This is bad for people with low vision or anyone who finds small text hard to read because it makes the website difficult or impossible to use.",
"how_to_test": null
},
{
"rule_id": "nonaxe-images-of-text",
"standard_code": "1.4.5",
"Notes": null,
"issue_severity": "minor",
"wcag_version_number": 2,
"wcag_level": "AA",
"affected_disabilities_json": "Low vision | Cognitive",
"help": "Use text instead of pictures of text.",
"title": "Images of text are used unnecessarily",
"dev_help": "['1. Identify instances where text is rendered as images instead of actual text.', '2. Replace images of text with equivalent text using HTML and CSS to style the text.', '3. If an image of text is unavoidable (e.g., logo), provide a descriptive alternative text using the `alt` attribute.', '4. Ensure that the text remains readable and customizable when the user adjusts font size, font family, color, and line height.', \"Example: Instead of `<img src='heading.png' alt='Welcome' />`, use `<h1>Welcome</h1>` and style it with CSS.\"]",
"help_url": "https://www.w3.org/WAI/WCAG22/Understanding/images-of-text.html",
"description": "Users can adjust how text is presented.",
"layman_help": "['1. Find any places on the website where the words are actually pictures.', '2. Change those pictures into real words that can be changed and styled.', '3. If you absolutely need to use a picture of words (like for a logo), make sure to add a description of the words to the picture so everyone knows what it says.', '4. Make sure the words still look good and can be changed when people make the text bigger, change the font, or change the colors.']",
"passed_title": "Images of text are avoided unless essential or decorative.",
"dev_description": "Ensure that text content is not presented as images of text, unless the image is purely decorative or the image of text is essential to the information being conveyed. Images of text prevent users from adjusting text properties such as font size, font family, color, and line height, which can be crucial for readability, especially for users with low vision or cognitive disabilities. If images of text are necessary, provide alternative text that conveys the same information. Using actual text allows users to customize the presentation according to their needs, and it also benefits search engine optimization and text-to-speech software.",
"layman_description": "Make sure that the words you see on the screen are actual text and not pictures of text. When words are just pictures, people who need to make the text bigger, change the font, or use a screen reader can't do it. This makes it hard for people with low vision or reading problems to understand the information. Using real text lets everyone adjust the words to a way that works best for them.",
"how_to_test": "1. Scan the page: Look carefully for any images that contain text.\n 2. Analyze each image of text: Ask these questions:\n i. Is it purely decorative? If the text adds no information, it might be okay (but still needs null alt text: alt=\"\").\n ii. Is it essential? Is the text part of a logo, brand name, or other situation where the specific visual style cannot be achieved with CSS and is crucial to the content? If yes, this usage is permitted (but requires appropriate alt text).\n iii. Could it be real text? If the text in the image conveys information (like a heading, a quote, button text, promotion details) and its appearance could be reasonably replicated using CSS on actual HTML text, then using an image of text fails this check.\n 3. Check for alt text (if essential): If an image of text is used because it's essential (like a logo), ensure it has appropriate alternative text that conveys the same words as the image.\n 4. Evaluate: If non-essential text is presented as an image where styled HTML text could have been used instead, it fails this check."
},
{
"rule_id": "color-contrast-enhanced",
"standard_code": "1.4.6",
"Notes": null,
"issue_severity": "serious",
"wcag_version_number": 2,
"wcag_level": "AAA",
"affected_disabilities_json": "Low vision | Color Blindness | Cognitive",
"help": "Elements must meet enhanced color contrast ratio thresholds",
"title": "Large text and graphical objects lack enhanced contrast",
"dev_help": "1. Use a color contrast analyzer tool to check the contrast ratio of text and background colors. There are many browser extensions and online tools available.\n 2. Adjust the foreground or background colors to meet the minimum contrast ratio requirements. For example, if you have dark text on a lighter background and the contrast is insufficient, darken the text or lighten the background.\n 3. For dynamic content, ensure the contrast ratio is maintained irrespective of the data being displayed.\n 4. Use CSS to define colors and maintain consistency throughout the website. Example: `body { color: #000000; background-color: #FFFFFF; }` (This example provides a high contrast ratio).",
"help_url": "https://dequeuniversity.com/rules/axe/4.10/color-contrast-enhanced?application=axeAPI",
"description": "Ensure the contrast between foreground and background colors meets WCAG 2 AAA enhanced contrast ratio thresholds",
"layman_help": "1. Check if the text on the website is easy to read by using a special tool that measures the difference between the text color and the background color. These tools are easy to find online.\n 2. If the text is hard to read, change the colors of the text or the background until the text stands out more clearly. For example, if the text is too light, make it darker.\n 3. If the website changes its content automatically (like news headlines), make sure the colors are still easy to read no matter what the content is.\n 4. Keep the colors consistent across the website to avoid confusion.",
"passed_title": "Large text and graphical objects have enhanced contrast.",
"dev_description": "Ensure that all text and images of text have a contrast ratio of at least 7:1. For large text (18pt or 14pt bold), ensure a contrast ratio of at least 4.5:1. Exceptions include incidental text, logos, and inactive UI components. This rule helps users with low vision or color deficiencies to perceive the content more easily. Verify that CSS and HTML attributes defining colors are correctly implemented and that dynamically generated content also adheres to these contrast ratios.",
"layman_description": "Make sure that the text on a website is easy to read against its background. For most text, the color difference between the text and background should be very high. For larger text, the color difference can be a little less, but still significant. This helps people with low vision or color blindness see the text clearly. Imagine trying to read white text on a light gray background – it would be difficult! This rule makes sure that doesn't happen.",
"how_to_test": null
},
{
"rule_id": "nonaxe-low-or-no-background-audio",
"standard_code": "1.4.7",
"Notes": null,
"issue_severity": "moderate",
"wcag_version_number": 2,
"wcag_level": "AAA",
"affected_disabilities_json": "deaf | Cognitive | Attention Deficit",
"help": "Avoid or lessen background sound, or let users turn it off.",
"title": "Background sounds in audio cannot be turned off or reduced",
"dev_help": "1. Identify prerecorded audio content with speech.\n 2. Measure the decibel level of the speech and any background sounds using audio editing software.\n 3. Ensure the background sound is at least 20 decibels lower than the speech.\n 4. If the background sound cannot be reduced, provide a control (e.g., a volume slider or mute button) to turn off the background sound.\n Example: `<button aria-label=\"Mute Background Music\" onclick=\"muteBackgroundMusic()\">Mute Music</button>`",
"help_url": "https://www.w3.org/WAI/WCAG22/Understanding/low-or-no-background-audio.html",
"description": "Prerecorded speech is not disrupted by background sound.",
"layman_help": "1. Check if there are videos or audio recordings on the website where someone is speaking.\n 2. Listen to the video or audio. Is there music or other sounds playing at the same time as the person speaking?\n 3. Is the music/sound so loud that it's hard to hear the person speaking clearly?\n 4. If yes, there should be a way to turn off the music/sound or make it quieter so you can understand the person speaking better.",
"passed_title": "Prerecorded audio keeps background sounds 20 dB below or allows muting.",
"dev_description": "Ensure that prerecorded audio content primarily consisting of speech does not contain background sounds played at the same volume as the speech. The background sound should be at least 20 decibels lower than the speech content. Alternatively, provide a mechanism to turn off the background sound. This ensures users can clearly understand the speech content without distraction or interference.",
"layman_description": "Imagine you're trying to listen to someone speaking in a video, but there's loud music playing at the same time. It's hard to understand what they're saying, right? This rule says that if a video or audio recording has someone speaking, any background music or sounds shouldn't be as loud as their voice. It should be quiet enough that you can easily hear and understand the person speaking. If it's not possible, then there should be a way to turn the background noise off. This makes it easier for everyone, especially people who are hard of hearing or have trouble focusing, to understand what's being said.",
"how_to_test": "1. Find audio with speech and background sounds: Locate any audio (or video with audio) on your page that has both spoken words and background sounds (music, ambient noise) playing together for more than 3 seconds.\n 2. Listen carefully: Can you easily understand everything being said? Does the speech sound clearly louder than the background noise? (Try to judge if it sounds roughly 4 times louder, which is about 20 decibels).\n 3. Look for controls: If the background sound seems loud or makes the speech hard to follow, look for controls specifically for the background audio. Can you:\n - Turn the background sound completely off?\n - Adjust the background sound volume separately from the speech volume?\n 4. Evaluate: If background sound interferes with speech clarity AND there's no way for the user to turn it off or lower it significantly relative to the speech, it fails this Level AAA check."
},
{
"rule_id": "nonaxe-visual-presentation",
"standard_code": "1.4.8",
"Notes": null,
"issue_severity": "minor",
"wcag_version_number": 2,
"wcag_level": "AAA",
"affected_disabilities_json": "Low vision | Cognitive | Attention Deficit",
"help": "Meet text display requirements or allow users to adjust them.",
"title": "Text color, width, spacing, or size cannot be adjusted",
"dev_help": "1. Use relative units (em, rem, %) for font sizes instead of pixels.\n 2. Use style sheets to control text appearance, separating content from presentation.\n 3. Allow users to override author styles using browser settings or custom stylesheets.\n 4. Ensure sufficient contrast between text and background colors, and provide options to adjust them.\n 5. Avoid using images of text. Use real text instead.\n 6. Test the website with different font sizes, line heights, and font families to ensure content remains readable and usable.\n 7. Use viewport meta tag to control layout on mobile devices.\n Example:\n font-size: 1.2em;\n line-height: 1.5;\n color: #333;\n background-color: #fff;",
"help_url": "https://www.w3.org/WAI/WCAG22/Understanding/visual-presentation.html",
"description": "Text appearance can be altered by users to meet preferences.",
"layman_help": "1. Make sure the website allows you to change the size of the text.\n 2. Ensure you can change the font to something easier to read.\n 3. The website should let you adjust the spacing between lines of text.\n 4. You should be able to change the colors of the text and background to make them easier to see.\n 5. The website should avoid using pictures of text, instead using real text.\n 6. Try changing these settings in your browser or using accessibility tools to see if the website still works well.",
"passed_title": "Users have mechanisms to adjust text color, width, spacing, and size.",
"dev_description": "Ensure that users can customize text appearance, including font size, line height, font family, spacing, and colors, without loss of content or functionality. Implement responsive design and avoid absolute units like pixels for font sizing. Use relative units such as em, rem, or percentages. Ensure sufficient contrast between text and background colors, and allow users to override author styles for text appearance. Verify text remains readable and usable when these changes are made. Avoid using images of text where real text can be used, as images of text cannot be easily resized or restyled.",
"layman_description": "This rule emphasizes the importance of allowing users to customize the way text looks on a website. People with low vision, cognitive issues, or attention deficits often need to adjust the size, spacing, font, or color of text to read it comfortably. If a website prevents these customizations, it becomes difficult or impossible for them to read and use the content. For example, a person with low vision might need to increase the font size, while someone with a cognitive disability might need more spacing between lines to better understand the text.",
"how_to_test": "1. Test Color Customization:\n - Use browser settings, an extension, or a custom user stylesheet to attempt to override the page's default text and background colors (e.g., set background to black, text to yellow).\n - Check: Do blocks of text respect the user's chosen colors? The check fails if the site's CSS forces colors using !important or uses background images that prevent user color selection for text blocks. (Note: Foreground and background colors must be specified together by the author if specified at all, per Failure F24).\n 2. Check Line Width (Max 80 Characters):\n - Examine main blocks of text.\n - Check: Do lines generally contain 80 characters or fewer (40 for CJK)? Use visual estimation or copy-paste a line into a character counter. Excessively wide blocks fail. CSS like max-width: 70ch; helps meet this.\n 3. Check Text Alignment (No Justification):\n - Look at paragraph alignment.\n - Check: Is the text fully justified (aligned to both left and right margins)? Full justification fails. Left (or right for RTL) alignment passes.\n 4. Check Spacing (Line and Paragraph):\n - Use browser developer tools to inspect the CSS for blocks of text.\n - Check Line Spacing: Is the line-height property at least 1.5 (or equivalent, like 150%)?\n - Check Paragraph Spacing: Is the space between paragraphs (e.g., margin-bottom or margin-top) at least 1.5 times the line-height value? (E.g., if line-height is 1.5, paragraph spacing should be at least 2.25em or 225%).\n 5, Test Resizing/Reflow (No Horizontal Scroll):\n - Zoom the browser to 200%.\n - Check: For blocks of text, do you need to scroll horizontally to read single lines of text? If yes, it fails. The text should wrap (reflow) to fit the viewport width. (Exceptions exist for content like data tables or maps where 2D layout is essential).\n 6. Evaluate: The check fails if any of these requirements are not met for blocks of text. Remember, the key is often that the user can make these adjustments; the site must not prevent them."
},
{
"rule_id": "nonaxe-images-of-text-no-exception",
"standard_code": "1.4.9",
"Notes": null,
"issue_severity": "moderate",
"wcag_version_number": 2,
"wcag_level": "AAA",
"affected_disabilities_json": "Low vision | Cognitive | Blind",
"help": "Do not use pictures of text unless there is no other way to present information.",
"title": "Images of text are used when they are not decorative or essential",
"dev_help": "1. Use relative units (em, rem, %) for font sizes instead of absolute units (px). Example: `font-size: 1.2em;`. 2. Use relative units for line height, letter spacing, and word spacing. Example: `line-height: 1.5;`, `letter-spacing: 0.1em;`, `word-spacing: 0.2em;`. 3. Avoid fixed-width containers that truncate text when resized. Use `min-width` and `max-width` as needed. 4. Test text resizing by using browser zoom (Ctrl + +) and custom stylesheets. Verify that text reflows correctly and no content is clipped or obscured. 5. Ensure sufficient contrast between text and background colors.",
"help_url": "https://www.w3.org/WAI/WCAG22/Understanding/images-of-text-no-exception.html",
"description": "Users can always adjust how text is presented.",
"layman_help": "1. The website should let you increase the text size using your browser's zoom function (usually Ctrl + +). 2. The text should still be readable and not overlap other elements or disappear off the screen when you make it bigger. 3. The spaces between the lines and letters should be adjustable. 4. The colors of the text and background should be different enough so you can easily read the text.",
"passed_title": "Non-text elements have sufficient contrast against adjacent colors.",
"dev_description": "Ensure users can customize text appearance without loss of content or functionality. This includes text resizing (up to 200%), line height, letter spacing, and word spacing. Avoid absolute units (px) for text and use relative units (em, rem, %). Ensure containers expand to accommodate larger text. Test with browser zoom and custom stylesheets.",
"layman_description": "Imagine trying to read a website where you can't make the text bigger, the lines are too close together, or the letters are crammed. This rule ensures you can adjust the text size and spacing to make it readable for you. This is especially helpful if you have low vision or a cognitive disability that makes reading difficult. The website must allow you to change these text settings without breaking the website's layout or making it unusable.",
"how_to_test": "1. Find all images containing text: Scan your webpage thoroughly.\n 2. Is it essential? For each image with text, ask:\n - Is this text part of our official logo or brand name? (This is usually considered essential).\n - Is the specific visual appearance of the text in this image absolutely necessary to understand the content, and impossible to create using normal text and styling (CSS)? (This is very rare for typical web content).\n 3. If not essential, it fails: If the text in the image is not part of a logo/brand and its specific visual style isn't truly essential, then using an image of text fails this strict Level AAA check. You should use real HTML text instead.\n 4. Check Alt Text for Essential Images: If an image of text is used because it's essential (like a logo), make sure it has accurate alt text describing the words in the image."
},
{
"rule_id": "frame-focusable-content",
"standard_code": "2.1.1",
"Notes": null,
"issue_severity": "serious",
"wcag_version_number": 2,
"wcag_level": "A",
"affected_disabilities_json": "Blind | Low vision | Mobility | Cognitive",
"help": "Frames with focusable content must not have tabindex=-1",
"title": "Content within <iframe> or <frame> is not keyboard accessible or focusable",
"dev_help": "1. Remove `tabindex=\"-1\"`: If the `<frame>` or `<iframe>` contains focusable content that should be accessible via keyboard, simply remove the `tabindex=\"-1\"` attribute altogether. \n 2. Set `tabindex=\"0\"`: Alternatively, if you want the element to be focusable but respect the natural tab order, set `tabindex=\"0\"`. Example: `<iframe src=\"content.html\" tabindex=\"0\"></iframe>`.\n 3. Review Tab Order (if using positive integers): If a positive integer is used, review the overall tab order of the page to ensure a logical and intuitive navigation flow.",
"help_url": "https://dequeuniversity.com/rules/axe/4.10/frame-focusable-content?application=axeAPI",
"description": "Ensure <frame> and <iframe> elements with focusable content do not have tabindex=-1",
"layman_help": "1. Check for Invisible Barriers: Find the 'boxes' on the website (frames). \n 2. Remove the 'Ignore Tab Key' Setting: If a box has a setting that tells the website to ignore the tab key for the contents of the box, remove that setting. \n 3. Make the Box Reachable: If you want people to be able to tab into the box using keyboard then change the 'Ignore Tab Key' setting to 'Make Reachable'. After this change the box will be reachable using keyboard.",
"passed_title": "Content within <iframe> or <frame> is keyboard accessible and focusable.",
"dev_description": "Ensure that `<frame>` and `<iframe>` elements containing focusable content do not have `tabindex=\"-1\"`. Setting `tabindex=\"-1\"` on these elements prevents users from tabbing into the content within the frame, effectively making it inaccessible via keyboard navigation. If the content inside a frame should be focusable, the `tabindex` attribute should either be removed or set to `0` or a positive integer. Setting it to `0` allows the element to be focusable in the natural tab order, while a positive integer sets a specific tab order, which is generally discouraged.",
"layman_description": "Imagine a website with content in a box (like a frame). If that box has a setting that says 'ignore the tab key,' people who use the keyboard to get around the website won't be able to reach anything inside the box. This rule makes sure that all parts of the website, including things in boxes, can be reached using only the keyboard. This is especially important for people who can't use a mouse.",
"how_to_test": null
},
{
"rule_id": "scrollable-region-focusable",
"standard_code": "2.1.1",
"Notes": null,
"issue_severity": "serious",
"wcag_version_number": 2,
"wcag_level": "A",
"affected_disabilities_json": "Blind | Low vision | Mobility | Cognitive",
"help": "Scrollable region must have keyboard access",
"title": "Scrollable regions are not keyboard focusable or operable",
"dev_help": "1. Identify elements with scrollable content (e.g., elements with CSS `overflow: auto` or `overflow: scroll`).\n 2. Check if these elements are focusable. If not, add `tabindex=\"0\"` to make them focusable.\n 3. Implement keyboard event listeners for arrow keys (Up, Down, Left, Right), Page Up, and Page Down.\n 4. Within the event listeners, programmatically adjust the `scrollTop` or `scrollLeft` properties of the element to scroll the content accordingly. For example:\n \n\n \n 5. Test thoroughly with a keyboard to ensure smooth and complete scrolling functionality.",
"help_url": "https://dequeuniversity.com/rules/axe/4.10/scrollable-region-focusable?application=axeAPI",
"description": "Ensure elements that have scrollable content are accessible by keyboard",
"layman_help": "1. Find any boxes or areas on the website that have scrollbars.\n 2. Make sure you can select or highlight these boxes using your keyboard (usually by pressing the 'Tab' key).\n 3. Try using the arrow keys (up, down, left, right) and the 'Page Up' and 'Page Down' keys to scroll the content inside the box.\n 4. If you can't scroll using the keyboard, the website needs to be fixed so that keyboard users can see all the content.",
"passed_title": "Scrollable regions are keyboard focusable and operable.",
"dev_description": "Ensure all elements with scrollable content, such as `<div>` or `<iframe>` elements styled with `overflow: auto` or `overflow: scroll`, can be scrolled using the keyboard. This typically involves ensuring that these elements are focusable (e.g., by setting `tabindex=\"0\"` if they are not inherently focusable) and that appropriate event listeners are in place to respond to keyboard events like arrow keys, Page Up, and Page Down. When an element receives focus, the user should be able to scroll its content using standard keyboard navigation.",
"layman_description": "Imagine a website with a box containing lots of text or images that you need to scroll to see everything. If you can't use a mouse, such as if you have a mobility impairment or are using a screen reader, you should still be able to scroll through this box using your keyboard. This rule ensures that people who rely on keyboards can access all the content within these scrollable areas, just like someone using a mouse.",
"how_to_test": null
},
{
"rule_id": "server-side-image-map",
"standard_code": "2.1.1",
"Notes": null,
"issue_severity": "minor",
"wcag_version_number": 2,
"wcag_level": "A",
"affected_disabilities_json": "Blind | Low vision | Mobility | Cognitive",
"help": "Server-side image maps must not be used",
"title": "Server-side image maps are used instead of client-side image maps",
"dev_help": "1. Replace server-side image maps with client-side image maps: Use the `<map>` and `<area>` HTML tags to define clickable regions directly in the HTML. Provide `alt` attributes for each `<area>` tag to describe the destination of each link. Example: `<img src=\"image.png\" alt=\"Descriptive image\" usemap=\"#mapname\"> <map name=\"mapname\"> <area shape=\"rect\" coords=\"0,0,50,50\" href=\"page1.html\" alt=\"Link to Page 1\"> <area shape=\"rect\" coords=\"50,50,100,100\" href=\"page2.html\" alt=\"Link to Page 2\"> </map>`. 2. Provide alternative text-based navigation: If using client-side image maps is not feasible, provide alternative text links that duplicate the functionality of the image map. This ensures that all users can access the content, regardless of their ability to use a mouse.",
"help_url": "https://dequeuniversity.com/rules/axe/4.10/server-side-image-map?application=axeAPI",
"description": "Ensure that server-side image maps are not used",
"layman_help": "1. Change the way the image map works so it's handled directly on your computer, not the website's server. This means using special HTML code that defines clickable areas on the image and lets you add descriptions to each area. 2. If you can't change the image map, add a list of text links below the image that go to the same places as the clickable areas. This way, everyone can still get to the different pages, even if they can't use the image map.",
"passed_title": "Image maps use client-side implementation for keyboard accessibility.",
"dev_description": "Server-side image maps rely on the server to determine the destination URL based on the coordinates of the user's click. This presents several accessibility issues. Firstly, they are inherently inaccessible to keyboard users, as they require mouse interaction. Secondly, screen reader users cannot easily navigate or understand the interactive areas within the image map. Thirdly, providing alternative text for the image itself does not convey the individual link destinations. Therefore, server-side image maps should be replaced with client-side image maps or alternative navigation mechanisms that are accessible to all users.",
"layman_description": "Imagine a picture on a webpage where different parts of the picture link to different pages. With server-side image maps, your computer sends the exact spot you clicked on the picture to the website's server, and the server decides where to send you. This is a problem for people who can't use a mouse, like those who use a keyboard or screen reader. They can't easily 'click' on the right spot, and the website gives them no easy way to understand where the clickable areas are on the picture. This makes the website very difficult or impossible to use for them.",
"how_to_test": null
},
{
"rule_id": "nonaxe-no-keyboard-trap",
"standard_code": "2.1.2",
"Notes": null,
"issue_severity": "serious",
"wcag_version_number": 2,
"wcag_level": "A",
"affected_disabilities_json": "Mobility | Blind | Low vision | Cognitive",
"help": "Ensure users always know how to navigate away from components.",
"title": "Keyboard focus is trapped and cannot move away",
"dev_help": "1. Identify the keyboard trap: Use only the keyboard to navigate the page. Try to Tab through all interactive elements. If you find an element you can enter but not exit, you've found a keyboard trap.\n 2. Implement proper focus management: When a component receives focus, ensure that pressing Tab (or Shift+Tab) will move focus to the next (or previous) logical element on the page.\n 3. Use ARIA attributes: Use `aria-hidden=\"true\"` to remove elements from the accessibility tree when they should not be focusable. Use `tabindex=\"0\"` to make non-interactive elements focusable if necessary, and `tabindex=\"-1\"` to make elements focusable via script but not via the normal tab order.\n 4. Handle modal dialogs correctly: When a modal dialog opens, focus should be moved to the dialog. Focus should be trapped within the dialog until it is closed, at which point focus should return to the element that triggered the dialog.\n Example:",
"help_url": "https://www.w3.org/WAI/WCAG22/Understanding/no-keyboard-trap.html",
"description": "Keyboard users don't get stuck.",
"layman_help": "1. Try using only your keyboard to move around the page using the Tab key.\n 2. If you get stuck and can't move to other parts of the page, there's a problem.\n 3. Make sure everything is reachable with the Tab key, including menus, buttons, and forms.\n 4. When something pops up (like a window), ensure you can close it and get back to where you were using only the keyboard.",
"passed_title": "Keyboard focus moves freely without trapping users.",
"dev_description": "Ensure that all interactive elements on a webpage are navigable using the keyboard. Users should be able to move focus into and out of each element using standard keyboard controls (usually the Tab key and Shift+Tab). A keyboard trap occurs when a user can enter a section of the page using the keyboard, but cannot exit it using only keyboard controls. This commonly happens with embedded content or custom widgets that don't properly manage keyboard focus.",
"layman_description": "Imagine trying to leave a room, but the door is locked and you can't find the key. A keyboard trap is similar. It happens when someone using a keyboard to navigate a website gets stuck in one part of the page and can't move to other areas. This can be frustrating and make the website unusable for people who rely on keyboards because they can't use a mouse, like individuals with motor impairments or those using screen readers due to blindness.",
"how_to_test": "1. Navigate with Keyboard: Start at the top of the page and use only the Tab key to move forward through all interactive elements (links, buttons, form fields, widgets, etc.) and Shift + Tab to move backward.\n 2. Test Interactive Components: Pay special attention when your focus enters things like:\n - Modal dialog boxes (pop-ups)\n - Embedded media players\n - Third-party widgets (like calendars, chat boxes)\n - Menus or complex controls\n 3. Try to Exit: Once your focus is inside one of these components, try to navigate out of it and back to the main page content using Tab (to get to the next element after the component) or Shift + Tab (to get to the previous element before the component).\n 4. Check for Traps: Does the focus keep cycling only within the component? Can you reach the elements outside of it using Tab and Shift + Tab?\n - If focus stays trapped inside, it's a failure.\n 5. Check Esc Key (Common Practice): For components like modal dialogs, try pressing the Esc key. Does it close the dialog and return focus logically (usually back to the button that opened it)? While not the only way to avoid a trap, it's a standard convention.\n 6. Evaluate: If you can navigate into any component but cannot navigate out using only the keyboard (Tab / Shift+Tab), it fails the \"No Keyboard Trap\" check."
},
{
"rule_id": "nonaxe-keyboard-no-exception",
"standard_code": "2.1.3",
"Notes": null,
"issue_severity": "moderate",
"wcag_version_number": 2,
"wcag_level": "AAA",
"affected_disabilities_json": "Blind | Mobility | Low vision | Cognitive",
"help": "Ensure all pointer actions have a keyboard equivalent.",
"title": "Functionality is not operable via keyboard without timing",
"dev_help": "1. Identify Non-Keyboard Accessible Functionality: Audit the website by attempting to use all interactive elements using only the keyboard (Tab, Shift+Tab, Enter, Spacebar, Arrow keys). Note any areas that are inaccessible or difficult to use.\n 2. Provide Keyboard Alternatives: For functionality that is only mouse-accessible, implement keyboard equivalents. For example:\n * Hover-triggered menus: Make the menu appear when the parent item receives keyboard focus and allow navigation with arrow keys.\n * Drag-and-drop: Provide buttons or controls to reorder items or manipulate elements.\n * Custom controls: Ensure custom JavaScript controls are properly coded to receive keyboard focus and respond to keyboard events.\n 3. Ensure Logical Focus Order: Verify that the Tab key moves focus through interactive elements in a logical order (typically left-to-right, top-to-bottom).\n 4. Provide Visible Focus Indicators: Use CSS to style the focus state of interactive elements, ensuring a clear visual indication of which element currently has focus (e.g., `outline`, `border`).\n 5. Test with Assistive Technologies: Test the website with screen readers and other assistive technologies to ensure proper keyboard navigation and interaction.",
"help_url": "https://www.w3.org/WAI/WCAG22/Understanding/keyboard-no-exception.html",
"description": "Everything can be done with a keyboard.",
"layman_help": "1. Check with your keyboard: Try using your website with just the keyboard. Can you click on everything? Can you fill out forms?\n 2. Add keyboard ways to do things: If something only works with a mouse, add a way to do it with the keyboard too. For example, if a menu appears when you hover over it, make it appear when you select it with the keyboard.\n 3. Make sure you go in order: When you press the Tab key, the focus should move in a way that makes sense (like reading a book).\n 4. Show where you are: When you select something with the keyboard, make it obvious what you've selected with a border or highlight.\n 5. Test with others: Have someone who uses a keyboard instead of a mouse try your website to make sure it works for them.",
"passed_title": "Keyboard operation works without timing constraints.",
"dev_description": "Ensure that all interactive elements and functionalities of the webpage are operable through a keyboard interface, without requiring a mouse or other pointing device. This includes links, buttons, form fields, and custom controls. Verify that keyboard focus is clearly visible and follows a logical order. Focusable elements should receive focus in a predictable sequence aligning with the visual layout of the page. If any functionality is only accessible via mouse interaction (e.g., drag-and-drop, hover-triggered menus), provide an alternative keyboard-accessible mechanism.",
"layman_description": "Imagine trying to use a website if you can't use a mouse. People with mobility impairments, blindness, or other conditions rely on keyboards to navigate websites. This rule means that everything you can do with a mouse – clicking buttons, filling out forms, navigating menus – should also be possible using only a keyboard. If a website requires a mouse for certain actions and doesn't offer a keyboard alternative, many people won't be able to use it.",
"how_to_test": "1. Comprehensive Keyboard Test: Use only the keyboard (Tab, Shift+Tab, Enter, Space, Arrow keys, Esc) to try and operate every single interactive feature on the page. This includes forms, buttons, links, menus, sliders, media players, etc. [Follow steps similar to testing SC 2.1.1].\n 2. Focus on Complex Interactions: Pay extra attention to any functionality that involves:\n - Dragging and dropping items\n - Drawing or freehand input\n - Resizing elements\n - Using sliders or dials\n - Complex data visualizations or custom controls\n 3. Verify Keyboard Alternatives: For every function identified in step 2 (or any other function):\n - Can you perform the entire action using only standard keyboard keys?\n - For example, can you select an item in a drag-and-drop list and use arrow keys or an \"Move\" button (activated by Enter/Space) to change its position? Can you adjust a slider using arrow keys?\n 4. No Exceptions Allowed: If there is any functionality that can only be operated using a mouse or specific pointer gestures, and has no keyboard equivalent, it fails this Level AAA check.\n 5. Use Semantic HTML: (Auditor Note) Check if standard HTML controls (<button>, <input>, <a>, <select>, etc.) are used where possible, as they have built-in keyboard accessibility. If custom components are built (e.g., using <div>s), verify they have been explicitly programmed to handle keyboard focus (tabindex=\"0\") and interaction (via JavaScript event handlers for keys like Enter, Space, Arrows)."
},
{
"rule_id": "nonaxe-character-key-shortcuts",
"standard_code": "2.1.4",
"Notes": null,
"issue_severity": "minor",
"wcag_version_number": 2.1,
"wcag_level": "A",
"affected_disabilities_json": "Mobility | Cognitive",
"help": "Ensure character-only shortcut keys can be turned off or modified.",
"title": "Character-only keyboard shortcuts can't be turned off or remapped",
"dev_help": "1. Provide a mechanism to disable the shortcut: Offer users a setting to turn off the keyboard shortcut.\n \n \n 2. Allow remapping of the shortcut: Let users change the keys used for the shortcut.\n \n 3. Restrict activation to focused components: Ensure the shortcut only works when the relevant component has focus. Use `addEventListener` with appropriate focus and blur handling.",
"help_url": "https://www.w3.org/WAI/WCAG22/Understanding/character-key-shortcuts.html",
"description": "Reduce accidental activation of keyboard shortcuts.",
"layman_help": "1. Add a setting to turn off the shortcut: Include an option in the settings menu that allows you to disable the problematic shortcut.\n 2. Let users change the shortcut: Provide a way to customize the key combination for the shortcut to something easier or less prone to accidental activation.\n 3. Make sure the shortcut only works when it's needed: The shortcut should only be active when you're actively using that specific function or part of the website.",
"passed_title": "Character-only shortcuts can be turned off or remapped.",
"dev_description": "Ensure that keyboard shortcuts can be disabled, remapped, or only activated when a component has focus. This prevents accidental activation of shortcuts which can disrupt the user's workflow. This is particularly important for single-character shortcuts which are easy to accidentally trigger.",
"layman_description": "Imagine you accidentally press a key and suddenly something unexpected happens on the screen, like closing a window or deleting text. This rule makes sure that keyboard shortcuts (combinations of keys that do specific actions) are not too easy to activate by accident. It either lets you turn them off, change them, or makes sure they only work when you're actively using a specific part of the page. This helps prevent frustration, especially for people who might have trouble with precise movements or who use assistive technologies.",
"how_to_test": "1. Identify Single-Key Shortcuts: Explore the website or web application. Try pressing various letter, number, or punctuation keys without modifier keys (Ctrl, Alt, Cmd, Shift). Does pressing any single key trigger an action or function? (Check help documentation if available).\n 2. Check for Management Options: If you find single-key shortcuts active globally on the page:\n - Turn Off: Look in settings or preferences. Is there an option to disable single-key shortcuts?\n - Remap: Can you customize the keyboard shortcuts to require a modifier key (e.g., change 'R' to Ctrl+R)?\n - Focus Constraint: Test if the shortcut only works when a specific part of the page (like a text editor, media player, or game canvas) has keyboard focus. Does pressing the key do nothing when focus is elsewhere (like the address bar or other page content)?\n 3. Evaluate: If single-key shortcuts exist and none of the mechanisms (Turn Off, Remap, Active Only on Focus) are available, the check fails."
},
{
"rule_id": "meta-refresh",
"standard_code": "2.2.1",
"Notes": null,
"issue_severity": "critical",
"wcag_version_number": 2,
"wcag_level": "A",
"affected_disabilities_json": "Blind | Low vision | Cognitive | Attention Deficit | Mobility",
"help": "Delayed refresh under 20 hours must not be used",
"title": "Users cannot turn off, adjust, or extend time limits set by content",
"dev_help": "1. Remove any `<meta http-equiv=\"refresh\">` tags used for timed redirects or refreshes.\n 2. If a redirect is necessary, use server-side redirects (e.g., HTTP 302 status code) instead of meta refresh. This allows assistive technologies to handle the redirect appropriately.\n 3. If a refresh is necessary, provide a clear control for the user to manually refresh the content. For example, a button labeled 'Refresh Content'.\n 4. If an automatic redirect is unavoidable, provide the user with a warning and sufficient time to opt-out of the redirect before it occurs. For example, 'You will be redirected in 10 seconds. Click here to stay on this page.'",
"help_url": "https://dequeuniversity.com/rules/axe/4.10/meta-refresh?application=axeAPI",
"description": "Ensure <meta http-equiv=\"refresh\"> is not used for delayed refresh",
"layman_help": "1. The website developer should remove any automatic refresh or redirect features that use a special code in the background.\n 2. If the website needs to take you to a new page, it should use a method that assistive technologies can understand, like sending a signal from the server (the computer that hosts the website) instead of using the refresh code.\n 3. If the website needs to update, it should include a button you can click to refresh the page yourself.\n 4. If a redirect is absolutely necessary, the website should warn you and give you enough time to stop it from happening. For example, a message like 'You will be taken to a new page in 10 seconds. Click here to stay on this page.'",
"passed_title": "Users can adjust, extend, or disable time limits.",
"dev_description": "The `<meta http-equiv=\"refresh\">` tag with a specified delay is used to automatically redirect users to a different page or refresh the current page after a certain time interval. This can be problematic for users with disabilities because it can disrupt their navigation and orientation on the website. Screen reader users may not have enough time to read the content before being redirected. Users with cognitive disabilities may become disoriented by the unexpected page transition. Users with motor impairments might not be able to interact with the page before the refresh happens. It is essential to avoid using `<meta http-equiv=\"refresh\">` for timed redirects or refreshes. Instead, use server-side redirects or provide users with clear controls and sufficient time to complete tasks.",
"layman_description": "Imagine you're reading a website, and suddenly, without warning, the page jumps to a new one or reloads itself. This is what happens when a website uses a `<meta http-equiv=\"refresh\">` tag to automatically refresh or redirect. For people who are blind and use screen readers, this means the screen reader might not have enough time to read the content before the page changes. For people with cognitive or attention issues, sudden changes can be confusing and disorienting. Even for people using a keyboard or other assistive devices, it can be frustrating if the page refreshes before they've finished interacting with it. This rule makes sure websites don't automatically refresh or redirect, so everyone has enough time to read and interact with the content.",
"how_to_test": null
},
{
"rule_id": "blink",
"standard_code": "2.2.2",
"Notes": null,
"issue_severity": "serious",
"wcag_version_number": 2,
"wcag_level": "A",
"affected_disabilities_json": "Low vision | Cognitive | Attention Deficit",
"help": "<blink> elements are deprecated and must not be used",
"title": "Blinking content can't be paused or stopped by the user",
"dev_help": "1. Remove all `<blink>` elements from your HTML.\n 2. Replace the blinking effect with CSS animations or JavaScript solutions.\n 3. Ensure the animations can be paused or stopped by the user.\n Example:\n Instead of `<blink>Important Message</blink>` use:\n \n \n Add a button to pause the animation:",
"help_url": "https://dequeuniversity.com/rules/axe/4.10/blink?application=axeAPI",
"description": "Ensure <blink> elements are not used",
"layman_help": "1. Find any text or images on your website that are blinking.\n 2. Remove the blinking effect. If you need to highlight something, try making the text a different color, making it bigger, or using a simple animation that doesn't flash quickly.\n 3. If you use an animation, make sure people can stop it if they want to. This can be done by adding a button that says 'Pause Animation'.",
"passed_title": "Blinking content can be paused or stopped by users.",
"dev_description": "The `<blink>` element is deprecated and should not be used because it can cause seizures in some users. The blinking effect can be distracting and make it difficult for users to focus on the content. Replace `<blink>` elements with CSS animations or JavaScript solutions that allow users to control the animation or turn it off entirely. This ensures content is accessible and does not trigger adverse reactions.",
"layman_description": "Avoid using blinking text or images on your website. Blinking can be very distracting and even cause seizures in some people. It can also make it hard for people with attention problems or low vision to read the text or understand the content on the page. Instead of blinking, use other ways to draw attention to important information, like changing the color or size of the text, or using a subtle animation that doesn't flash rapidly.",
"how_to_test": null
},
{
"rule_id": "marquee",
"standard_code": "2.2.2",
"Notes": null,
"issue_severity": "serious",
"wcag_version_number": 2,
"wcag_level": "A",
"affected_disabilities_json": "Cognitive | Low vision | Attention Deficit",
"help": "<marquee> elements are deprecated and must not be used",
"title": "Moving content lacks controls to pause, stop, or hide",
"dev_help": "1. Remove all `<marquee>` elements from the HTML code.\n 2. Replace the functionality with CSS animations or JavaScript. \n 3. Ensure any animations have controls to pause, stop, and adjust speed.\n Example: Instead of `<marquee>Scrolling text</marquee>`, use CSS animation:\n \n \n Add pause/play button using javascript to control animation speed.",
"help_url": "https://dequeuniversity.com/rules/axe/4.10/marquee?application=axeAPI",
"description": "Ensure <marquee> elements are not used",
"layman_help": "1. Get rid of any moving text on the page.\n 2. If you need to show moving text, use a different method, like a slideshow or animated image, that lets people stop, start, or slow down the movement.\n 3. Make sure there are buttons or controls available for users to pause, stop, or change the speed of the animation.",
"passed_title": "Moving content has controls to pause, stop, or hide it.",
"dev_description": "<marquee> elements create moving content that can be distracting and difficult to follow. This violates accessibility principles by causing potential seizures, cognitive overload, and difficulty for users to control the reading speed, leading to a degraded user experience. Developers should avoid using `<marquee>` and instead use CSS animations or JavaScript to provide similar functionality, but with proper controls to pause, stop, and adjust the speed of the animation.",
"layman_description": "Moving text, like in an old-fashioned marquee sign, can be really annoying and hard to read, especially if you have trouble focusing or reading quickly. It's like trying to catch a fly! This rule says websites shouldn't use moving text because it can make people dizzy or distract them so much that they can't understand what the website is trying to say. It's better to keep text still, or if you really need it to move, make sure people can stop it or slow it down.",
"how_to_test": null
},
{
"rule_id": "nonaxe-no-timing",
"standard_code": "2.2.3",
"Notes": null,
"issue_severity": "moderate",
"wcag_version_number": 2,
"wcag_level": "AAA",
"affected_disabilities_json": "Cognitive | Low vision | Mobility",
"help": "Do not use time limits, except for video and live events.",
"title": "No alternative for time-based interactions with fixed timing",
"dev_help": "1. Identify all time limits on the website.\n 2. Determine if the time limit is essential. If not, remove it.\n 3. If the time limit is essential, provide at least one of the following options:\n a. Turn off the time limit before encountering it.\n b. Adjust the time limit before encountering it (e.g., the user can request 10x more time).\n c. Extend the time limit before it expires (e.g., \"Are you still there? Click here to continue\").\n d. In cases where a real-time event occurs (e.g., an auction), provide alternatives such as email or SMS alerts.\n e. The time limit is a result of an inactivity and the data is preserved for more than 20 hours.\n Example: For a banking website, provide a session timeout warning with an option to extend the session. Use ARIA attributes to make the warning accessible to screen readers.",
"help_url": "https://www.w3.org/WAI/WCAG22/Understanding/no-timing.html",
"description": "Users do not face time limits.",
"layman_help": "1. Check if there are any timers on the website that might cut you off.\n 2. If there is a timer, make sure the website lets you:\n a. Turn the timer off completely, OR\n b. Make the timer longer before it starts, OR\n c. Give you a chance to add more time before the timer runs out.\n This way, you won't get rushed or timed out before you're ready.",
"passed_title": "Alternatives exist for fixed-time interactions.",
"dev_description": "Ensure that users are not subjected to time limits for reading, processing, or responding to content, unless a time limit is essential and the user is given options to turn off, adjust, or extend the time limit. This success criterion is about ensuring users have sufficient time to complete tasks, read content, and interact with the website without feeling rushed or timed out. Exceptions are allowed when the time limit is essential, such as during a live auction, but even in those cases, users should be given as much control as possible.",
"layman_description": "Imagine trying to fill out a form or read something important online, but the website keeps cutting you off because you're taking too long. This rule makes sure websites give you enough time to read, understand, and finish what you're doing. If there's a time limit, like in a game, the website should let you turn it off, change it, or get more time. This helps people who need more time to read, think, or type, like someone with a learning disability or someone who uses a screen reader.",
"how_to_test": "1. Identify Potential Timed Content: Browse the website and look for areas where users interact or consume content. Could any of these have a time limit? Examples include:\n - Online forms (applications, registrations, checkouts)\n - Quizzes or tests (unless timing is the point, like a reaction game)\n - Sessions that log you out automatically after inactivity (related to SC 2.2.1 and 2.2.6, but this SC advises avoiding the timeout altogether if possible).\n - Content that disappears after a set time (like pop-ups or messages).\n - Check for Timers: Interact with these areas. Do you see any countdown timers? Does any content vanish after a short period? Does the site warn you about session timeouts?\n 2. Analyze the Time Limit: If a time limit exists:\n 3. Is it for a real-time event like an auction? (Exception applies)\n - Is it just the natural length of a video or audio file? (Exception applies)\n - Is it related to security (like a session timeout)? (SC 2.2.1 or 2.2.6 might apply, requiring warnings or adjustments, but SC 2.2.3 prefers avoiding it if possible for non-critical tasks).\n - Is it for anything else, like reading content or filling out a standard form?\n 4. Evaluate: If a time limit is imposed on an activity where timing is not essential (e.g., filling out a contact form, reading an article, taking a non-speed-based quiz), it fails this Level AAA check. The ideal is to allow users unlimited time for such tasks."
},
{
"rule_id": "meta-refresh-no-exceptions",
"standard_code": "2.2.4",
"Notes": null,
"issue_severity": "minor",
"wcag_version_number": 2,
"wcag_level": "AAA",
"affected_disabilities_json": "Blind | Low vision | Cognitive | Attention Deficit",
"help": "Delayed refresh must not be used",
"title": "Users cannot postpone or disable non-emergency interruptions",
"dev_help": "1. Remove the `<meta http-equiv=\"refresh\">` tag: Locate and remove any `<meta http-equiv=\"refresh\" content=\"...\">` tags from the `<head>` section of your HTML. \n 2. Implement Server-Side Redirects: Use server-side redirects (e.g., HTTP 301 or 302 redirects) if you need to redirect users to a different page. These redirects are handled by the server and do not rely on the client-side rendering of a meta tag. For example, in PHP: `header(\"Location: newpage.html\"); exit;`\n 3. Use JavaScript with User Control: If a client-side redirect is necessary, use JavaScript but provide a clear warning and a way for the user to prevent the redirect. For example:\n \n Include an option to cancel the redirect using `clearInterval(intervalId)`. Give the user a button: `<button onclick='clearInterval(intervalId); alert(\"Redirect cancelled.\");'>Cancel Redirect</button>`",
"help_url": "https://dequeuniversity.com/rules/axe/4.10/meta-refresh-no-exceptions?application=axeAPI",
"description": "Ensure <meta http-equiv=\"refresh\"> is not used for delayed refresh",
"layman_help": "1. Find and Remove the Automatic Redirect: If you can edit the website's code, look for a hidden instruction that automatically sends you to a new page. It's like finding the invisible string pulling you away.\n 2. Use Proper Redirects: If the website needs to send you to a new page, it should do it in a way that's clear and doesn't happen suddenly without your permission.\n 3. Give People Control: If a website needs to automatically send you to another page, it should provide a countdown and a button labeled 'Cancel Redirect' so you can stay on the current page if you need more time.",
"passed_title": "Users can postpone or disable non-emergency alerts.",
"dev_description": "Ensure that the `<meta http-equiv=\"refresh\">` tag is not used for delayed page refresh or redirection. This tag can automatically redirect users to a different page after a specified time interval. This can be disorienting and confusing for users, especially those with cognitive or visual impairments. Instead of using `<meta http-equiv=\"refresh\">`, implement server-side redirects or JavaScript-based redirects with proper user notification and control.",
"layman_description": "Imagine you're reading a website, and suddenly, without warning, the page automatically jumps to a new page. This can be confusing and annoying for anyone, but especially difficult for people who need more time to read and understand content, like those with cognitive disabilities or low vision. This rule says websites shouldn't use sneaky automatic redirects that you can't stop or control. It is like someone snatching the book from your hand when you are not finished with it.",
"how_to_test": null
},
{
"rule_id": "nonaxe-re-authenticating",
"standard_code": "2.2.5",
"Notes": null,
"issue_severity": "moderate",
"wcag_version_number": 2,
"wcag_level": "AAA",
"affected_disabilities_json": "Cognitive | Mobility | Low vision | Blind",
"help": "Preserve users' prior activity and data through reauthentication.",
"title": "Re-authentication causes loss of user data or progress",
"dev_help": "1. Implement session management that preserves form data or user state before requiring re-authentication.\n 2. Use server-side session storage or browser local storage (with appropriate security measures) to temporarily save the data.\n 3. Upon successful re-authentication, automatically repopulate the form fields with the saved data.\n 4. Alternatively, redirect the user back to the exact point in the process where they were interrupted before re-authentication was required.\n 5. Clearly inform the user about the upcoming session timeout and the re-authentication process beforehand.\n Example: Using server-side session:",
"help_url": "https://www.w3.org/WAI/WCAG22/Understanding/re-authenticating.html",
"description": "Users do not lose information or context due to reauthentication.",
"layman_help": "If a website asks you to log in again after you've already started doing something, like filling out a form, the website should remember what you were doing. When you log back in, the website should either fill in the form for you automatically or take you right back to where you left off, so you don't have to start all over again. The website should also warn you beforehand if it's about to time out and ask you to log in again.",
"passed_title": "Re-authentication keeps user data and progress intact.",
"dev_description": "WCAG 2.2.5 (Re-authenticating) states that if a user is required to re-authenticate after a period of inactivity, they should not lose any data that they previously entered. This means that any information the user provided before the re-authentication request should be preserved and automatically re-populated, or the user should be guided back to their previous state upon successful login. This primarily affects users filling out forms or engaging in multi-step processes. Ensure that session timeouts and re-authentication flows do not cause data loss or require users to restart their tasks from the beginning.",
"layman_description": "Imagine filling out a long form online. If the website suddenly asks you to log in again, you'd expect that all the information you already typed in would still be there when you log back in. This rule ensures that people with disabilities, especially those with cognitive or motor impairments that make form filling slow and difficult, don't lose their work due to unexpected re-authentication requests. It ensures they don't have to start over, which can be very frustrating and time-consuming.",
"how_to_test": "1. Identify a Relevant Process: Find a task on the website that:\n - Requires you to be logged in.\n - Involves entering information across multiple steps or fields (e.g., multi-page form, checkout process, profile update).\n - Might have a session timeout due to inactivity.\n 2. Start Entering Data: Log in and begin the process. Fill in several fields or complete a few steps.\n 3. Wait for Timeout: Leave the page inactive long enough for your session to likely expire. (This might take 15-30 minutes or longer, depending on the site's settings).\n 4. Trigger Re-authentication: Try to continue the process (e.g., click \"Next\" or try to submit). The site should prompt you to log in again because your session expired.\n 5. Log In Again: Complete the login process.\n 6. Check for Saved Data: After successfully logging back in, look at the form or process you were working on.\n - Check: Is the data you entered before the timeout still there? Are you returned to the step where you left off?\n 7. Evaluate: If, after re-authenticating, you are returned to the process but your previously entered data is lost and you have to start over, the check fails."
},
{
"rule_id": "nonaxe-timeouts",
"standard_code": "2.2.6",
"Notes": null,
"issue_severity": "moderate",
"wcag_version_number": 2.1,
"wcag_level": "AAA",
"affected_disabilities_json": "Cognitive | Mobility | Low vision",
"help": "Tell users how long their session can be inactive before they may lose information.",
"title": "No warning or option to extend session before timeouts",
"dev_help": "1. Implement a timeout warning mechanism that activates a reasonable amount of time (e.g., 2 minutes) before the session expires. Display a clear and easily understandable message to the user.\n 2. Provide an option for the user to extend the session with a simple action (e.g., clicking a button labeled 'Extend Session').\n 3. If extending the session isn't possible, ensure that data is automatically saved at regular intervals (e.g., every minute) and that the user is notified that their data is being saved. Consider providing an explicit 'Save' button.\n 4. If the user doesn't respond to the warning or the session expires, clearly inform the user what happened and, if possible, how to recover their data or resume their session. Provide clear instructions on how to log back in or retrieve saved work.\n Example:",
"help_url": "https://www.w3.org/WAI/WCAG22/Understanding/timeouts.html",
"description": "Users do not lose data due to unknown timeouts.",
"layman_help": "1. The website should display a warning message a few minutes before your session is about to expire.\n 2. The warning should have a button or link that lets you extend your session. Clicking this button gives you more time to finish what you're doing.\n 3. If the website can't extend your session, it should automatically save your work regularly so you don't lose it. It should also tell you that it's saving your work.\n 4. If your session expires, the website should tell you what happened and explain how you can log back in or get your saved work back.",
"passed_title": "Users get warnings and can extend sessions before timeouts.",
"dev_description": "Ensure that users are warned about the duration of any session timeout that could result in data loss, unless the data is preserved for more than 20 hours of user inactivity. Provide a mechanism for the user to extend the timeout or save their data before the timeout occurs. This prevents unexpected data loss due to inactivity, especially when completing long forms or complex tasks. Implement a timeout warning mechanism that triggers before the timeout occurs, giving users sufficient time to respond. If the user does not respond to the warning, data should still be preserved (e.g., auto-saved) where possible.",
"layman_description": "Imagine you're filling out a long form online, like an application or a survey. If the website 'times out' because you take too long, all your work could be lost. This rule means the website should warn you before timing out and give you a way to keep working (like extending the time) or save your progress. Without this, people with disabilities, especially those with cognitive or motor impairments, may need extra time to complete forms. They might lose their work unexpectedly, causing frustration and difficulty.",
"how_to_test": "1. Identify Data-Entry Processes: Find tasks on the site involving data entry where inactivity might lead to loss (e.g., complex forms, application processes, shopping carts before final checkout).\n 2. Look for Timeout Information:\n - Check for Warnings: Before starting or early in the process, does the site display any message informing you about an inactivity timeout duration that could cause data loss (e.g., \"For security, sessions expire after 30 minutes of inactivity, unsaved data may be lost\")?\n - Test Data Preservation (If No Warning): If no warning about a specific duration is given, you need to test if data is preserved for a long time (the easiest way to meet the SC without warnings).\n i. Start the process, enter some data.\n ii. Leave the page inactive for a significant period (e.g., 30-60 minutes, or whatever the likely timeout is suspected to be, though testing the full 20 hours is usually impractical).\n iii. Try to resume. If you are timed out and forced to re-log in (triggering SC 2.2.5), check if the data was saved upon return. If you weren't logged in, check if the data persists when you revisit the form/process later. (While you can't easily verify the full 20 hours manually, if data is lost after a typical short timeout and no warning about the duration was given, it likely fails).\n 3. Evaluate:\n - Pass: If either (a) data entered is preserved for at least 20 hours of inactivity OR (b) the user is clearly informed upfront about the duration of inactivity that will lead to data loss (if less than 20 hours).\n - Fail: If data can be lost due to inactivity in less than 20 hours, AND the user was not informed of the inactivity duration that causes this loss."
},
{
"rule_id": "nonaxe-three-flashes-or-below-threshold",
"standard_code": "2.3.1",
"Notes": null,
"issue_severity": "critical",
"wcag_version_number": 2,
"wcag_level": "A",
"affected_disabilities_json": "Cognitive | Low vision",
"help": "Avoid content that flashes, or keep it under thresholds.",
"title": "Content flashes too fast or does not meet flash safety checks",
"dev_help": "1. Avoid flashing content altogether if possible. 2. If flashing is necessary, ensure the flash rate is no more than three times per second. 3. Keep the area of the flash below the defined thresholds (general flash and red flash thresholds as per WCAG guidelines). 4. Use tools to analyze content for potential flashing issues. 5. Provide a warning before content that might trigger seizures.",
"help_url": "https://www.w3.org/WAI/WCAG22/Understanding/three-flashes-or-below-threshold.html",
"description": "Content does not trigger seizures.",
"layman_help": "1. If you can, avoid using any flashing lights or images on your website or app. 2. If you have to use flashing, make sure it doesn't flash too quickly (no more than three times in one second). 3. The flashing area on the screen should be small. 4. If you're not sure, get someone to check your content to make sure it's safe. 5. If you have content that might cause seizures, warn people before they see it.",
"passed_title": "Content passes flash safety and does not flash too fast.",
"dev_description": "Ensure content does not contain anything that flashes more than three times per second, or if the flash area exceeds defined thresholds. This is crucial to prevent seizures in individuals with photosensitive epilepsy. Specifically, avoid rapid changes in luminance or flashing patterns that could trigger adverse reactions.",
"layman_description": "Imagine watching a video or looking at a website where things flash on and off very quickly. For some people, especially those with epilepsy, this can cause a seizure. This rule makes sure websites and apps don't have content that flashes too much, so it's safer for everyone, especially people who are sensitive to flashing lights. This includes animations, videos, and any content that changes rapidly.",
"how_to_test": "1. Watch the page: Load the webpage and carefully observe all content, especially animations, videos, ads, or any element that changes brightness or color rapidly.\n 2. Identify flashing: Look for anything that blinks or flashes noticeably.\n 3. Count the flashes: For any flashing element, try to count how many times it flashes (changes from light to dark and back, or between contrasting colors) within a one-second period. You might need to watch it for a few seconds to get a sense of the rate.\n 4. Evaluate:\n - Pass: If no content flashes more than three times per second.\n - Fail: If any content clearly flashes more than three times in one second. (Unless you are certain it meets the complex \"below threshold\" exception for small size and contrast, which usually requires specialized tools to verify accurately. For a basic manual check, exceeding three flashes per second is generally considered a failure)."
},
{
"rule_id": "nonaxe-three-flashes",
"standard_code": "2.3.2",
"Notes": null,
"issue_severity": "critical",
"wcag_version_number": 2,
"wcag_level": "AAA",
"affected_disabilities_json": "Cognitive",
"help": "Do not flash content more than 3 times a second.",
"title": "Content flashes more than three times per second",
"dev_help": "1. Analyze video content for flashing using seizure-testing tools (e.g., photosensitive epilepsy analysis tools).\n 2. Ensure flash rate is below 3 flashes per second or use the General Flash and Red Flash thresholds.\n 3. Reduce the flashing area if rates exceed the thresholds. Decrease brightness or contrast between flashes.\n 4. For animations, control the animation speed to prevent seizure-inducing flashing.\n 5. Use static images or slower transitions as alternatives.\n 6. Provide warnings before content with potentially seizure-inducing flashes, giving users the option to avoid it.\n Example: If a video has flashing lights, edit the video to reduce the flash rate or area. Provide a still image or a summary in text format as an alternative.",
"help_url": "https://www.w3.org/WAI/WCAG22/Understanding/three-flashes.html",
"description": "Content does not trigger seizures.",
"layman_help": "1. Check videos and websites to see if anything flashes quickly.\n 2. Make sure the flashing isn't too fast (less than 3 times a second).\n 3. If it's flashing too much, either slow it down or make the flashing area smaller. You can also reduce the difference in brightness between the flashes.\n 4. For moving images, make sure they don't flash too quickly.\n 5. If something might cause a seizure, warn people before they see it, so they can choose not to watch it.\n Example: If a video has flashing lights, try to reduce the flashing or offer a version without the flashes. Or, warn people before they watch the video that it contains flashing lights.",
"passed_title": "Content does not flash over three times per second.",
"dev_description": "Content must not contain anything that flashes more than three times in any one-second period, or the flash must be below the general flash and red flash thresholds. This is because certain types of flashing can cause seizures. General flash and red flash thresholds are defined in WCAG 2.x. Specifically, avoid content that flashes at a rate between 2 Hz and 55 Hz; or if the flashing area exceeds certain spatial thresholds, flashing at even slower rates might trigger seizures. Ensure animations, videos, and any rapidly changing content adheres to these flashing thresholds. Use tools to analyze content for potential flashing violations.",
"layman_description": "Imagine watching a video or looking at a website where things flash on and off very quickly. For some people with epilepsy or other conditions, this rapid flashing can trigger a seizure, which is a sudden, uncontrolled electrical disturbance in the brain. This rule makes sure that websites and videos don't have flashing that's too fast or too bright, so they don't cause seizures in people who are sensitive to flashing lights. It's like making sure the lights aren't too intense for someone with a headache.",
"how_to_test": "1. Watch the page: Load the webpage and meticulously observe all content, including tiny elements, animations, videos, etc.\n 2. Identify ANY flashing: Look for anything that flashes (changes brightness or color rapidly), no matter how small or subtle.\n 3. Count the flashes: For any flashing element you find, try to count its flashes within a one-second period.\n 4. Evaluate (Strictly):\n - Pass: If absolutely no content flashes more than three times in any one-second period.\n - Fail: If any content, regardless of size or location, flashes more than three times per second. There are no exceptions for size or dimness at this Level AAA. (Specialized tools like PEAT can analyze video content precisely, but for manual checks, visual identification of rapid flashing is the key)."
},
{
"rule_id": "nonaxe-animation-from-interactions",
"standard_code": "2.3.3",
"Notes": null,
"issue_severity": "moderate",
"wcag_version_number": 2.1,
"wcag_level": "AAA",
"affected_disabilities_json": "Cognitive | Low vision | Attention Deficit",
"help": "Support user preferences for motion, and eliminate unnecessary motion effects.",
"title": "No option to disable animations triggered by user input",
"dev_help": "1. Identify any content on the page that flashes or flickers. 2. Use tools to measure the flash rate of the content. The flash rate should not exceed three times per second. 3. If the flash rate exceeds the threshold, either remove the flashing content or reduce the flash rate. 4. If flashing content is necessary, provide a warning to users and a mechanism to turn off the flashing content. Example: `<button onclick=\"stopFlashing()\">Stop Flashing</button>`. 5. Ensure that animations and transitions are smooth and do not involve rapid flickering.",
"help_url": "https://www.w3.org/WAI/WCAG22/Understanding/animation-from-interactions.html",
"description": "Users are not harmed or distracted by motion.",
"layman_help": "1. Check if anything on the website is flashing quickly. 2. If something is flashing too fast, either remove it or slow it down. 3. If you absolutely need to have something flashing, warn people about it beforehand. 4. Give people a way to stop the flashing if they want to. It's like having a 'turn off lights' button. 5. Make sure animations move smoothly instead of flickering rapidly.",
"passed_title": "Users can disable animations triggered by input.",
"dev_description": "Ensure that content does not contain anything that flashes more than three times in any one-second period, or the flash is below the general flash and red flash thresholds. This is to prevent seizures or physical reactions due to flashing content. Consider using animations or transitions that are subtle and do not involve rapid flickering or strobing effects. If flashing is necessary, provide a warning and a mechanism to turn off the flashing content. Use tools to measure the flash rate and ensure it is below the threshold.",
"layman_description": "Imagine watching a website and suddenly, images or animations start flashing rapidly, like a strobe light. For some people, especially those with epilepsy or light sensitivity, this flashing can trigger seizures or cause severe discomfort. This rule ensures that websites don't contain such rapid flashing. It's like making sure a TV show has a warning before a scene with flashing lights, so people who are sensitive can avoid it. By avoiding excessive flashing, websites become safer and more comfortable for everyone to use.",
"how_to_test": "1. Enable \"Reduce Motion\": Go into your operating system's accessibility settings (Windows, macOS, iOS, Android) and turn on the option called \"Reduce Motion,\" \"Remove Animations,\" or similar.\n 2. Interact with the Page: Visit the webpage and perform actions that might trigger animations:\n - Click buttons.\n - Hover over interactive elements.\n - Open menus or accordions.\n - Scroll the page (looking for parallax or scroll-triggered effects).\n - Submit forms.\n 3. Observe Animations: Did any interactions trigger noticeable motion (sliding, zooming, fading with movement, etc.)?\n 4. Check if Motion is Reduced: With your OS \"Reduce Motion\" setting enabled:\n - Are the animations completely turned off or replaced with simple, non-moving transitions (like a quick fade)?\n - If motion effects still occur despite the OS setting being on, the check likely fails. The website code should respect prefers-reduced-motion.\n 5. Look for a Website Toggle (Alternative): If respecting the OS setting isn't implemented, check if the website itself provides an accessibility setting or toggle (e.g., in a user profile or settings menu) to specifically \"Reduce Animations\" or \"Turn Off Motion Effects\" for the site. If this exists and works, it can also meet the requirement.\n 6. Consider Essential Animation: Is the animation absolutely essential to the function itself (e.g., an animation preview tool)? If so, it doesn't need to be turned off. But purely decorative animations (like celebratory effects after submitting a form) must be disableable.\n 7. Evaluate: If non-essential animations are triggered by user interaction and there's no way to turn them off (either via respecting the OS prefers-reduced-motion setting or a site-specific toggle), it fails this Level AAA check."
},
{
"rule_id": "bypass",
"standard_code": "2.4.1",
"Notes": null,
"issue_severity": "serious",
"wcag_version_number": 2,
"wcag_level": "A",
"affected_disabilities_json": "Blind | Low vision | Mobility | Cognitive",
"help": "Page must have means to bypass repeated blocks",
"title": "No mechanism to bypass repeated blocks of content",
"dev_help": "1. Implement a 'skip to content' link: Place a visually hidden link as the first focusable element on the page. This link, when activated, should move focus to the beginning of the main content area.\n \n\n \n \n\n 2. Use semantic HTML5 landmarks: Use elements like `<main>`, `<nav>`, `<aside>`, `<footer>`, and `<header>` to define the structure of your page. Assistive technologies can use these landmarks to provide quick navigation options.\n \n\n \n \n\n 3. ARIA landmarks (if semantic HTML5 isn't sufficient): If you can't use semantic HTML5, you can use ARIA `role` attributes to define landmarks.",
"help_url": "https://dequeuniversity.com/rules/axe/4.10/bypass?application=axeAPI",
"description": "Ensure each page has at least one mechanism for a user to bypass navigation and jump straight to the content",
"layman_help": "Website designers should add a 'skip to content' button at the top of each page. This button lets people quickly jump past the menus and other stuff that's the same on every page, right to the main information. They should also use clear labels to divide the page into sections, like a 'navigation' area, a 'main content' area, and a 'footer' area. This helps people using screen readers understand the layout of the page and find what they're looking for more easily.",
"passed_title": "Mechanisms let users bypass repeated content blocks.",
"dev_description": "Ensure each page has at least one mechanism for a user to bypass blocks of content that are repeated on multiple pages. This is typically achieved through 'skip links' that allow users to jump directly to the main content, or by using landmarks (e.g., `<main>`, `<nav>`, `<aside>`, `<footer>`, `<header>`) to structure the page, which can be navigated by assistive technologies. Without a bypass mechanism, users relying on assistive technologies may have to navigate through repetitive content like navigation menus on every page, leading to a frustrating experience.",
"layman_description": "Imagine reading a book where you have to read the table of contents before every chapter. It would be very annoying! This rule makes sure that people using screen readers or other assistive technology can easily skip repeated content like menus or headers on a website and go straight to the main part of the page. This makes it much faster and easier for them to use the site. For example, a blind person using a screen reader can jump directly to the main content instead of listening to the same navigation links on every page.",
"how_to_test": null
},
{
"rule_id": "nonaxe-section-headings",
"standard_code": "2.4.10",
"Notes": null,
"issue_severity": "minor",
"wcag_version_number": 2,
"wcag_level": "AAA",
"affected_disabilities_json": "Blind | Low vision | Cognitive",
"help": "Where content is organized in sections, provide section headings.",
"title": "Section headings are not clear or meaningful for organizing content",
"dev_help": "1. Use heading elements (<h1> to <h6>) to structure content logically. The most important heading should be <h1>, followed by <h2> for major sections, and so on.\n 2. Ensure headings accurately reflect the content of the section they introduce.\n 3. Avoid using heading elements for purely visual styling; use CSS for that purpose.\n 4. Check for heading order. Don't skip heading levels, like jumping from <h1> to <h3>.\n Example:",
"help_url": "https://www.w3.org/WAI/WCAG22/Understanding/section-headings.html",
"description": "Users understand how content is organized in sections.",
"layman_help": "Think of headings as the titles and subtitles in a book. To fix this problem:\n 1. Use titles (headings) to organize the information on the page. The most important title should be the biggest (like the book title), and the less important ones should be smaller (like chapter titles).\n 2. Make sure the titles accurately describe what the section is about.\n 3. Don't use titles just to make the text look bigger or bolder. Use other ways to style the text.\n 4. Make sure your headings are in the right order. Don't skip levels, like going straight from a main title to a sub-subtitle.",
"passed_title": "Section headings are clear and meaningful.",
"dev_description": "Ensure that sections within web pages are clearly delineated using appropriate headings (<h1> to <h6>). Headings should accurately describe the content of the section they introduce. Consistent and logical heading structures aid navigation and understanding, especially for users relying on assistive technologies. Improper or missing headings can lead to confusion and difficulty in comprehending the page's organization.",
"layman_description": "Imagine reading a book without chapter titles or subtitles. It would be hard to understand how the book is organized and where to find specific information. Website sections are like chapters, and headings (like titles and subtitles) help organize content. This guideline says that website sections should have clear headings so that everyone, especially people who use screen readers or have trouble focusing, can easily understand the website's structure and find what they're looking for.",
"how_to_test": "1. Identify Content Sections: Look at the main written content on the page (articles, long descriptions, guides, etc.). Is the information naturally divided into distinct topics or sections?\n 2. Look for Headings: Check if each distinct section of content is preceded by a heading. Visually, these are often larger, bold text lines. (Technically, they should be marked up with <h1>-<h6> tags for SC 1.3.1, but this check focuses on their presence and descriptive quality for organization). \n 3. Check Heading Clarity: Read the heading text for each section. Does it accurately describe or introduce the content that follows? \n 4. Evaluate:\n - Pass: Content that is logically organized into sections uses headings to introduce those sections.\n - Fail: If long content covering different topics is presented as one continuous block without headings, or if the content is clearly sectionalized visually but lacks actual headings to demarcate those sections."
},
{
"rule_id": "nonaxe-focus-not-obscured-minimum",
"standard_code": "2.4.11",
"Notes": null,
"issue_severity": "minor",
"wcag_version_number": 2.2,
"wcag_level": "AA",
"affected_disabilities_json": "Low vision | Cognitive | Mobility",
"help": "Ensure when an item gets keyboard focus, it is at least partially visible.",
"title": "Focused elements are completely hidden by other content",
"dev_help": "1. Check for elements that might overlap or cover the focused element when it receives focus, such as modals, sticky headers, or other dynamically positioned elements.\n 2. Use CSS to ensure that the focused element remains visible. Techniques include:\n * Adjusting the `z-index` of the focused element to bring it to the front.\n * Modifying the positioning of overlapping elements to move them out of the way.\n * Adding padding or margin to the focused element to ensure it is not covered.\n 3. Test with keyboard navigation to verify the focused element remains visible in all states and resolutions.\n Example: Suppose a sticky header overlaps a focused link. The fix would be to either temporarily hide the sticky header when the link receives focus, or adjust the link's position to ensure it's always visible.",
"help_url": "https://www.w3.org/WAI/WCAG22/Understanding/focus-not-obscured-minimum.html",
"description": "Keep the focused item visible.",
"layman_help": "1. Check if anything on the screen covers up the highlighted item when you select it with the keyboard. This could be a bar at the top of the page or a pop-up window.\n 2. If something is covering the highlighted item, you need to make sure the highlighted item is always on top. You can also move the thing that's covering it out of the way or make the highlighted area bigger so you can always see it.\n 3. Test using only your keyboard to make sure that the highlighted area is always visible on different screen sizes.",
"passed_title": "Focused elements are not hidden by other content.",
"dev_description": "Ensure that when a user interface component receives focus, the focused element is not entirely hidden or obscured by author-created content. A portion of the focused element must be visible to the user. This is crucial for keyboard users who rely on the focus indicator to navigate the page. The minimum area of the focused element should be at least large enough to distinguish the focused element from its surroundings.",
"layman_description": "Imagine using a website with just your keyboard. When you press 'tab' to move between buttons and links, a highlight appears around the thing you've selected. This is the 'focus indicator.' This rule says that the highlight and at least part of the button or link it's highlighting, must always be visible. It shouldn't be hidden by something else on the page because If the focus indicator or the focused item is hidden, keyboard users won't know where they are on the page, making it very difficult to use the website.",
"how_to_test": "1. Identify Sticky/Overlapping Elements: Look for any parts of the page that stay in a fixed position when you scroll (sticky headers/footers/sidebars) or elements that might pop up and overlap content (cookie banners, non-modal dialogs, chat widgets).\n 2. Navigate Near Edges: Use the Tab key to move focus through interactive elements on the page. Pay special attention to elements located directly below a sticky header, directly above a sticky footer, or near other potentially overlapping elements.\n 3. Check Visibility on Focus: When an element near one of these sticky/overlapping components receives keyboard focus, look closely at its focus indicator (the outline or highlight).\n - Check: Is at least some part of the focused element (or its indicator) visible?\n 4. Test Scrolling: Scroll the page up and down while an element near a sticky header/footer has focus. Does the sticky element completely cover the focused element and its indicator at any point during scrolling?\n 5. Evaluate:\n - Pass: The focused element is always at least partially visible. Overlapping content (like sticky headers) never completely hides the entire element receiving focus.\n - Fail: If any author-created content (like a sticky header, footer, or banner) completely covers the element receiving keyboard focus at any time."
},
{
"rule_id": "nonaxe-focus-not-obscured-enhanced",
"standard_code": "2.4.12",
"Notes": null,
"issue_severity": "moderate",
"wcag_version_number": 2.2,
"wcag_level": "AAA",
"affected_disabilities_json": "Low vision | Mobility | Cognitive",
"help": "Ensure when an item gets keyboard focus, it is fully visible.",
"title": "Keyboard focus indicators are obscured by other content",
"dev_help": "1. Identify elements that receive focus and check if any other content overlaps or obscures them when focused.\n 2. Adjust the positioning or z-index of overlapping elements using CSS to ensure the focused element is always fully visible.\n 3. If overlapping is intentional, consider alternative designs to avoid obscuring focused elements.\n 4. Ensure sufficient padding or margins are applied to the focused element to prevent overlapping with adjacent elements.\n 5. Test with keyboard navigation to confirm that the focused element remains visible and unobstructed throughout the interaction.",
"help_url": "https://www.w3.org/WAI/WCAG22/Understanding/focus-not-obscured-enhanced.html",
"description": "Don't cover any part of the item with focus.",
"layman_help": "1. Check if anything on the page covers up the item you're currently using (like when you're using a keyboard to move around).\n 2. If something is covering it, move that thing out of the way so you can see the selected item clearly.\n 3. Make sure there's enough space around the selected item so nothing bumps into it and hides it.\n 4. Try using the website with just a keyboard to make sure the item you're on is always easy to see.",
"passed_title": "Focus indicators remain visible and unobscured.",
"dev_description": "Ensure that when an element receives focus (e.g., through keyboard navigation or tabbing), no part of the focused element is obscured or hidden by other content. This is to prevent loss of context and ensure the user can clearly see and interact with the focused element. Overlapping content can cause confusion and hinder the ability to use the interface effectively. The element with focus should be fully visible, or at least have a clearly visible indication of focus that is not obscured.",
"layman_description": "Imagine you're using a website with a keyboard and as you move between items, the currently selected item is partially hidden by other stuff on the page. This makes it hard to see what you've selected and what you can do with it. This rule makes sure that when you select something on a website, it's fully visible and not covered up, so everyone, especially people with vision or motor skill issues, can easily use the site.",
"how_to_test": "1. Identify Sticky/Overlapping Elements: Look for sticky headers, footers, sidebars, cookie banners, chat widgets, etc.\n 2. Navigate Near Edges: Use the Tab key to move focus through interactive elements, especially those located just below a sticky header, just above a sticky footer, or near other potentially overlapping content.\n 3. Check Full Visibility on Focus: When an element near one of these sticky/overlapping components receives keyboard focus, look very closely at the focused element and its indicator.\n - Check: Is the entire element, including its entire focus indicator, fully visible? Or is even a small part covered by the sticky/overlapping content?\n 4. Test Scrolling: Scroll the page up and down while an element near a sticky header/footer has focus. Does the sticky element cover any part of the focused element or its indicator during scrolling? (Using CSS scroll-padding can help prevent this).\n 5. Check Modals: If activating an element opens a modal dialog, ensure the dialog itself is fully visible and that focus is properly contained within it (preventing focus from landing on obscured elements behind it).\n 6. Evaluate:\n Pass: The focused element and its indicator are always fully visible and never obscured, even partially, by author-created content like sticky elements.\n Fail: If any part of the element receiving keyboard focus (or its focus indicator) is covered by author-created content at any time."
},
{
"rule_id": "nonaxe-focus-appearance",
"standard_code": "2.4.13",
"Notes": null,
"issue_severity": "moderate",
"wcag_version_number": 2.2,
"wcag_level": "AAA",
"affected_disabilities_json": "Low vision | Mobility | Cognitive",
"help": "Use a focus indicator of sufficient size and contrast.",
"title": "Keyboard focus indicators lack visibility, size, or contrast",
"dev_help": "1. Ensure a visible focus indicator is present for all interactive elements. \n 2. Make sure the contrast ratio between the focus indicator and its adjacent background is at least 3:1.\n 3. If using an area around the control to indicate focus, ensure the area meets minimum size requirements (border of 1 CSS pixel thick).\n 4. Avoid using CSS styles that remove or obscure the default focus indicator (e.g., outline: none; without providing an alternative).\n Example:",
"help_url": "https://www.w3.org/WAI/WCAG22/Understanding/focus-appearance.html",
"description": "Make it easier to spot the keyboard focus.",
"layman_help": "1. Make sure that when you use a keyboard to navigate, you can clearly see a highlight around the item you are currently on.\n 2. This highlight should be a color that stands out clearly against the background so it's easy to see.\n 3. Don't remove the default highlight provided by the website (usually a blue or gray outline) unless you replace it with something that is even easier to see.\n 4. If the highlight is hard to see, ask the website developers to improve the color contrast or make the highlight thicker.",
"passed_title": "Focus indicators have visibility, size, and contrast.",
"dev_description": "The visual focus indicator must be sufficiently noticeable to users. When a user navigates a webpage using a keyboard or assistive technology, a visual focus indicator should be present for each interactive element (e.g., links, buttons, form fields). The focus indicator needs to meet specific contrast requirements to ensure visibility against the adjacent background. Specifically, the focus indicator must have a contrast ratio of at least 3:1 between the focused and unfocused states or meet the following condition. Focus indicators should have a minimum area equal to the area of the border of a 1 CSS pixel thick rectangle around the unfocused control. It’s crucial to ensure that the focus indicator’s style is not obscured or hidden by author-defined styles.",
"layman_description": "When you use a keyboard to move around a website, there should be a clear visual cue (like a highlighted border) showing which part of the page you're currently on. This is called the focus indicator. This indicator needs to be easy to see, meaning it should stand out from the surrounding colors and elements. If the focus indicator is not visible or hard to see, people with low vision or those who rely on keyboard navigation may have difficulty understanding where they are on the page and interacting with the content.",
"how_to_test": "1. Navigate with Keyboard: Use the Tab key to move focus to various interactive elements (buttons, links, inputs, custom controls, menu items, etc.).\n 2. Assess Indicator Size:\n - Look at the focus indicator that appears. Does it look reasonably substantial?\n - Verification: The simplest way to pass is using a solid outline that is at least 2 CSS pixels thick. If a different style is used (e.g., background change, thicker underline), you'd technically need to calculate if its area meets the \"2px perimeter\" rule, which is complex. For manual checks, look for indicators that are clearly visible and substantial – a 1px dotted line likely fails, while a 2px solid outline likely passes the size check.\n 3. Assess Contrast Change:\n - Use browser developer tools (\"Inspect\") to identify the color values involved.\n - Compare Focused vs. Unfocused: You need to compare the color of the pixels making up the focus indicator when focused with the color of those exact same pixels when the element is not focused.\n - Use Contrast Tool: Use a color contrast analyzer to check the ratio between these two colors (focused state pixel vs. unfocused state pixel).\n - Check Ratio: Is the contrast ratio at least 3:1? This must apply to an area of the indicator that meets the minimum size requirement (from step 2). For example, if a 2px blue outline appears on a white background, the change is white (#FFF) to blue (#00F), which has high contrast. If a button changes from light gray to slightly darker gray, the contrast change might be less than 3:1 and fail.\n 4. Check Exceptions: Does the site appear to be using unmodified browser default focus indicators and has it not modified the adjacent background colors in a way that reduces the indicator's visibility? If yes, the check passes due to the exception. If the author has customized the indicator (outline, border, background-color on focus) or its adjacent background, the size and contrast change rules must be met.\n 5. Evaluate: The check fails if the focus indicator does not meet both the minimum size requirement AND the minimum 3:1 contrast change requirement (unless the user agent default exception applies)."
},
{
"rule_id": "document-title",
"standard_code": "2.4.2",
"Notes": null,
"issue_severity": "serious",
"wcag_version_number": 2,
"wcag_level": "A",
"affected_disabilities_json": "Blind | Low vision | Cognitive",
"help": "Documents must have <title> element to aid in navigation",
"title": "Web page lacks a clear and descriptive title",
"dev_help": "1. Open the HTML file in a text editor.\n 2. Locate the `<head>` section of the document.\n 3. Ensure there is a `<title>` tag within the `<head>` section.\n 4. The `<title>` tag should contain descriptive and unique text that accurately reflects the page's content. For example, instead of `<title>Home `, use `Example Company - Home Page `.\n 5. Make sure the title is not empty: ` element",
"layman_help": "Think of the page title as the name tag for a webpage. If a webpage doesn't have one, it's like a person walking around without a name! To fix this, the website owner needs to add a short description inside the website's code that explains what the page is all about. This description should appear at the very top of the browser window. Each page of the website should have a unique short description.",
"passed_title": "Each page has a clear, descriptive title.",
"dev_description": "Every HTML document should have a descriptive and unique `<title>` element within the `<head>` section. The title provides a concise summary of the page's content. Assistive technologies, such as screen readers, rely on the title to announce the current page. A missing, empty, or generic title can disorient users, especially those using assistive technologies.",
"layman_description": "Imagine a book without a title. You wouldn't know what it's about! Similarly, a webpage needs a title to tell you what it is. The title appears in the tab of your browser and is read out loud by screen readers for blind people. Without a good title, people who are blind or have trouble understanding the page's content might get lost or confused.",
"how_to_test": null
},
{
"rule_id": "nonaxe-focus-order",
"standard_code": "2.4.3",
"Notes": null,
"issue_severity": "moderate",
"wcag_version_number": 2,
"wcag_level": "A",
"affected_disabilities_json": "Blind | Low vision | Mobility | Cognitive",
"help": "Elements receive focus in an order that preserves meaning.",
"title": "Keyboard focus does not follow a logical, meaningful sequence",
"dev_help": "1. Review the tab order: Manually tab through the page to identify any illogical jumps or skips in the focus order.\n 2. Correct 'tabindex' values: Use 'tabindex=\"0\"' to include elements in the natural tab order. Use 'tabindex=\"-1\"' to remove elements from the tab order temporarily. Avoid using positive 'tabindex' values (e.g., 'tabindex=\"1\"', 'tabindex=\"2\"') as they can create a confusing and difficult-to-manage focus order. It's much better to reorder the elements in the DOM to change the tabbing order.\n 3. Ensure visual and focus order match: Make sure the visual order of elements aligns with the DOM order. If CSS is used to reposition elements, test the focus order to ensure it still makes sense.\n 4. Avoid keyboard traps: Ensure users can always navigate away from any focused element using the keyboard. This often occurs when focus is programmatically set.\n 5. Test with assistive technologies: Test the tab order with screen readers to confirm that the announced content matches the visual order and makes sense.\n Example: To ensure a custom component is focusable, add 'tabindex=\"0\"' to its root element. To temporarily remove an element from the tab order, set 'tabindex=\"-1\"'.",
"help_url": "https://www.w3.org/WAI/WCAG22/Understanding/focus-order.html",
"description": "Keyboard users navigate content in a correct order.",
"layman_help": "1. Check the order: Use the 'Tab' key to go through each item on the page. See if the order makes sense. Does it follow what you see on the screen?\n 2. Fix the order: If the order is wrong, the website developer needs to adjust the 'Tab' key order. They can do this by changing the website's code so that the 'Tab' key moves you through the content in a logical way.\n 3. Make sure you don't get stuck: Ensure you can always move forward on the page using the 'Tab' key. You shouldn't get stuck on any one element.\n 4. Test with a screen reader: Ask someone who uses a screen reader (a tool that reads the screen aloud) to test the website to see if it makes sense.",
"passed_title": "Keyboard focus follows a logical, meaningful order.",
"dev_description": "Ensure that the focus order of interactive elements (links, form fields, buttons, etc.) follows a logical sequence that preserves meaning and operability. The focus order should generally follow the visual layout of the page. Use the 'tabindex' attribute judiciously to control the focus order, but avoid using it to create unnatural or confusing navigation patterns. Ensure that elements receive focus in a predictable and intuitive manner. If the visual order is disrupted (e.g., through CSS positioning), ensure that the focus order still makes sense. If using Javascript to change focus, make sure it is done correctly to avoid keyboard traps.",
"layman_description": "Imagine using only your keyboard to navigate a website. This rule ensures that when you press the 'Tab' key, you move through the website's content in a way that makes sense – like reading a book from left to right, top to bottom. If the 'Tab' key takes you to elements in a random or illogical order, it can be very confusing and frustrating, especially for people who can't use a mouse, such as individuals with mobility impairments or who are blind and rely on screen readers. The focus order needs to match the order that items appear on the page so people can understand and use the page.",
"how_to_test": "1. Start Tabbing: Click near the top of the page (e.g., in the address bar) and then press the Tab key repeatedly.\n 2. Observe Focus Movement: Watch where the visual focus indicator (the outline or highlight) moves with each Tab press.\n 3. Check Logical Flow:\n - Does the focus generally move from top-to-bottom and left-to-right (in English)?\n - Does it move through items in a sensible sequence (e.g., through navigation links in order, then into the main content, through form fields sequentially)?\n - Are there any weird jumps (e.g., from the first form field to the submit button, then back to the second field)?\n - Does Shift + Tab move focus backward in a logical reverse order?\n 4. Test Dynamic Content: If activating an element (like a button) reveals new content (like a modal dialog or dropdown menu):\n - Does focus move logically into the new content immediately after activation?\n - When the new content is closed (e.g., pressing Esc on a modal), does focus return predictably (usually to the element that triggered it)?\n 5. Check for tabindex Issues (Advanced): If the focus order seems very strange, you can use developer tools to inspect elements. Look for positive tabindex values (e.g., tabindex=\"1\", tabindex=\"5\"). Using positive values often causes illogical focus order and should generally be avoided (use tabindex=\"0\" only if needed to make custom elements focusable, or -1 to make them focusable only via script).\n 7. Evaluate: If the focus order is illogical, unpredictable, or prevents users from easily reaching all interactive content in a sensible sequence, it fails this check."
},
{
"rule_id": "link-name",
"standard_code": "2.4.4",
"Notes": null,
"issue_severity": "serious",
"wcag_version_number": 2,
"wcag_level": "A",
"affected_disabilities_json": "Blind | Low vision | Cognitive",
"help": "Links must have discernible text",
"title": "Links lack clear, descriptive text or accessible names",
"dev_help": "1. Replace generic link text with descriptive text that accurately reflects the link's destination.\n 2. If using images or icons as links, provide alternative text (alt attribute) that describes the link's purpose. For example, instead of `<a href='/home'><img src='home.png' alt='Home'></a>`, use `<a href='/home'>Home</a>` or ensure `alt='Go to the home page'` is descriptive.\n 3. Use `aria-label` or `aria-labelledby` to provide an accessible name if descriptive text cannot be included directly within the link.\n 4. Ensure that the visual presentation of the link (e.g., color, underline) is sufficient to distinguish it from surrounding text.",
"help_url": "https://dequeuniversity.com/rules/axe/4.10/link-name?application=axeAPI",
"description": "Ensure links have discernible text",
"layman_help": "1. Change vague link text like 'click here' to something more specific, such as 'Read more about our services'.\n 2. If a link is an image, make sure the image has alt text that describes where the link goes. For example, if the image is a house and it links to the homepage, the alt text should be 'Go to the home page'.\n 3. If you can't change the link text directly, you can add a hidden label that screen readers can read. Ask your developer to help you with this.\n 4. Make sure links are easy to spot on the page. They should be a different color or underlined.",
"passed_title": "Links have clear, descriptive text or names.",
"dev_description": "Ensure that each link has descriptive text that clearly indicates the destination or function of the link. Avoid generic text like 'click here' or 'read more' without additional context. The link text should be unique and understandable within the context of the surrounding content. Use aria-label or aria-labelledby to provide accessible names for links that use icons or images.",
"layman_description": "Imagine browsing a website and encountering many 'click here' links. How would you know where each link leads? This rule ensures that all links have clear and descriptive text, so everyone, including people using screen readers, can easily understand the purpose of each link and navigate the website effectively. Without descriptive link text, it's difficult for people with disabilities to understand where a link will take them.",
"how_to_test": null
},
{
"rule_id": "area-alt",
"standard_code": "2.4.4",
"Notes": null,
"issue_severity": "critical",
"wcag_version_number": 2,
"wcag_level": "A",
"affected_disabilities_json": "Blind | Low vision | Cognitive",
"help": "Active <area> elements must have alternate text",
"title": "Clickable image map areas lack descriptive alternative text",
"dev_help": "1. Identify all `<map>` elements and their corresponding `<img>` elements using the `usemap` attribute.\n 2. For each `<area>` element within the `<map>`, ensure that the `alt` attribute is present.\n 3. Provide a concise and meaningful description in the `alt` attribute that accurately reflects the destination or function of the link.\n 4. If an area doesn't navigate anywhere, use `alt=\"\"` to indicate that it is intentionally blank, this prevents screen readers from announcing the image as a link.\n \n\n Example:",
"help_url": "https://dequeuniversity.com/rules/axe/4.10/area-alt?application=axeAPI",
"description": "Ensure <area> elements of image maps have alternate text",
"layman_help": "When a picture has clickable zones, each zone needs a text description. Check each of these clickable zones in the image. Add a short, descriptive text for each one, explaining where that click will lead. If a clickable zone doesn't do anything, make sure it has a blank description so that screen readers don't get confused.",
"passed_title": "Clickable image maps have descriptive alt text.",
"dev_description": "Ensure that all `<area>` elements within `<map>` elements (image maps) have meaningful `alt` attributes. The `alt` attribute provides alternative text descriptions for each clickable area of the image, allowing users who cannot see the image to understand the purpose and destination of each link. Missing or inadequate `alt` text hinders accessibility for screen reader users and those with low vision.",
"layman_description": "Imagine a picture on a website where you can click on different parts of it to go to different pages. These clickable areas need descriptions (called 'alt text') so that people who can't see the picture (like those using screen readers) know where each click will take them. Without these descriptions, they won't be able to use the picture map, making the website confusing and unusable for them. It's like having a map with no labels.",
"how_to_test": null
},
{
"rule_id": "nonaxe-multiple-ways",
"standard_code": "2.4.5",
"Notes": null,
"issue_severity": "moderate",
"wcag_version_number": 2,
"wcag_level": "AA",
"affected_disabilities_json": "Blind | Low vision | Mobility | Cognitive",
"help": "Provide at least two options for reaching the same content.",
"title": "No multiple ways provided to locate each page within the site",
"dev_help": "1. Ensure a sitemap is present and linked. A sitemap provides a comprehensive list of all pages on the website.\n 2. Implement a search function. A search function allows users to directly query the content of the website.\n 3. Provide clear and consistent navigation menus. Navigation menus should be easy to understand and consistently placed throughout the website.\n 4. Use breadcrumbs. Breadcrumbs show the user's current location in the website's hierarchy.\n Example: `<nav aria-label=\"Breadcrumb\"> <ol> <li><a href=\"/\">Home</a></li> <li><a href=\"/products\">Products</a></li> <li>Current Page</li> </ol> </nav>`",
"help_url": "https://www.w3.org/WAI/WCAG22/Understanding/multiple-ways.html",
"description": "Users can get to content in multiple ways.",
"layman_help": "1. Look for a list of all the website's pages (called a sitemap). \n 2. Check if there's a search bar where you can type what you're looking for.\n 3. See if the website has menus that are easy to understand and in the same place on every page.\n 4. See if the website uses 'breadcrumbs' (like a trail of links) to show you where you are on the site.",
"passed_title": "Multiple ways exist to locate pages on the site.",
"dev_description": "Provide more than one way to locate a web page within a set of web pages except where the Web Page is the result of, or a step in, a process.",
"layman_description": "Imagine a website as a big house. This rule means there should be more than one way to find what you're looking for. Like having both a staircase and an elevator. For example, you should be able to find a page through the website's menu and through a search bar. This is helpful for people who might have trouble using a mouse, remembering where things are, or understanding the site's layout. If a website only has one way to find something, like only using a complicated menu, some users might get lost or give up.",
"how_to_test": "1. Identify Navigation Methods: Look across the website (on multiple pages like the homepage, content pages, etc.). What methods are available for finding other pages?\n - Is there a main navigation menu?\n - Is there a site search bar/feature?\n - Is there a link to a sitemap?\n - Are there links within the content connecting related pages or sections?\n - Are there breadcrumbs?\n - Is there a table of contents (for very long pages)?\n 2. Count the Ways: Verify that at least two distinct site-wide navigation or page-finding mechanisms are present. For example, having just a main menu is not enough; you might need a main menu and a search function, or a main menu and a sitemap.\n 3. Consider Exceptions: If you're looking at a page that's clearly part of a defined sequence (like step 3 of a 4-step checkout), it doesn't need to meet this requirement itself.\n 4. Evaluate: If users can only find pages through one single method (e.g., only via the main navigation menu, with no search, sitemap, or other relevant links), the check fails."
},
{
"rule_id": "nonaxe-headings-and-labels",
"standard_code": "2.4.6",
"Notes": null,
"issue_severity": "moderate",
"wcag_version_number": 2,
"wcag_level": "AA",
"affected_disabilities_json": "Blind | Low vision | Cognitive",
"help": "Provide descriptive headings and labels",
"title": "Headings and labels do not accurately describe their purpose",
"dev_help": "1. Use semantic HTML (<h1> to <h6>) to create a clear heading structure.\n 2. Ensure heading levels are nested logically (e.g., <h1> followed by <h2>, not <h1> followed by <h3>).\n 3. Use the `<label>` element to associate labels with form controls. Use the 'for' attribute to link the label to the form control's 'id' attribute (e.g., `<label for=\"name\">Name:</label><input type=\"text\" id=\"name\">`).\n 4. If a visible label is not appropriate, provide an accessible name using aria-label or aria-labelledby.\n 5. Test with a screen reader to confirm the heading structure and label associations are correctly announced.",
"help_url": "https://www.w3.org/WAI/WCAG22/Understanding/headings-and-labels.html",
"description": "A page's content is described in headings and labels",
"layman_help": "1. Make sure each section of the website has a clear title or heading that tells you what it's about.\n 2. If there are forms to fill, each box should have a clear instruction or label explaining what information is needed.\n 3. Website developers can use special codes to link the labels to the correct boxes. If a box doesn't have a label, there is a way to add a hidden one that screen readers can still understand.",
"passed_title": "Headings and labels clearly describe their purpose.",
"dev_description": "Ensure that headings (<h1> to <h6>) are used to structure content logically and accurately reflect the topic of each section. Labels for form controls (e.g., <label> for <input>, <select>, <textarea>) should be descriptive and accurately identify the purpose of the associated form element. Avoid using headings for purely presentational purposes. Ensure labels are programmatically associated with their respective form elements using the 'for' attribute.",
"layman_description": "Imagine reading a book without chapters or titles. It would be hard to understand what each part is about! Similarly, on a website, headings act like titles, telling you what each section contains. Labels on forms are like instructions that tell you what information is needed in each box (like your name or email). If a website doesn't have clear headings and labels, it's like trying to find your way in a dark room. People with visual impairments or cognitive disabilities rely on these headings and labels to understand and navigate the content effectively. Without them, it can be very confusing and frustrating to use the website.",
"how_to_test": "1. Review Headings:\n - Identify the headings used to organize content sections on the page (these should ideally be marked up with <h1> to <h6> tags - which relates to SC 1.3.1, but here we focus on the text content).\n - Read each heading. Does it accurately summarize or describe the topic of the content that immediately follows it? Vague headings like \"More Info\" or \"Section 3\" likely fail if they don't adequately describe the section's purpose.\n 2. Review Labels:\n - Identify all interactive elements like form fields (<input>, <textarea>, <select>) and buttons (<button>, <input type=\"submit\">, etc.).\n - Look at their visible labels (often <label> elements, or button text).\n - Does the label clearly explain what information is needed for an input field? (e.g., \"First Name\", not just \"Name\" if there's also a \"Last Name\" field).\n - Does the label/text on a button clearly describe the action it performs? (e.g., \"Search Products\", not just \"Go\").\n 3. Evaluate:\n - Pass: Headings accurately describe their sections, and labels clearly identify the purpose or required input for controls.\n - Fail: Headings are vague or misleading. Labels are unclear, ambiguous, or missing for form fields or buttons."
},
{
"rule_id": "nonaxe-focus-visible",
"standard_code": "2.4.7",
"Notes": null,
"issue_severity": "moderate",
"wcag_version_number": 2,
"wcag_level": "AA",
"affected_disabilities_json": "Blind | Low vision | Mobility | Cognitive",
"help": "Ensure each item receiving focus has a visible indicator.",
"title": "Keyboard focus indicators are not clearly visible",
"dev_help": "1. Identify focusable elements: Determine all interactive elements on the page that can receive focus (e.g., `<a>`, `<button>`, `<input>`, `<select>`, `<textarea>`).\n 2. Check for existing focus styles: Examine the default focus styles provided by the browser. Often, these are sufficient, but they might need enhancement for better visibility or to match the website's design.\n 3. Add or modify focus styles: If the default styles are insufficient or need customization, use CSS to add or modify focus styles. Use the `:focus` pseudo-class. Example: `a:focus { outline: 2px solid blue; }`. Ensure sufficient contrast between the focus indicator and the surrounding elements. Use tools to check the contrast ratio.\n 4. Avoid `outline: none` without replacement: If you remove the default outline using `outline: none`, provide an alternative, highly visible focus indicator. Example: `a:focus { outline: none; box-shadow: 0 0 5px blue;}`.\n 5. Test thoroughly: Test keyboard navigation with different browsers and zoom levels to ensure the focus indicator is consistently visible and usable.",
"help_url": "https://www.w3.org/WAI/WCAG22/Understanding/focus-visible.html",
"description": "Users know which element has keyboard focus.",
"layman_help": "1. Find interactive elements: Identify all the clickable things on the page like buttons, links, and boxes where you can type.\n 2. Check how they look when selected: When you use the keyboard to select these elements, see if there's a clear visual change that shows it's selected (like a border or color change).\n 3. Make the selection obvious: If it's not clear enough, add a visual change to make it very obvious which element is selected. For example, add a thick border or change the background color when the element is selected.\n 4. Don't remove the selection indicator without replacing it: If you remove the default selection indicator, make absolutely sure to add a different one that's very easy to see.\n 5. Test it out: Use only your keyboard to move around the page and make sure you can always clearly see which element is selected. Try this on different browsers to make sure it works everywhere.",
"passed_title": "Keyboard focus indicators are clearly visible.",
"dev_description": "Ensure that any element which can receive focus via keyboard input (e.g., links, form fields, buttons) has a visible focus indicator. This indicator should be sufficiently distinct from the element's default state in terms of color, contrast, size, and/or shape. The focus indicator must not be fully obscured or hidden by author-defined styles. The focus indicator should remain visible until the focus moves to another element. It's crucial to test with various browsers as default focus styles may differ. Use CSS properties like `outline`, `box-shadow`, or `border` to define focus styles. Avoid removing the focus indicator entirely using `outline: none` without providing an alternative.",
"layman_description": "When you use a keyboard to navigate a website, a visual cue should clearly show which element currently has focus (is selected). This could be a border, a change in color, or some other indicator. Without this clear indicator, people with visual impairments or those who rely on keyboard navigation may not be able to tell where they are on the page, making it difficult or impossible to use the website. Imagine trying to find your way through a building in the dark; the focus indicator is like a flashlight that shows you where you are.",
"how_to_test": "1. Click on the Page: Click anywhere on the webpage body or address bar first to ensure the window is active.\n 2. Press Tab Repeatedly: Use the Tab key to move forward through all interactive elements (links, buttons, form fields, menu items, etc.). Use Shift + Tab to move backward.\n 3. Look for the Indicator: As each element receives focus, look closely. Is there any visual change indicating it's the active element? Common indicators include:\n - An outline appearing around the element (often blue or black by default, but can be custom styled).\n - A change in background color.\n - A change in text color or style (e.g., becoming underlined).\n 4. Check ALL Elements: Make sure every single interactive element shows some kind of visible indicator when focused. Pay attention to custom controls or areas where default browser styles might have been turned off (a common mistake using outline: none; in CSS).\n 5. Evaluate:\n Pass: Every interactive element shows a visible indicator when it receives keyboard focus.\n Fail: Any interactive element receives keyboard focus but shows no visual change whatsoever. (Note: How clear or obvious the indicator is relates to newer criteria like SC 2.4.11 Focus Appearance, but this check, 2.4.7, simply requires that some indicator is visible)."
},
{
"rule_id": "nonaxe-location",
"standard_code": "2.4.8",
"Notes": null,
"issue_severity": "minor",
"wcag_version_number": 2,
"wcag_level": "AAA",
"affected_disabilities_json": "Blind | Low vision | Cognitive",
"help": "Use breadcrumbs, site maps, or other indicators to give context.",
"title": "Users cannot determine their location within the site",
"dev_help": "1. Implement breadcrumb navigation: Add a breadcrumb trail showing the user's path from the homepage to the current page. Example: Home > Products > Electronics > Headphones. \n 2. Ensure the current page is clearly indicated: Make sure the current page in the breadcrumb trail or navigation is visually distinct (e.g., bolded or different color).\n 3. Provide a site map: Offer a site map page that outlines the entire website structure.\n 4. Use clear and consistent navigation: Ensure the primary navigation clearly reflects the site's information architecture.",
"help_url": "https://www.w3.org/WAI/WCAG22/Understanding/location.html",
"description": "Users know where they are in a set of pages.",
"layman_help": "1. Add a 'trail' of links: Like Hansel and Gretel, leave a trail of links (called breadcrumbs) at the top of the page that shows the path you took to get there (e.g., Home > Products > Shoes > Running Shoes).\n 2. Highlight where you are: Make the current page in the trail stand out (like making it bold) so you know exactly where you are.\n 3. Have a website map: Provide a page that shows the entire layout of the website, like a map of a park, so you can see all the different areas.\n 4. Keep the website easy to use: Make sure the way you move around the website makes sense, so it's always easy to find your way.",
"passed_title": "Users can identify their location within the site.",
"dev_description": "WCAG 2.4.8 (Location): Each page in a set of web pages should have a mechanism to indicate the current page's location within the site's information architecture. This helps users understand where they are within the site's navigation. Implement breadcrumb navigation, site maps, or other means of indicating the user's location within the website.",
"layman_description": "Imagine you're in a library with many rooms and books. WCAG 2.4.8 is like having signs that tell you exactly where you are in the library. For example, a breadcrumb trail on a website tells you which pages you've clicked to get to where you are now. This helps people, especially those with vision problems or who have trouble remembering where they are on a website, to navigate more easily and not get lost.",
"how_to_test": "1. Identify Page Sets: Find groups of related pages on the website. This could be:\n - Pages within a specific section (e.g., all pages under \"About Us\").\n - Steps in a process (e.g., checkout, registration, multi-page tutorial).\n - A sequence of articles or chapters.\n 2. Navigate Through the Set: Go through several pages within the identified set.\n 3. Look for Location Cues: On each page within the set, look for at least one clear indicator of your current position. Check for:\n - Breadcrumbs: Is there a breadcrumb trail near the top showing your path? Are the links correct?\n - Navigation Highlighting: Is the current page visually highlighted (e.g., different background, bold text) in the main navigation menu or any relevant sidebar menu?\n - Step Indicators: In a process, is there text like \"Step X of Y\"?\n - Contextual Titles/Headings: Does the page <h1> or <title> clearly indicate the specific page's place within the set (e.g., \"Contact Us\" within the \"About Us\" section)?\n - Site Map Access: Is there a link to a site map easily available from the page? (Less direct, but can contribute if the sitemap itself is well-structured).\n 4. Evaluate: If pages within a set lack any clear mechanism to help the user understand their location within that set or the overall site structure, it fails this Level AAA check."
},
{
"rule_id": "identical-links-same-purpose",
"standard_code": "2.4.9",
"Notes": null,
"issue_severity": "minor",
"wcag_version_number": 2,
"wcag_level": "AAA",
"affected_disabilities_json": "Blind | Low vision | Cognitive",
"help": "Links with the same name must have a similar purpose",
"title": "Link purpose is not clear from link text alone",
"dev_help": "1. Identify all links on the page that have the same accessible name (link text or associated alternative text).\n 2. Review the destination or action performed by each of these links.\n 3. If the links do not serve a similar purpose, change the link text or provide sufficient context to differentiate them. For example, instead of multiple 'Read more' links, use 'Read more about cats,' 'Read more about dogs,' etc.\n 4. If the links do serve a similar purpose, ensure they all point to the same destination or perform the same action. \n Example: Avoid having two 'Download' links where one downloads a PDF and another downloads a DOC file, rename them as 'Download PDF' and 'Download DOC' respectively.",
"help_url": "https://dequeuniversity.com/rules/axe/4.10/identical-links-same-purpose?application=axeAPI",
"description": "Ensure that links with the same accessible name serve a similar purpose",
"layman_help": "1. Find all the links on the page that use the exact same words.\n 2. Check where each of those links takes you.\n 3. If the links take you to different and unrelated places, the website needs to be fixed. The links should either use different words to explain where they go, or they should all take you to a similar place.\n For example, If there are two buttons that say 'Apply now', one should not take you to the payment page and the other to the application instructions page.",
"passed_title": "Link purposes are clear from link text alone.",
"dev_description": "Ensure that links with the same accessible name serve a similar purpose. When multiple links on a webpage share the same link text, they should all lead to the same destination or perform the same action. This prevents confusion and ensures predictability for users, especially those using assistive technologies.",
"layman_description": "Imagine you see the word 'Read more' linked multiple times on a page. If each 'Read more' link takes you to a completely different topic, it would be confusing, right? This rule makes sure that if links use the same words (like 'Read more'), they all take you to similar or the same places. This helps everyone, especially people using screen readers, to know where a link will take them.",
"how_to_test": null
},
{
"rule_id": "nonaxe-pointer-gestures",
"standard_code": "2.5.1",
"Notes": null,
"issue_severity": "moderate",
"wcag_version_number": 2.1,
"wcag_level": "A",
"affected_disabilities_json": "Mobility | Cognitive | Low vision",
"help": "Provide single-point operation for all functions.",
"title": "Functionality is not operable with a single pointer gesture",
"dev_help": "1. Identify complex gestures: Review all touch interactions on your site or app. Identify any that require multi-finger gestures or complex motions.\n 2. Provide single-pointer alternatives: For each complex gesture, create a single-pointer alternative. For example, replace pinch-to-zoom with zoom buttons.\n 3. Ensure sufficient target size: Make sure interactive elements are large enough to be easily tapped with a single finger.\n 4. Test with assistive technologies: Test your site or app with assistive technologies and with users who have motor impairments to ensure the single-pointer alternatives are effective.\n Example: Instead of relying solely on pinch-to-zoom, provide '+' and '-' buttons for zooming in and out of an image.",
"help_url": "https://www.w3.org/WAI/WCAG22/Understanding/pointer-gestures.html",
"description": "Let users operate touchscreens with one finger and reduced gestures.",
"layman_help": "1. Check if there are any actions on the screen that need more than one finger, like pinching to zoom. \n 2. Add simple ways to do the same things. For example, instead of pinching to zoom, add buttons to zoom in and out. \n 3. Make sure the buttons or things you tap on the screen are big enough so they're easy to hit with one finger.\n 4. Ask someone who has trouble moving their hands to try using the screen to see if it's easy for them.",
"passed_title": "Functionality works with a single pointer gesture.",
"dev_description": "Ensure that all interactive elements and functionalities on touchscreens can be operated using single-pointer gestures, such as tapping, swiping, or dragging with one finger or a stylus. Avoid reliance on complex multi-finger gestures, pinch-to-zoom (unless an alternative is provided), or gestures that require high precision or dexterity. Consider providing alternative, simpler methods for users who may have motor impairments or cognitive disabilities that affect their ability to perform intricate gestures. For example, provide buttons for zooming in and out, or alternatives to swiping actions.",
"layman_description": "Imagine trying to use a touchscreen if you have difficulty moving your hands or fingers, or if you have trouble understanding complex motions. This rule means websites and apps should be designed so you can do everything by tapping, swiping, or dragging with one finger. It avoids things like needing to pinch the screen with two fingers to zoom in, or doing complicated gestures that are hard for some people. This makes it easier for people with disabilities affecting movement or understanding to use touchscreens.",
"how_to_test": "1. Find Complex Gestures: Interact with the website, specifically looking for components that seem to require:\n - Swiping (e.g., image carousels, sliders).\n - Dragging (e.g., sliders, range controls, drag-and-drop lists).\n - Pinching (e.g., zooming maps or images).\n - Other multi-finger or specific path movements.\n 2. Look for Simple Alternatives: For each feature identified in Step 1, check if there's an alternative control that accomplishes the exact same function using only simple clicks or taps. Examples:\n - Carousels/Sliders: Are there \"Next\"/\"Previous\" buttons or clickable dots/thumbnails?\n - Zooming: Are there '+' and '-' buttons?\n - Sliders: Are there buttons to increase/decrease the value, or an input field to type the value? Can you click directly on the track to set the value?\n - Drag-and-Drop: Are there buttons to move items up/down or between lists?\n 3. Verify Functionality: Ensure the simple alternative controls are easy to find (usually adjacent to the gesture-based component) and actually perform the same task as the complex gesture.\n 4. Evaluate: If a function relies only on a multipoint or path-based pointer gesture without offering a single-click/tap alternative (and the gesture isn't essential like a signature), it fails this check."
},
{
"rule_id": "nonaxe-pointer-cancellation",
"standard_code": "2.5.2",
"Notes": null,
"issue_severity": "moderate",
"wcag_version_number": 2.1,
"wcag_level": "A",
"affected_disabilities_json": "Mobility | Cognitive | Low vision",
"help": "Make pointer cancellation predictable and consistent.",
"title": "Users cannot cancel pointer-initiated actions",
"dev_help": "1. Implement a confirmation step for critical actions (e.g., deleting data, submitting forms). 2. Provide an 'undo' option immediately after an action is completed. 3. Ensure touch targets are adequately sized (at least 44x44 CSS pixels) and spaced apart to prevent accidental activation. 4. If using a single pointer input, ensure the up-event triggers the action rather than the down-event. Example: `<button onclick='handleClick(event)'>Click Me</button> function handleClick(event) { if (event.pointerType === 'touch') { // Action logic } }`. 5. Avoid placing interactive elements too close together.",
"help_url": "https://www.w3.org/WAI/WCAG22/Understanding/pointer-cancellation.html",
"description": "Reduce accidental activation of controls by mouse or touch.",
"layman_help": "1. Before deleting something important, the website should ask, 'Are you sure?' 2. After you do something, there should be an 'undo' button right away. 3. Buttons should be big enough and far enough apart so you don't accidentally press the wrong one. 4. Make sure a click or tap only does something when you lift your finger or mouse, not when you first touch the screen or click the button. This gives you a chance to change your mind before anything happens. 5. Keep buttons and links from being too close to each other.",
"passed_title": "Users can cancel pointer-initiated actions.",
"dev_description": "Ensure that controls are designed to minimize accidental activation. This can be achieved through techniques like providing an undo option for critical actions, requiring multiple steps for irreversible actions, or ensuring sufficient spacing between interactive elements. Consider the size and placement of touch targets, especially on touch-based interfaces, to reduce errors. Also, for single pointer inputs, ensure that the down-event of the pointer is not used to trigger the action.",
"layman_description": "Imagine you accidentally tap the wrong button on your phone or computer because the buttons are too close together or too sensitive. This rule makes sure that websites and apps are designed so you're less likely to accidentally do something you didn't mean to. For example, it might require you to confirm a big decision, like deleting a file, so you don't do it by mistake. This is especially helpful for people who have trouble with fine motor control or cognitive functions.",
"how_to_test": "1. Identify Clickable Elements: Find interactive elements activated by a single click, tap, or press (buttons, links, custom controls).\n 2. Perform Press-Slide-Release Test: For each element:\n - Press down with your mouse button or finger, but don't release yet.\n - While still holding down, slide your pointer/finger off the element's boundary.\n - Now, release the mouse button or lift your finger.\n 3. Observe When Action Occurs:\n - Check: Did the element's action (e.g., submitting, navigating) trigger when you first pressed down? Or did it only trigger if you released while still on the element?\n 4. Check for Undo/Abort (If Down-Event Triggered): If the action did happen on the down-event (which is generally discouraged unless essential), is there an immediate and easy way presented to cancel or undo that action (like a confirmation prompt)?\n 5. Evaluate:\n - Pass: If the action triggers only on the up-event (when releasing on the target), allowing cancellation by sliding off before release. OR, if it triggers on the down-event but provides an easy abort/undo mechanism. OR, if it's a temporary action reversed on the up-event.\n - Fail: If the action triggers on the down-event and cannot be cancelled by sliding off, and no easy abort/undo mechanism is provided (unless the down-event activation is essential)."
},
{
"rule_id": "label-content-name-mismatch",
"standard_code": "2.5.3",
"Notes": null,
"issue_severity": "serious",
"wcag_version_number": 2.1,
"wcag_level": "A",
"affected_disabilities_json": "Blind | Low vision | Cognitive",
"help": "Elements must have their visible text as part of their accessible name",
"title": "Accessible names of UI components do not include the visible label text",
"dev_help": "1. Identify elements labelled by their visible text: Look for buttons, links, or other interactive elements where the visible text describes the element's purpose.\n 2. Inspect the accessible name: Use browser developer tools to inspect the element's accessible name. In Chrome, you can use the Accessibility tab. In Firefox, use the Accessibility panel.\n 3. Verify inclusion of visible text: Ensure that the accessible name includes the visible text. If it doesn't, update the accessible name using `aria-label`, `aria-labelledby`, or the element's text content.\n Example 1: Using aria-label\n `<button aria-label='Click Here to Read More'>Click Here</button>`\n Example 2: Using aria-labelledby\n `<span id='read-more-label'>Click Here</span>\n <button aria-labelledby='read-more-label'> </button>`\n Example 3: If element contains the text\n `<a> Click Here to Read More </a>` (Ensure the entire text is the accessible name).\n 4. Test with a screen reader: Test the element with a screen reader (e.g., NVDA, VoiceOver) to ensure the accessible name is announced correctly and includes the visible text.",
"help_url": "https://dequeuniversity.com/rules/axe/4.10/label-content-name-mismatch?application=axeAPI",
"description": "Ensure that elements labelled through their content must have their visible text as part of their accessible name",
"layman_help": "1. Find the confusing button or link: Look for parts of the website that have text on them that tell you what they do (like a button that says 'Buy Now').\n 2. Check what a screen reader says: Imagine you can't see the screen and have to listen to the website. Does the screen reader say the same thing as what's written on the button? For example, does it say 'Buy Now Button'?\n 3. Fix the problem: If the screen reader only says 'Button' or something that doesn't make sense, tell the website developers to add the missing text using special code, so the screen reader says the same thing you see on the screen (like 'Buy Now Button').\n 4. Test it again: After fixing it, test with a screen reader to make sure it now works correctly.",
"passed_title": "UI component names include visible label text.",
"dev_description": "Ensure that if an element is labelled using its visible text content, the accessible name includes the visible text. This is important for screen reader users, speech input users, and those who rely on accessible names to understand the purpose of interactive elements. When the visible text is not included in the accessible name, users may be confused or unable to interact with the element effectively. For instance, if a button displays the text 'Click Here' but its accessible name is only 'Button', a screen reader user will miss the context provided by 'Click Here'.",
"layman_description": "Imagine a button that says 'Read More'. If a blind person using a screen reader only hears 'Button' instead of 'Read More Button', they won't know what the button does. This rule ensures that if text is visible on the screen to explain what something is, that same text is also available to people who can't see the screen, so they understand what will happen if they click on it. This makes the website easier to use for everyone.",
"how_to_test": null
},
{
"rule_id": "nonaxe-motion-actuation",
"standard_code": "2.5.4",
"Notes": null,
"issue_severity": "moderate",
"wcag_version_number": 2.1,
"wcag_level": "A",
"affected_disabilities_json": "Mobility | Cognitive",
"help": "Don't rely solely on device motion to control page content.",
"title": "Motion-triggered functionality is not operable without motion",
"dev_help": "['1. Identify all functionalities that are triggered by device motion.', '2. For each motion-triggered function, provide an alternative control (e.g., a button, a link, or a menu item) that performs the same action.', '3. Ensure the alternative control is clearly labeled and easily discoverable within the user interface.', '4. Test with users who have motor impairments or cognitive disabilities to ensure the alternative control is effective.', \"Example: Instead of only allowing users to shake their device to refresh content, provide a 'Refresh' button that achieves the same outcome.\"]",
"help_url": "https://www.w3.org/WAI/WCAG22/Understanding/motion-actuation.html",
"description": "Content is not dependent on a user's ability to move a device.",
"layman_help": "['1. Find any features that make you move your device.', '2. Add a button or another way to do the same thing without moving the device.', '3. Make sure the button is easy to find and says what it does.', \"4. Ask someone who has trouble moving or thinking to test it out to make sure it's easy to use.\", 'Example: If you can shake to refresh, also add a refresh button.']",
"passed_title": "Motion-triggered features work without motion.",
"dev_description": "Ensure that functionality that requires device motion (e.g., shaking a phone to undo an action) can also be accessed through a more conventional interface component (e.g., a button or menu item). Users should not be solely reliant on motion-based interaction to operate essential features. Provide alternative, static controls for all functions triggered by device motion.",
"layman_description": "Imagine trying to use an app that requires you to shake your phone to undo a mistake, but you have difficulty moving your hands or understanding the concept of shaking. This rule ensures that you can still use the app by providing alternative controls, like a button, to achieve the same result. It helps people with mobility issues or cognitive challenges access all functionalities without relying on motion alone.",
"how_to_test": "1. Test on a Motion-Sensing Device: Use a smartphone or tablet if possible.\n 2. Look for Motion-Activated Features: Interact with the website. Are there any instructions or functionalities that require you to:\n - Shake the device?\n - Tilt the device?\n - Make specific gestures with the device?\n 3. Check for Alternative Controls: If a function can be operated by motion, look for an alternative way to achieve the exact same result using standard interface controls:\n - Are there on-screen buttons?\n - Are there menu options?\n - Can it be done with keyboard commands (if applicable)?\n 4. Check for Disable Option: Look for a setting within the website or application that allows you to turn off the motion-activated feature specifically.\n 5. Consider OS Settings (Informational): Does the feature respect the device's operating system-level settings for reducing or disabling motion input (like iOS \"Shake to Undo\" setting)? While respecting OS settings is good practice, WCAG requires that the functionality also be available via standard controls and that the motion feature itself can be turned off via some mechanism (which could be the OS setting if the site respects it, or a site-specific setting).\n 6. Evaluate:\n - Pass: If any function operable by motion can also be operated by standard UI controls, AND there is a way to turn off the motion activation.\n - Fail: If a function relies only on motion actuation without a standard control alternative, OR if there is no way to disable the motion feature."
},
{
"rule_id": "nonaxe-target-size-enhanced",
"standard_code": "2.5.5",
"Notes": null,
"issue_severity": "moderate",
"wcag_version_number": 2.1,
"wcag_level": "AAA",
"affected_disabilities_json": "Mobility | Low vision | Cognitive",
"help": "Make custom targets at least 44 by 44 pixels.",
"title": "Interactive targets are too small or too close together",
"dev_help": "1. Inspect the size of interactive elements using browser developer tools.\n 2. If an element is smaller than 24x24 CSS pixels, increase its size using CSS properties such as `width`, `height`, and `padding`. Example: `button { width: 30px; height: 30px; padding: 5px;}`.\n 3. If increasing the element's size is not feasible, ensure sufficient spacing around the element to achieve an effective target size of 24x24 CSS pixels. Example: `margin: 10px;` around a smaller icon button.\n 4. Verify that the adjustments do not negatively impact the layout or functionality of the page.\n 5. Test the element on various devices, including touch screens, to ensure usability.",
"help_url": "https://www.w3.org/WAI/WCAG22/Understanding/target-size-enhanced.html",
"description": "Controls can be operated more easily, especially on touch screens.",
"layman_help": "1. Check if the buttons and links on the page look small and hard to click or tap.\n 2. If they are small, ask the website developers to make them bigger, or add space around them. Imagine a small button surrounded by an invisible bubble, so it is easy to tap the bubble around the button. \n 3. Make sure that making the buttons bigger doesn't mess up how the rest of the page looks.\n 4. Try using the buttons and links on a phone or tablet to make sure they are easy to use on touch screens.",
"passed_title": "Interactive targets are large and well-spaced.",
"dev_description": "Ensure that interactive elements (e.g., buttons, links, form fields) have a target size of at least 24x24 CSS pixels. This helps users with motor impairments or limited dexterity to accurately activate the controls. If target is less than 24x24 CSS pixels, ensure that there is sufficient padding around the target to meet this requirement. Exceptions may apply to inline links within text or controls that are already inherently large.",
"layman_description": "Interactive elements on a webpage, like buttons and links, should be large enough to easily click or tap, especially on touch screens. If these elements are too small, people with disabilities, such as those who have trouble controlling their movements or those with low vision, may find it difficult or impossible to use them. They may accidentally click the wrong thing, or not be able to click anything at all. Making these elements bigger, or adding space around them, makes the webpage easier to use for everyone.",
"how_to_test": "1. Identify Targets: Find all interactive elements activated by clicking or tapping (buttons, links, icons used as controls, custom controls, etc.). Exclude links within sentences or blocks of text.\n 2. Measure Target Size:\n - Use browser developer tools (\"Inspect Element\").\n - Select the target element.\n - Check its computed dimensions (height and width). Pay attention to padding that might increase the clickable area beyond the visible element size. The goal is to measure the actual target area.\n 3. Verify Size: Is the calculated target area at least 44 CSS pixels wide AND at least 44 CSS pixels high?\n 4. Check Exceptions: If a target is smaller than 44x44 CSS pixels, check if any exceptions apply:\n - Is there an equivalent control on the same page that is 44x44 or larger?\n - Is the target part of a sentence/block of text?\n - Is the size purely the browser default, unmodified by the author's CSS?\n - Is the small size truly essential for the information conveyed?\n 5. Evaluate:\n - Pass: All targets are at least 44x44 CSS pixels, OR they are smaller but meet one of the specific exceptions (Equivalent, Inline, User Agent Control, Essential).\n - Fail: Any target is smaller than 44x44 CSS pixels and does not meet any of the exceptions."
},
{
"rule_id": "nonaxe-concurrent-input-mechanisms",
"standard_code": "2.5.6",
"Notes": null,
"issue_severity": "minor",
"wcag_version_number": 2.1,
"wcag_level": "AAA",
"affected_disabilities_json": "Mobility | Cognitive | Low vision",
"help": "Do not prevent users from switching their mode of input.",
"title": "Switching input methods causes data or functionality loss",
"dev_help": "['1. Identify all interactive components and functionalities on the web page.', '2. Verify that users can operate these components using multiple input methods concurrently (e.g., keyboard and mouse simultaneously).', '3. Ensure that no input method is unnecessarily restricted unless security is compromised or user preference exist.', '4. Document any intentional restrictions of input methods and provide a clear justification.', '5. Test with assistive technologies to confirm that multiple input methods work as expected.', 'Example: A drawing application could allow users to draw with a mouse while simultaneously using keyboard shortcuts to change colors or brush sizes.']",
"help_url": "https://www.w3.org/WAI/WCAG22/Understanding/concurrent-input-mechanisms.html",
"description": "Users can choose different ways of inputting content.",
"layman_help": "['1. Check if you can use both your keyboard and mouse (or touch screen) at the same time to do things on the website.', \"2. Make sure the website doesn't stop you from using one input method when you're using another.\", \"3. If there's a good reason for limiting how you can interact (like keeping your information safe), the website should explain why.\", '4. If you have any difficulty using one input method, try using a different one at the same time to see if it helps.']",
"passed_title": "Switching input methods does not lose data or function.",
"dev_description": "Ensure that web content allows users to interact with the interface using different input methods (e.g., keyboard, mouse, touch, voice) concurrently, unless restricting input modalities is essential for security or respects the user setting.",
"layman_description": "The website should let you use different ways to interact with it at the same time, like using a keyboard and a mouse together. For example, if you have trouble using a mouse, you can use the keyboard to navigate while still using the mouse for some actions. This helps people with disabilities who might find one input method difficult, giving them more options to access the website, unless security reasons or user preferences limit the input methods.",
"how_to_test": "1. Use a Multi-Input Device (If Possible): Access the website on a device like a touchscreen laptop, a tablet with an external keyboard/mouse paired, or a desktop with multiple pointing devices connected.\n 2. Interact with One Method: Use one input method (e.g., the mouse) to perform some actions (click links, focus fields).\n 3. Switch to Another Method: Without reloading the page, switch to a different available input method (e.g., use the touchscreen, then the keyboard, then the mouse again).\n 4. Verify Functionality: Try performing the same or different actions with the new input method.\n - Check: Does the website respond correctly to all available input methods? Does using one method (like touch) cause other methods (like keyboard focus or mouse clicks) to stop working?\n 5. Evaluate:\n - Pass: The website allows the user to seamlessly use and switch between all available input methods supported by their platform without restriction (unless an essential, security, or user setting restriction applies).\n - Fail: If the website restricts functionality based on the input method used (e.g., disabling keyboard navigation after touch input, or assuming only one input method is available when multiple are present)."
},
{
"rule_id": "nonaxe-dragging-movements",
"standard_code": "2.5.7",
"Notes": null,
"issue_severity": "moderate",
"wcag_version_number": 2.2,
"wcag_level": "AA",
"affected_disabilities_json": "Mobility | Cognitive | Low vision",
"help": "For any action that involves dragging, provide a simple pointer alternative.",
"title": "Drag-based functionality lacks alternative activation methods",
"dev_help": "1. Identify Dragging Functionality: Locate all instances where dragging is used to perform actions (e.g., reordering items, drawing, panning, etc.).\n 2. Provide Alternative Mechanism: For each dragging interaction, implement a non-dragging alternative. Examples include:\n - Buttons to move items up/down in a list.\n - Text fields for direct input of coordinates or values.\n - Arrow keys or other keyboard controls for panning.\n 3. Ensure Equivalent Functionality: Verify that the alternative mechanism provides the same level of functionality as the dragging interaction.\n 4. Test with Assistive Technologies: Test the alternative mechanism with assistive technologies (e.g., screen readers, switch devices) to ensure it is accessible.\n \n\n Example:\n Instead of dragging to reorder items in a list, provide up/down arrow buttons for each item.",
"help_url": "https://www.w3.org/WAI/WCAG22/Understanding/dragging-movements.html",
"description": "Don’t rely on dragging for user actions.",
"layman_help": "1. Find anything on the website where you have to drag something to make it work.\n 2. Add another way to do the same thing without dragging. For example:\n - If you drag things to put them in order, add buttons to move them up or down.\n - If you drag something to draw, let people type in numbers to draw instead.\n 3. Make sure the new way does the same thing as dragging.\n 4. Ask someone who uses assistive technology (like a screen reader) to test the new way to make sure it works for them.",
"passed_title": "Drag-based features have alternate activation methods.",
"dev_description": "Ensure that all functionality that uses a dragging movement for operation can also be achieved through an alternative method that does not require dragging. This is necessary because some users may have difficulty with or be unable to perform dragging movements with a mouse, touch screen, or other input devices.",
"layman_description": "If you need to drag something on a website or app to make it work, there should be another way to do the same thing without dragging. Some people can't drag things easily because of problems with their hands, vision, or thinking. Make sure everyone can use the website, no matter how they use a mouse, touchscreen, or other device.",
"how_to_test": "1. Identify Dragging Interfaces: Look for any parts of the website where you need to click (or tap) and hold, move the pointer, and then release to perform an action. Common examples include:\n - Sliders (for volume, brightness, price range, etc.)\n - Reordering lists (dragging items up/down)\n - Drag-and-drop interfaces (like Kanban boards or file uploads)\n - Panning maps or large images by dragging.\n - Color pickers that involve dragging.\n 2. Look for Single-Pointer Alternatives: For each dragging interface found, check if there is a non-dragging way to achieve the same result using only simple clicks or taps. Look for things like:\n - Sliders: '+' / '-' buttons, input fields to type a value, clickable track points.\n - Reordering Lists: \"Move Up\" / \"Move Down\" buttons next to items.\n - Maps: Arrow buttons for panning, '+' / '-' buttons for zooming.\n - Color Pickers: Input fields for color values (HEX, RGB), predefined color swatches to click.\n 3. Verify Functionality: Make sure the alternative controls are easy to find and perform the same function as the dragging action.\n 4. Evaluate: If a function can only be operated by dragging and lacks a single-click/tap alternative method, it fails this check."
},
{
"rule_id": "target-size",
"standard_code": "2.5.8",
"Notes": null,
"issue_severity": "serious",
"wcag_version_number": 2.2,
"wcag_level": "AA",
"affected_disabilities_json": "Mobility | Low vision | Cognitive",
"help": "All touch targets must be 24px large, or leave sufficient space",
"title": "Interactive targets do not meet minimum size requirements",
"dev_help": "1. Check Touch Target Size: Inspect the CSS dimensions of touch targets to ensure they meet the minimum size requirements (24x24 CSS pixels, or 44x44 CSS pixels). Use browser developer tools to examine the computed size and spacing of elements.\n 2. Increase Target Size: If targets are too small, increase their width and height using CSS. For example:\n \n 3. Add Spacing: If increasing the target size is not feasible, add sufficient spacing around the target using CSS margins or padding. Ensure that the spacing is at least 1 CSS pixel.\n \n 4. Consider Path-Based definition: If a path-based definition is used for the touch target, make sure the path encompasses a sufficient area to allow for easy interaction. If not, increase area.\n 5. Test on Mobile Devices: Test the touch target on a variety of mobile devices and screen sizes to ensure that it remains accessible and usable.",
"help_url": "https://dequeuniversity.com/rules/axe/4.10/target-size?application=axeAPI",
"description": "Ensure touch targets have sufficient size and space",
"layman_help": "1. Check the Size: See if the buttons and links on the screen are big enough to tap easily.\n 2. Make Them Bigger: If they're too small, make them bigger using the website's design tools.\n 3. Add Space: If you can't make them bigger, put some space around them so it's easier to tap without accidentally tapping something else.\n 4. Test on Phones and Tablets: Try using the buttons and links on different phones and tablets to make sure they're easy to tap on all devices.",
"passed_title": "Interactive targets meet size and spacing requirements.",
"dev_description": "Ensure touch targets (e.g., buttons, links) are at least 24x24 CSS pixels, or have a minimum size of 44x44 CSS pixels when accounting for pointer inaccuracies. If touch targets are smaller than this, ensure that there is sufficient spacing around them (at least 1 CSS pixel) to avoid accidental activation of adjacent controls. The calculation of touch target size can consider the visual size of the target and any surrounding non-interactive area that helps with target acquisition. Also consider if a path-based definition is used as opposed to rectangular bounding box for pointer input.",
"layman_description": "Make sure that buttons and other interactive elements on the screen are big enough and have enough space around them so that people can easily tap them, especially those with motor impairments or who use touch screens with less precision. Imagine someone with shaky hands trying to tap a tiny button right next to another button – it would be very frustrating! This rule ensures that interactive elements are easy to use for everyone.",
"how_to_test": null
},
{
"rule_id": "html-has-lang",
"standard_code": "3.1.1",
"Notes": null,
"issue_severity": "serious",
"wcag_version_number": 2,
"wcag_level": "A",
"affected_disabilities_json": "Blind | Low vision | Cognitive",
"help": "<html> element must have a lang attribute",
"title": "No lang attribute on <html> element to define the page's language",
"dev_help": "1. Open the HTML file of your webpage.\n 2. Locate the `<html>` tag at the beginning of the document.\n 3. Add the `lang` attribute to the `<html>` tag, specifying the language of the page. For example, for English, use `<html lang=\"en\">`. For Spanish, use `<html lang=\"es\">`. For French, use `<html lang=\"fr\">`.\n 4. If parts of the page are in a different language, add the `lang` attribute to the specific elements containing that content. For example, `<p lang=\"fr\">Ceci est un paragraphe en français.</p>`.\n 5. Save the changes to your HTML file.",
"help_url": "https://dequeuniversity.com/rules/axe/4.10/html-has-lang?application=axeAPI",
"description": "Ensure every HTML document has a lang attribute",
"layman_help": "1. Find the code for your webpage (usually in a file ending with .html).\n 2. Look for the very first line that starts with `<html`.\n 3. Add a space after `html` and then type `lang=\"en\"` if the page is in English, `lang=\"es\"` if it's in Spanish, or `lang=\"fr\"` if it's in French. So, it should look like `<html lang=\"en\">`.\n 4. If some parts of the page are in a different language, find the part of the code for that text and add `lang=\"fr\"` (or whatever language it is) to the tag around that text. For example: `<p lang=\"fr\">The text in french</p>`.\n 5. Save the file.",
"passed_title": "<html> has a lang attribute defining the page's language.",
"dev_description": "Ensure every HTML document includes a `lang` attribute in the `<html>` tag. This attribute specifies the primary language of the page's content. This is crucial for screen readers, search engines, and other assistive technologies to correctly interpret and present the content. If the page contains content in multiple languages, use the `lang` attribute on specific elements to indicate the language of that content.",
"layman_description": "Make sure each webpage tells your computer what language it's written in. This is done by adding a little tag that says 'this page is in English' or 'this page is in Spanish.' If the computer knows the language, it can help people who are blind (using screen readers) or who have trouble reading. Without it, the computer might mispronounce words or not understand the page correctly, making it hard for some people to use the website.",
"how_to_test": null
},
{
"rule_id": "html-xml-lang-mismatch",
"standard_code": "3.1.1",
"Notes": null,
"issue_severity": "moderate",
"wcag_version_number": 2,
"wcag_level": "A",
"affected_disabilities_json": "Blind | Low vision | Cognitive",
"help": "HTML elements with lang and xml:lang must have the same base language",
"title": "lang and xml:lang attributes on the <html> element are inconsistent",
"dev_help": "1. Identify the HTML element(s) with both `lang` and `xml:lang` attributes. The most common element this applies to is the `<html>` tag.\n 2. Ensure both attributes have valid language tags. Refer to the IANA Language Subtag Registry for valid language tags.\n 3. Ensure both attributes have the same language tag. If they are different, choose the correct language for the content and update both attributes accordingly.\n \n\n Example:\n \n \n\n If the content is in French:",
"help_url": "https://dequeuniversity.com/rules/axe/4.10/html-xml-lang-mismatch?application=axeAPI",
"description": "Ensure that HTML elements with both valid lang and xml:lang attributes agree on the base language of the page",
"layman_help": "Think of it like labeling a box of toys. You need to make sure you put the right label on it. To fix this on a website:\n 1. Find where the website tells the computer what language it's in (look for the `<html>` tag and attributes `lang` and `xml:lang`).\n 2. Make sure both labels (`lang` and `xml:lang`) say the same language (like \"English\" or \"Spanish\"). If they say different things, change one so they both match the language the website is actually written in.",
"passed_title": "<html> lang and xml:lang attributes are consistent.",
"dev_description": "This rule checks that when both the `lang` and `xml:lang` attributes are used on the same HTML element, their values are consistent and represent the same base language. Inconsistent language declarations can confuse assistive technologies, leading to incorrect text-to-speech pronunciation, incorrect font rendering, and other accessibility issues. The most common element this applies to is the `<html>` tag.",
"layman_description": "Imagine a book where some parts are in English and others are in Spanish. If the book doesn't clearly tell you which language each part is in, you might mispronounce words or not understand the meaning. Similarly, on a website, if the `lang` and `xml:lang` attributes (which tell assistive technologies like screen readers what language the page is in) don't agree, people using these technologies might have trouble understanding the content. This is especially problematic for people who are blind or have low vision, as they rely on screen readers to read the content aloud.",
"how_to_test": null
},
{
"rule_id": "html-lang-valid",
"standard_code": "3.1.1",
"Notes": null,
"issue_severity": "serious",
"wcag_version_number": 2,
"wcag_level": "A",
"affected_disabilities_json": "Blind | Low vision | Cognitive",
"help": "<html> element must have a valid value for the lang attribute",
"title": "Invalid language code used in the lang attribute on the <html> element",
"dev_help": "1. Check for the `lang` attribute: Ensure that the `<html>` tag includes the `lang` attribute. For example: `<html lang=\"en\">`.\n 2. Validate the language code: Verify that the value of the `lang` attribute is a valid language tag according to the BCP 47 standard. For English, use `en`. For Spanish, use `es`. For French, use `fr`. If the content is specific to a region, include the region code as well, such as `en-US` for US English or `en-GB` for British English. Refer to the IANA Language Subtag Registry (www.iana.org/assignments/language-subtag-registry) for a comprehensive list of valid tags.\n 3. Multiple Languages: If a page contains content in multiple languages, use the `lang` attribute on the elements containing the text in the secondary language. For example: `<p lang=\"fr\">Bonjour le monde!</p>`.\n 4. Avoid deprecated attributes: Do not use the deprecated `xml:lang` attribute. Use only the `lang` attribute on HTML elements.\n 5. Test with assistive technologies: Use a screen reader to verify that the language is being correctly identified and that the text is being pronounced correctly.",
"help_url": "https://dequeuniversity.com/rules/axe/4.10/html-lang-valid?application=axeAPI",
"description": "Ensure the lang attribute of the <html> element has a valid value",
"layman_help": "1. Find the language setting: Ask your website developer to check for a setting that tells the website what language it's written in. It's like labeling a book so everyone knows what language it's in.\n 2. Make sure the language is correct: The developer needs to ensure that the language selected is the right one (e.g., English, Spanish, French). If the website is for people in the US, it might be even more specific, like 'US English'.\n 3. For different languages: If some parts of the website are in a different language, those parts also need to be labeled with their specific language. \n 4. Test it out: Ask someone who uses a screen reader (a tool that reads the website out loud) to check if it pronounces the words correctly. If it does, you've done a good job!",
"passed_title": "<html> uses a valid language code in the lang attribute.",
"dev_description": "Ensure the `lang` attribute is present on the `<html>` element and that its value is a valid language tag according to BCP 47. This attribute specifies the primary language of the document. Using correct language tags is crucial for screen readers, braille translators, search engines, and other assistive technologies to properly interpret and present the content. Incorrect or missing `lang` attributes can lead to mispronunciation by screen readers, incorrect character rendering, and accessibility issues for users who rely on language-specific adaptations.",
"layman_description": "Make sure the website's main language is clearly identified. This is done by adding a small piece of code that tells computers and assistive technologies (like screen readers) what language the website is in. If the language isn't identified correctly, screen readers might mispronounce words, making it hard for blind or visually impaired people to understand the content. It also helps people using translation tools or braille displays to correctly interpret the content on the site. Imagine a screen reader trying to read English text as if it were German; it would be garbled and incomprehensible.",
"how_to_test": null
},
{
"rule_id": "valid-lang",
"standard_code": "3.1.2",
"Notes": null,
"issue_severity": "serious",
"wcag_version_number": 2,
"wcag_level": "AA",
"affected_disabilities_json": "Blind | Low vision | Cognitive",
"help": "lang attribute must have a valid value",
"title": "Language changes in content are not programmatically identified",
"dev_help": "1. Verify the `lang` attribute exists on the `<html>` tag. It should be present like this: `<html lang=\"en\">`.\n 2. Ensure the value of the `lang` attribute is a valid language code. Use the IANA Language Subtag Registry (https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry) to find the correct code. For example, use `en` for English, `es` for Spanish, or `fr` for French.\n 3. If the page contains content in multiple languages, use the `lang` attribute on specific elements. For example: `<p lang=\"fr\">Bonjour le monde!</p>`.\n 4. If using language subtags (e.g., for regional variations), ensure they are also valid. For example, `en-US` for US English or `en-GB` for British English.\n 5. Avoid using deprecated or non-standard language codes. Always refer to the IANA registry for the most up-to-date and correct codes.",
"help_url": "https://dequeuniversity.com/rules/axe/4.10/valid-lang?application=axeAPI",
"description": "Ensure lang attributes have valid values",
"layman_help": "1. Make sure the website tells your computer what language it's using. Look for something like `<html lang=\"en\">` at the very beginning of the website's code.\n 2. Check that the language code is correct. For example, `en` is for English, `es` is for Spanish, and `fr` is for French. If the code is wrong, ask the website owner to fix it.\n 3. If parts of the website are in different languages, each part should say what language it's using. For example, a sentence in French should have a little tag that says it's French: `<p lang=\"fr\">Bonjour!</p>`.\n 4. If the language has a specific region like American English or British English make sure the website specifies that also. \n 5. By ensuring the correct language is specified, you make sure that your computer pronounces the content properly and displays it correctly.",
"passed_title": "Language changes are identified programmatically.",
"dev_description": "The `lang` attribute, used on the `<html>` tag or other relevant elements, specifies the language of the content. This rule checks that the values assigned to the `lang` attribute are valid according to the IANA Language Subtag Registry. Invalid or missing `lang` attributes can prevent screen readers and other assistive technologies from correctly interpreting and presenting the content, leading to a degraded user experience. Correct language declaration helps assistive technologies switch to the appropriate pronunciation and character rendering.",
"layman_description": "Imagine your computer speaks a certain language, like English. Websites also have a language. If the website's language is set incorrectly, your computer might mispronounce words or display them wrong. This is especially difficult for people who use screen readers, as they rely on the website's language setting to understand the text. This rule makes sure websites speak the right language so everyone can understand them properly. For example, a website in French should declare it speaks French, so a screen reader knows how to read it correctly.",
"how_to_test": null
},
{
"rule_id": "nonaxe-unusual-words",
"standard_code": "3.1.3",
"Notes": null,
"issue_severity": "minor",
"wcag_version_number": 2,
"wcag_level": "AAA",
"affected_disabilities_json": "Cognitive | Low vision | Blind",
"help": "Provide definitions for technical jargon and unusual terms.",
"title": "Users cannot identify or get definitions for unusual words",
"dev_help": "1. Identify unusual words, idioms, jargon, or non-standard terms used on the page.\n 2. Provide definitions using one of the following methods:\n a. Create a glossary page linked from the main content.\n b. Use the `<abbr>` tag with the `title` attribute for inline definitions (e.g., `<abbr title=\"Hypertext Markup Language\">HTML</abbr>`).\n c. Provide context-sensitive help, such as a tooltip or pop-up, when the user interacts with the term.\n 3. Ensure the definition is clear, concise, and easy to understand.\n 4. Test with assistive technologies to ensure the definition is accessible.",
"help_url": "https://www.w3.org/WAI/WCAG22/Understanding/unusual-words.html",
"description": "Users can identify and learn what unusual words mean.",
"layman_help": "1. Look for confusing or uncommon words on the website.\n 2. Check if there is a way to find out what those words mean. This could be a special page on the website that explains words (like a dictionary), or it could be a definition that pops up when you hover your mouse over the word.\n 3. Make sure the definition is easy to understand. \n 4. If you use special tools to help you read the website, like a screen reader, check if the definitions work with those tools.",
"passed_title": "Users can get definitions for unusual words.",
"dev_description": "Provide a mechanism for identifying specific definitions of words or phrases used in an unusual or restricted way, including idioms, jargon, and non-standard words. This can be achieved through a glossary, in-line definitions, or context-sensitive help. Ensure the mechanism is consistently applied and easily accessible to users.",
"layman_description": "Imagine reading a website and constantly bumping into words you've never seen before or that seem to be used in a strange way. This rule wants websites to help you understand these unusual words. If you have trouble understanding language, for example, if you have a cognitive disability or if you use assistive technology like a screen reader, it can be really frustrating to keep running into words you don't understand. The website should provide definitions or explanations for these words, like a little built-in dictionary, so everyone can follow along.",
"how_to_test": "1. Read the Content: Read the text on the webpage.\n 2. Identify Unusual Words/Phrases: Look for:\n - Technical terms or industry-specific jargon.\n - Idiomatic phrases.\n - Common words used with a very specific or uncommon meaning in this context.\n 3. Check for Definitions: For each unusual word/phrase identified, check if its specific meaning is provided through one of these mechanisms:\n - Inline Definition: Is the definition given in parentheses right after the term the first time it's used? (e.g., \"Document Object Model (DOM)\").\n - Linked Definition: Is the term linked to a glossary page or definition elsewhere?\n - Footnote/Endnote: Is there a link to a definition at the bottom of the page?\n - Glossary Access: Is there an easily accessible glossary feature covering the terms used?\n - Description List: Are terms and definitions presented using HTML description lists (<dl>, <dt>, <dd>)?\n 4. Evaluate:\n - Pass: A mechanism (like inline definition, link to glossary, etc.) is available to determine the specific definition of jargon, idioms, or words used in an unusual/restricted way.\n - Fail: If such terms are used without any readily available mechanism to understand their specific meaning in that context."
},
{
"rule_id": "nonaxe-abbreviations",
"standard_code": "3.1.4",
"Notes": null,
"issue_severity": "minor",
"wcag_version_number": 2,
"wcag_level": "AAA",
"affected_disabilities_json": "Cognitive | Low vision",
"help": "Provide the expanded form of abbreviations to users.",
"title": "Users cannot identify or expand abbreviations",
"dev_help": "1. Use the `<abbr>` tag: Mark up abbreviations with the HTML `<abbr>` tag.\n 2. Provide the full form: Include the full form of the abbreviation in the `title` attribute of the `<abbr>` tag. Example: `<abbr title=\"World Wide Web Consortium\">W3C</abbr>`.\n 3. For the first occurrence of abbreviation explain the meaning. Example: The World Wide Web Consortium (<abbr title=\"World Wide Web Consortium\">W3C</abbr>) is an international community that develops open standards.\n 4. If abbreviations are used extensively, create a glossary on the page or link to an external resource that explains them.",
"help_url": "https://www.w3.org/WAI/WCAG22/Understanding/abbreviations.html",
"description": "Users can identify and learn what abbreviations mean.",
"layman_help": "1. When you use an abbreviation, add a little explanation.\n 2. The first time you use the abbreviation put the full word or phrase next to it or above it. Example: 'Use 'W3C (World Wide Web Consortium)' to represent the World Wide Web Consortium'.\n 3. If you use a lot of abbreviations, create a list of all of them and what they mean on the same page or another page.",
"passed_title": "Users can identify and expand abbreviations.",
"dev_description": "Provide a mechanism for identifying the expanded form or meaning of abbreviations. This helps users understand the content, especially if they are unfamiliar with the abbreviations used. Use the `<abbr>` HTML element to mark up abbreviations, and provide the full meaning in the `title` attribute. For complex abbreviations, consider providing a glossary or a more detailed explanation on the page.",
"layman_description": "When you use shortened forms of words (abbreviations) on a website, like 'USA' for 'United States of America,' make sure it's easy for everyone to understand what they mean. People with learning disabilities or those who aren't familiar with the subject might not know what the abbreviation stands for. By explaining the meaning of abbreviations, you make the content easier to understand for everyone, especially people with cognitive disabilities.",
"how_to_test": "1. Scan for Abbreviations: Read the text on the webpage and identify any abbreviations (shortened forms of words or phrases, including acronyms and initialisms).\n 2. Check for Expansion Mechanism: For each abbreviation found, check if its expanded form is available through one of these common methods:\n - First Use Expansion: Is the full term written out immediately before or after the abbreviation the first time it appears on the page? (e.g., \"Web Content Accessibility Guidelines (WCAG)\"). This is the most common method.\n - Glossary Link: Is the abbreviation linked to an entry in a glossary page?\n - <abbr> Tag: (More technical) Use developer tools to inspect the abbreviation. Is it wrapped in an <abbr> tag with a title attribute containing the expansion? (e.g., <abbr title=\"Web Content Accessibility Guidelines\">WCAG</abbr>). Note: Screen reader support for this tag can vary.\n - Description List: Are abbreviations defined using a description list (<dl>) nearby?\n - On-Page Dictionary/Search: Is there a feature provided on the site to look up abbreviations?\n 3. Evaluate:\n - Pass: A mechanism is available (like expansion on first use or a glossary link) allowing users to find the meaning of abbreviations used on the page. If an abbreviation has multiple meanings on the page, the mechanism should clarify the correct meaning in context.\n - Fail: Abbreviations are used without any clear way for the user to find out their full expanded form or meaning within the context of the page."
},
{
"rule_id": "nonaxe-reading-level",
"standard_code": "3.1.5",
"Notes": null,
"issue_severity": "minor",
"wcag_version_number": 2,
"wcag_level": "AAA",
"affected_disabilities_json": "Cognitive | Attention Deficit",
"help": "When text information becomes complex, create a more easily understood version.",
"title": "No mechanism is available to simplify the content's reading level",
"dev_help": "1. Identify Complex Content: Determine sections of your website or application that require advanced reading skills.\n 2. Create Simplified Version: Develop an alternative version of the content using simpler language, shorter sentences, and clear explanations.\n 3. Link Simplified Version: Provide a clear and easily accessible link to the simplified version from the original complex content.\n 4. Use Summaries: Include concise summaries that capture the main points of the complex content.\n 5. Utilize Plain Language: Rewrite the content using plain language principles, focusing on clarity and avoiding jargon.\n Example: Original (Complex): 'Pursuant to the provisions delineated in Section 27A of the Securities Act of 1933, as amended, and Section 21E of the Securities Exchange Act of 1934, as amended, forward-looking statements are subject to certain risks, uncertainties, and caveats.'\n Simplified: 'This information contains predictions about the future that might not be accurate.'",
"help_url": "https://www.w3.org/WAI/WCAG22/Understanding/reading-level.html",
"description": "Users can get a simplified version of complex information.",
"layman_help": "1. Find the Hard Parts: Look for parts of the website or app that are hard to understand.\n 2. Make it Simpler: Create a simpler version of those parts, using easy words and short sentences.\n 3. Link the Simple Version: Put a link near the hard part that takes you to the simpler version.\n 4. Use Summaries: Add short summaries that explain the main points of the hard part.\n 5. Use Easy Language: Rewrite the hard parts using plain language that everyone can understand.",
"passed_title": "A mechanism exists to simplify reading level.",
"dev_description": "Provide a simplified version of complex content when the original requires reading ability more advanced than the lower secondary education level. A simplified version provides the same information but uses simpler language and sentence structures, making it easier to understand for individuals with cognitive disabilities or those who struggle with complex text. This can be achieved by providing a summary, an alternative version, or using tools to simplify the text.",
"layman_description": "Imagine you're reading something really complicated, like a legal document or a scientific article. It's full of long words and confusing sentences. This rule says that there should also be a simpler version available, written in plain language that most people can understand. This helps people with learning disabilities or those who find complex text difficult, so they can still understand the information.",
"how_to_test": "1. Identify Main Text Content: Focus on the primary written content of the page (articles, explanations, instructions).\n 2. Assess Reading Level:\n - Read and Judge: Read through the content. Does it use complex sentence structures, advanced vocabulary, or abstract concepts that would likely be difficult for someone who hasn't completed upper secondary education (high school)? (This is subjective).\n - Use Readability Tools (Optional): You can paste sample text (removing proper names and titles first) into online readability calculators (like Flesch-Kincaid tools). These tools provide an estimated grade level. Check if the estimated level is significantly above the lower secondary level (around grade 9 in the US system). Note that these tools have limitations and are just estimations.\n 3.Check for Supplemental Content: If the text does appear to require reading ability beyond the lower secondary level:\n - Look for alternative versions or aids provided on the page or linked nearby. Is there a:\n => Clearly labeled summary written in simpler language?\n => Relevant illustration, diagram, chart, or video explaining the key concepts?\n => Link to an \"Easy Read\" version?\n => Spoken audio version available?\n => Sign language version available?\n 4. Evaluate:\n - Pass: If the text requires reading ability at or below the lower secondary level, OR if the text is more advanced but appropriate supplemental content (summary, illustration, alternative version) is provided.\n - Fail: If the text requires reading ability more advanced than the lower secondary education level, AND no supplemental content is provided to aid understanding."
},
{
"rule_id": "nonaxe-pronunciation",
"standard_code": "3.1.6",
"Notes": null,
"issue_severity": "minor",
"wcag_version_number": 2,
"wcag_level": "AAA",
"affected_disabilities_json": "Cognitive | Low vision",
"help": "Indicate how to pronounce a word, where its meaning is otherwise unclear.",
"title": "No pronunciation guidance is provided for ambiguous words or phrases",
"dev_help": "['1. Identify words on your page that have ambiguous pronunciations (homographs).', '2. Choose a method to provide pronunciation guidance: phonetic spelling, audio clip, or dictionary link.', '3. Implement the chosen method for each ambiguous word. For example, use the <ruby> tag for phonetic guides or provide an accessible audio player for pronunciation clips.', '4. Ensure the pronunciation guide is accessible to assistive technologies by using appropriate ARIA attributes or alternative text.', '5. Test with users, including those with cognitive disabilities, to ensure the pronunciation guidance is effective and easily understood.']",
"help_url": "https://www.w3.org/WAI/WCAG22/Understanding/pronunciation.html",
"description": "Users can identify the pronunciation of ambiguous words.",
"layman_help": "[\"1. Look for words on the page that might sound the same but have different meanings (like 'read' - I read a book, vs. I will read a book tomorrow).\", '2. Add a way for people to hear the correct pronunciation of those words. This could be a button to play the word, a written guide on how to say the word, or a link to a dictionary.', '3. Make sure everyone can use the pronunciation help, including people who use screen readers.', '4. Ask someone to try it out and make sure the pronunciation help makes sense.']",
"passed_title": "Pronunciation guidance is provided for ambiguous words.",
"dev_description": "Provide a mechanism for users to understand the pronunciation of words where the meaning is ambiguous without knowing the correct pronunciation. This could involve providing a phonetic spelling, an audio pronunciation guide, or linking to a dictionary definition with pronunciation information. Ensure that this mechanism is readily available and easily accessible to all users, including those using assistive technologies.",
"layman_description": "Sometimes, the way a word sounds changes its meaning. This rule says that if a word's meaning is unclear based on how it's pronounced, the website should provide a way for people to figure out the correct pronunciation. This could be a written pronunciation guide (like saying 'toe-may-toe' for 'tomato'), an audio clip of the word being spoken, or a link to a dictionary. This helps people, especially those with learning difficulties or those who are not native speakers, understand the content better.",
"how_to_test": "1. Read the Content: Read the text on the webpage.\n 2. Identify Ambiguous Words: Look specifically for words where:\n - The spelling is the same, but pronunciation changes the meaning (heteronyms like 'read', 'live', 'object', 'present').\n - Characters (especially in languages like Japanese Kanji) might have multiple possible pronunciations affecting meaning.\n 3. Assess Context: For each potentially ambiguous word, can the correct meaning and pronunciation be easily understood just from the surrounding sentence or context? If yes, no mechanism is needed for that word.\n 4. Check for Pronunciation Mechanism: If the meaning is truly ambiguous without knowing the pronunciation, look for a mechanism that provides it:\n - Inline Pronunciation: Is the pronunciation given in text immediately after the word (e.g., \"lead (pronounced led)\")?\n - Link to Sound File: Is the word linked to an audio file demonstrating the pronunciation?\n - Glossary: Is the word linked to a glossary entry that includes pronunciation?\n - Ruby Annotation: (Technical, common in East Asian languages) Is the pronunciation shown above or next to the characters using HTML Ruby elements?\n 5. Evaluate:\n - Pass: If a mechanism is available to determine the pronunciation of any word whose meaning would otherwise be ambiguous in context.\n - Fail: If a word's meaning is ambiguous without knowing the pronunciation, and no mechanism is provided to clarify it."
},
{
"rule_id": "nonaxe-on-focus",
"standard_code": "3.2.1",
"Notes": null,
"issue_severity": "moderate",
"wcag_version_number": 2,
"wcag_level": "A",
"affected_disabilities_json": "Cognitive | Low vision | Blind | Mobility",
"help": "Do not change a user's context when items get focus.",
"title": "Unexpected context changes occur when elements receive focus",
"dev_help": "['1. Identify inconsistencies in the UI components and navigation.', '2. Standardize the placement and behavior of navigation menus, buttons, and interactive elements.', '3. Use consistent labels and icons for similar functions.', '4. Ensure that the page layout is consistent across different pages of the website.', '5. Use CSS frameworks or UI libraries to enforce consistency in styling and behavior.', '6. Test the website with users, including those with disabilities, to identify potential usability issues.']",
"help_url": "https://www.w3.org/WAI/WCAG22/Understanding/on-focus.html",
"description": "Content can be navigated more predictably.",
"layman_help": "['1. Check if the website looks and works the same way on different pages.', '2. Make sure that menus and buttons are always in the same place and do the same thing.', '3. Use the same pictures or symbols for the same actions across the website.', '4. If something seems out of place or works differently than expected, let the website owner know.']",
"passed_title": "Focus does not trigger unexpected context changes.",
"dev_description": "Ensure that the user interface components and navigation elements are used in a consistent and predictable way throughout the website. This includes maintaining a consistent layout, navigation menus, and the behavior of interactive elements. Consistent presentation helps users learn and predict how the site functions, reducing cognitive load and improving usability. For example, ensure that if a button navigates to a new page in one instance, it does so consistently throughout the site. Also, if a set of icons are used for the same purpose in different places of a website, ensure that the user always knows what each icons represents.",
"layman_description": "Imagine if every time you opened a door, the handle was in a different place or worked differently. It would be confusing and frustrating, right? This rule ensures that websites work in a predictable way. Things like menus, buttons, and page layouts should stay consistent across the site. This helps people with cognitive disabilities, low vision, or who are blind to easily understand and use the website without getting lost or confused. It's about making the website easy to navigate and use.",
"how_to_test": "1. Navigate with Keyboard: Use the Tab key to move forward and Shift + Tab to move backward through all interactive elements on the page (links, buttons, form fields, etc.).\n 2. Observe on Focus: As each element receives focus, pay close attention to what happens on the page before you activate anything (i.e., before pressing Enter or Space).\n 3. Look for Unexpected Changes: Does landing focus on an element automatically cause any of the following?\n - A form submits?\n - A new window or tab opens?\n - Focus jumps to another element unexpectedly?\n - The page scrolls significantly?\n 4. Large amounts of content appear, disappear, or rearrange, changing the context?\n 5. Distinguish from Expected Behavior: Minor visual changes like the focus indicator appearing or a dropdown menu opening when focus lands on its parent button are usually acceptable and expected. The rule targets major, unexpected changes of context just from receiving focus.\n 6. Evaluate: If receiving focus on any element triggers a significant, unexpected change of context without the user explicitly activating the element, it fails this check."
},
{
"rule_id": "nonaxe-on-input",
"standard_code": "3.2.2",
"Notes": null,
"issue_severity": "moderate",
"wcag_version_number": 2,
"wcag_level": "A",
"affected_disabilities_json": "Cognitive | Low vision | Mobility",
"help": "Forewarn users if their context will change based on their input.",
"title": "Unexpected changes in content or context occur upon user input",
"dev_help": "1. Identify any user interface components that trigger a change of context when their setting is changed.\n 2. Verify that the user is informed of this behavior before interacting with the component, either through clear labeling or instructions.\n 3. If the change of context is not essential, consider modifying the component's behavior to avoid the change of context or provide a clear warning before it occurs. Example: Instead of automatically submitting a form when a field is completed, add a submit button and clearly label it.\n 4. For components that open new windows or tabs, provide a clear indication that this will happen (e.g., 'Opens in a new window' next to the link).",
"help_url": "https://www.w3.org/WAI/WCAG22/Understanding/on-input.html",
"description": "Content can be operated more predictably.",
"layman_help": "1. Look at the website and find things like buttons, forms, or dropdown menus.\n 2. Check if using these things causes something unexpected to happen, like opening a new page or submitting a form automatically.\n 3. If something unexpected happens, make sure there's a warning or explanation before it happens. For example, if clicking a button opens a new window, it should say 'Opens in a new window'. If the unexpected behavior isn't really needed, it's best to change it so it doesn't happen, or at least give a clear warning beforehand.",
"passed_title": "User input does not trigger unexpected context changes.",
"dev_description": "Ensure that changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behavior before using the component. A change of context includes: changing the user agent; changing the viewport; moving focus to another component; or significantly changing the content of the page. Unexpected changes can disorient users and make it difficult to understand the interface. Examples of violations include submitting a form automatically when a field is completed or opening a new window without warning.",
"layman_description": "Imagine you're filling out a form online, and as soon as you select an option in a dropdown, the website suddenly jumps to a completely different page without warning. This can be confusing and frustrating, especially for people with cognitive disabilities who need things to be predictable. This rule means that when you interact with something on a webpage (like a button or a form field), it shouldn't cause unexpected changes, like opening new windows or submitting a form, unless you've been told beforehand that this will happen. This helps everyone navigate the website more easily and with less confusion.",
"how_to_test": "1. Identify Form Controls: Find form controls on the page where you can input data or change a setting (e.g., dropdown menus (<select>), checkboxes (<input type=\"checkbox\">), radio buttons (<input type=\"radio\">), text fields (<input type=\"text\">, <textarea>)).\n 2. Change the Value: Interact with these controls:\n - Select a different option from a dropdown list.\n - Check or uncheck a checkbox.\n - Select a different radio button in a group.\n - Type text into an input field.\n 3. Observe What Happens Immediately: After changing the value, before clicking any submit button or taking another action, watch carefully:\n - Does the page automatically navigate away or reload?\n - Does the form submit automatically?\n - Does focus jump unexpectedly?\n - Does a large part of the page content drastically change?\n 4. Look for Advance Warning: If changing the input does cause an immediate change of context, was there clear text beforehand warning the user that this would happen? (e.g., \"Selecting a language will automatically refresh the page\").\n 5. Evaluate:\n - Pass: Changing the setting of a form control does not cause any major, unexpected change of context OR the user was clearly warned beforehand that the change would occur upon input.\n - Fail: Changing the setting of a form control automatically triggers a significant change of context (like submitting or navigating) without the user being warned in advance."
},
{
"rule_id": "nonaxe-consistent-navigation",
"standard_code": "3.2.3",
"Notes": null,
"issue_severity": "moderate",
"wcag_version_number": 2,
"wcag_level": "AA",
"affected_disabilities_json": "Blind | Low vision | Cognitive",
"help": "Consistently order navigation that repeats across multiple pages.",
"title": "Navigation mechanisms are not consistently presented across pages",
"dev_help": "1. Identify all repeated navigation mechanisms (e.g., menus, breadcrumbs, site search) across your website.\n 2. Ensure these mechanisms appear in the same relative order on all pages. For example, if the main menu is at the top and the site search is in the right sidebar on one page, maintain this order on all other pages.\n 3. If changes to the navigation are necessary, ensure they are initiated by the user (e.g., through personalization settings). Avoid changes that occur automatically based on the page content or user history.\n 4. Use semantic HTML to structure your navigation (e.g., `<nav>`, `<ul>`, `<li>`) to provide a consistent and predictable structure for assistive technologies.\n 5. Test with assistive technologies, such as screen readers, to verify the consistency of the navigation experience.",
"help_url": "https://www.w3.org/WAI/WCAG22/Understanding/consistent-navigation.html",
"description": "Content can be navigated more predictably.",
"layman_help": "1. Think about the menus and links that show up on almost every page of the website.\n 2. Make sure these menus and links are always in the same spot. For example, if the menu is at the top of the page, keep it at the top on every page.\n 3. If you need to change the menu, make sure it's because the user asked for it (like if they changed their settings). Don't change it automatically based on what page they are on.\n 4. Ask someone who uses a screen reader to test the website and make sure the navigation is easy to understand and consistent.",
"passed_title": "Navigation is consistent across all website pages.",
"dev_description": "Ensure that navigational mechanisms that are repeated on multiple web pages within a set of web pages occur in the same relative order each time they are repeated, unless a change is initiated by the user. This includes menus, site search, and other navigation elements. Consistent presentation and order of navigation aids users in predicting the location of content and functionalities, improving usability and accessibility.",
"layman_description": "Imagine going to the same store every week, but they keep moving the bread and milk to different locations. It would be frustrating, right? This rule is about making sure that website menus and navigation tools stay in the same place on every page. This helps people with disabilities, especially those who are blind or have cognitive issues, because they can learn where to find things and don't have to search all over again each time. Consistent navigation makes websites easier to use for everyone.",
"how_to_test": "1. Identify Repeated Navigation: Find the navigation components that appear on multiple pages. Common examples include:\n - Main header navigation menu\n - Footer links menu\n - Site search bar/link\n - Breadcrumbs trail\n - \"Skip to content\" link\n 2. Visit Multiple Pages: Navigate to several different types of pages within the website (e.g., homepage, a main section page, a specific content page, contact page).\n 3. Compare Location: On each page where a specific navigation element appears (e.g., the main menu), check its position relative to other consistent page elements. Is the main menu always at the top? Is the footer menu always at the bottom?\n 4. Compare Order: Look at the items within each repeating navigation element (e.g., the links inside the main menu). Are they always presented in the exact same sequence?\n 5. Evaluate:\n - Pass: Repeating navigation elements maintain the same relative location and the same relative order across all pages where they appear.\n - Fail: If the position of a repeating navigation element changes significantly across pages (e.g., header vs. sidebar), or if the order of items within a repeating menu changes between pages."
},
{
"rule_id": "nonaxe-consistent-identification",
"standard_code": "3.2.4",
"Notes": null,
"issue_severity": "minor",
"wcag_version_number": 2,
"wcag_level": "AA",
"affected_disabilities_json": "Cognitive | Low vision",
"help": "Identify repeating functions consistently.",
"title": "Components with the same function are not consistently identified",
"dev_help": "1. Identify all components with the same functionality across the website.\n 2. Ensure that these components use the same labels. For example, a button that submits a form should always be labeled 'Submit'.\n 3. Maintain consistent visual presentation. If a button uses a specific icon and color scheme on one page, it should use the same icon and color scheme on all other pages where it performs the same function.\n 4. Standardize the placement of common elements such as navigation menus, search bars, and login buttons.\n 5. Verify that the behavior of interactive elements is consistent. For example, if a link opens in a new tab on one page, it should do the same on all pages.\n 6. Use a style guide or component library to enforce consistency across the entire website.",
"help_url": "https://www.w3.org/WAI/WCAG22/Understanding/consistent-identification.html",
"description": "Actions are more predictable across pages.",
"layman_help": "1. Check all the buttons, links, and other interactive things on your website.\n 2. Make sure that if something does the same thing, it always looks and acts the same way no matter what page you're on.\n 3. For example, if you have a 'Contact Us' link, make sure it's always in the same place and looks the same on every page.\n 4. If a button is blue and says 'Submit' on one page, make sure it's also blue and says 'Submit' on all other pages where it does the same thing.\n 5. This helps everyone, especially people who have trouble remembering things or seeing clearly, use your website more easily.",
"passed_title": "Similar components are identified consistently.",
"dev_description": "Ensure that components with the same functionality across different web pages are consistently identified. This includes using the same labels, icons, placement, and behavior for interactive elements like buttons, links, and form controls. Inconsistent presentation and functionality can cause confusion and make it difficult for users to predict the outcome of their actions.",
"layman_description": "Imagine using a website where the 'Search' button changes its location and appearance on every page. This can be confusing and frustrating, especially for people with cognitive disabilities or low vision. This rule ensures that if something does the same thing on different pages, like a 'Search' button, it looks and acts the same way, making the website easier to use.",
"how_to_test": "1. Find Repeating Navigation: Identify the navigation blocks that are reused across many pages (e.g., header menu, footer menu, search bar).\n 2. Browse Multiple Pages: Go to different pages on the site (homepage, content page, contact page, etc.).\n 3. Check Location: Look at a specific repeating block (like the header menu). Is it always in the same relative spot (e.g., always across the top)?\n 4. Check Order: Look inside that repeating block (like the links within the header menu). Are the items always listed in the exact same sequence?\n 5. Evaluate:\n - Pass: Repeating navigation blocks consistently appear in the same relative location with the same internal order of items on all pages where they are present.\n - Fail: If the location of a repeating navigation block changes significantly between pages, or if the order of links/items within that block changes."
},
{
"rule_id": "nonaxe-change-on-request",
"standard_code": "3.2.5",
"Notes": null,
"issue_severity": "moderate",
"wcag_version_number": 2,
"wcag_level": "AAA",
"affected_disabilities_json": "Cognitive | Low vision | Mobility",
"help": "Provide ways for users to trigger or turn off changes of context.",
"title": "Context changes occur without explicit user request",
"dev_help": "1. Identify any instances where major content changes occur automatically without user initiation.\n 2. Implement controls to ensure that such changes only happen after a user action (e.g., button click, form submission).\n 3. If automatic changes are unavoidable, provide a clear warning to the user before the change occurs.\n 4. Ensure focus is managed appropriately after a change to guide users to the updated content.\n Example: Instead of automatically redirecting a user after a timer expires, display a message and a button to redirect manually.",
"help_url": "https://www.w3.org/WAI/WCAG22/Understanding/change-on-request.html",
"description": "Users have full control of major content changes.",
"layman_help": "1. Check if the website changes without you clicking or doing anything.\n 2. Make sure the changes only happen when you click a button or fill out a form.\n 3. If the website has to change automatically, it should warn you first.\n 4. After the change, make sure the website shows you where the new information is so you don't get lost. \n Example: Instead of sending you to a different page automatically after a few seconds, show a message that says 'Click here to continue'.",
"passed_title": "Context changes occur only on explicit user request.",
"dev_description": "Ensure that major changes to the content of a web page that can disorient users or interfere with their tasks only occur when initiated by the user. This includes changes like submitting a form, activating a link, or any action that a user would reasonably expect to trigger a change. Avoid unexpected content updates, focus shifts, or page reloads that are not directly requested by the user.",
"layman_description": "Imagine reading a website, and suddenly, the page changes without you clicking anything! This can be confusing and frustrating, especially if you have trouble focusing or seeing the screen clearly. This rule ensures that significant changes on a webpage only happen when you, the user, ask for them. For example, clicking a button should change the page, but the page shouldn't change on its own unexpectedly. This helps everyone stay oriented and in control.",
"how_to_test": "1. Review 'On Focus' / 'On Input' Tests: Revisit the findings from testing SC 3.2.1 (On Focus) and SC 3.2.2 (On Input). Any change of context identified there that happens automatically without user request (and without prior warning) would likely also fail this stricter Level AAA check.\n 2. Identify Potential Automatic Changes: Look for features that might update or change context automatically:\n - Auto-refreshing content sections (like stock tickers, news feeds).\n - Automatic redirection from one page to another (client-side redirects).\n - Links or controls that open new windows/tabs without warning.\n - Form submissions triggered automatically (e.g., by selecting from a list).\n 3. Check Trigger: For any identified automatic change of context:\n - Was it initiated by an explicit user action (clicking a submit button, activating a link clearly marked to open a new window, clicking an \"Update Now\" button)? If yes, it passes.\n 4. Check for Disable Mechanism: If the change happens automatically (like an auto-refreshing section):\n - Is there a control available (like a pause button or a setting) that allows the user to turn off these automatic updates? If yes, it passes.\n 5. Evaluate:\n - Pass: All significant changes of context are initiated by explicit user request OR a mechanism is available to turn off automatic changes.\n - Fail: If a significant change of context (like submitting a form, navigating, opening a new window unexpectedly, or auto-updating content) happens automatically without user request AND there is no way for the user to turn off the automatic change."
},
{
"rule_id": "nonaxe-consistent-help",
"standard_code": "3.2.6",
"Notes": null,
"issue_severity": "minor",
"wcag_version_number": 2.2,
"wcag_level": "A",
"affected_disabilities_json": "Cognitive | Low vision | Mobility",
"help": "Put help in the same place when it is on multiple pages.",
"title": "Help mechanisms are not provided consistently across the website",
"dev_help": "1. Provide a clear and consistent link to help/support: Place a link (e.g., 'Help', 'Support', 'Contact Us') in a consistent location on every page, typically in the header or footer.\n Example: `<a href=\"/help\">Help</a>`\n 2. Offer multiple support channels: Provide various ways for users to get help, such as email, phone, chat, and FAQs.\n 3. Ensure contact information is up-to-date: Regularly verify that all contact details (phone numbers, email addresses) are accurate.\n 4. Make FAQs easily accessible and searchable: Create a comprehensive FAQ section and include a search function to help users quickly find answers.\n 5. Implement Contextual Help: Add help tips next to the related parts of the webpage.\n Example: `<label for=\"name\">Your Name: <span aria-label=\"Enter your full name.\">[?]</span></label>`",
"help_url": "https://www.w3.org/WAI/WCAG22/Understanding/consistent-help.html",
"description": "Make it easier to find help and support.",
"layman_help": "1. Make help easy to find: Put a 'Help' button or link in the same place on every page, like at the top or bottom.\n 2. Offer different ways to get help: Provide options like a phone number, email address, or online chat.\n 3. Keep contact information current: Make sure the phone numbers and email addresses are always correct.\n 4. Create a 'Frequently Asked Questions' (FAQ) page: List common questions and answers, and make it easy to search.\n 5. Add help tips: Add hints next to parts of the page that people may have difficulty understanding.",
"passed_title": "Help mechanisms are consistently available site-wide.",
"dev_description": "Ensure that users can easily find help and support information on the website. This includes providing clear and consistent links to contact information, FAQs, tutorials, or other support resources. The location of these links should be predictable across the site to enhance usability. Implementing features like chatbots and contextual help can also significantly improve accessibility. For AAA compliance, customisation of help texts is needed for different user groups.",
"layman_description": "Imagine you're lost in a big store and can't find what you need. Websites should have clear signs showing you where to get help. This could be a phone number, a 'frequently asked questions' page, or a way to chat with someone online. It's like having a helpful assistant available whenever you need it. This is very important for people with cognitive disabilities, who may get lost on a website, users with low vision who may struggle to locate help content, or people with mobility impairments who may find it difficult to navigate to a help section.",
"how_to_test": "1. Identify Help Mechanisms: Browse the site and find any ways users can get help. This could include:\n - Contact phone number or email address.\n - Link to a \"Contact Us\" page or form.\n - Link to an FAQ or Help Center.\n - A live chat widget.\n 2. Identify Page Sets: Determine if the website has distinct sets of related pages (e.g., main site pages, blog pages, shop pages). Testing should focus on consistency within a set.\n 3. Visit Multiple Pages within a Set: Navigate to several different pages that belong to the same set (e.g., homepage, about page, services page).\n 4. Check Location Consistency: If a specific help mechanism (like the \"Contact Us\" link or the chat widget) appears on these pages:\n - Is it located in the same relative position on each page (e.g., always in the main footer, always in the top right of the header, always in the bottom-right corner)?\n - Does it appear in the same relative order compared to other elements that are also consistent (like navigation links)?\n 5. Evaluate:\n Pass: Any help mechanisms that repeat across multiple pages within a set are found in the same relative location and order.\n Fail: If a help mechanism (e.g., Contact Us link) appears in significantly different locations (e.g., header on one page, footer on another, sidebar on a third) across pages within the same related set."
},
{
"rule_id": "nonaxe-error-identification",
"standard_code": "3.3.1",
"Notes": null,
"issue_severity": "moderate",
"wcag_version_number": 2,
"wcag_level": "A",
"affected_disabilities_json": "Blind | Low vision | Cognitive | Attention Deficit",
"help": "Provide descriptive notification of errors.",
"title": "Errors are not clearly identified or described to users",
"dev_help": "1. Identify input fields where errors are possible.\n 2. Implement client-side validation to detect errors early.\n 3. Use server-side validation as a backup.\n 4. Provide clear, specific error messages related to the error\n 5. Programmatically associate the error message with the input field using `aria-describedby` or other appropriate methods.\n 6. Ensure error messages are visually prominent and easily noticeable.\n \n\n Example:",
"help_url": "https://www.w3.org/WAI/WCAG22/Understanding/error-identification.html",
"description": "Users know an error exists and what is wrong.",
"layman_help": "1. When you fill out a form and make a mistake, look for a message that clearly explains what's wrong.\n 2. Make sure the message is near the field where you made the mistake so you know exactly what to fix.\n 3. Read the message carefully, and follow the instructions to correct your mistake.\n 4. If you're using a screen reader, it will read the error message to you, so listen carefully and make the necessary changes.",
"passed_title": "Errors are clearly identified and described to users.",
"dev_description": "WCAG 3.3.1 (Error Identification) requires that when an input error is automatically detected, the user is informed of the error and provided with sufficient information to correct it. This involves providing clear and specific error messages that are programmatically associated with the problematic input field. The error message should describe the nature of the error and guide the user on how to fix it. The error message should be displayed near the input field where the error occurred.",
"layman_description": "Imagine filling out a form online, and you make a mistake. This rule ensures that the website clearly tells you what you did wrong and helps you fix it. For example, if you forget to type your email address correctly, the site should tell you that the email is in the wrong format and show where exactly the error is. This is especially helpful for people who have trouble seeing the screen clearly, have difficulty understanding complex instructions, or use screen readers which read the error message out loud.",
"how_to_test": "1. Find Forms: Locate any forms on the page (contact forms, login, registration, search, etc.).\n 2. Make Errors: Try submitting the form with intentional errors:\n - Leave required fields blank.\n - Enter data in the wrong format (e.g., letters in a phone number field, an invalid email format like \"test@test\").\n - Enter data that violates a rule (e.g., password too short, zip code wrong length).\n 3. Attempt Submission: Click the submit button.\n 4. Observe Error Handling: If errors are detected, check the following:\n - Is the error described in text? Is there a message clearly stating what is wrong (e.g., \"This field is required,\" \"Invalid email format\")?\n - Is the field in error identified? Is it clear which specific input field the error message refers to? This could be by:\n => Placing the error message directly next to the field.\n => Visually highlighting the field (e.g., border color change) in addition to the text message.\n => Providing a summary message at the top of the form listing the errors and linking to the specific fields.\n - Is the error information accessible? (Recommended: Use a screen reader). Does the screen reader announce the errors and correctly associate them with their respective fields? (This often involves checking the code for techniques like aria-describedby linking the error message to the input, or aria-invalid=\"true\" on the input).\n 5. Evaluate:\n - Pass: Errors are identified, described clearly in text, and associated with the specific input field(s) that need correction.\n - Fail: Errors are indicated only by color or icons without text descriptions. Error messages are vague (e.g., \"Invalid input\") without identifying the specific field or problem. Required fields aren't clearly indicated as being missed."
},
{
"rule_id": "form-field-multiple-labels",
"standard_code": "3.3.2",
"Notes": null,
"issue_severity": "moderate",
"wcag_version_number": 2,
"wcag_level": "A",
"affected_disabilities_json": "Blind | Low vision | Cognitive",
"help": "Form field must not have multiple label elements",
"title": "User input fields lack clear labels or instructions",
"dev_help": "1. Identify form fields with multiple associated `<label>` elements.\n 2. Remove the duplicate `<label>` elements, ensuring only one `<label>` is associated with each input.\n 3. Verify that the remaining `<label>` element's `for` attribute correctly matches the `id` of the associated form field.\n \n\n Example:\n Incorrect:\n \n Correct:",
"help_url": "https://dequeuniversity.com/rules/axe/4.10/form-field-multiple-labels?application=axeAPI",
"description": "Ensure form field does not have multiple label elements",
"layman_help": "1. Find any form fields that seem to have more than one label.\n 2. Remove the extra labels so that each form field only has one label.\n 3. Make sure the label is correctly connected to the form field. This is like making sure the right sign is pointing to the right door.\n \n\n Example: If you see two labels for 'Name', remove one and make sure the remaining label clearly says what to enter (like 'Full Name').",
"passed_title": "Input fields have clear labels or instructions.",
"dev_description": "Form fields should be associated with a single `<label>` element using the `for` attribute, which corresponds to the input's `id` attribute. Multiple labels can cause confusion for assistive technology users, as it's unclear which label is the correct one associated with the input. This rule checks that each form field has a single, correctly associated label.",
"layman_description": "Imagine a form where you have to fill in your name, but there are two labels for the same name field. This can be confusing, especially if you're using a screen reader because the screen reader might read out both labels, making it difficult to know which one is actually for your name. This rule makes sure each form field has one clear label so everyone knows what information to enter.",
"how_to_test": null
},
{
"rule_id": "nonaxe-error-suggestion",
"standard_code": "3.3.3",
"Notes": null,
"issue_severity": "minor",
"wcag_version_number": 2,
"wcag_level": "AA",
"affected_disabilities_json": "Cognitive | Low vision | Mobility",
"help": "Where errors are detected, suggest known ways to correct them.",
"title": "No clear suggestions provided for correcting input errors",
"dev_help": "['1. Implement client-side validation to provide immediate feedback to users.', '2. Use aria-describedby to link error messages with the associated form fields.', '3. Provide specific and actionable suggestions related to the error.', '4. Ensure suggestions are displayed close to the input field.', '5. Test with assistive technologies to confirm the suggestions are accessible.']",
"help_url": "https://www.w3.org/WAI/WCAG22/Understanding/error-suggestion.html",
"description": "Users get suggestions on how to resolve errors.",
"layman_help": "['1. Make sure the website tells you exactly what you did wrong.', \"2. The website should give you tips right away, as you're typing.\", '3. The tips should be clear and easy to understand.', '4. Check if the tips appear near where you made the mistake.']",
"passed_title": "Clear suggestions guide users to correct input errors.",
"dev_description": "Ensure that helpful suggestions are provided to users when input errors are detected. These suggestions should guide users towards correcting the errors and successfully completing the form or process. The suggestions must be contextual and related to the error. Consider providing inline suggestions, tooltips, or clear error messages near the erroneous field.",
"layman_description": "When you make a mistake while filling out a form, the website should give you hints on how to fix it. For example, if you enter the wrong format for a date, the website should tell you the correct format instead of just saying 'Error.' This helps people, especially those with cognitive or vision problems, understand and correct their mistakes more easily, making it less frustrating to use the website.",
"how_to_test": "1. Identify Forms and Fields: Find forms on the page where input is validated and suggestions might be possible (e.g., fields for names, cities, dates, phone numbers, emails; avoid testing password fields).\n 2. Make Plausible Errors: Enter data that is incorrect but where a suggestion is reasonable:\n - Misspell a common word (e.g., \"Testt\" instead of \"Test\", \"Chicargo\" instead of \"Chicago\").\n - Enter a date or phone number in a slightly wrong but recognizable format (e.g., \"1/5/25\" instead of \"01/05/2025\").\n - Enter text that's close to a valid option if choices are limited.\n 3. Trigger Validation: Submit the form or move focus away from the field (if validation happens dynamically).\n 4. Analyze the Error Message: When the error is identified (as required by SC 3.3.1):\n - Check for Suggestions: Does the error message provide guidance on how to fix the input? Does it:\n => Explain the expected format? (e.g., \"Phone number must be 10 digits\").\n => Suggest a specific correction? (e.g., \"Did you mean 'London'?\").\n => List allowed values if input must be one of them?\n 5. Evaluate:\n - Pass: If, for detected errors where a suggestion is reasonably possible and appropriate, the error message provides helpful text guidance or specific suggestions for correction.\n - Fail: If an error is detected, but the error message is vague (\"Invalid Input\") and provides no guidance on how to fix it, even when a likely correction or format requirement could have been suggested. (Note: If the system truly cannot determine a suggestion, then not providing one is acceptable)."
},
{
"rule_id": "nonaxe-error-prevention-legal-financial-data",
"standard_code": "3.3.4",
"Notes": null,
"issue_severity": "moderate",
"wcag_version_number": 2,
"wcag_level": "AA",
"affected_disabilities_json": "Cognitive | Low vision | Mobility",
"help": "Provide ways for users to confirm, correct, or reverse important submissions.",
"title": "Users can't review, correct, or undo submissions with important data",
"dev_help": "1. Implement a review page before final submission where users can see all entered information.\n 2. Provide clear 'Edit' links or buttons next to each section of the form.\n 3. Offer an 'Undo' or 'Cancel' option for critical actions.\n 4. Use client-side validation to highlight errors in real-time, but always validate on the server-side.\n 5. Provide specific and helpful error messages. For example, instead of 'Invalid input,' use 'Please enter a valid email address'.\n 6. For irreversible actions, display a confirmation dialog to ensure the user intended the action.\n 7. Ensure the review page and error messages are accessible to screen readers.",
"help_url": "https://www.w3.org/WAI/WCAG22/Understanding/error-prevention-legal-financial-data.html",
"description": "Users can avoid submitting incorrect important information.",
"layman_help": "1. Before you finish, there should be a page that shows you everything you've entered so you can check it.\n 2. Make sure there are buttons or links that allow you to change the information if you need to.\n 3. If you're doing something important, like deleting an account, there should be a way to cancel or undo it.\n 4. The website should check for mistakes as you type, but it should also double-check on its end to make sure everything is correct.\n 5. If you make a mistake, the website should tell you exactly what's wrong, like 'Please enter a valid phone number.'\n 6. For very important actions, a pop-up should appear asking you to confirm that you really want to do it.\n 7. Make sure that people using screen readers can also review their information and understand any error messages.",
"passed_title": "Users can review, correct, or undo important submissions.",
"dev_description": "Ensure that mechanisms are in place to allow users to review, correct, or reverse submissions of important information before the submission is finalized. This can be achieved through confirmation screens, edit options, or the ability to undo actions. Important information includes financial data, legal commitments, or personal details that could have significant consequences if entered incorrectly. Implement server-side validation to prevent malicious data injection, in addition to client-side validation for usability, and handle errors gracefully, providing clear and actionable feedback to the user. Avoid relying solely on client-side validation, as it can be bypassed.",
"layman_description": "Imagine you're filling out a form to buy something online. This rule ensures that before you finally click 'Submit,' you have a chance to double-check everything you've typed. This is particularly important for crucial information like your address, credit card details, or agreeing to terms and conditions. If you make a mistake, it could cause serious problems, like ordering the wrong item or being charged incorrectly. This rule helps people with cognitive disabilities, low vision, or mobility issues, who may find it harder to spot and correct errors quickly.",
"how_to_test": "1. Identify Critical Processes: Find any parts of the website where users:\n - Agree to legal terms/contracts.\n - Complete purchases or financial transactions.\n - Submit important forms (like applications, tests).\n - Modify or delete user-controlled data (profiles, saved records, files).\n 2. Perform the Action (Up to Final Step): Go through the process until the very last step before the action becomes final (e.g., just before clicking the final \"Submit Payment,\" \"Agree & Sign,\" or \"Confirm Deletion\" button).\n 3. Look for Prevention Mechanisms: Check if at least one of these is present:\n - Reversible: Is there clear information stating you can undo or cancel the action after submitting (e.g., \"You can cancel this order within 30 minutes\")?\n - Checked: Does the system validate your input for errors at this stage (or earlier) and prompt you to fix them before you can finalize? (Relates to SC 3.3.1 but is crucial before finalizing here).\n - Confirm: Is there a summary page or confirmation step allowing you to review all the details (items, cost, address, data to be deleted, etc.) and providing an option to go back and edit before you commit to the final action?\n 4. Evaluate: If a process involves legal commitments, financial transactions, or modifying/deleting user data, and it lacks at least one of these three prevention methods (Reversible, Checked, Confirm) before the final submission, it fails this check."
},
{
"rule_id": "nonaxe-help",
"standard_code": "3.3.5",
"Notes": null,
"issue_severity": "minor",
"wcag_version_number": 2,
"wcag_level": "AAA",
"affected_disabilities_json": "Cognitive | Low vision | Mobility",
"help": "Provide help to users on the function currently being performed.",
"title": "Context-sensitive help is not available when needed",
"dev_help": "1. Offer Reversible Actions: Provide a clear way for users to undo submissions or actions, especially those involving financial transactions or data modification. For example, include an 'Undo' button after a purchase or a 'Restore' option after deleting data.\n 2. Implement Input Validation: Check user input for errors as it's entered. Use client-side validation to provide immediate feedback and server-side validation for a more robust check. Highlight invalid fields and provide clear error messages describing how to correct them. For example, check that an email address is in the correct format or that a password meets specific complexity requirements.\n 3. Provide Confirmation Steps: Before finalizing a critical action, present a summary of the information and require the user to confirm that it's correct. This could be a confirmation page before submitting an order or a verification step before deleting an account. For example, display an order summary with the items, quantity, and total cost and ask the user to click 'Confirm Order' to proceed.",
"help_url": "https://www.w3.org/WAI/WCAG22/Understanding/help.html",
"description": "Users can avoid making mistakes.",
"layman_help": "1. Make it Easy to Undo: Allow people to easily reverse their actions, especially when money or important information is involved. Think of it like an 'Oops! Take me back' button.\n 2. Check for Mistakes as You Go: The website should automatically check what you type to make sure it's correct. If there's a mistake, it should tell you right away and help you fix it.\n 3. Ask for Confirmation: Before anything final happens, the website should show you a summary of what you're about to do and ask you to confirm it. This gives you a chance to double-check and make sure everything is right.",
"passed_title": "Context-sensitive help is available when needed.",
"dev_description": "WCAG 3.3.5 (Error Prevention (Legal, Financial, Data)): For Web pages that cause legal commitments or financial transactions for the user to occur, that modify or delete user-controllable data in data storage systems, or that submit user test responses, at least one of the following is true: (1) Reversible: Submissions are reversible. (2) Checked: Data entered by the user is checked for input errors and the user is provided an opportunity to correct them. (3) Confirmed: A mechanism is available for reviewing, correcting, or confirming the information before finalizing the submission.",
"layman_description": "This rule helps people avoid making serious mistakes when using websites, especially when it comes to things like buying something, managing money, or entering important information. It ensures that you have a chance to undo actions, check your entries for errors, or confirm everything before it's final. This is helpful for everyone, but especially those with cognitive or motor impairments, who might be more prone to errors. Without this, someone might accidentally buy the wrong item or delete important data and not have a way to fix it.",
"how_to_test": "1. Identify Complex Areas: Find parts of the website that might be complex or require specific input, such as forms with multiple fields, configuration settings, or multi-step processes.\n 2. Look for Contextual Help: As you interact with these complex areas, look for help mechanisms provided in relation to specific fields or sections. Check for:\n - Inline instructions clarifying requirements for a field (e.g., password complexity rules listed nearby).\n - Examples showing the expected data format (e.g., \"(###) ###-####\" next to a phone field).\n - Help icons (like '?') next to fields or sections that provide relevant tips or explanations when activated.\n - Links like \"Help with this section\" that lead to specific guidance, not just a generic help page.\n - Features like spell-check suggestions within text areas.\n 3. Evaluate Availability and Relevance:\n - Is help available within the context where a user might need it?\n - Is the help relevant to the specific field or task?\n - Is the existence of the help mechanism obvious?\n 4. Consider Sufficiency: Is the standard label for a field sufficient on its own? Context-sensitive help is only required if the label isn't enough to describe all functionality or requirements. For very simple, common fields (\"First Name\"), extra help might not be needed. For more complex fields (\"Adjust Depreciation Schedule\"), it likely is.\n 5. Evaluate:\n - Pass: Context-sensitive help is available where needed (i.e., where labels alone aren't sufficient) to assist users in understanding and completing tasks or providing input correctly.\n - Fail: Complex forms or interactions lack readily available, context-specific instructions or help mechanisms. Relying solely on a generic help page link located elsewhere on the page generally fails this check."
},
{
"rule_id": "nonaxe-error-prevention-all",
"standard_code": "3.3.6",
"Notes": null,
"issue_severity": "moderate",
"wcag_version_number": 2,
"wcag_level": "AAA",
"affected_disabilities_json": "Cognitive | Low vision | Mobility",
"help": "Provide ways for users to confirm, correct, or reverse any submissions.",
"title": "No mechanisms provided to prevent or correct input errors across contexts",
"dev_help": "['1. Provide clear and concise instructions for filling out forms and using interactive elements.', '2. Implement input validation to catch errors on the client-side before submission. Use appropriate input types (e.g., email, number) to leverage built-in browser validation.', 'Example: `<input type=\"email\" required>`', '3. Offer confirmation steps for critical actions, such as placing an order or deleting data. Use confirmation dialogs or review screens.', '4. Implement undo functionality where appropriate, allowing users to reverse actions easily.', '5. For multi-step processes, allow users to review and modify previous steps before proceeding.', '6. Provide error messages that are clear, specific, and actionable. Indicate the location of the error and how to correct it.', 'Example: `<span>Please enter a valid email address.</span>`', '7. Use labels and instructions that are persistently visible and associated with the correct form fields.', 'Example: `<label for=\"name\">Name:</label> <input type=\"text\" id=\"name\" name=\"name\">`']",
"help_url": "https://www.w3.org/WAI/WCAG22/Understanding/error-prevention-all.html",
"description": "Users can avoid submitting incorrect information.",
"layman_help": "['1. Websites should give you clear instructions on how to fill out forms.', '2. The website should check your answers as you type and tell you if something looks wrong before you submit it.', '3. Before you do something important, like buy something or delete a file, the website should ask you to confirm that you really want to do it.', '4. If you make a mistake, the website should let you easily undo it.', '5. If you have to fill out a long form in steps, the website should let you go back and change your answers from previous steps.', '6. If you make a mistake, the website should tell you exactly what you did wrong and how to fix it.', '7. Websites should make sure the labels that tell you what to type in each box are always visible and easy to understand.']",
"passed_title": "Mechanisms prevent or correct input errors across contexts.",
"dev_description": "Ensure that web forms and interfaces provide mechanisms to help users avoid and correct mistakes before submitting data. This can include providing clear instructions, allowing users to review and correct information, and offering confirmation steps for critical actions. Implement features such as undo functionality, confirmation dialogs, and data validation to minimize the risk of errors.",
"layman_description": "Imagine filling out a form online and accidentally typing something wrong. This rule makes sure websites give you a chance to check your answers and fix any mistakes before you send the form. This is important because people with disabilities, like those with cognitive issues or limited vision, might find it harder to spot errors. Giving everyone a chance to review and correct information makes the website easier to use for everyone.",
"how_to_test": "1. Identify All Forms: Find every form on the website where a user submits information (e.g., contact forms, comment forms, search boxes that submit data, user preference settings, etc.), not just the critical ones covered by SC 3.3.4.\n 2. Test Submission Process: For each form, fill it out and proceed to submit it.\n 3. Check for Prevention Mechanisms: Before or immediately after submitting, verify if at least one of these exists:\n - Reversible: After submission, is there an immediate and obvious way to undo or retract it (e.g., a \"Delete My Comment\" button appears next to the posted comment; a \"Revert Settings\" option)?\n - Checked: Before final submission, does the form check for input errors (like required fields, correct format) and allow you to correct them? (Relates to SC 3.3.1/3.3.3).\n - Confirm: Is there a review step before the final submission where you can check your input and confirm you want to proceed? (e.g., \"Preview your comment before posting?\").\n 4. Evaluate:\n - Pass: Every form submission process includes at least one of the three mechanisms (Reversible, Checked, or Confirmed).\n - Fail: Any form allows submission without offering at least one of these error prevention safeguards."
},
{
"rule_id": "nonaxe-redundant-entry",
"standard_code": "3.3.7",
"Notes": null,
"issue_severity": "moderate",
"wcag_version_number": 2.2,
"wcag_level": "A",
"affected_disabilities_json": "Cognitive | Low vision | Blind | Mobility | Attention Deficit",
"help": "Don't ask for the same information twice in the same session.",
"title": "Users are required to re-enter the same information unnecessarily",
"dev_help": "1. Ensure that instructions and labels are clear, concise, and easy to understand. Use plain language and avoid jargon. 2. Provide context-sensitive help messages that are tailored to the specific input field or step in the process. Use the 'aria-describedby' attribute to associate help messages with form elements. 3. Implement error prevention mechanisms, such as input masking and validation, to reduce the likelihood of errors. 4. Provide clear and informative error messages that tell users what went wrong and how to fix it. 5. Provide a 'help' button or link that is always visible on the page. This button should open a help panel or redirect users to a help page. 6. Allow users to save their progress and return to the process later. This can be done using cookies or server-side sessions. 7. Ensure that all help content is accessible to users with disabilities. Use semantic HTML, provide alternative text for images, and ensure that content is keyboard accessible.",
"help_url": "https://www.w3.org/WAI/WCAG22/Understanding/redundant-entry.html",
"description": "Make it easier for users to complete multi-step processes.",
"layman_help": "1. Use simple and clear instructions for each step. 2. Offer helpful tips and explanations right where people need them. 3. Try to prevent mistakes by giving users guidance as they fill things out. 4. If someone makes a mistake, tell them exactly what went wrong and how to fix it. 5. Have a 'Help' button or link always visible on the screen. 6. Allow people to save their progress so they can come back later. 7. Make sure the help information is accessible to everyone, including people with disabilities.",
"passed_title": "Users do not re-enter the same information unnecessarily.",
"dev_description": "For multi-step processes (e.g., online forms, checkout flows, wizards), ensure users can easily access help and guidance throughout the entire process. This includes providing clear instructions, context-sensitive help, and error prevention mechanisms. Help should be consistently available and easily discoverable, regardless of the user's current step in the process. Examples include: Providing clear labels and instructions for each input field, Offering context-sensitive help messages when users encounter errors, Providing progress indicators to show users how far they are in the process, Providing a 'help' button or link that is always visible on the page, Allowing users to save their progress and return to the process later.",
"layman_description": "Imagine filling out a long form online. This rule ensures that help is always available and easy to find, no matter where you are in the form. It's like having a friendly guide who can answer your questions or provide assistance whenever you need it. Without this, people with disabilities, especially those with cognitive or visual impairments, might get lost or frustrated and be unable to complete the form.",
"how_to_test": "1. Identify Multi-Step Processes: Find any tasks that involve filling out information over multiple steps or pages within a single session (e.g., checkout, registration, booking, multi-page applications).\n 2. Enter Information: Start the process and enter information when first asked (e.g., enter your shipping address).\n 3. Proceed to Later Steps: Continue through the process.\n 4. Look for Repeated Requests: Does the website ask for the exact same information again later in the same process (e.g., asking for the billing address fields after you already entered the shipping address)?\n 5. Check for Auto-fill or Selection: If the same information is requested again:\n - Is it automatically filled in for you?\n - Is there an easy option (like a checkbox or button) to reuse the information you entered earlier?\n 6. Evaluate:\n - Pass: If previously entered information is either automatically re-filled or easily selectable when requested again within the same process (unless an exception like password confirmation applies).\n - Fail: If the user is forced to manually re-type identical information previously entered in the same session, and no auto-fill or easy selection mechanism is provided (and it's not an essential re-entry like a password)."
},
{
"rule_id": "nonaxe-accessible-authentication-minimum",
"standard_code": "3.3.8",
"Notes": null,
"issue_severity": "minor",
"wcag_version_number": 2.2,
"wcag_level": "AA",
"affected_disabilities_json": "Cognitive | Low vision | Attention Deficit",
"help": "Don't make people solve, recall, or transcribe something to log in.",
"title": "Authentication lacks alternatives to cognitive tests or user help",
"dev_help": "1. Provide alternative login methods: Offer options like social logins (e.g., 'Login with Google') or password managers.\n 2. Simplify password requirements: Avoid overly complex password requirements.\n 3. Implement password reset: Make it easy for users to reset their passwords if they forget them.\n 4. Offer two-factor authentication: Implement 2FA methods that don't rely solely on memory or cognitive skills (e.g., using authenticator apps with biometric unlock).\n 5. Avoid cognitive tests for general login: Refrain from using CAPTCHAs or other cognitive challenges unless they are essential for preventing fraud or abuse.\n 6. If using cognitive tests for critical functions: Provide alternatives or assistance for users who struggle with these tests.",
"help_url": "https://www.w3.org/WAI/WCAG22/Understanding/accessible-authentication-minimum.html",
"description": "Make logins possible with less mental effort.",
"layman_help": "1. Use a Password Manager: Use a trusted password manager to store and automatically fill in your passwords.\n 2. Link Accounts: Connect with Google or Facebook so you don’t have to make a separate account.\n 3. Reset Passwords Easily: If you forget your password, it should be easy to reset it.\n 4. Two-Step Verification: Use an app on your phone or a code sent to your email address to double-check it’s you.\n 5. Avoid puzzles when you log in: Websites should not ask you to solve puzzles to log in, because it may be hard for people with disabilities to solve the puzzle.",
"passed_title": "Authentication offers alternatives to cognitive function tests.",
"dev_description": "Ensure that authentication processes do not rely solely on cognitive functions such as remembering complex passwords or solving cognitive challenges unless a cognitive function test is part of that process. Offer alternatives like password managers or social logins. Avoid cognitive tests unless they are explicitly tied to fraud or safety concerns. Offer assistance options, such as password reset features or two factor authentication.",
"layman_description": "Logging in to websites should not be overly complicated. People with memory or learning difficulties, or those who struggle to focus, can find it very difficult to remember complicated passwords or solve puzzles just to log in. This rule suggests offering easier ways to log in, like using a password manager, using your Google or Facebook account, or sending a code to your phone or email. Websites should try to avoid making you use your memory or brainpower too much just to log in, unless it is very important for security reasons. When you create an account at the super market, they should not test your brain power to let you create the account.",
"how_to_test": "1. Go to Login: Navigate to all login pages or processes on the site.\n 2. Identify Cognitive Tests: Does any step require the user to perform actions like:\n - Remembering and typing a password/PIN from memory?\n - Transcribing text/numbers from an image (e.g., standard visual CAPTCHA)?\n - Transcribing text/numbers from audio (e.g., standard audio CAPTCHA)?\n - Solving a puzzle (e.g., image matching, math problem)?\n - Transcribing a code sent via another method (e.g., SMS, email)?\n 3. Check for Alternatives or Help: If any cognitive test (from step 2) is present, is at least one of the following also available?\n - Alternative Method: Is there another way to log in that doesn't use that specific test? (e.g., \"Login with Google/Facebook/Apple\", email magic link, using a physical security key like YubiKey, biometrics like fingerprint/face ID if applicable).\n - Helping Mechanism:\n => Passwords: Can password managers auto-fill the password field? (i.e., is pasting allowed?) Is there a \"Show Password\" option?\n => Codes: Can verification codes (sent via SMS/email) be easily copied and pasted? Does the browser/OS offer to auto-fill the code?\n => CAPTCHA: Is an accessible CAPTCHA alternative offered? (e.g., a simple \"I'm not a robot\" checkbox, an object recognition task like \"select photos you uploaded\", or an audio option that doesn't require complex transcription). Is solving the CAPTCHA the only way to proceed?\n 4. Evaluate:\n - Pass: If every cognitive function test used in the login process either has an accessible alternative method available OR provides a mechanism (like copy-paste support, password manager support) that helps the user complete it without relying solely on memory, transcription, or puzzle-solving.\n - Fail: If the login process relies only on a cognitive function test (like memorizing and typing a password where pasting is blocked, or only offering a standard visual/audio CAPTCHA) without providing an alternative method or a helping mechanism."
},
{
"rule_id": "nonaxe-accessible-authentication-enhanced",
"standard_code": "3.3.9",
"Notes": null,
"issue_severity": "moderate",
"wcag_version_number": 2.2,
"wcag_level": "AAA",
"affected_disabilities_json": "Cognitive | Low vision | Attention Deficit",
"help": "Don't make people recognize objects or user-supplied images and media to login.",
"title": "Authentication methods lack flexible options for users needing extra support",
"dev_help": "1. Integrate with password managers: Allow users to easily save and retrieve their credentials using browser-based or third-party password managers.\n 2. Offer Single Sign-On (SSO): Implement SSO options using services like Google, Facebook, or institutional accounts to streamline the login process.\n 3. Provide Biometric Authentication: If feasible, offer biometric login options such as fingerprint or facial recognition.\n 4. Enable Copy-Paste: Allow users to copy and paste usernames and passwords into the login fields.\n 5. Use Clear and Actionable Error Messages: Provide specific and helpful error messages when login attempts fail (e.g., \"Incorrect username or password. Please try again or reset your password.\").\n 6. Avoid or Provide Accessible CAPTCHAs: If CAPTCHAs are necessary, provide accessible alternatives like audio CAPTCHAs or no CAPTCHA reCAPTCHA. Consider using methods other than CAPTCHAs like rate limiting or honeypots.\n 7. Offer password reset options: Make it easy to reset passwords.",
"help_url": "https://www.w3.org/WAI/WCAG22/Understanding/accessible-authentication-enhanced.html",
"description": "Make logins possible with less mental effort.",
"layman_help": "1. Use a password manager: A password manager helps you remember your passwords, so you don't have to try to remember them yourself.\n 2. Log in with Google or Facebook: If a website lets you log in with your Google or Facebook account, it can make it easier because you don't have to remember another password.\n 3. Use your fingerprint or face: Some websites let you log in with your fingerprint or face, which can be easier than typing a password.\n 4. Copy and paste your password: Make sure the website lets you copy and paste your password into the login box.\n 5. Get clear help when you make a mistake: If you type your password wrong, the website should tell you what to do to fix it (like try again or reset your password).\n 6. Make security checks easy: If the website uses a security check (like a CAPTCHA), make sure it's easy to use, even for people who have trouble seeing or hearing.\n 7. Make it easy to reset your password.",
"passed_title": "Authentication methods support users needing extra help.",
"dev_description": "Provide mechanisms to assist users in remembering, transcribing, and entering information during login processes to reduce cognitive load. This includes features like password managers integration, single sign-on (SSO) options, biometric authentication, and the option to copy and paste credentials. Avoid CAPTCHAs or provide accessible alternatives. Ensure that error messages related to login failures are clear, informative, and actionable.",
"layman_description": "Logging into websites should be easy and not require too much thinking. This rule suggests ways to help people remember their usernames and passwords, like using password managers or logging in with a fingerprint. It also means avoiding confusing security checks, like CAPTCHAs, that can be hard for some people to use. This is especially helpful for people with memory problems, learning disabilities, or trouble focusing, as well as those with low vision who may struggle to type accurately.",
"how_to_test": "1. Go to Login: Navigate to all login pages or processes.\n 2. Analyze ALL Steps: Review every required step in the authentication flow(s).\n 3. Identify Any Cognitive Test: Does any step require the user to:\n - Remember and type a password/PIN?\n - Transcribe text/codes from images or audio (CAPTCHA)?\n - Solve a puzzle?\n - Transcribe a code sent separately (SMS/email)?\n - Recognize objects (e.g., \"select all images with cars\")?\n - Identify personal content (e.g., \"select your security photos\")?\n 4. Check for Alternatives/Help: If any test from step 3 is present, is there always an alternative method OR a helping mechanism provided that completely bypasses that specific cognitive test?\n - Alternative Method: Can the user choose a different path that avoids the test entirely (e.g., use \"Login with Google\" instead of password, use a hardware key instead of SMS code)?\n - Helping Mechanism: Does the site fully support mechanisms that remove the cognitive load?\n => Allows password manager auto-fill/paste for passwords?\n => Allows copy-paste or OS auto-fill for verification codes?\n => Provides truly accessible CAPTCHA alternatives that don't rely on transcription or complex recognition?\n 5. Evaluate:\n - Pass: The authentication process can be completed without the user ever needing to rely on remembering/typing credentials from memory, transcribing codes, solving puzzles, recognizing objects, or identifying personal content, because sufficient alternative methods or helping mechanisms are always available at each step.\n - Fail: If any step requires the user to perform a cognitive function test (including object recognition or identifying personal content) and provides no alternative method or mechanism to bypass that specific cognitive test. For example, requiring password entry from memory (even if pasting is allowed) fails AAA; requiring transcription of an SMS code (if copy/paste or auto-fill is blocked) fails AAA; relying solely on object-recognition CAPTCHA fails AAA."
},
{
"rule_id": "aria-command-name",
"standard_code": "4.1.2",
"Notes": null,
"issue_severity": "serious",
"wcag_version_number": 2,
"wcag_level": "A",
"affected_disabilities_json": "Blind | Low vision | Cognitive | Mobility",
"help": "ARIA commands must have an accessible name",
"title": "ARIA command elements lack clear, accessible names for screen readers",
"dev_help": "1. Check for missing accessible names: Identify all ARIA button, link, and menuitem roles on the page.\n 2. Verify accessible name: Ensure that each element has an accessible name using one of the following methods:\n - `aria-label`: Add the `aria-label` attribute to the element, providing a descriptive name. Example: `<button aria-label='Close dialog'>X</button>`\n - `aria-labelledby`: Use `aria-labelledby` to reference another element on the page containing the accessible name. Example: `<h2 id='dialog-title'>Confirm Delete</h2><button aria-labelledby='dialog-title'>Delete</button>`\n - Text Content: For simple buttons and links, use the element's text content as the accessible name. Example: `<button>Submit</button>`\n 3. Test with a screen reader: Use a screen reader to verify that the accessible name is correctly announced for each element.",
"help_url": "https://dequeuniversity.com/rules/axe/4.10/aria-command-name?application=axeAPI",
"description": "Ensure every ARIA button, link and menuitem has an accessible name",
"layman_help": "If a button or link is missing a label, add a clear and simple description to it. Think about what the button does and write a short phrase that explains it. For example, instead of just having a button with an 'X' on it, label it 'Close'. This way, everyone knows what the button is for.",
"passed_title": "ARIA command elements have accessible names for readers.",
"dev_description": "This rule ensures that all ARIA button, link, and menuitem roles have an accessible name. An accessible name is crucial for assistive technologies like screen readers to convey the purpose of the element to users. Elements without accessible names are effectively invisible to screen reader users, leading to an inability to interact with these elements. An accessible name can be provided using techniques such as: `aria-label`, `aria-labelledby`, or using the element's text content.",
"layman_description": "Imagine a website with buttons that don't have labels. A person using a screen reader, which reads the website aloud, wouldn't know what these buttons do because the screen reader has nothing to announce. This rule makes sure that every interactive element (like buttons and links) has a clear name that assistive technologies can use, enabling people with disabilities to fully use the website.",
"how_to_test": null
},
{
"rule_id": "aria-required-attr",
"standard_code": "4.1.2",
"Notes": null,
"issue_severity": "critical",
"wcag_version_number": 2,
"wcag_level": "A",
"affected_disabilities_json": "Blind | Low vision | Mobility | Cognitive",
"help": "Required ARIA attributes must be provided",
"title": "Required ARIA attributes for elements with ARIA roles are missing",
"dev_help": "1. Identify the element with the ARIA role that is missing required attributes.\n 2. Consult the ARIA specification (WAI-ARIA) to determine which attributes are required for the specific role.\n 3. Add the missing ARIA attributes to the element with appropriate values. For example, if a `role=\"slider\"` is missing `aria-valuenow`, `aria-valuemin`, and `aria-valuemax`, add them like this: `<div role=\"slider\" aria-valuenow=\"50\" aria-valuemin=\"0\" aria-valuemax=\"100\"></div>`.\n 4. Test with assistive technologies to ensure the element is properly announced and interactive.",
"help_url": "https://dequeuniversity.com/rules/axe/4.10/aria-required-attr?application=axeAPI",
"description": "Ensure elements with ARIA roles have all required ARIA attributes",
"layman_help": "If something on a website is supposed to be a specific type of interactive element (like a button or a slider), it needs to have all the information that makes it work correctly with assistive technologies. A developer needs to check the code to see if any of these elements are missing necessary information. If they are, the developer must add the missing information to the element's code. After the code is updated, the developer should test it using assistive technology to verify that the element is working as expected.",
"passed_title": "Required ARIA attributes for roles are included.",
"dev_description": "This rule ensures that when an ARIA role is used on an HTML element, all the ARIA attributes required for that role are also present. ARIA (Accessible Rich Internet Applications) roles define the type of user interface element, while ARIA attributes provide additional information about the element's state, properties, and relationships. Failing to include required ARIA attributes can prevent assistive technologies from correctly interpreting and interacting with the element, leading to accessibility issues.",
"layman_description": "Imagine you're using a screen reader to navigate a website. ARIA roles tell the screen reader what a specific element is (like a button or a menu). ARIA attributes provide extra details about that element, such as whether a button is currently pressed or not. This rule makes sure that if something is defined as a specific type of element with ARIA, it also provides all the extra necessary details. Without those details, assistive technologies, like screen readers, can't accurately describe or allow interaction with the element, making it very difficult or impossible for people with disabilities to use the website.",
"how_to_test": null
},
{
"rule_id": "aria-hidden-focus",
"standard_code": "4.1.2",
"Notes": null,
"issue_severity": "serious",
"wcag_version_number": 2,
"wcag_level": "A",
"affected_disabilities_json": "Blind | Low vision | Mobility | Cognitive",
"help": "ARIA hidden element must not be focusable or contain focusable elements",
"title": "Keyboard focus is placed on elements hidden using aria-hidden=\"true\"",
"dev_help": "1. Identify focusable elements within `aria-hidden=\"true\"` containers: Use browser developer tools or accessibility testing tools to identify any elements within containers with `aria-hidden=\"true\"` that are still focusable (e.g., have a `tabindex` greater than or equal to 0, are naturally focusable like links or buttons, or have JavaScript event listeners that set focus).\n 2. Remove focusability from elements:\n * If the element is not meant to be interactive when hidden, remove it from the tab order by setting `tabindex=\"-1\"`. Example: `<button aria-hidden=\"true\" tabindex=\"-1\">Hidden Button</button>`\n * If the element needs to retain its functionality when it becomes visible, manage its `tabindex` dynamically using JavaScript. Set `tabindex=\"-1\"` when `aria-hidden=\"true\"` and remove the `tabindex` attribute or set it to `0` when `aria-hidden=\"false\"`.\n * For elements that become visible based on other conditions, ensure they are focusable only when visible.\n 3. Ensure no focusable elements are added to `aria-hidden` containers dynamically: If content is dynamically added to a container that is `aria-hidden`, verify that any focusable elements within the new content are also appropriately handled to prevent focusability when hidden.\n 4. Test with assistive technologies: Use a screen reader and keyboard navigation to verify that elements marked with `aria-hidden=\"true\"` are indeed hidden from assistive technologies and are not focusable.",
"help_url": "https://dequeuniversity.com/rules/axe/4.10/aria-hidden-focus?application=axeAPI",
"description": "Ensure aria-hidden elements are not focusable nor contain focusable elements",
"layman_help": "1. Find the hidden things on the page that you can still click on or select with your keyboard.\n 2. Make it so you can't click on or select them when they're hidden. This might mean changing some settings behind the scenes so your keyboard skips over them. \n 3. If the hidden things sometimes become visible, make sure they only become clickable when they're actually visible. \n 4. Test it out! Use tools that people with disabilities use (like screen readers) to make sure those hidden things really are hidden and don't cause any problems.",
"passed_title": "Focus is not placed on aria-hidden=\"true\" hidden elements.",
"dev_description": "Ensure that elements with the `aria-hidden=\"true\"` attribute are not focusable and do not contain any focusable elements. Focusable elements are those that can receive focus via keyboard navigation (e.g., links, buttons, form fields) or programmatically via JavaScript. If an element is hidden from assistive technologies using `aria-hidden=\"true\"`, it should also be removed from the focus order to prevent keyboard users from unexpectedly landing on hidden content. This prevents confusion and ensures a logical navigation flow for users of assistive technologies and keyboard-only users.",
"layman_description": "If something is hidden on a webpage using special code ('aria-hidden=\"true\"'), it should also be made so you can't accidentally select it with your keyboard or other tools. Imagine trying to walk through a store, and your cane keeps hitting invisible shelves – that's how it feels for someone using assistive technology when hidden things are still selectable. This rule makes sure hidden stuff stays truly hidden, so it doesn't confuse people.",
"how_to_test": null
},
{
"rule_id": "aria-valid-attr",
"standard_code": "4.1.2",
"Notes": null,
"issue_severity": "critical",
"wcag_version_number": 2,
"wcag_level": "A",
"affected_disabilities_json": "Blind | Low vision | Cognitive",
"help": "ARIA attributes must conform to valid names",
"title": "ARIA attributes are invalid or misspelled",
"dev_help": "1. Check the spelling of the ARIA attribute. Ensure it matches the ARIA specification. For example, use aria-label instead of aria-labe.\n 2. Verify that the ARIA attribute is applicable to the HTML element it is used on. Some ARIA attributes are only meant for certain types of elements.\n 3. Consult the ARIA specification to confirm the correct usage of the attribute.\n 4. Remove any non-standard or custom aria-* attributes that are not part of the official ARIA specification.\n Example:\n Correct: `<button aria-label=\"Close\">X</button>`\n Incorrect: `<div aria-labelledby=\"some-id\"></div>` (if 'some-id' does not exist or is not appropriate)",
"help_url": "https://dequeuniversity.com/rules/axe/4.10/aria-valid-attr?application=axeAPI",
"description": "Ensure attributes that begin with aria- are valid ARIA attributes",
"layman_help": "1. Look for any special labels (ARIA attributes) on the website's code and make sure they are spelled correctly.\n 2. Check if the label is being used on the right part of the website. Some labels are only meant to be used on certain things.\n 3. If you're not sure, look up the label in a guide to see how it's supposed to be used.\n 4. Remove any labels that aren't standard or part of the official list of ARIA labels.",
"passed_title": "ARIA attributes are valid and correctly spelled.",
"dev_description": "Ensure that all ARIA attributes used in your HTML code are valid according to the ARIA specification. Invalid ARIA attributes are ignored by assistive technologies, leading to accessibility issues. This audit checks if the aria-* attributes are correctly spelled and exist in the ARIA specification. It also checks if the ARIA attributes are used on elements where they are allowed.",
"layman_description": "Imagine a website using special labels to help people using screen readers understand what different parts of the page are. If these labels are misspelled or used incorrectly, the screen reader might not understand them, leaving the user confused or unable to use the website properly. This rule checks to ensure these labels (called ARIA attributes) are written correctly so that assistive technologies like screen readers can work as expected.",
"how_to_test": null
},
{
"rule_id": "select-name",
"standard_code": "4.1.2",
"Notes": null,
"issue_severity": "critical",
"wcag_version_number": 2,
"wcag_level": "A",
"affected_disabilities_json": "Blind | Low vision | Cognitive",
"help": "Select element must have an accessible name",
"title": "<select> elements lack accessible names",
"dev_help": "1. Use a `<label>` element with the `for` attribute to associate it with the `<select>` element's `id` attribute: `<label for=\"mySelect\">Choose an option:</label><select id=\"mySelect\">...</select>`. 2. Use `aria-labelledby` attribute if the label is already present in the DOM: `<div id=\"selectLabel\">Choose an option:</div><select aria-labelledby=\"selectLabel\">...</select>`. 3. Use the `aria-label` attribute directly on the `<select>` element: `<select aria-label=\"Choose an option\">...</select>`. Ensure the accessible name accurately describes the purpose of the select element.",
"help_url": "https://dequeuniversity.com/rules/axe/4.10/select-name?application=axeAPI",
"description": "Ensure select element has an accessible name",
"layman_help": "Make sure every dropdown menu has a clear title or label. If you see a dropdown without a label, tell the website developers to add a label that clearly describes what the dropdown is for. This label should be visible on the screen and also be readable by screen readers.",
"passed_title": "<select> elements have accessible, descriptive names.",
"dev_description": "The `<select>` element must have an accessible name. This can be achieved using a `<label>` element associated with the `<select>` element using the `for` attribute and the `id` attribute, the `aria-labelledby` attribute, or the `aria-label` attribute. An accessible name provides a textual alternative that is used by assistive technologies to identify the purpose of the select element. Without an accessible name, users of assistive technologies may not be able to understand the purpose of the select element, making it difficult or impossible to use the form.",
"layman_description": "Imagine a form with a dropdown menu where you are asked to select an option, like your favorite color or your preferred shipping method. If this dropdown menu doesn't have a clear title or label that screen readers can understand, people who are blind or have low vision won't know what the dropdown is for. This makes it very difficult, if not impossible, for them to fill out the form.",
"how_to_test": null
},
{
"rule_id": "aria-deprecated-role",
"standard_code": "4.1.2",
"Notes": null,
"issue_severity": "minor",
"wcag_version_number": 2,
"wcag_level": "A",
"affected_disabilities_json": "Blind | Low vision | Mobility | Cognitive",
"help": "Deprecated ARIA roles must not be used",
"title": "Deprecated ARIA roles are used",
"dev_help": "1. Identify deprecated ARIA roles in your HTML code. These roles are typically flagged by accessibility testing tools or IDE extensions.\n 2. Replace the deprecated roles with their recommended alternatives. Refer to the ARIA specification for the most up-to-date roles and their proper usage.\n - For example, if you are using `role='application'` on an element that doesn't truly represent a complex interactive application, remove it or replace it with a more appropriate role such as `role='document'` or `role='region'`.\n 3. Test the changes with assistive technologies (e.g., screen readers) to ensure that the content is now properly interpreted and accessible. Use the accessibility testing tools to make sure there are no errors.\n Example:",
"help_url": "https://dequeuniversity.com/rules/axe/4.10/aria-deprecated-role?application=axeAPI",
"description": "Ensure elements do not use deprecated roles",
"layman_help": "1. Find the outdated labels (roles) on the website. Special tools or experts can help with this.\n 2. Replace the old labels with the new, correct ones. It's like updating the street signs on a map.\n 3. Check if the website now works correctly with tools used by people with disabilities (like screen readers). This ensures everyone can understand and use the website easily. You can use accessibility testing tools to make sure there are no errors.",
"passed_title": "Deprecated ARIA roles are not used.",
"dev_description": "Deprecated ARIA roles are roles that are no longer recommended for use because they have been superseded by newer roles or because they have been found to cause accessibility issues. Using deprecated roles can lead to unpredictable behavior in assistive technologies, making it difficult or impossible for users with disabilities to understand and interact with the content. For example, if a role such as 'application' is inappropriately used, it can override user expectations and keyboard navigation patterns, creating a confusing experience.",
"layman_description": "Imagine you are using a map that is out of date. It might show roads that no longer exist or not show new important landmarks. Similarly, websites use special labels called 'roles' to tell assistive technologies (like screen readers) what different parts of the page are. If the website uses old or outdated 'roles', the screen reader might misinterpret the page, making it confusing or impossible for someone with a disability to understand or use the website properly. This is like trying to find your way with an inaccurate map.",
"how_to_test": null
},
{
"rule_id": "aria-roles",
"standard_code": "4.1.2",
"Notes": null,
"issue_severity": "critical",
"wcag_version_number": 2,
"wcag_level": "A",
"affected_disabilities_json": "Blind | Low vision | Mobility | Cognitive",
"help": "ARIA roles used must conform to valid values",
"title": "Invalid ARIA roles are used on elements",
"dev_help": "1. Review all elements with the `role` attribute.\n 2. Verify that the value of the `role` attribute is a valid ARIA role according to the ARIA specification (https://www.w3.org/TR/wai-aria/#role_definitions).\n 3. Correct any invalid `role` values to valid ARIA roles.\n 4. If the role is not needed, remove the role attribute.\n Example: change `<div role='foo'>...</div>` to `<div role='button'>...</div>` or remove the role attribute if it's not needed.",
"help_url": "https://dequeuniversity.com/rules/axe/4.10/aria-roles?application=axeAPI",
"description": "Ensure all elements with a role attribute use a valid value",
"layman_help": "If you see a mistake, like a button being called something it's not, tell the website developers. They need to check all the labels on the website to make sure they are using the right ones. It's like making sure all the street signs point you in the right direction.",
"passed_title": "Only valid ARIA roles are used on elements.",
"dev_description": "This rule checks that all HTML elements using the `role` attribute have valid, supported values according to the ARIA specification. An invalid role can prevent assistive technologies from correctly interpreting and conveying the element's purpose and functionality to users. For example, `role='foo'` is an invalid role.",
"layman_description": "Imagine a website telling your screen reader that a button is actually a paragraph. This rule makes sure that all the labels used for elements like buttons, links, and sections are correct. If these labels are wrong, people using screen readers or other assistive tools won't be able to understand how to use the website properly. This can make it very confusing or even impossible for them to navigate and interact with the content.",
"how_to_test": null
},
{
"rule_id": "summary-name",
"standard_code": "4.1.2",
"Notes": null,
"issue_severity": "serious",
"wcag_version_number": 2,
"wcag_level": "A",
"affected_disabilities_json": "Blind | Low vision | Cognitive",
"help": "Summary elements must have discernible text",
"title": "<summary> elements lack accessible, descriptive text",
"dev_help": "1. Verify that each `<summary>` element contains meaningful text.\n 2. Ensure the text accurately describes the content hidden within the `<details>` element.\n 3. Check that the text has sufficient contrast against its background, meeting WCAG contrast requirements.\n 4. Ensure the `<summary>` element is focusable and has a proper accessible name.\n Example:\n \n Correct:\n \n Incorrect:",
"help_url": "https://dequeuniversity.com/rules/axe/4.10/summary-name?application=axeAPI",
"description": "Ensure summary elements have discernible text",
"layman_help": "1. Make sure that every 'summary' has text that makes sense.\n 2. The text should tell you exactly what you'll see when you click on the summary.\n 3. The text should be easy to read - not too small or hard to see because of the colors used.\n For example:\n Good:\n 'Click to see more about cats'\n Bad:\n (Nothing there! No text at all.)",
"passed_title": "<summary> elements have accessible, descriptive text.",
"dev_description": "The `<summary>` element, when used within a `<details>` element, should contain text that is easily discernible and provides a clear indication of the content that will be revealed when the `<details>` element is expanded. Ensure that the text within the `<summary>` element is not empty, uses sufficient contrast, and accurately reflects the content it represents.",
"layman_description": "When you click on a 'summary' (like a heading that expands to show more information), the text in that summary needs to be clear and easy to understand. It should tell you what you'll find when you click on it. If the text is missing or unclear, people who are blind (using screen readers) or have trouble understanding things won't know what the summary is about and what will happen when they click it.",
"how_to_test": null
},
{
"rule_id": "aria-toggle-field-name",
"standard_code": "4.1.2",
"Notes": null,
"issue_severity": "serious",
"wcag_version_number": 2,
"wcag_level": "A",
"affected_disabilities_json": "Blind | Low vision | Cognitive",
"help": "ARIA toggle fields must have an accessible name",
"title": "ARIA toggle elements lack accessible names indicating their purpose",
"dev_help": "1. Use `aria-label`: Add the `aria-label` attribute to the element with a descriptive name. Example: `<button role='switch' aria-checked='false' aria-label='Notifications'>`. \n 2. Use `aria-labelledby`: Reference another element on the page that contains the descriptive name using the `aria-labelledby` attribute. Example: `<span id='notification-label'>Notifications</span> <button role='switch' aria-checked='false' aria-labelledby='notification-label'>`. \n 3. Use element content: If the toggle contains text, ensure the text accurately describes the toggle's purpose. Example: `<button role='switch' aria-checked='false'>Notifications</button>` (if the button's visual design clearly indicates its toggle nature).",
"help_url": "https://dequeuniversity.com/rules/axe/4.10/aria-toggle-field-name?application=axeAPI",
"description": "Ensure every ARIA toggle field has an accessible name",
"layman_help": "Make sure every on/off switch has a clear label. This label should tell you exactly what the switch controls, like 'Notifications' or 'Sound Effects'. The label should be directly associated with the switch, so it's clear what it belongs to.",
"passed_title": "ARIA toggle elements have clear, accessible names.",
"dev_description": "ARIA toggle fields (elements with `role='switch'` or `aria-checked='true'|'false'`) must have an accessible name. This name provides context and meaning to the toggle, allowing users to understand its purpose and current state. An accessible name can be provided using `aria-label`, `aria-labelledby`, or the element's content.",
"layman_description": "Imagine a light switch without a label. You wouldn't know what it controls! Similarly, on websites, toggle switches (like on/off buttons) need clear names. This helps people, especially those who are blind or have difficulty understanding, to know what the switch does and whether it's currently on or off. Without a name, these switches become confusing and unusable.",
"how_to_test": null
},
{
"rule_id": "frame-title",
"standard_code": "4.1.2",
"Notes": null,
"issue_severity": "serious",
"wcag_version_number": 2,
"wcag_level": "A",
"affected_disabilities_json": "Blind | Low vision | Cognitive",
"help": "Frames must have an accessible name",
"title": "<iframe> or <frame> elements lack titles describing their purpose",
"dev_help": "1. Use the `title` attribute: Add a descriptive `title` attribute to the `<iframe>` or `<frame>` element. For example: `<iframe src=\"...\" title=\"YouTube video about web accessibility\"></iframe>`. \n 2. Use the `aria-label` attribute: If a visible title isn't desired, use `aria-label` to provide a text label. For example: `<iframe src=\"...\" aria-label=\"Interactive map of city parks\"></iframe>`.\n 3. Use the `aria-labelledby` attribute: If a visible element on the page describes the frame, use `aria-labelledby` to associate that element with the frame. For example: `<h2 id=\"map-title\">City Parks Map</h2><iframe src=\"...\" aria-labelledby=\"map-title\"></iframe>`.\n 4. Verify Implementation: After implementing a fix, test the page with a screen reader to ensure the accessible name is properly announced.",
"help_url": "https://dequeuniversity.com/rules/axe/4.10/frame-title?application=axeAPI",
"description": "Ensure <iframe> and <frame> elements have an accessible name",
"layman_help": "If you encounter a 'window' on a website that doesn't have a clear label, tell the website owner to add one. They can do this by adding a short description (like a title) directly to the 'window' code, or by linking the 'window' to a nearby heading or text that describes what it's about. This helps everyone understand what the 'window' is showing.",
"passed_title": "Titles on <iframe> and <frame> describe their purpose.",
"dev_description": "Ensure that all `<iframe>` and `<frame>` elements have an accessible name. This can be achieved by using the `title` attribute, `aria-label` attribute, or `aria-labelledby` attribute. Providing an accessible name allows assistive technologies like screen readers to accurately describe the purpose and content of the frame to users. Neglecting to provide an accessible name makes it difficult for users to understand the context and purpose of the embedded content, leading to confusion and a diminished user experience. For inline frames the title attribute is preferred and required.",
"layman_description": "Imagine browsing a website and encountering a section that's like a window to another page. This window is created using `<iframe>` or `<frame>` elements. If these windows don't have a label (like a title) that describes what's inside, it's like trying to understand a picture without a caption. People using screen readers or those with cognitive disabilities rely on these labels to know what the 'window' is about. Without it, they might miss important information or get confused.",
"how_to_test": null
},
{
"rule_id": "aria-braille-equivalent",
"standard_code": "4.1.2",
"Notes": null,
"issue_severity": "serious",
"wcag_version_number": 2,
"wcag_level": "A",
"affected_disabilities_json": "Blind | deafBlind",
"help": "aria-braille attributes must have a non-braille equivalent",
"title": "Braille label equivalents are not provided where required for assistive technologies\n\nText and images of text do not meet minimum contrast ratios",
"dev_help": "1. Identify elements using `aria-braillelabel` or `aria-brailleroledescription`.\n 2. For each element, ensure there is a corresponding visible text alternative or a programmatically associated text (e.g., using `aria-labelledby` or `aria-describedby`) that conveys the same meaning as the braille-specific attribute. Example: if you have `<button aria-braillelabel='Close Menu'>X</button>`, ensure that the button's visual text, which is 'X' here, means 'Close Menu' to sighted users.\n 3. If a visible text label is not appropriate, consider using `aria-labelledby` to associate a hidden element containing the equivalent text description. Example: `<button aria-braillelabel='Play' aria-labelledby='play-desc'>►</button><span id='play-desc' class='visually-hidden'>Play Audio</span>`.",
"help_url": "https://dequeuniversity.com/rules/axe/4.10/aria-braille-equivalent?application=axeAPI",
"description": "Ensure aria-braillelabel and aria-brailleroledescription have a non-braille equivalent",
"layman_help": "If you see something on a website that is only described using braille (special code for braille devices), make sure that same description is also available in regular text on the screen. This can be done by writing the same description next to the braille label or linking the braille label to a hidden piece of text that says the same thing. This way, everyone can understand what the braille label means, even if they don't use braille.",
"passed_title": "Braille labels are provided where assistive tech requires them.",
"dev_description": "Ensure that `aria-braillelabel` and `aria-brailleroledescription` attributes have equivalent non-braille text alternatives. These attributes provide specific information for braille users, and it's crucial that the same information is available in a standard text format for users who don't use braille or when braille output is unavailable. This ensures that all users have access to the same core information and functionality.",
"layman_description": "If a website uses special labels or descriptions that are only visible to people using braille devices, it must also provide the same information in regular text. This is important because not everyone uses braille. If information is only available in braille, people who don't use braille won't be able to understand or use the website properly. For example, a blind person not using a braille display or a sighted person assisting them.",
"how_to_test": null
},
{
"rule_id": "nested-interactive",
"standard_code": "4.1.2",
"Notes": null,
"issue_severity": "serious",
"wcag_version_number": 2,
"wcag_level": "A",
"affected_disabilities_json": "Blind | Low vision | Mobility | Cognitive",
"help": "Interactive controls must not be nested",
"title": "Interactive elements are nested within other interactive elements",
"dev_help": "1. Review the HTML structure to identify any nested interactive elements (e.g., `<button>` inside `<a>`, `<a>` inside `<button>`, or `<button>` inside `<button>`).\n 2. Restructure the HTML to avoid nesting. If an element needs to trigger multiple actions, consider using JavaScript to handle those actions separately on a single, properly structured interactive element.\n 3. For example, instead of `<button><a href='#'>Click Me</a></button>`, use a single `<a>` or `<button>` with appropriate styling and JavaScript event handlers to achieve the desired functionality.\n 4. Test with assistive technologies (screen readers, keyboard navigation) to ensure the controls are announced and function as expected.",
"help_url": "https://dequeuniversity.com/rules/axe/4.10/nested-interactive?application=axeAPI",
"description": "Ensure interactive controls are not nested as they are not always announced by screen readers or can cause focus problems for assistive technologies",
"layman_help": "1. Check if there are any buttons or links inside other buttons or links on the webpage.\n 2. If there are, try to rearrange the page so that buttons and links are separate.\n 3. If you need a button to do more than one thing, use a simple button and then use some code (JavaScript) to make it do all the things you need.\n 4. Test the page with a screen reader or by using only the keyboard to make sure everything works correctly.",
"passed_title": "Interactive elements are not nested within other interactives.",
"dev_description": "Interactive elements like buttons, links, and form fields should not be nested within each other. Nesting interactive controls can cause screen readers to misinterpret the page structure, leading to incorrect announcements. It can also create focus management issues, where assistive technologies have difficulty navigating the nested elements, and users may not be able to access or operate all controls.",
"layman_description": "Imagine buttons or links inside other buttons or links on a webpage. This can confuse people who use screen readers (software that reads the screen aloud) because the screen reader might not announce all the buttons correctly. It can also make it hard for people using keyboards or other assistive devices to click on the right thing because the focus might jump around unexpectedly. It's like having too many doors inside each other – you get lost and can't find the right one!",
"how_to_test": null
},
{
"rule_id": "aria-allowed-attr",
"standard_code": "4.1.2",
"Notes": null,
"issue_severity": "critical",
"wcag_version_number": 2,
"wcag_level": "A",
"affected_disabilities_json": "Blind | Low vision | Mobility | Cognitive",
"help": "Elements must only use supported ARIA attributes",
"title": "Disallowed ARIA attributes are used for certain roles",
"dev_help": "1. Identify the element with the incorrect ARIA attribute and role combination.\n 2. Check the ARIA specification to determine if the ARIA attribute is valid for the element's role. Refer to the WAI-ARIA specification for valid role-attribute combinations.\n 3. Correct the ARIA attribute or the element's role:\n a. If the ARIA attribute is unnecessary, remove it.\n b. If the ARIA attribute is necessary, change the element's role to a compatible one.\n c. If the role is correct, use only supported ARIA attributes.\n Example: Incorrect: `<img role='img' aria-required='true' src='image.png' alt='An image'>`.\n Correct: `<input type='text' role='textbox' aria-required='true'>` or `<img role='img' src='image.png' alt='An image'>`",
"help_url": "https://dequeuniversity.com/rules/axe/4.10/aria-allowed-attr?application=axeAPI",
"description": "Ensure an element's role supports its ARIA attributes",
"layman_help": "If you find a mismatch:\n 1. Figure out which part of the website has the incorrect label.\n 2. Look up whether the label is actually meant to be used with that specific kind of element.\n 3. Fix the issue:\n a. If the label isn't needed, just remove it.\n b. If the label is needed, change the kind of element to one that the label makes sense for.\n c. Make sure you're using the right labels for the right things.",
"passed_title": "Only allowed ARIA attributes are used for each role.",
"dev_description": "This rule verifies that the ARIA attributes applied to an HTML element are compatible with the element's role. ARIA (Accessible Rich Internet Applications) attributes enhance the accessibility of web content, but they must be used correctly. An ARIA attribute should be valid for the role assigned to the element. For example, applying `aria-required` to an element with `role='img'` is incorrect because the `img` role doesn't support `aria-required`. Incorrect use of ARIA attributes can mislead assistive technologies, causing usability issues for users relying on screen readers or other assistive tools.",
"layman_description": "Imagine a website where interactive parts are not properly labeled. This rule ensures that when special labels (ARIA attributes) are added to elements on a webpage to make them more accessible, these labels actually make sense for what the element is supposed to do. For example, you wouldn't put a 'required' label on a picture because pictures don't require any input. If the labels are mismatched, people using screen readers or other assistive technology might get confused, making it hard for them to use the website.",
"how_to_test": null
},
{
"rule_id": "button-name",
"standard_code": "4.1.2",
"Notes": null,
"issue_severity": "critical",
"wcag_version_number": 2,
"wcag_level": "A",
"affected_disabilities_json": "Blind | Low vision | Cognitive | Mobility",
"help": "Buttons must have discernible text",
"title": "<button> elements lack accessible, descriptive names",
"dev_help": "1. Direct Text Content: The simplest solution is to include descriptive text directly within the `<button>` element:\n \n 2. `aria-label`: If the button content is an icon or image, use `aria-label` to provide a text alternative:\n \n 3. `aria-labelledby`: If the button's text is present elsewhere on the page, use `aria-labelledby` to associate it with the button:\n \n 4. Avoid Generic Text: Do not use generic text like 'Click Here' or 'Read More'. Be specific about the button's action or destination.\n 5. Test with Screen Readers: Always test your buttons with a screen reader to ensure that the accessible name is being announced correctly.",
"help_url": "https://dequeuniversity.com/rules/axe/4.10/button-name?application=axeAPI",
"description": "Ensure buttons have discernible text",
"layman_help": "1. Add Clear Labels: Make sure every button has a clear text label that says exactly what it does (e.g., 'Submit', 'Cancel', 'Add to Cart').\n 2. If Using Pictures: If a button uses a picture (icon), add a text description to the button so screen readers can tell people what the button does. You can do this by adding a hidden label to the image, also known as `alt text`.\n 3. Avoid Vague Words: Don't use vague phrases like 'Click Here'. Instead, say exactly what will happen when someone clicks the button.\n 4. Test It Out: Have someone who uses a screen reader try out your website to make sure they can easily understand what each button does.",
"passed_title": "<button> elements have accessible, descriptive names.",
"dev_description": "All buttons must have text content that clearly describes their purpose. This text should be directly visible within the button element or be made accessible through alternative means like `aria-label` or `aria-labelledby` if using an icon or image as the button's content. The text must be meaningful and specific, avoiding generic terms like 'Click Here'. Ensure that the accessible name accurately reflects the button's function when announced by assistive technologies.",
"layman_description": "Imagine using a website where the buttons don't have clear labels. For example, instead of a button saying 'Submit Form', it just has an icon or nothing at all. If you're blind and using a screen reader, or if you have trouble understanding visual cues, you won't know what the button does. This rule ensures that every button has a clear text label, so everyone knows what will happen when they click it. This makes the website easier to use for people with visual impairments or cognitive disabilities.",
"how_to_test": null
},
{
"rule_id": "aria-conditional-attr",
"standard_code": "4.1.2",
"Notes": null,
"issue_severity": "serious",
"wcag_version_number": 2,
"wcag_level": "A",
"affected_disabilities_json": "Blind | Low vision | Mobility | Cognitive",
"help": "ARIA attributes must be used as specified for the element's role",
"title": "Conditional ARIA attributes are used when not applicable",
"dev_help": "1. Identify the element with the ARIA role and attributes in question.\n 2. Consult the ARIA specification for the role being used (e.g., `role='button'`, `role='navigation'`).\n 3. Verify that all ARIA attributes applied to the element are permitted and make sense for that specific role.\n 4. Correct or remove any ARIA attributes that are not allowed or that conflict with the role's specification.\n \n\n Example: If an element has `role='button'`, it should not have attributes that are only applicable to a `role='menuitem'`. Incorrect: `<div role='button' aria-selected='true'>Click me</div>`. Correct: `<button aria-pressed='true'>Click me</button>` or `<div role='button' aria-pressed='true'>Click me</div>`.",
"help_url": "https://dequeuniversity.com/rules/axe/4.10/aria-conditional-attr?application=axeAPI",
"description": "Ensure ARIA attributes are used as described in the specification of the element's role",
"layman_help": "If a website isn't working correctly with your screen reader, it might be because the website is using the wrong labels. The website developer needs to check if the labels (ARIA attributes) they're using are correct for the type of item they're labeling (the ARIA role). They should correct the labels or remove any that are confusing.",
"passed_title": "Conditional ARIA attributes appear only when applicable.",
"dev_description": "ARIA (Accessible Rich Internet Applications) attributes provide semantic meaning to HTML elements, especially when native HTML elements don't offer sufficient semantics or when elements are used in a non-standard way. This rule ensures that ARIA attributes applied to an element are valid and consistent with the element's ARIA role specification. Incorrectly used ARIA attributes can mislead assistive technologies, leading to an inaccurate representation of the page structure and functionality for users.",
"layman_description": "Imagine you're describing a website element to someone who can't see it. ARIA attributes are like labels that tell screen readers what each element does (e.g., 'this is a button', 'this is a menu'). This rule checks if those labels are correct and make sense for the element. If the labels are wrong, it's like mislabeling items in a store, making it very confusing for people who rely on those labels to navigate.",
"how_to_test": null
},
{
"rule_id": "frame-title-unique",
"standard_code": "4.1.2",
"Notes": null,
"issue_severity": "serious",
"wcag_version_number": 2,
"wcag_level": "A",
"affected_disabilities_json": "Blind | Low vision | Cognitive",
"help": "Frames must have a unique title attribute",
"title": "<iframe> or <frame> elements lack unique, descriptive titles",
"dev_help": "1. Add a `title` attribute to each `<iframe>` and `<frame>` element.\n 2. Ensure the `title` attribute's value accurately and concisely describes the content within the frame.\n 3. Make sure the `title` is unique to differentiate between multiple frames on the same page.\n \n\n Example:\n \n \n\n Avoid using generic titles like 'Advertisement' or 'Frame 1'. Provide specific details about the embedded content.",
"help_url": "https://dequeuniversity.com/rules/axe/4.10/frame-title-unique?application=axeAPI",
"description": "Ensure <iframe> and <frame> elements contain a unique title attribute",
"layman_help": "1. For every 'window' (iframe) on the website, add a short description (a 'title') that explains what's inside.\n 2. Make sure the description is accurate and easy to understand, like a label on a box.\n 3. If there are multiple 'windows,' make sure each one has a different and unique description so you can tell them apart easily.\n \n\n For example, instead of just saying 'Advertisement,' say 'Advertisement for eco-friendly cleaning products.'",
"passed_title": "<iframe> and <frame> have unique, descriptive titles.",
"dev_description": "All <iframe> and <frame> elements must have a non-empty `title` attribute that accurately describes the content within the frame. The `title` attribute provides a text alternative for the frame, allowing users of assistive technologies like screen readers to understand the purpose and context of the embedded content. The `title` should be unique within the page to avoid confusion when multiple frames are present. Empty or missing `title` attributes can lead to accessibility issues, especially for users who rely on screen readers to navigate the page.",
"layman_description": "Imagine you're reading a book, and suddenly, parts of other books are inserted without any labels or explanations. That's similar to what happens when websites use 'iframes' (like windows showing other web pages) without clear titles. If you're using a screen reader (software that reads the screen aloud), you'll hear the content of these iframes without knowing what they are or why they're there. A good title on each iframe helps everyone understand what's inside each 'window' and why it's important. This is very important for people using screen readers because otherwise, they won't understand the content in the iframe.",
"how_to_test": null
},
{
"rule_id": "input-button-name",
"standard_code": "4.1.2",
"Notes": null,
"issue_severity": "critical",
"wcag_version_number": 2,
"wcag_level": "A",
"affected_disabilities_json": "Blind | Low vision | Cognitive | Mobility",
"help": "Input buttons must have discernible text",
"title": "Input buttons lack accessible names",
"dev_help": "1. For `<input type=\"button\">`, `<input type=\"submit\">`, and `<input type=\"reset\">` elements, ensure there is a `value` attribute with descriptive text: `<input type=\"submit\" value=\"Submit Form\">`. 2. If using an image within the button (e.g., `<input type=\"image\">`), provide a meaningful `alt` attribute: `<input type=\"image\" src=\"submit.png\" alt=\"Submit Form\">`. 3. If using CSS to display text on the button, ensure the text is present in the HTML and styled with CSS. Do not rely solely on background images to convey the button's purpose. For example: `<button class=\"submit-button\">Submit</button>` with CSS styling the text 'Submit'.",
"help_url": "https://dequeuniversity.com/rules/axe/4.10/input-button-name?application=axeAPI",
"description": "Ensure input buttons have discernible text",
"layman_help": "If a button doesn't have text, add it! If it has an image instead of text, make sure the image has a description (called 'alt text') that says what the button does. If the button uses a picture for the text, make sure the real text is also there for screen readers, even if it's hidden with styling. Always describe what the button does clearly.",
"passed_title": "Input buttons have accessible, descriptive names.",
"dev_description": "Ensure that all `<input type=\"button\">`, `<input type=\"submit\">`, and `<input type=\"reset\">` elements have discernible text labels. This text should clearly indicate the button's purpose. If a button uses an image, provide meaningful alternative text via the `alt` attribute. For buttons relying on CSS background images for text, ensure the text remains visible and understandable even when images are disabled or not loaded. If the text is not visible or the image doesn't convey the button's purpose, assistive technologies cannot properly convey the button's function to users.",
"layman_description": "Imagine trying to use a website where the buttons don't have clear labels. For someone who is blind and uses a screen reader, the screen reader won't be able to tell them what the button does if it has no text or unclear text. Similarly, people with cognitive disabilities might struggle to understand the button's purpose without a clear label. This rule ensures that all buttons have text that clearly describes what they do, making the website usable for everyone.",
"how_to_test": null
},
{
"rule_id": "aria-roledescription",
"standard_code": "4.1.2",
"Notes": null,
"issue_severity": "serious",
"wcag_version_number": 2,
"wcag_level": "A",
"affected_disabilities_json": "Blind | Low vision | Cognitive",
"help": "aria-roledescription must be on elements with a semantic role",
"title": "aria-roledescription is used with invalid roles or has unclear descriptions",
"dev_help": "1. Identify elements with `aria-roledescription`: Review your HTML/JSX code to find instances where `aria-roledescription` is used.\n 2. Verify the element has a role: Ensure that each element with `aria-roledescription` either has a `role` attribute defined or possesses an implicit role based on its HTML element type (e.g., `<button>` has an implicit `role='button'`).\n 3. Add a role if missing: If an element lacks a role but requires `aria-roledescription`, add the appropriate `role` attribute. Choose a role that accurately reflects the element's purpose.\n Example:\n \n 4. Remove `aria-roledescription` if no role is applicable: If an element doesn't logically correspond to any ARIA role, remove the `aria-roledescription` attribute altogether. Avoid using `aria-roledescription` simply for stylistic purposes; instead, rely on accurate semantic markup.\n Example:",
"help_url": "https://dequeuniversity.com/rules/axe/4.10/aria-roledescription?application=axeAPI",
"description": "Ensure aria-roledescription is only used on elements with an implicit or explicit role",
"layman_help": "1. Find all the elements on the website that have a special 'nickname' using `aria-roledescription`.\n 2. Check if these elements actually are what their nicknames suggest. For example, if something has the nickname of 'Custom Button', is it actually a button?\n 3. If the element doesn't have a role, but it should, add one! Make sure the role is right for what the element does.\n 4. If the element doesn't need a role or a special nickname, just remove the `aria-roledescription` altogether. It's better to keep things simple and clear.",
"passed_title": "aria-roledescription uses valid roles with clear descriptions.",
"dev_description": "The `aria-roledescription` attribute is used to provide an alternative, human-readable description for the role of an element. This attribute should only be applied to elements that already have either an implicit (inherent HTML element role) or explicit role (defined using the `role` attribute). Using `aria-roledescription` on elements without a defined role can lead to unexpected behavior for assistive technologies and confuse users. It's crucial to ensure a semantic foundation (either through native HTML or ARIA roles) before enhancing the description with `aria-roledescription`.",
"layman_description": "Imagine you're telling someone what a button does on a website. The `aria-roledescription` is like giving that button a special nickname that assistive technologies like screen readers will announce. But if the element isn't actually a button (doesn't have the role of a button), giving it a button nickname will confuse the user. This rule ensures that you only give elements a 'nickname' if they already have a well-defined role (like a button, link, or heading) so that screen reader users understand the element correctly.",
"how_to_test": null
},
{
"rule_id": "duplicate-id-aria",
"standard_code": "4.1.2",
"Notes": null,
"issue_severity": "critical",
"wcag_version_number": 2,
"wcag_level": "A",
"affected_disabilities_json": "Blind | Low vision | Cognitive | Mobility",
"help": "IDs used in ARIA and labels must be unique",
"title": "IDs referenced by ARIA attributes are not unique within the page",
"dev_help": "1. Inspect the HTML source code to identify elements with duplicate `id` attributes, especially those used with ARIA attributes or label `for` attributes.\n 2. Rename the duplicate `id` attributes to be unique within the document. Ensure that any ARIA attributes or label `for` attributes that reference the old `id` are updated to use the new, unique `id`.\n \n\n Example:\n \n\n Incorrect:\n \n \n\n Correct:",
"help_url": "https://dequeuniversity.com/rules/axe/4.10/duplicate-id-aria?application=axeAPI",
"description": "Ensure every id attribute value used in ARIA and in labels is unique",
"layman_help": "Find the places on the website where the same identifier is used for different things. Change the identifiers so that each thing has its own unique identifier. If something else on the page uses that identifier to refer to the thing, update it to use the new identifier. For example, if two text boxes both have the same identifier, change one of them, and then update any labels that point to that text box to use the new identifier.",
"passed_title": "ARIA attribute IDs are unique within the page.",
"dev_description": "The `id` attribute must be unique within the entire HTML document. When the same `id` is used multiple times, assistive technologies may not be able to correctly identify elements. This can lead to incorrect associations between labels and form controls, and ARIA attributes that rely on `id` references may fail to function as expected. This rule checks for duplicate `id` attributes that are used in ARIA attributes like `aria-labelledby`, `aria-describedby`, `aria-controls`, etc., as well as within `<label>` elements using the `for` attribute. A failure occurs when the same `id` is assigned to multiple elements, particularly when those `id`s are referenced by ARIA attributes or label elements.",
"layman_description": "Imagine you have two houses on the same street with the same number. When someone tries to visit a specific house using that number, they won't know which one is the right one. Similarly, on a website, each element must have a unique identifier (like a house number). If two or more elements have the same identifier, assistive technologies like screen readers get confused and can't correctly identify or interact with the intended element. For example, a label might not be correctly associated with the input field it's supposed to describe, making it difficult for people using screen readers to fill out forms.",
"how_to_test": null
},
{
"rule_id": "aria-valid-attr-value",
"standard_code": "4.1.2",
"Notes": null,
"issue_severity": "critical",
"wcag_version_number": 2,
"wcag_level": "A",
"affected_disabilities_json": "Blind | Low vision | Cognitive | Mobility",
"help": "ARIA attributes must conform to valid values",
"title": "ARIA attributes use invalid values",
"dev_help": "1. Identify elements with ARIA attributes.\n 2. For each ARIA attribute, consult the ARIA specification to determine the valid values for that attribute.\n 3. Verify that the ARIA attribute's value matches one of the valid values defined in the ARIA specification.\n 4. Correct any invalid ARIA attribute values. Example: If `aria-expanded` is set to 'maybe', change it to 'true' or 'false'.\n 5. Test with assistive technologies to confirm that the corrected ARIA attributes are properly interpreted.",
"help_url": "https://dequeuniversity.com/rules/axe/4.10/aria-valid-attr-value?application=axeAPI",
"description": "Ensure all ARIA attributes have valid values",
"layman_help": "If a website is not behaving as expected, it could be because some hidden settings, called ARIA attributes, are set incorrectly. The website developer needs to check each of these settings against a special guide. If a setting is wrong (like having a checkbox set to 'sort of checked'), they need to fix it to be a correct setting (like 'checked' or 'not checked'). After fixing the settings, they should test the website with assistive technologies, like screen readers, to make sure everything now works correctly for everyone.",
"passed_title": "ARIA attributes use valid specification values.",
"dev_description": "All ARIA attributes must have values that conform to the ARIA specification. Invalid ARIA values can prevent assistive technologies from correctly interpreting and conveying the state or properties of user interface elements. This can lead to a degraded or unusable experience for users relying on assistive technologies.",
"layman_description": "Imagine trying to understand a website, but the instructions are garbled or nonsensical. That's what happens when ARIA attributes have invalid values. ARIA helps screen readers and other assistive technologies understand what things on a webpage are and how they behave. If these ARIA attributes have the wrong information, people using assistive technology may not be able to use the website properly. For example, if a button's ARIA state is invalid, a screen reader user might not know that it's a button or whether it's currently active or disabled, making the website unusable.",
"how_to_test": null
},
{
"rule_id": "aria-input-field-name",
"standard_code": "4.1.2",
"Notes": null,
"issue_severity": "serious",
"wcag_version_number": 2,
"wcag_level": "A",
"affected_disabilities_json": "Blind | Low vision | Cognitive | Mobility",
"help": "ARIA input fields must have an accessible name",
"title": "ARIA input fields lack accessible names",
"dev_help": "1. Use the `<label>` element and associate it with the input field using the `for` and `id` attributes:\n \n 2. Use the `aria-label` attribute:\n \n 3. Use the `aria-labelledby` attribute to reference an existing element that contains the accessible name:\n \n 4. Use the `title` attribute (less preferred, but can be used as a fallback):\n \n Ensure that the accessible name accurately describes the purpose of the input field.",
"help_url": "https://dequeuniversity.com/rules/axe/4.10/aria-input-field-name?application=axeAPI",
"description": "Ensure every ARIA input field has an accessible name",
"layman_help": "Make sure every box or interactive element on the website has a clear and descriptive label. If you can't see the screen, imagine someone telling you what each box is for. That's what the label does for people using assistive technology. If a box is for your name, the label should say 'Name'. If it's for your email, the label should say 'Email'. This makes it possible for everyone to understand and use the website effectively.",
"passed_title": "ARIA input fields have accessible, descriptive names.",
"dev_description": "All ARIA input fields must have an accessible name. This name is used by assistive technologies, like screen readers, to identify the input field to the user. An accessible name can be provided using the `aria-label` attribute, the `aria-labelledby` attribute, the `title` attribute, or by associating the input field with a `<label>` element. Without an accessible name, users of assistive technologies will not be able to understand the purpose of the input field, making it unusable.",
"layman_description": "Imagine trying to fill out a form where some of the boxes aren't labeled. You wouldn't know what information to put in them, right? This rule makes sure that all interactive elements on a website, like text fields and dropdown menus, have clear labels that everyone can understand, including people who use screen readers or other assistive technologies. Without a label, these users can't understand the purpose of the input field, which makes filling out forms very difficult or impossible.",
"how_to_test": null
},
{
"rule_id": "aria-tooltip-name",
"standard_code": "4.1.2",
"Notes": null,
"issue_severity": "serious",
"wcag_version_number": 2,
"wcag_level": "A",
"affected_disabilities_json": "Blind | Low vision | Cognitive",
"help": "ARIA tooltip nodes must have an accessible name",
"title": "Elements with role=\"tooltip\" lack descriptive accessible names",
"dev_help": "1. Identify Tooltip Elements: Locate all elements in your HTML that are designated as tooltips, typically using `role=\"tooltip\"`. \n 2. Check for Accessible Name: Verify that each tooltip element has an accessible name. This can be achieved using one of the following methods:\n * `aria-label`: Add an `aria-label` attribute to the tooltip element with a descriptive text value (e.g., `<div role=\"tooltip\" aria-label=\"Explanation of the term\">`).\n * `aria-labelledby`: Use `aria-labelledby` to reference another element on the page whose text content will serve as the tooltip's accessible name (e.g., `<div id=\"tooltip-desc\">Explanation of the term</div><div role=\"tooltip\" aria-labelledby=\"tooltip-desc\">`).\n * Text Content: Ensure the tooltip element contains meaningful text content that accurately describes its purpose. If using text content, ensure the element is not hidden from assistive technologies.\n 3. Example:",
"help_url": "https://dequeuniversity.com/rules/axe/4.10/aria-tooltip-name?application=axeAPI",
"description": "Ensure every ARIA tooltip node has an accessible name",
"layman_help": "1. Find all the little help bubbles on the website.\n 2. Make sure each bubble has a clear label or name that a screen reader can read. This name tells people who can't see the screen what the help bubble is about. You can add a small text explaining what the tooltip is for.",
"passed_title": "Role=\"tooltip\" elements have descriptive accessible names.",
"dev_description": "This rule checks that all ARIA tooltip elements have an accessible name. An accessible name is crucial for assistive technologies like screen readers to convey the purpose and content of the tooltip to users. Tooltips without accessible names are effectively invisible to screen reader users, rendering the information inaccessible. The accessible name can be provided using attributes like `aria-label`, `aria-labelledby`, or through the element's text content if it's appropriately structured.",
"layman_description": "Imagine tooltips as little help bubbles that pop up when you hover over something on a website. This rule makes sure those help bubbles have a name that screen readers can read out loud. If a tooltip doesn't have a name that a screen reader can understand, people who can't see the screen won't know what the tooltip is trying to tell them, making it harder for them to use the website.",
"how_to_test": null
},
{
"rule_id": "label",
"standard_code": "4.1.2",
"Notes": null,
"issue_severity": "critical",
"wcag_version_number": 2,
"wcag_level": "A",
"affected_disabilities_json": "Blind | Low vision | Cognitive | Mobility",
"help": "Form elements must have labels",
"title": "Form inputs lack associated visible or programmatic labels",
"dev_help": "1. Explicitly associate labels with form elements using the 'for' and 'id' attributes:\n \n 2. Implicitly associate labels by wrapping the form element inside the <label> tag:\n \n 3. If a visible label is not desired, use 'aria-label', 'aria-labelledby', or 'title' attributes to provide a text alternative. Ensure 'aria-label' is used with caution and only when a visible label is truly not appropriate, as it hides information from sighted users.\n \n 4. For complex form elements, such as a set of radio buttons or checkboxes, use <fieldset> and <legend> elements to provide a group label:",
"help_url": "https://dequeuniversity.com/rules/axe/4.10/label?application=axeAPI",
"description": "Ensure every form element has a label",
"layman_help": "1. Make sure every box, button, and selection on the form has a clear instruction (label) next to it. The label tells you what information to put in that box.\n 2. Connect the instruction directly to the box by using special code (the 'for' and 'id' attributes). This ensures that the screen reader can correctly identify the box and its purpose.\n 3. If you don't want the instruction to be visible on the screen, you can still provide it using hidden code that screen readers can read (using 'aria-label', 'aria-labelledby', or 'title'). But, be careful: Don't hide the instruction if everyone needs to see it.\n 4. For a group of similar options (like radio buttons or checkboxes), put them inside a box with a title (using <fieldset> and <legend>). This helps everyone understand what the group of options is about.",
"passed_title": "Form inputs have visible or programmatic labels.",
"dev_description": "All form elements (e.g., <input>, <textarea>, <select>) must have associated labels. Labels provide a textual description of the purpose of the form element, which is essential for users to understand the expected input. Labels can be associated explicitly using the 'for' attribute that refers to the 'id' of the form element, or implicitly by wrapping the form element within the label tag. Absence of a label or an improperly associated label makes the form unusable for assistive technology users and difficult to understand for some users with cognitive impairments.",
"layman_description": "Imagine filling out a form where some boxes don't have clear instructions. You wouldn't know what information to put in them, right? People with disabilities, especially those who are blind or have low vision, rely on screen readers to tell them what each box is for. If a form element is missing a label, the screen reader can't announce what information is needed, making the form unusable. This is also difficult for users with cognitive issues, because they will not understand what the form element is for.",
"how_to_test": null
},
{
"rule_id": "aria-prohibited-attr",
"standard_code": "4.1.2",
"Notes": null,
"issue_severity": "serious",
"wcag_version_number": 2,
"wcag_level": "A",
"affected_disabilities_json": "Blind | Low vision | Cognitive | Mobility",
"help": "Elements must only use permitted ARIA attributes",
"title": "Prohibited ARIA attributes are used on certain roles",
"dev_help": "1. Identify the element and role that is triggering the error. \n 2. Consult the ARIA specification (WAI-ARIA) to determine if the ARIA attribute is permitted for the element's role. WAI-ARIA documentation provides detailed information on allowed ARIA attributes for each role. \n 3. If the ARIA attribute is not permitted, remove it or choose a different attribute that is valid for the given role. If no appropriate ARIA attribute exists, consider using a different HTML element or ARIA role that allows the attribute to be used correctly. \n 4. Test the changes with assistive technologies (e.g., screen readers) to ensure that the element is now properly announced and functions as expected. \n Example: If a `<div>` element with `role='button'` has `aria-required='true'`, this is incorrect as `aria-required` is not a valid attribute for a button. Remove `aria-required` or use an appropriate HTML element like `<button>` that inherently supports the concept of being required.",
"help_url": "https://dequeuniversity.com/rules/axe/4.10/aria-prohibited-attr?application=axeAPI",
"description": "Ensure ARIA attributes are not prohibited for an element's role",
"layman_help": "If something is not working well on the page, ask for help from a developer. They can check the special instructions for the website (ARIA attributes) to make sure they are correct. If an instruction is not right, they can either remove it or replace it with a better one. After making changes, they should test the page with tools that help people with disabilities to make sure everything works as expected.",
"passed_title": "Prohibited ARIA attributes are not used on roles.",
"dev_description": "This rule verifies that ARIA (Accessible Rich Internet Applications) attributes used on HTML elements are valid and permitted for the element's role. ARIA attributes are designed to enhance the accessibility of web content by providing semantic information to assistive technologies, such as screen readers. However, using ARIA attributes incorrectly, such as applying a prohibited attribute to a specific role, can disrupt the intended accessibility and create a confusing or misleading experience for users who rely on assistive technologies. This rule ensures that developers are using ARIA attributes according to their specifications and in a way that complements the element's inherent role.",
"layman_description": "Imagine you're using a special app that reads websites to you. This app relies on hidden labels and instructions (called ARIA attributes) to understand what's on the page. This rule makes sure that these hidden instructions aren't wrong or confusing. If the instructions are wrong, the app might tell you the wrong thing, making it hard or impossible for someone who can't see the screen well to use the website.",
"how_to_test": null
},
{
"rule_id": "nonaxe-status-messages",
"standard_code": "4.1.3",
"Notes": null,
"issue_severity": "moderate",
"wcag_version_number": 2.1,
"wcag_level": "AA",
"affected_disabilities_json": "Blind | Low vision | Cognitive",
"help": "Let assistive technology notify users about status changes that don't take focus.",
"title": "Status messages are not conveyed clearly to assistive technologies",
"dev_help": "1. Identify elements that display status messages.\n 2. Determine the appropriate ARIA live region value: `aria-live='polite'` for non-urgent updates, `aria-live='assertive'` for urgent updates.\n 3. Add the `aria-live` attribute to the parent container of the status message.\n 4. Ensure the status message text content is dynamically updated using JavaScript.\n Example:",
"help_url": "https://www.w3.org/WAI/WCAG22/Understanding/status-messages.html",
"description": "Make users aware of important changes in content.",
"layman_help": "When a website gives you a message (like 'Saved!' or 'Error!'), it needs to make sure everyone knows about it. If you can't see the screen, the website needs to 'announce' those messages to you. The website developers need to use special codes that tell screen readers to announce these messages when they appear. This way, everyone gets the information they need.",
"passed_title": "Status messages are clear to assistive technologies.",
"dev_description": "Ensure that status messages, which provide important information to the user without changing the context of the page, are programmatically exposed in a way that assistive technologies can perceive them. Use ARIA live regions (e.g., aria-live='polite' or aria-live='assertive') to announce status updates dynamically without requiring the user to navigate to the updated content.",
"layman_description": "Imagine you're filling out a form online. Sometimes, the website will tell you if something went right or wrong, like \"Your password has been updated!\" or \"That username is already taken.\" This rule is about making sure those messages are announced to people who can't see the screen, such as blind people using screen readers. If the messages aren't announced, they won't know what's happening and might get stuck or confused.",
"how_to_test": "1. Identify Actions Triggering Status Messages: Find actions on the site that display brief feedback messages without interrupting you. Examples:\n - Adding an item to a cart/wishlist.\n - Submitting a simple form (like newsletter signup) that updates on the same page.\n - Applying filters that dynamically update results.\n - Saving settings.\n - Actions that might show brief success, progress, or error notifications.\n 2. Use a Screen Reader (Recommended):\n - Turn on a screen reader (like NVDA, JAWS, VoiceOver).\n - Perform the action identified in Step 1. Keep your keyboard focus on the control you activated (e.g., the \"Add to Cart\" button).\n - Listen: Does the screen reader automatically announce the status message (e.g., \"Item added to cart\") shortly after you perform the action, even though your focus didn't move to the message itself?\n 3. Inspect the Code (Alternative/Confirmation):\n - Perform the action to make the status message appear visually.\n - Use browser developer tools (\"Inspect Element\") to examine the HTML element containing the status message text.\n - Check: Does the message container (or a parent) have an appropriate ARIA live region attribute? Look for:\n => role=\"status\" (for general updates, implicitly aria-live=\"polite\")\n => role=\"alert\" (for important errors/warnings, implicitly aria-live=\"assertive\")\n => aria-live=\"polite\" (announces when user is idle)\n => aria-live=\"assertive\" (interrupts to announce immediately)\n => Other roles like log or progressbar might also imply live regions.\n 4. Evaluate:\n - Pass: Status messages that appear visually are also automatically announced by screen readers (or have the appropriate ARIA live region attributes in the code).\n - Fail: Status messages appear visually but are not announced by screen readers because they lack the necessary ARIA live region markup (role=\"status\", role=\"alert\", aria-live, etc.)."
},
{
"rule_id": null,
"standard_code": null,
"Notes": null,
"issue_severity": null,
"wcag_version_number": null,
"wcag_level": null,
"affected_disabilities_json": null,
"help": null,
"title": "Braille label equivalents are not provided where required for assistive technologies\n\nText and images of text do not meet minimum contrast ratios",
"dev_help": null,
"help_url": null,
"description": null,
"layman_help": null,
"passed_title": null,
"dev_description": null,
"layman_description": null,
"how_to_test": null
},
{
"rule_id": 60,
"standard_code": null,
"Notes": null,
"issue_severity": "2.0 auto",
"wcag_version_number": 67,
"wcag_level": null,
"affected_disabilities_json": null,
"help": null,
"title": null,
"dev_help": null,
"help_url": null,
"description": null,
"layman_help": null,
"passed_title": null,
"dev_description": null,
"layman_description": null,
"how_to_test": null
},
{
"rule_id": null,
"standard_code": null,
"Notes": null,
"issue_severity": "2.0 manual",
"wcag_version_number": 39,
"wcag_level": null,
"affected_disabilities_json": null,
"help": null,
"title": null,
"dev_help": null,
"help_url": null,
"description": null,
"layman_help": null,
"passed_title": null,
"dev_description": null,
"layman_description": null,
"how_to_test": null
},
{
"rule_id": null,
"standard_code": null,
"Notes": null,
"issue_severity": "2.1 auto",
"wcag_version_number": 4,
"wcag_level": null,
"affected_disabilities_json": null,
"help": null,
"title": null,
"dev_help": null,
"help_url": null,
"description": null,
"layman_help": null,
"passed_title": null,
"dev_description": null,
"layman_description": null,
"how_to_test": null
},
{
"rule_id": null,
"standard_code": null,
"Notes": null,
"issue_severity": "2.1 manual",
"wcag_version_number": 13,
"wcag_level": null,
"affected_disabilities_json": null,
"help": null,
"title": null,
"dev_help": null,
"help_url": null,
"description": null,
"layman_help": null,
"passed_title": null,
"dev_description": null,
"layman_description": null,
"how_to_test": null
},
{
"rule_id": null,
"standard_code": null,
"Notes": null,
"issue_severity": "2.2 auto",
"wcag_version_number": 1,
"wcag_level": null,
"affected_disabilities_json": null,
"help": null,
"title": null,
"dev_help": null,
"help_url": null,
"description": null,
"layman_help": null,
"passed_title": null,
"dev_description": null,
"layman_description": null,
"how_to_test": null
},
{
"rule_id": null,
"standard_code": null,
"Notes": null,
"issue_severity": "2.2 manual",
"wcag_version_number": 8,
"wcag_level": null,
"affected_disabilities_json": null,
"help": null,
"title": null,
"dev_help": null,
"help_url": null,
"description": null,
"layman_help": null,
"passed_title": null,
"dev_description": null,
"layman_description": null,
"how_to_test": null
},
{
"rule_id": "aria-allowed-role",
"standard_code": "best-practice",
"Notes": null,
"issue_severity": "low",
"wcag_version_number": null,
"wcag_level": null,
"affected_disabilities_json": "Blind | Deaf Blind | Mobility",
"help": "ARIA role should be appropriate for the element",
"title": "ARIA role should be appropriate for the element",
"dev_help": "- Check every element that has a `role=\"…\"` attribute and confirm the role is allowed for that element and context in the HTML in ARIA specification.\n- If the element already has correct native semantics, remove the unnecessary `role`.\n- If you need the ARIA semantics, use an allowed role for that tag, or change to an appropriate tag.\n- Use valid patterns like:\n - `<ul role=\"menu\">` with list items set to presentational and interactive controls inside, e.g.:\n - `<li role=\"none\"><button role=\"menuitem\">Start</button></li>`\n- Fix invalid patterns such as:\n - `<ul role=\"button\">Name</ul>` → don’t assign `button` to a `ul`; use a real `<button>` or restructure.\n - `<button role=\"heading\" aria-level=\"2\">Welcome</button>` → don’t assign `heading` to a `button`; use a real heading element (e.g., `h2`) or keep it as a button without `role=\"heading\"` (depending on intent).",
"help_url": "https://dequeuniversity.com/rules/axe/4.11/aria-allowed-role?application=axeAPI",
"description": "Ensure role attribute has an appropriate value for the element",
"layman_help": "- Find the parts of the page that are being “labeled” for assistive technology (these labels are called roles).\n- Make sure each label matches what that item really is supposed to be.\n - A list shouldn’t pretend to be a button.\n - A button shouldn’t pretend to be a heading.\n- If something needs to act like a menu, structure it like a real menu: a menu container with items inside it (for example, menu items that are actual clickable controls).\n- If something is meant to be a heading, use a real heading for the title and a separate button only when you need something clickable.\n- When in doubt, remove the extra label if the element already communicates the right meaning on its own.",
"passed_title": null,
"dev_description": "Elements with a `role` attribute must only use ARIA role values that are permitted for that specific HTML element (and its context) per the HTML in ARIA specification. Update invalid `role` assignments by either:\n\n- removing the `role` attribute when native semantics already apply, or\n- changing `role=\"…\"` to a role that is allowed for that element, or\n- changing the underlying HTML element to one that is allowed to have that role.\n\nCommon failures include assigning interactive roles to non-interactive elements (e.g., `ul role=\"button\"`) or assigning structural roles to interactive elements (e.g., `button role=\"heading\"`).",
"layman_description": "Some parts of a webpage are labeled behind the scenes so assistive technologies (like screen readers) know what each part is (for example, “menu,” “button,” or “heading”). This issue happens when an element is given a label that doesn’t match what that element is allowed to be. When the label doesn’t fit, assistive technology can announce the wrong thing or behave unexpectedly.",
"how_to_test": null
},
{
"rule_id": "frame-tested",
"standard_code": "best-practice",
"Notes": null,
"issue_severity": "critical",
"wcag_version_number": null,
"wcag_level": null,
"affected_disabilities_json": "Blind | Deaf Blind",
"help": "Frames should be tested with axe-core",
"title": "Frames should be tested with axe-core",
"dev_help": "- For every `<iframe>` and `<frame>`, ensure the framed document includes the axe-core script so axe can run inside that context.\n- Verify framed content is actually tested (not just the top-level page); otherwise results will not include nodes inside frames.\n- If using an optional `after` function, use it as the page-level hook to process results gathered from iframe elements.\n- If enabling the page-level behavior (page-level “Ensures iframe and frame elements contain the axe-core script”), note it only applies when the entire page is tested and combines results from nodes in different frames into a single result.\n- Confirm any result aggregation logic correctly merges findings across frames when running full-page tests.",
"help_url": "https://dequeuniversity.com/rules/axe/4.11/frame-tested?application=axeAPI",
"description": "Ensure <iframe> and <frame> elements contain the axe-core script",
"layman_help": "- Identify any embedded sections on the page (often parts of the page that show another page inside a box).\n- Make sure the accessibility checker is being run inside each of those embedded sections, not only on the main page.\n- If your team uses a process that gathers results from multiple embedded sections and combines them, ensure it’s turned on when testing the whole page so issues found inside embedded sections are included in the final report.\n- Re-run the accessibility test and confirm the report includes findings from the embedded sections as well as the main page.",
"passed_title": null,
"dev_description": "When testing a page that contains embedded documents, ensure every `<iframe>` and legacy `<frame>` loads axe-core so accessibility checks run inside those frames too.\n\n- Affected elements: `<iframe>`, `<frame>`.\n- Required change: the document loaded inside each frame must include the axe-core script (the same script used on the top-level page), otherwise violations inside the framed content will not be detected.\n- If your setup uses an `after` callback for page-level checks, it should be used to process and combine results returned from the frame documents.\n- If your configuration enables the page-level version of this rule (e.g., `pageLevel: true`), it applies only when testing the entire page and will combine results from nodes across multiple frames into a single result.",
"layman_description": "If a page shows content inside embedded boxes (frames), those embedded sections also need to be checked for accessibility.\n\nThis rule means: the accessibility checker must also run inside each embedded area. If it doesn’t, problems inside those embedded sections can be missed, even if the main page is tested.",
"how_to_test": null
},
{
"rule_id": "landmark-no-duplicate-main",
"standard_code": "best-practice",
"Notes": null,
"issue_severity": "medium",
"wcag_version_number": null,
"wcag_level": null,
"affected_disabilities_json": "Blind | Deaf Blind | Mobility",
"help": "Document should not have more than one main landmark",
"title": "Document should not have more than one main landmark",
"dev_help": "- Use a single main landmark for the primary content:\n - Prefer `<main>` for the primary content section.\n - Or use `role=\"main\"` (but do not create multiple elements with `role=\"main\"`).\n- If both HTML5 and ARIA are used, keep landmarks consistent and unique (e.g., `<main role=\"main\">…</main>` as the single main region).\n- Ensure other content is in appropriate landmark regions where applicable (best practice):\n - `<header role=\"banner\">…</header>`\n - `<nav role=\"navigation\">…</nav>`\n - `<main role=\"main\">…</main>` (only once)\n - `<footer role=\"contentinfo\">…</footer>`\n- For pages with iframes: check the content inside each `<iframe>` and ensure each iframe document contains 0 or 1 main landmark.\n- Example landmark structure:",
"help_url": "https://dequeuniversity.com/rules/axe/4.11/landmark-no-duplicate-main?application=axeAPI",
"description": "Ensure the document has at most one main landmark",
"layman_help": "- Identify the one section that truly contains the page’s primary content (the main article, main form, main information).\n- Make sure only that one section is labeled as the main content.\n- If the page has embedded content (like an embedded page inside the page), make sure each embedded page also has at most one section labeled as main content.\n- It can help to organize the page into clear regions such as:\n - a top area for the site name/logo\n - a navigation area for menus\n - one main content area\n - a bottom area for footer information\n\nThis makes it easier for screen reader users to quickly jump to the main part of the page without getting confused by multiple “main” areas.",
"passed_title": null,
"dev_description": "The page must contain no more than one `main` landmark.\n\n- Ensure there is only a single primary content container using either the HTML5 element `<main>` or an element with `role=\"main\"`.\n- If you have iframes, each `<iframe>` document must also contain zero or one `main` landmark (not multiple).\n- Fix by removing extra `<main>` elements, removing extra `role=\"main\"` attributes, or restructuring so only the primary content area is marked as the main landmark.",
"layman_description": "This page has more than one area marked as the main content.\n\nScreen reader users rely on these page “signposts” to jump straight to the primary content. If more than one section is labeled as the main content, it becomes confusing because there should only be one clear starting point for the page’s primary information.",
"how_to_test": null
},
{
"rule_id": "landmark-one-main",
"standard_code": "best-practice",
"Notes": null,
"issue_severity": "medium",
"wcag_version_number": null,
"wcag_level": null,
"affected_disabilities_json": "Blind | Deaf Blind | Mobility",
"help": "Document should have one main landmark",
"title": "Document should have one main landmark",
"dev_help": "- Add a single main landmark around the primary content using `<main>` and/or `role=\"main\"`.\n- Ensure there is only one main landmark in the document:\n - Fix duplicates by merging content into one `<main>`/`role=\"main\"`, or removing extra `role=\"main\"` assignments.\n- For each `<iframe>`:\n - Verify the iframe’s document contains no main landmark or exactly one main landmark.\n- Keep content within landmark regions (HTML5 landmarks and/or ARIA landmark roles) so screen reader users can navigate by region.\n- Example landmark structure (redundant but robust during transition):",
"help_url": "https://dequeuniversity.com/rules/axe/4.11/landmark-one-main?application=axeAPI",
"description": "Ensure the document has a main landmark",
"layman_help": "- Find the part of the page that contains the main information people came for (for example: the article, product details, or the central form).\n- Make sure the page has one—and only one—clearly marked main section for that content.\n- If the page has more than one main section, decide which one is truly the main content and combine or re-label the others so there’s only one.\n- If the page includes embedded sections (like content inside an embedded window/frame), check each embedded page too: it should have either no main section or just one.\n- This helps screen reader users quickly jump past repeated parts like headers and menus to reach the primary content.",
"passed_title": null,
"dev_description": "The page must expose exactly one primary content landmark.\n\n- Ensure there is one `<main>` element for the page’s primary content, and/or one element with `role=\"main\"`.\n- Do not have multiple main landmarks (e.g., multiple `<main>` elements, or multiple elements with `role=\"main\"`).\n- If the page includes `<iframe>` elements, each iframe document must contain either no main landmark or exactly one main landmark.\n- Place the primary content inside the main landmark so assistive technologies have a single, reliable navigation point to the main content.",
"layman_description": "The page should have one clear “main content” area.\n\nScreen reader users often jump straight to the main part of a page (the real content, not the menus and headers). If a page has no main area or more than one, it can be confusing because there isn’t a single, dependable place to jump to. If the page includes embedded content (like an embedded page), that embedded page should also have zero or one main area.",
"how_to_test": null
},
{
"rule_id": "scope-attr-valid",
"standard_code": "best-practice",
"Notes": null,
"issue_severity": "medium",
"wcag_version_number": null,
"wcag_level": null,
"affected_disabilities_json": "Blind | Deaf Blind | Mobility",
"help": "scope attribute should be used correctly",
"title": "scope attribute should be used correctly",
"dev_help": "- Verify `scope` is present and valid for table header cells.\n- Restrict `scope` usage by doctype:\n - HTML5: use `scope` only on `<th>`.\n - HTML 4: use `scope` only on `<th>` and `<td>`.\n- Ensure `scope` values are only:\n - `scope=\"col\"` for column headers\n - `scope=\"row\"` for row headers\n- Remove/replace any other `scope` values (anything besides `row`/`col`).\n- Add `scope` to all `<th>` elements that do not have one.\n- Example pattern:\n - Column headers: `<th scope=\"col\">Name</th>`, `<th scope=\"col\">1 mile</th>`\n - Row headers: `<th scope=\"row\">Mary</th>`, `<th scope=\"row\">Betsy</th>`",
"help_url": "https://dequeuniversity.com/rules/axe/4.11/scope-attr-valid?application=axeAPI",
"description": "Ensure the scope attribute is used correctly on tables",
"layman_help": "- Look at each table and find the cells that act like labels (the headings at the top of columns and sometimes the first cell in each row).\n- Make sure each of those label cells is identified as one of these two types:\n - A label for a column (it applies to everything underneath it).\n - A label for a row (it applies to everything to the right of it).\n- Ensure the label type is only one of those two options (not something else).\n- If any heading cell is missing this label type, add it so assistive technologies can announce the correct heading when reading each data value.\n\nIn the example table, the top headings (like “Name” and “1 mile”) are marked as column labels, and the names down the side (like “Mary” and “Betsy”) are marked as row labels so each time can be read with the right context.",
"passed_title": null,
"dev_description": "Ensure HTML table `scope` is used correctly to define header relationships in non-complex data tables.\n\n- Only apply `scope` to header cells:\n - HTML5: `scope` must be on `<th>` elements only.\n - HTML 4: `scope` may be on `<th>` and `<td>` only.\n- `scope` values must be only `row` or `col`.\n- Add missing `scope` values to any `<th>` that lacks it.\n\nUpdate markup so column headers use `<th scope=\"col\">` and row headers use `<th scope=\"row\">`.",
"layman_description": "This check makes sure tables clearly tell assistive technologies (like screen readers) which header labels apply to which row or column.\n\nIf a table’s header labels aren’t marked correctly, someone using a screen reader may hear data without the right label (for example, a time or number without being told which column it belongs to). The fix is to ensure each header cell is marked as a header for either a column or a row, and not anything else.",
"how_to_test": null
},
{
"rule_id": "skip-link",
"standard_code": "best-practice",
"Notes": null,
"issue_severity": "medium",
"wcag_version_number": null,
"wcag_level": null,
"affected_disabilities_json": "Blind | Deaf Blind | Mobility",
"help": "The skip-link target should exist and be focusable",
"title": "The skip-link target should exist and be focusable",
"dev_help": "- Place the skip link at the top of the page, right after the opening `<body>` tag.\n- Ensure each skip link’s `href` points to a same-page fragment that exists, e.g. `href=\"#content\"` requires an element with `id=\"content\"`.\n- Ensure the target is focusable so keyboard focus can move there (use a naturally focusable element or make the target able to receive focus when necessary).\n- Example markup (from provided guidance):\n - `<div id=\"skip\"><a href=\"...#content\">Skip Content</a></div>`\n- Do not hide the skip link using:\n - `display: none;`\n - `visibility: invisible` / `visibility: hidden;`\n- Preferred approaches:\n - Keep the skip link permanently visible, or\n - Hide it off-screen until it receives keyboard focus.\n- Example CSS pattern (from provided guidance):\n - `#skip a { display: block; position: absolute; left: -999px; top: -999px; }`\n - `#skip a:focus { left: 0; top: 0; padding: 3px; background: #ffc; border: 1px solid #990000; }`\n- Note: WebKit browsers (Safari/Chrome) may have issues with same-page links; consider a JavaScript workaround as needed.\n- Consider additional skip links to bypass other repetitive sections when helpful.",
"help_url": "https://dequeuniversity.com/rules/axe/4.11/skip-link?application=axeAPI",
"description": "Ensure all skip links have a focusable target",
"layman_help": "- Put a “Skip to content” link right at the start of the page so keyboard users can reach it immediately.\n- Make sure the link’s destination is real: when someone activates the skip link, it should jump to the main content section (not to nowhere).\n- Make sure the jump actually places the keyboard highlight at the main content area so the person can continue tabbing from there.\n- Don’t completely hide the skip link. If you don’t want it visible all the time, it can be hidden off-screen and then shown when someone tabs to it (so keyboard users can see and use it).\n- If you test it: reload the page, press the Tab key once or twice until you reach “Skip to content,” activate it, and confirm you land at the main content and can continue from there.\n- In some cases, adding more than one skip link (for example, to skip repeated banners or sidebars) can be helpful.",
"passed_title": null,
"dev_description": "Skip links (`<a href=\"#...\">`) must point to an element that exists and can receive keyboard focus. Verify each skip link’s `href` fragment (e.g., `#content`) matches a real target element `id`, and ensure the target is focusable (naturally focusable or made focusable when needed).\n\nCommon implementation:\n- A skip link near the top of the page (immediately after `<body>`).\n- A matching target element such as `<main id=\"content\">…</main>`.\n- If the target isn’t normally focusable, ensure it can receive focus so keyboard users land there reliably.\n\nAvoid hiding the skip link with `display: none` or `visibility: hidden`; instead keep it visible or reveal it on keyboard focus using off-screen positioning.",
"layman_description": "A “skip link” is a link at the top of a page that lets people who use a keyboard jump past repeated navigation (like menus) straight to the main content.\n\nThis issue happens when that link doesn’t actually go anywhere usable—either the destination isn’t on the page, or the destination can’t be reached properly when someone tabs with a keyboard. As a result, people may be forced to tab through the same menu items on every page.\n\nThe skip link should be available and work for both screen reader users and sighted keyboard users.",
"how_to_test": null
},
{
"rule_id": "label-title-only",
"standard_code": "best-practice",
"Notes": null,
"issue_severity": "high",
"wcag_version_number": null,
"wcag_level": null,
"affected_disabilities_json": "Blind | Deaf Blind | Mobility",
"help": "Form elements should have a visible label",
"title": "Form elements should have a visible label",
"dev_help": "- Prefer a standard HTML `<label>` for each form control; it is the most widely supported method.\n- Use an explicit label by matching `label[for]` to the control `id`:\n - Example:\n - `<label for=\"fname\">First Name:</label> <input type=\"text\" id=\"fname\" name=\"fname\">`\n- If needed, use an implicit label by wrapping the control inside `<label>` (note: support can be inconsistent across assistive tech for some controls like selects):\n - Example:\n - `<label>First Name: <input type=\"text\" name=\"fname\"></label>`\n- Only when a visible `<label>` is not feasible, use ARIA labeling:\n - `aria-label` (invisible label; avoid unless necessary):\n - `<input type=\"text\" aria-label=\"Search\">`\n - `aria-labelledby` pointing to existing visible text (useful for complex labeling):\n - `<p id=\"search\">Search</p><input type=\"text\" aria-labelledby=\"search\">`\n- Do not treat `title` or `aria-describedby` as the primary label; they are not sufficient substitutes for a visible label.\n- Verify each control has exactly the intended label association (especially when multiple fields are close together).",
"help_url": "https://dequeuniversity.com/rules/axe/4.11/label-title-only?application=axeAPI",
"description": "Ensure that every form element has a visible label and is not solely labeled using hidden labels, or the title or aria-describedby attributes",
"layman_help": "- Look at every field where a person can type, choose, or check something (like text boxes, dropdowns, and checkboxes).\n- Make sure each one has a clear label you can see on the page, such as “Email address” or “Search,” placed right next to the field.\n- Don’t rely on:\n - text that only appears when you hover over the field (a tooltip)\n - instructions that appear somewhere else and aren’t clearly the field’s name\n - hidden text that sighted users can’t see\n- If space is tight (for example, a small search box), the label can still be visible as nearby text that clearly names the field.\n- After changes, check that a new visitor can understand what each field is for without clicking into it or hovering over it.",
"passed_title": null,
"dev_description": "Each form control must have a visible, on-page label. Do not rely on labeling that is only available to assistive tech or only appears on hover, such as:\n\n- hidden labels\n- `title`\n- `aria-describedby`\n\nFix by providing an actual label via one of the supported labeling methods:\n\n- Explicit `<label for>` + matching control `id` (preferred)\n- Implicit `<label>` wrapping the control\n- `aria-label` or `aria-labelledby` (only when a visible `<label>` cannot be used)\n\nEnsure the label text identifies the purpose of the control and is associated with the correct element.",
"layman_description": "Some form fields don’t have a clear, visible name next to them. Instead, they may only have a tooltip (text that appears when you hover) or hidden text that sighted users can’t see.\n\nThis makes forms harder to use because people may not know what information to enter, and they can’t easily review the form later to confirm which field is which.\n\nEach field needs a visible label (like “First name” or “Search”) shown on the page near the field.",
"how_to_test": null
},
{
"rule_id": "accesskeys",
"standard_code": "best-practice",
"Notes": null,
"issue_severity": "high",
"wcag_version_number": null,
"wcag_level": null,
"affected_disabilities_json": "Blind | Low vision | Mobility",
"help": "accesskey attribute value should be unique",
"title": "accesskey attribute value should be unique",
"dev_help": "- Find every element with an `accesskey` attribute (for example: `<a accesskey=\"g\">`).\n- Check for duplicates: the same `accesskey` character/value must not appear on more than one element in the page.\n- Fix by changing one of the duplicates to a different, unused value.\n- Example problem:\n - `<a href=\"google.com\" accesskey=\"g\">Link to Google</a>`\n - `<a href=\"github.com\" accesskey=\"g\">Link to GitHub</a>`\n- Example fix (make values unique):\n - `<a href=\"google.com\" accesskey=\"g\">Link to Google</a>`\n - `<a href=\"github.com\" accesskey=\"h\">Link to GitHub</a>`\n- Consider removing `accesskey` instead of adding more, because support and behavior vary by browser, shortcuts may not be obvious to users, developer-defined keys can conflict with browser defaults, and chosen letters may not work well across languages.",
"help_url": "https://dequeuniversity.com/rules/axe/4.11/accesskeys?application=axeAPI",
"description": "Ensure every accesskey attribute value is unique",
"layman_help": "- Look for places where the page offers keyboard shortcuts (for example, a shortcut key that jumps to a link or button).\n- Make sure each shortcut is used only once on the page.\n- If two different items use the same shortcut, change one of them so it uses a different unused shortcut, or remove the shortcut.\n- Keep in mind that these shortcuts may not work the same in every browser, may be hard for people to discover, can clash with built-in browser shortcuts, and can be harder to use on pages shown in multiple languages.",
"passed_title": null,
"dev_description": "Elements using the HTML `accesskey` attribute must not share the same value anywhere in the document. If multiple elements (for example, multiple `<a>` links) have duplicate `accesskey` values, keyboard shortcuts become ambiguous or conflicting. Update the markup so each `accesskey=\"...\"` value is unique, or remove `accesskey` where it is not needed.",
"layman_description": "Keyboard shortcuts on a page must not be assigned to more than one thing. If two different items share the same shortcut, the browser may not know which one to activate, and people relying on keyboard navigation can get confused or blocked.",
"how_to_test": null
},
{
"rule_id": "aria-dialog-name",
"standard_code": "best-practice",
"Notes": null,
"issue_severity": "high",
"wcag_version_number": null,
"wcag_level": null,
"affected_disabilities_json": "Blind | Low vision | Mobility",
"help": "ARIA dialog and alertdialog nodes should have an accessible name",
"title": "ARIA dialog and alertdialog nodes should have an accessible name",
"dev_help": "- For every element with `role=\"dialog\"` or `role=\"alertdialog\"`, ensure it has an accessible name.\n- Pass patterns from the rule help:\n - Use `aria-labelledby` to point to visible label text:\n - `<div role=\"dialog\" id=\"alb\" aria-labelledby=\"labeldiv\"></div>`\n - Use a non-empty `aria-label`:\n - `<div role=\"alertdialog\" id=\"combo\" aria-label=\"Aria Name\">Name</div>`\n - Use a non-empty `title` attribute (per provided example):\n - `<div role=\"dialog\" id=\"title\" title=\"Title\"></div>`\n- Avoid failing patterns:\n - Missing name entirely: `<div role=\"dialog\" id=\"empty\"></div>`\n - Empty `aria-label`: `<div role=\"alertdialog\" id=\"alempty\" aria-label=\"\"></div>`\n - `aria-labelledby` references a non-existent ID: `<div role=\"dialog\" id=\"albmissing\" aria-labelledby=\"nonexistent\"></div>`\n - `aria-labelledby` references an element with no text: `<div role=\"dialog\" id=\"albempty\" aria-labelledby=\"emptydiv\"></div>` with `<div id=\"emptydiv\"></div>`\n- If using `aria-labelledby`, confirm the referenced element exists and contains discernible text for screen reader users.",
"help_url": "https://dequeuniversity.com/rules/axe/4.11/aria-dialog-name?application=axeAPI",
"description": "Ensure every ARIA dialog and alertdialog node has an accessible name",
"layman_help": "- Give every pop-up dialog a clear title that assistive technology can read aloud.\n- Make sure the dialog’s name is not blank.\n- Ensure the name comes from one of these sources:\n - A short text label attached directly to the dialog (a hidden “name” meant for screen readers).\n - A reference to an on-screen title (for example, a heading at the top of the dialog) so the dialog uses that text as its name.\n - A built-in title value (as shown in the provided example).\n- If the dialog is supposed to use a visible title, confirm that title actually exists and contains real words (not an empty area), otherwise screen reader users will still hear nothing useful.",
"passed_title": null,
"dev_description": "Elements with `role=\"dialog\"` or `role=\"alertdialog\"` must expose an accessible name to assistive technologies. Provide a name using one of the supported mechanisms:\n\n- Add a non-empty `aria-label`.\n- Add `aria-labelledby` that references an existing element whose text content provides the dialog’s name.\n- (As shown in the rule help) provide a `title` attribute with a non-empty value.\n\nFix dialogs/alertdialogs that have no naming attribute, an empty `aria-label`, an `aria-labelledby` that points to a missing ID, or an `aria-labelledby` that points to an element with no text.",
"layman_description": "A dialog (a pop-up window) needs a clear name that screen readers can announce (for example, “Settings” or “Confirm delete”). If the dialog has no name—or the name is blank—people using screen readers may not know what the pop-up is for, even though it appears on the screen.",
"how_to_test": null
},
{
"rule_id": "aria-text",
"standard_code": "best-practice",
"Notes": null,
"issue_severity": "high",
"wcag_version_number": null,
"wcag_level": null,
"affected_disabilities_json": "Blind | Mobility",
"help": "\"role=text\" should have no focusable descendants",
"title": "\"role=text\" should have no focusable descendants",
"dev_help": "- Ensure any element with `role=\"text\"` contains only non-focusable content (plain text and non-interactive formatting such as `<br />`).\n- Do not wrap links or other interactive elements inside a `role=\"text\"` container.\n- Correct example:\n - `<h1><span role=\"text\">Hello <br/>World</span></h1>`\n- Incorrect example (link inside `role=\"text\"`):\n - `<span role=\"text\"><a href=\"/site.html\">Not announced as link</a></span>`\n- Fix the incorrect pattern by removing `role=\"text\"` from the wrapper or moving the link outside so the `role=\"text\"` element has no focusable descendants.",
"help_url": "https://dequeuniversity.com/rules/axe/4.11/aria-text?application=axeAPI",
"description": "Ensure role=\"text\" is used on elements with no focusable descendants",
"layman_help": "- Find places where something is marked to be read as “text only” (`role=\"text\"`).\n- Make sure anything inside it is not something you can tab to or click, like a link.\n- If there is a link inside, change the page so the “text only” label is removed from that container, or move the link outside of it.\n- It’s fine to use this for simple text that just needs line breaks (for example, “Hello” on one line and “World” on the next), but not for text that includes clickable items.",
"passed_title": null,
"dev_description": "Elements with `role=\"text\"` must not contain any focusable descendant elements. Do not apply `role=\"text\"` to a container that includes interactive/focusable HTML such as `<a href>`, `<button>`, `<input>`, `<select>`, `<textarea>`, or any element made focusable with `tabindex`. If the content includes links or controls, remove `role=\"text\"` from the wrapper or restructure so `role=\"text\"` is only on a non-interactive element that contains text-only content (e.g., text with `<br>`).",
"layman_description": "`role=\"text\"` is meant to tell assistive technology to read something as plain text. If you put it on something that contains things a person can click or tab to (like a link or button), those items may not be announced correctly. This can cause people using screen readers or keyboard navigation to miss that something is interactive.",
"how_to_test": null
},
{
"rule_id": "aria-treeitem-name",
"standard_code": "best-practice",
"Notes": null,
"issue_severity": "high",
"wcag_version_number": null,
"wcag_level": null,
"affected_disabilities_json": "Blind | Low vision | Mobility",
"help": "ARIA treeitem nodes should have an accessible name",
"title": "ARIA treeitem nodes should have an accessible name",
"dev_help": "- For every element with `role=\"treeitem\"`, ensure it has an accessible name.\n- Pass by using one of these patterns:\n - Add a non-empty `aria-label`:\n - `<div role=\"treeitem\" id=\"al\" aria-label=\"Name\"></div>`\n - Point `aria-labelledby` to an element that exists and contains discernible text:\n - `<div role=\"treeitem\" id=\"alb\" aria-labelledby=\"labeldiv\"></div>`\n - Provide discernible inner text (can also include `aria-label`):\n - `<div role=\"treeitem\" id=\"combo\" aria-label=\"Aria Name\">Name</div>`\n - Provide a non-empty `title`:\n - `<div role=\"treeitem\" id=\"title\" title=\"Title\"></div>`\n- Failures to fix:\n - Empty treeitem with no text/name:\n - `<div role=\"treeitem\" id=\"empty\"></div>`\n - Empty `aria-label`:\n - `<div role=\"treeitem\" id=\"alempty\" aria-label=\"\"></div>`\n - `aria-labelledby` points to a missing element:\n - `<div role=\"treeitem\" id=\"albmissing\" aria-labelledby=\"nonexistent\"></div>`\n - `aria-labelledby` points to an element with no text:\n - `<div role=\"treeitem\" id=\"albempty\" aria-labelledby=\"emptydiv\"></div>` with `<div id=\"emptydiv\"></div>`\n- When using `aria-labelledby`, verify the referenced id exists in the DOM and has readable text content.",
"help_url": "https://dequeuniversity.com/rules/axe/4.11/aria-treeitem-name?application=axeAPI",
"description": "Ensure every ARIA treeitem node has an accessible name",
"layman_help": "- Make sure every item in the tree has a name people can see or hear.\n- Use at least one of these ways to give it a name:\n - Put a clear text label inside the item (the words shown to users).\n - If the label is provided another way, ensure it isn’t blank and it points to real text.\n - If a tooltip-style name is used, it must contain real words (not empty).\n- Check for common mistakes:\n - The item has no label at all.\n - The label exists but is empty (for example, set to “nothing”).\n - The item tries to use a label from somewhere else, but that label doesn’t exist or contains no text.\n- After fixing, confirm each tree item would be announced with a meaningful name (for example, “Documents”, “Pictures”, “Settings”).",
"passed_title": null,
"dev_description": "Elements with `role=\"treeitem\"` must have a non-empty accessible name so assistive technologies can announce each node.\n\nProvide the name using one of these sources:\n- Visible/inner text inside the treeitem element.\n- A non-empty `aria-label=\"...\"`.\n- `aria-labelledby=\"...\"` that references an existing element whose text is discernible.\n- A non-empty `title=\"...\"`.\n\nFix treeitems that have no text, an empty `aria-label`, or an `aria-labelledby` reference that is missing or points to empty text.",
"layman_description": "Items in a tree (like a folder list) need a clear spoken name so screen readers can tell people what each item is.\n\nThis issue happens when a tree item has no label at all, or its label is blank or missing. As a result, someone using a screen reader may hear something like “tree item” without knowing what it is.",
"how_to_test": null
},
{
"rule_id": "empty-heading",
"standard_code": "best-practice",
"Notes": null,
"issue_severity": "low",
"wcag_version_number": null,
"wcag_level": null,
"affected_disabilities_json": "Blind | Deaf Blind | Mobility",
"help": "Headings should not be empty",
"title": "Headings should not be empty",
"dev_help": "- Ensure every heading tag (`<h1>` through `<h6>`) contains meaningful text; avoid empty markup like:\n - Bad: `<h1></h1>`\n- Do not hide heading text from assistive technologies:\n - Bad: `<h1 aria-hidden=\"true\">Heading Text</h1>`\n- Avoid CSS that makes heading text inaccessible (e.g., `display: none`) when that text is intended to be the heading.\n- Confirm headings are actually headings (use `<h1>`–`<h6>` only for section titles) and keep them brief, clear, unique, and in a logical hierarchy so reading just the headings gives a sense of the page’s contents.",
"help_url": "https://dequeuniversity.com/rules/axe/4.11/empty-heading?application=axeAPI",
"description": "Ensure headings have discernible text",
"layman_help": "- Go through the page’s headings and check that each one has real, visible wording (not blank).\n- Make sure the heading text isn’t set up to be hidden from screen readers. Sometimes text can look present to sighted users but be marked as “hidden” for assistive technology.\n- Read only the headings, top to bottom. If they don’t give a good overview of what the page is about, rewrite them so they’re clearer.\n- Use headings only where something is truly a section title, and keep the heading levels in a sensible order so the page structure makes sense.",
"passed_title": null,
"dev_description": "Heading elements (`<h1>`–`<h6>`) must contain discernible text. Do not render empty headings (e.g., `<h1></h1>`) or headings whose text is hidden from assistive technology, such as when using `aria-hidden=\"true\"` or CSS that removes content from the accessibility tree (e.g., `display: none`). Ensure the heading’s text is present in the DOM and exposed to screen readers.",
"layman_description": "Headings shouldn’t be blank or “invisible” to people using screen readers. If a heading has no text, or if the text is hidden from assistive technology, some users won’t be able to understand the page structure or navigate the page by headings.",
"how_to_test": null
},
{
"rule_id": "empty-table-header",
"standard_code": "best-practice",
"Notes": null,
"issue_severity": "low",
"wcag_version_number": null,
"wcag_level": null,
"affected_disabilities_json": "Blind | Low vision",
"help": "Table header text should not be empty",
"title": "Table header text should not be empty",
"dev_help": "- Ensure every header cell (`<th>` or elements with `role=\"rowheader\"` / `role=\"columnheader\"`) has non-empty, visible text content.\n- Correct example:\n - `<table><tr><th>Student Name</th></tr></table>`\n- Incorrect examples (empty header text):\n - `<table><tr><th></th></tr></table>`\n - `<table><tr><th aria-label=\"Student Name\"></th></tr></table>`\n- Change empty headers by placing the descriptive label as text inside the header element.",
"help_url": "https://dequeuniversity.com/rules/axe/4.11/empty-table-header?application=axeAPI",
"description": "Ensure table headers have discernible text",
"layman_help": "- Look at the top row (or the first column) of your table where the labels should be.\n- For each label cell, make sure there are visible words that describe what the column/row is (for example, “Student Name”).\n- If a header cell looks blank, add the missing label text so people can understand what the table information means.",
"passed_title": null,
"dev_description": "Table header cells must have discernible visible text.\n\nAny element used as a table header—`<th>`, or an element with `role=\"rowheader\"` / `role=\"columnheader\"`—should contain text content that describes the header’s purpose. Fix by adding meaningful text inside the header element; do not leave it empty.",
"layman_description": "The titles at the top of a table (the header cells) shouldn’t be blank.\n\nEach header should show a real label (like “Student Name”) so people can understand what the column or row is about when they read the table.",
"how_to_test": null
},
{
"rule_id": "focus-order-semantics",
"standard_code": "best-practice",
"Notes": null,
"issue_severity": "low",
"wcag_version_number": null,
"wcag_level": null,
"affected_disabilities_json": "Blind | Deaf Blind | Mobility",
"help": "Elements in the focus order should have an appropriate role",
"title": "Elements in the focus order should have an appropriate role",
"dev_help": "- Prefer native HTML controls so the correct role is implied automatically (no extra `role` needed):\n - Buttons: `<button>`\n - Links: `<a href=\"...\">`\n - Form fields: `<input>`, `<select>`, `<textarea>`\n- For custom interactive widgets (e.g., clickable `<div>`/`<span>` in the tab order), add a valid ARIA `role` that matches the behavior (e.g., `role=\"button\"`, `role=\"link\"`, `role=\"checkbox\"`, `role=\"textbox\"`, etc.).\n- Ensure every focusable element has semantics appropriate for interactive content:\n - If there is no role, screen readers may announce nothing meaningful when focus lands on it.\n - If the role is inappropriate for an interactive element (e.g., `role=\"paragraph\"`), it may not be treated as focusable/interactive and may not be announced as a control.\n- Use valid ARIA role values that fit the control type, such as:\n - Widget roles: `button`, `checkbox`, `radio`, `textbox`, `combobox`, `slider`, `tab`, `menuitem`, etc.\n - Landmark roles (for regions): `main`, `navigation`, `banner`, `contentinfo`, `search`, etc.\n- If a screen reader user lands on an element that only has text, they may hear the text but won’t know what the element is unless the role is appropriate.",
"help_url": "https://dequeuniversity.com/rules/axe/4.11/focus-order-semantics?application=axeAPI",
"description": "Ensure elements in the focus order have a role appropriate for interactive content",
"layman_help": "- Check the parts of the page you can reach with the keyboard (press Tab). Each one should be clearly a “button”, “link”, or “form field”, not an unidentified or confusing item.\n- If a control can be selected but your screen reader doesn’t say what it is, it likely needs to be identified properly.\n- Make sure interactive items are built using the correct kind of component:\n - Use real buttons for actions, real links for navigation, and real form fields for typing/choosing.\n- If your site uses custom-made controls that look like buttons or switches, they still need to be labeled as the right type so assistive technology can announce them correctly.\n- Re-test with keyboard and a screen reader: when focus lands on a control, it should be announced as the correct type (for example, “button” or “checkbox”), not just read as plain text.",
"passed_title": null,
"dev_description": "Elements that are reachable via keyboard focus must expose an appropriate semantic role for interactive content.\n\nIf a focused element has no role (or only generic semantics), assistive technologies may not announce what it is.\n\nIf an interactive element is given an inappropriate role (e.g., `role=\"paragraph\"`), it may not be treated as interactive and may not receive focus/announcements.\n\nUse native interactive HTML where possible (e.g., `<button>`, `<a href>`, `<input>`). For custom widgets (non-native interactive elements), add a valid ARIA `role` that matches the control’s behavior (e.g., `role=\"button\"`).",
"layman_description": "Anything you can reach with the keyboard (by pressing Tab) should be clearly identified as something you can use—like a button, link, or form field.\n\nIf an item can be focused but isn’t identified correctly, screen readers may not announce what it is. A person may hear the text, but won’t know whether it’s a button, a link, or something else.\n\nIf something is meant to be interactive but is labeled as the wrong type, it may not behave like an interactive control for keyboard and screen reader users.",
"how_to_test": null
},
{
"rule_id": "heading-order",
"standard_code": "best-practice",
"Notes": null,
"issue_severity": "medium",
"wcag_version_number": null,
"wcag_level": null,
"affected_disabilities_json": "Blind | Deaf Blind | Mobility",
"help": "Heading levels should only increase by one",
"title": "Heading levels should only increase by one",
"dev_help": "- Ensure all headings use semantic HTML heading elements: `<h1>` through `<h6>` (not visually styled text pretending to be a heading).\n- Ensure heading levels are ordered hierarchically and only increase by one level at a time:\n - Valid: `<h1>` → `<h2>` → `<h3>` …\n - Avoid: `<h1>` → `<h3>` (skips `<h2>`)\n- Do not use heading elements for non-heading content (e.g., styling a sentence as a heading just to make it stand out).\n- Prefer starting the main content with an `<h1>` and placing sub-sections as `<h2>`. If an `<h2>` section has sub-sections, use `<h3>`, and so on.\n- Example structure:\n - `<h1>Setting the Exposure Manually on a Camera</h1>`\n - `<h2>Set the ISO</h2>`\n - `<h2>Choose an aperture</h2>`\n - `<h2>Choose a shutter speed</h2>`\n- Quick validation: read only the headings in order; they should provide a clear outline of the page’s contents.",
"help_url": "https://dequeuniversity.com/rules/axe/4.11/heading-order?application=axeAPI",
"description": "Ensure the order of headings is semantically correct",
"layman_help": "1. Look at the page’s main title and section titles in the order they appear.\n2. Make sure they form a clear outline:\n - One main title at the start of the main content.\n - Sections under that main title.\n - Smaller sections nested under the sections (if needed).\n3. Avoid “skipping” levels. For example, don’t jump from a main title straight to a much smaller sub-title level.\n4. Only mark real section titles as headings. Don’t use heading styling just to make regular text look bigger or bolder.\n5. Test the structure by reading only the headings: if you can’t get a good sense of what the page is about from headings alone, rewrite or reorganize them.",
"passed_title": null,
"dev_description": "Heading structure is not semantically hierarchical. Heading levels (`<h1>`–`<h6>`) should progress in order and only increase by one level at a time (e.g., `<h1>` → `<h2>`, not `<h1>` → `<h3>`). Use true heading elements for section titles only, and do not apply heading markup to non-heading text.\n\nFix by changing heading tags so the document outline matches the intended section/subsection hierarchy (e.g., convert skipped levels like `<h3>` to `<h2>` when it is the next section level).",
"layman_description": "The page’s titles and section labels aren’t organized in a clear, step-by-step order. This can make the page harder to understand and harder to navigate with assistive tools.\n\nHeadings should work like an outline: a main title first, then sections under it, then smaller sections under those. If the page “jumps” from a big heading to a much smaller one, or uses heading styling on text that isn’t really a section title, the structure becomes confusing.",
"how_to_test": null
},
{
"rule_id": "hidden-content",
"standard_code": "best-practice",
"Notes": null,
"issue_severity": "low",
"wcag_version_number": null,
"wcag_level": null,
"affected_disabilities_json": "Blind",
"help": "Hidden content on the page should be analyzed",
"title": "Hidden content on the page should be analyzed",
"dev_help": "- If the result is incomplete, expose the detected hidden items and re-run the audit; the tool needs the content to be displayed/available to analyze it.\n- If the result is a failure, treat it as a problem analyzing the page under test due to hidden content/state; make the content render in a testable state.\n- Trigger UI states that reveal content (e.g., open menus/accordions/dialogs, expand “read more”, reveal tooltips/popovers when they contain important content).\n- Review common hiding techniques that can block analysis:\n - CSS `display: none` (element removed from layout and typically not exposed).\n - CSS `visibility: hidden` (element not visible and typically not exposed).\n - “Visually hidden” patterns (hidden from sighted users but available to screen readers) and screen-reader-only hiding.\n- Use hiding techniques with caution, similar to CSS-generated text: hidden content may be missed during analysis unless you expose it.\n- Ensure any content that must be audited can be made visible/available in the test environment (e.g., render expanded states by default for testing, or provide a deterministic way to open/expand before running checks).",
"help_url": "https://dequeuniversity.com/rules/axe/4.11/hidden-content?application=axeAPI",
"description": "Inform users about hidden content.",
"layman_help": "1. Look for parts of the page that are collapsed or hidden, like:\n - Menus that open only when you click them\n - Sections that expand (“Show more”, accordions)\n - Pop-ups or dialogs\n2. Open or reveal those parts so the hidden information becomes visible.\n3. Run the accessibility check again after everything relevant is shown.\n4. If the result says incomplete, it usually means the checker noticed hidden items but couldn’t fully review them until they were opened.\n5. If the result says failed, it means the checker couldn’t properly review the page because some content was hidden in a way it can’t access. Make sure the hidden sections can be shown during testing (for example, by opening them first).",
"passed_title": null,
"dev_description": "Some page content is hidden in a way that prevents automated accessibility analysis. Hidden content can be:\n\n- Hidden from all users (for example via CSS `display: none` or `visibility: hidden`).\n- Hidden from sighted users only (visually hidden but still available to screen readers).\n- Hidden from screen readers only.\n\nWhen hidden content exists, the audit may report incomplete (items were detected but could not be fully analyzed until you expose them) or fail (the tool could not analyze the content on the page under test). Passing means all content on the page could be analyzed and no hidden content was found.\n\nTo resolve, trigger or modify the UI/state so hidden elements become visible/available for testing, and avoid hiding important content in ways that block analysis unless intentionally required.",
"layman_description": "Some information on the page is not currently visible (it may only appear after you open something like a menu, accordion, modal, or other hidden section). Because it’s hidden, the accessibility check may not be able to review it.\n\nIf the check says incomplete, it likely found hidden items but couldn’t fully test them until they’re shown. If it fails, the tool couldn’t properly analyze the page’s content. If it passes, it means everything on the page could be checked and no hidden content was found.",
"how_to_test": null
},
{
"rule_id": "image-redundant-alt",
"standard_code": "best-practice",
"Notes": null,
"issue_severity": "low",
"wcag_version_number": null,
"wcag_level": null,
"affected_disabilities_json": "Blind | Deaf Blind",
"help": "Alternative text of images should not be repeated as text",
"title": "Alternative text of images should not be repeated as text",
"dev_help": "- If an `<img>` is inside a link (`<a>`) and the adjacent visible text already provides the same label, do not duplicate that label in `alt`.\n- Example problem:\n - `<a href=\"index.html\"><img src=\"images/home-icon.png\" alt=\"Home Page\">Home Page</a>` causes “Home Page Home Page”.\n- Fix for redundant/decorative icon images next to the same text:\n - Set `alt=\"\"` on the icon image.\n- For image buttons, `alt` is the label:\n - Use `<input type=\"image\" ... alt=\"Submit\">` (must be present and describe the action).\n- Write `alt` text to convey intent/purpose/meaning:\n - Ask: What information does it present? What purpose does it fulfill? What words would you use if there were no image?\n - Avoid unhelpful words like “image”, “chart”, “diagram”, or file names.",
"help_url": "https://dequeuniversity.com/rules/axe/4.11/image-redundant-alt?application=axeAPI",
"description": "Ensure image alternative is not repeated as text",
"layman_help": "- Look for places where there is an icon next to words that say the same thing (for example, a home icon next to the words “Home Page”).\n- If the icon doesn’t add extra meaning beyond the nearby words, leave the icon’s image description blank so screen readers don’t repeat it.\n- If the image is the button itself (an image-only button), it still needs a short, clear label that says what happens when you use it (for example, “Submit”), not what the picture looks like.\n- When choosing wording, focus on the purpose:\n - What does this control do?\n - What would you call it if there were no picture?\n - Avoid vague labels like “image” or using the file name.",
"passed_title": null,
"dev_description": "When an image inside a link (`<a>`) or other UI element has adjacent visible text that already provides the same label, the image’s `alt` text must not repeat that same wording. Otherwise, assistive technologies may announce the label twice (e.g., “Home Page Home Page”).\n\nImplementation: for decorative/redundant icons next to the same visible label, set the image to `alt=\"\"` (empty alt). For image buttons (e.g., `<input type=\"image\">`), keep a meaningful `alt` because it is used as the accessible label; make it concise and action-focused (what the control does), not a description of the pixels.",
"layman_description": "If an icon sits next to words that already say the same thing, repeating those same words in the image description makes screen readers say the label twice. For someone using a screen reader, “Home Page” can become “Home Page Home Page,” which is distracting and confusing.\n\nOnly give the picture a description when it adds new information. If the nearby text already explains it, the picture’s description should be left blank. If the picture itself is a clickable button (an image-only button), it still needs a clear label that explains the action (like “Submit”).",
"how_to_test": null
},
{
"rule_id": "landmark-banner-is-top-level",
"standard_code": "best-practice",
"Notes": null,
"issue_severity": "medium",
"wcag_version_number": null,
"wcag_level": null,
"affected_disabilities_json": "Blind | Deaf Blind",
"help": "Banner landmark should not be contained in another landmark",
"title": "Banner landmark should not be contained in another landmark",
"dev_help": "- Find each element using `role=\"banner\"` (and any `<header>` you’ve explicitly turned into a banner).\n- Ensure each banner landmark is not contained within another landmark, including containers with roles like `banner`, `navigation`, `main`, `contentinfo`, `complementary`, `form`, or `region`.\n- Restructure DOM nesting so the banner is top-level (commonly a child of `<body>`), rather than inside another landmark.\n- Prefer having a single site-wide banner landmark for the page when possible; avoid multiple banner landmarks and avoid nesting them within other landmarks.",
"help_url": "https://dequeuniversity.com/rules/axe/4.11/landmark-banner-is-top-level?application=axeAPI",
"description": "Ensure the banner landmark is at top level",
"layman_help": "- Identify the site’s main header area (usually where the logo, site name, and primary header controls live).\n- Make sure that header area isn’t placed “inside” another big page section like the main content area, a navigation section, a footer section, or a sidebar section.\n- If it is nested, move the header area so it sits at the top level of the page structure, alongside those other big sections rather than inside them.\n- Try to keep just one main header area for the page so it’s easy for assistive technology users to find.",
"passed_title": null,
"dev_description": "Elements with the ARIA landmark `role=\"banner\"` must be top-level landmarks and not nested inside any other landmark region. In practice, ensure the banner (often a site-wide `<header>`/banner container) is not placed inside another landmark element/role such as `role=\"main\"`, `role=\"navigation\"`, `role=\"contentinfo\"`, `role=\"complementary\"`, `role=\"form\"`, `role=\"region\"`, etc.\n\nUpdate the markup so the banner container is a direct child of the page structure (commonly under `<body>`) rather than inside another landmark, even though multiple HTML5 `<header>` elements can exist.",
"layman_description": "The page’s main header area (the “banner”) should be on its own at the top level of the page layout, not placed inside another major section. If the banner is tucked inside another big section (like the main content area or navigation area), it can confuse people who use assistive technologies to jump around the page.",
"how_to_test": null
},
{
"rule_id": "landmark-complementary-is-top-level",
"standard_code": "best-practice",
"Notes": null,
"issue_severity": "medium",
"wcag_version_number": null,
"wcag_level": null,
"affected_disabilities_json": "Blind | Deaf Blind | Mobility",
"help": "Aside should not be contained in another landmark",
"title": "Aside should not be contained in another landmark",
"dev_help": "- Locate `<aside>` elements and elements with `role=\"complementary\"`.\n- Verify they are not descendants of another landmark (e.g., not inside `<main>`, `role=\"main\"`, `role=\"banner\"`, `role=\"contentinfo\"`, etc.).\n- Refactor markup so the complementary landmark is top-level (typically a sibling of `<main>`).\n- Failing example (nested complementary landmark):\n \n\n- Passing example (top-level complementary landmark):",
"help_url": "https://dequeuniversity.com/rules/axe/4.11/landmark-complementary-is-top-level?application=axeAPI",
"description": "Ensure the complementary landmark or aside is at top level",
"layman_help": "- Find the “side” or “related info” area on the page (often a sidebar, extra notes, or supplementary content).\n- Check whether it’s placed inside another big section of the page (like the main content area).\n- If it is nested inside another big section, move it so it sits next to the main content area as its own separate section.\n- This helps people using screen readers because they rely on these major sections to quickly navigate the page; nesting them makes navigation more confusing.",
"passed_title": null,
"dev_description": "Ensure any complementary landmark is top-level in the page structure.\n\n- Do not place an `<aside>` element (or any element with `role=\"complementary\"`) inside another landmark such as `<main>`, `<header role=\"banner\">`, `<footer role=\"contentinfo\">`, or any other landmark region.\n- Change the DOM structure so the complementary landmark is a sibling of other landmarks (e.g., alongside `<main>`), not a descendant.\n\nNesting landmarks can create a confusing landmark structure for assistive technologies.",
"layman_description": "Make sure the page’s “extra information” section (often a sidebar or related content area) isn’t placed inside another major section of the page.\n\nWhen these sections are nested inside other major sections, it can make the page outline confusing for people who use screen readers to jump between sections. The extra/side content should be its own main section at the same level as other main sections.",
"how_to_test": null
},
{
"rule_id": "landmark-contentinfo-is-top-level",
"standard_code": "best-practice",
"Notes": null,
"issue_severity": "medium",
"wcag_version_number": null,
"wcag_level": null,
"affected_disabilities_json": "Blind | Deaf Blind",
"help": "Contentinfo landmark should not be contained in another landmark",
"title": "Contentinfo landmark should not be contained in another landmark",
"dev_help": "- Ensure any element with `role=\"contentinfo\"` is not contained within another landmark region.\n- Treat the contentinfo landmark as the page-level footer area; place it outside other landmarks such as main content, header, or navigation regions.\n- Keep text content inside appropriate landmark regions, but make sure the footer landmark (`role=\"contentinfo\"`) is separated from the header and main body content by being top-level in the page structure.",
"help_url": "https://dequeuniversity.com/rules/axe/4.11/landmark-contentinfo-is-top-level?application=axeAPI",
"description": "Ensure the contentinfo landmark is at top level",
"layman_help": "- Find the part of the page that acts like the footer (often includes copyright, contact details, or site-wide information).\n- Make sure this footer section is not placed inside another large section like the main content area, the site header area, or the navigation area.\n- The footer should stand on its own as a separate section of the page so it’s easier to locate and understand, especially for people using screen readers.",
"passed_title": null,
"dev_description": "The contentinfo landmark (`role=\"contentinfo\"`, typically a page footer) must be top-level and not nested inside another landmark (for example inside `role=\"main\"`, `role=\"navigation\"`, `role=\"banner\"`, or another `role=\"contentinfo\"`).\n\nUpdate the DOM structure so the element with `role=\"contentinfo\"` (or the page-level `<footer>` that acts as contentinfo) is a direct landmark region on the page rather than contained within other landmark elements/regions.",
"layman_description": "The page’s footer area (the part that usually has things like copyright, contact info, or site-wide links) shouldn’t be placed inside another major page section.\n\nWhen it’s nested inside another big section, some people who use assistive technologies can have a harder time finding and understanding where the footer starts and ends.",
"how_to_test": null
},
{
"rule_id": "landmark-main-is-top-level",
"standard_code": "best-practice",
"Notes": null,
"issue_severity": "medium",
"wcag_version_number": null,
"wcag_level": null,
"affected_disabilities_json": "Blind | Deaf Blind | Mobility",
"help": "Main landmark should not be contained in another landmark",
"title": "Main landmark should not be contained in another landmark",
"dev_help": "- Ensure the main landmark is not contained within another landmark.\n- Use an HTML5 `<main>` element and/or `role=\"main\"` to designate the main content region.\n- Keep landmark regions organized so all content is inside meaningful regions such as `<header>`, `<nav>`, `<main>`, `<footer>` (and/or their ARIA roles).\n- Follow the robust pattern shown in the example (HTML5 + ARIA roles used together):\n\n\n\n\n- If your current structure nests `<main>` inside another landmark (e.g., inside `<nav>` or `<header>`), move it out so it is a top-level region.",
"help_url": "https://dequeuniversity.com/rules/axe/4.11/landmark-main-is-top-level?application=axeAPI",
"description": "Ensure the main landmark is at top level",
"layman_help": "1. Find the area of the page that contains the primary content (the part someone is meant to read or use).\n2. Make sure that “main content” area is its own top-level section of the page, not placed inside the site’s header area, menu area, or footer area.\n3. Keep the page organized into clear sections like: header (top branding), navigation (menu), main content (the important part), and footer (bottom information).\n\nThis helps screen reader users jump directly to the main content because the page’s big sections are clearly separated and labeled.",
"passed_title": null,
"dev_description": "The `<main>` element / `role=\"main\"` landmark must be top-level** (not nested inside another landmark container).\n\nFailing examples include placing the main landmark inside other landmark elements/roles such as `<header>` / `role=\"banner\"`, `<nav>` / `role=\"navigation\"`, or `<footer>` / `role=\"contentinfo\"`.\n\nChange the DOM structure so the page’s primary content region is represented by a single main landmark that is a direct page region (e.g., a sibling of header/nav/footer), rather than being contained by another landmark.",
"layman_description": "The main part of the page (the central content people came for) should be its own top-level section, not placed inside another big section like the site header, navigation, or footer.\n\nWhen the main section is tucked inside another section, people who use screen readers can have a harder time jumping straight to the primary content because the page’s sections are not clearly separated.",
"how_to_test": null
},
{
"rule_id": "landmark-no-duplicate-banner",
"standard_code": "best-practice",
"Notes": null,
"issue_severity": "medium",
"wcag_version_number": null,
"wcag_level": null,
"affected_disabilities_json": "Blind | Deaf Blind",
"help": "Document should not have more than one banner landmark",
"title": "Document should not have more than one banner landmark",
"dev_help": "- Ensure each HTML page has only one banner landmark.\n- Identify elements that create a banner landmark:\n - Elements with `role=\"banner\"`.\n - Page-level `<header>` used as the main site/page header.\n- Decide which banner you want to keep as the single, document-unique banner.\n- For any additional banners, remove the extra banner landmark by:\n - Removing `role=\"banner\"`, or\n - Changing the element’s role/semantics so it is not treated as the page banner.\n- Keep the banner landmark on the element that is unique to the document (typical main site header).",
"help_url": "https://dequeuniversity.com/rules/axe/4.11/landmark-no-duplicate-banner?application=axeAPI",
"description": "Ensure the document has at most one banner landmark",
"layman_help": "- Look for the main header area of the page (usually the top section with the site name/logo and main navigation).\n- Make sure only one section is marked as the page’s main banner.\n- If the page has other header-like sections (for example, a header at the top of a card, article, or panel), don’t mark those as the main banner.\n- Choose the one true page banner to keep, and change the others so they’re treated as normal sections rather than additional “main headers.”",
"passed_title": null,
"dev_description": "The page must contain no more than one banner landmark. A banner landmark is created by either:\n\n- An element with `role=\"banner\"`, or\n- The top-level page `<header>` that represents the site/page banner\n\nIf multiple elements create a banner landmark, screen readers may announce more than one “banner” region. Update the markup so only a single element remains the banner for the document, and remove or change the banner role/semantics on the others.",
"layman_description": "This page has more than one “top-of-page header area” marked as the main banner. Assistive technologies (like screen readers) expect only one main banner per page. When there are multiple, it can confuse people because the page seems to have more than one main header region.",
"how_to_test": null
},
{
"rule_id": "landmark-no-duplicate-contentinfo",
"standard_code": "best-practice",
"Notes": null,
"issue_severity": "medium",
"wcag_version_number": null,
"wcag_level": null,
"affected_disabilities_json": "Blind | Deaf Blind",
"help": "Document should not have more than one contentinfo landmark",
"title": "Document should not have more than one contentinfo landmark",
"dev_help": "- Ensure the document has at most one `role=\"contentinfo\"` landmark.\n- Use `role=\"contentinfo\"` exactly once for information that is unique for the whole page (commonly the overall footer).\n- Do not place `role=\"contentinfo\"` inside repeated structures (e.g., multiple `<main>` sections, multiple articles/cards) for per-section metadata.\n- Good pattern (single instance):\n - `role=\"banner\"` once, `role=\"main\"` once, `role=\"contentinfo\"` once.\n- Bad pattern to fix (multiple instances):\n - Multiple sections each containing `<div role=\"contentinfo\">...`.\n- Remember: ARIA landmark roles like `role=\"banner\"`, `role=\"main\"`, and `role=\"contentinfo\"` are intended to be used only once per page.",
"help_url": "https://dequeuniversity.com/rules/axe/4.11/landmark-no-duplicate-contentinfo?application=axeAPI",
"description": "Ensure the document has at most one contentinfo landmark",
"layman_help": "- Keep just one main footer for the entire page (the area that contains things like site/company info, copyright, or global links).\n- If you have small “footer-like” notes inside each article or section (for example, “information about this article”), keep them as normal text in that section, but don’t treat them as an additional page footer.\n- After changes, there should be only one place on the page that acts like “the footer for the whole page.”",
"passed_title": null,
"dev_description": "The page must contain no more than one `contentinfo` landmark.\n\nFail when the document includes multiple elements that create a contentinfo landmark, such as:\n- Multiple elements with `role=\"contentinfo\"`.\n- Multiple HTML5 footer landmarks that effectively act as the page-level contentinfo.\n\nUpdate markup so there is only one page-level contentinfo landmark (typically the site/page footer). If you need footer-like information inside repeated sections (e.g., articles/cards), do not mark those as `role=\"contentinfo\"`.",
"layman_description": "Your page should have only one “page footer” area for the whole document.\n\nRight now, the page has more than one footer-type section. This can confuse people who use assistive tools (like screen readers) to jump to the footer, because they may hear multiple “footer” areas and not know which one is the real page footer.",
"how_to_test": null
},
{
"rule_id": "landmark-unique",
"standard_code": "best-practice",
"Notes": null,
"issue_severity": "medium",
"wcag_version_number": null,
"wcag_level": null,
"affected_disabilities_json": "Blind | Deaf Blind",
"help": "Landmarks should have a unique role or role/label/title (i.e. accessible name) combination",
"title": "Landmarks should have a unique role or role/label/title (i.e. accessible name) combination",
"dev_help": "- Ensure each landmark is unique by role or by role + accessible name.\n- Prefer having only one `<main>` / `role=\"main\"`:\n - Passing: `<main id=\"pass-main\">Only main</main>`\n - Failing example pattern: multiple mains, including one in an `iframe`.\n- If you have multiple landmarks of the same type, give each a unique name:\n - Use different `aria-label` values:\n - Passing:\n - `<form id=\"pass-form-aria-label-1\" aria-label=\"form-label-1\"></form>`\n - `<form id=\"pass-form-aria-label-2\" aria-label=\"form-label-2\"></form>`\n - Failing pattern:\n - `<form aria-label=\"form-label\"></form>` repeated with the same label.\n - Or use `aria-labelledby` pointing to different text:\n - Passing:\n - `<div id=\"form-label-1\">form-with-label-1</div>` + `<form aria-labelledby=\"form-label-1\"></form>`\n - `<div id=\"form-label-2\">form-with-label-2</div>` + `<form aria-labelledby=\"form-label-2\"></form>`\n - Failing pattern: two different IDs that both contain identical text (so the computed name is the same), e.g., two label elements that both read `form-with-label`.\n- Watch for duplicated ARIA landmark roles without unique names, including:\n - `role=\"banner\"`, `role=\"contentinfo\"`, `role=\"complementary\"`, `role=\"region\"`, `role=\"search\"`, `role=\"navigation\"`, `role=\"form\"`, and native equivalents like `<nav>` / `<section>`.\n - Failing examples include repeating the same `aria-label` on the same role:\n - `<div aria-label=\"duplicate label\" role=\"banner\"></div>` repeated\n - `<nav aria-label=\"duplicate label for nav\"></nav>` repeated\n - `<section aria-label=\"duplicate label for section\"></section>` repeated\n- If landmarks appear in embedded documents (e.g., `iframe`), ensure uniqueness still holds in the combined user experience (or remove/avoid duplicate landmark roles where appropriate).",
"help_url": "https://dequeuniversity.com/rules/axe/4.11/landmark-unique?application=axeAPI",
"description": "Ensure landmarks are unique",
"layman_help": "- Look for repeated big page sections such as header, main content, navigation, footer, search, or sidebar.\n- If there is more than one section of the same kind (for example, two navigation areas), give each one a clear, different name so assistive technology can tell them apart (for example, “Primary navigation” vs “Footer navigation”).\n- If the page has more than one “main content” area, reduce it to one main content area whenever possible.\n- If you use embedded content (like a page inside a page), check that it doesn’t create another section that looks identical to one already on the page.\n- After naming or consolidating sections, verify that each repeated section is distinguishable by its name when navigating with accessibility tools.",
"passed_title": null,
"dev_description": "Landmark regions must be unique by either:\n\n- having a unique landmark role (e.g., only one `main`/`role=\"main\"`), or\n- when multiple landmarks of the same role exist, having a unique accessible name per landmark.\n\nThis rule fails when the page (including embedded content like `iframe`s) contains multiple landmarks with the same role and the same accessible name (or no name at all for roles that require differentiation).\n\nImplementation details:\n\n- Landmarks come from HTML elements such as `<main>`, `<header>`, `<footer>`, `<nav>`, `<section>`, and from ARIA roles such as `role=\"banner\"`, `role=\"navigation\"`, `role=\"complementary\"`, `role=\"contentinfo\"`, `role=\"main\"`, `role=\"region\"`, `role=\"search\"`, `role=\"form\"`.\n- Provide a unique accessible name using `aria-label=\"...\"` or `aria-labelledby=\"someId\"` (with referenced text that differs per landmark). If two same-role landmarks share the same `aria-label`, or two `aria-labelledby` references resolve to the same text, the combination is not unique.\n- Avoid multiple instances of roles meant to be singular (notably `main`/`role=\"main\"`).",
"layman_description": "Pages are often split into big “sections” (like main content, header, footer, navigation). Assistive technologies use these sections to help people jump around quickly.\n\nThis issue happens when the page has two or more sections that look the same to assistive technology—because they’re the same type of section and have the same name (or no distinguishing name). When that happens, people can’t easily tell which section is which when navigating.\n\nFor example, if there are two navigation areas both named the same thing, a screen reader user may hear the same label twice and not know which one they’re in. Some sections (like the main content area) should typically appear only once.",
"how_to_test": null
},
{
"rule_id": "meta-viewport-large",
"standard_code": "best-practice",
"Notes": null,
"issue_severity": "low",
"wcag_version_number": null,
"wcag_level": null,
"affected_disabilities_json": "Low vision",
"help": "Users should be able to zoom and scale the text up to 500%",
"title": "Users should be able to zoom and scale the text up to 500%",
"dev_help": "- Find the `<meta name=\"viewport\">` element in the page `<head>`.\n- Check its `content` attribute for zoom restrictions.\n- Remove `user-scalable=\"no\"` from `content` to allow zooming.\n- Ensure `maximum-scale` is present and >= 5 (not less than 5).\n- Re-test on mobile/tablet to confirm pinch-to-zoom works and can scale up to 500%.",
"help_url": "https://dequeuniversity.com/rules/axe/4.11/meta-viewport-large?application=axeAPI",
"description": "Ensure <meta name=\"viewport\"> can scale a significant amount",
"layman_help": "- Ask whoever maintains the site to check the page’s “viewport” setting (a small page setting that controls zoom on phones and tablets).\n- Make sure the site does not block zooming.\n- Make sure the site does not limit zoom too much—people should be able to zoom in a lot (up to about 500%).\n- After the change, test on a phone or tablet: try pinching to zoom in and confirm you can enlarge the page significantly.",
"passed_title": null,
"dev_description": "The page’s `<meta name=\"viewport\">` must not prevent zooming and must allow significant scaling.\n\nIn the viewport tag’s `content` attribute:\n- Do not include `user-scalable=\"no\"` (it disables pinch/zoom).\n- Ensure `maximum-scale` is not less than `5` (allows up to 500% zoom).\n\nExample tag to review: `<meta name=\"viewport\" content=\"...\">`.",
"layman_description": "People should be able to zoom in on the page (up to about 500%) so text and controls become easier to read and use.\n\nThis issue happens when the page tells the browser not to allow zooming, or it limits how far someone can zoom in. That can make the site hard to use for people with low vision or anyone who needs larger text.",
"how_to_test": null
},
{
"rule_id": "page-has-heading-one",
"standard_code": "best-practice",
"Notes": null,
"issue_severity": "medium",
"wcag_version_number": null,
"wcag_level": null,
"affected_disabilities_json": "Blind | Low vision | Deaf Blind",
"help": "Page should contain a level-one heading",
"title": "Page should contain a level-one heading",
"dev_help": "- Ensure the document contains a level-one heading: add an `<h1>` element to the page content, typically at the start of the main content.\n- Follow a consistent hierarchy: use `<h2>` for major sections under the `<h1>`, `<h3>` for sub-sections of `<h2>`, and so on.\n- Prefer a single `<h1>` on the page (best practice noted in the guidance).\n- If the page includes an `<iframe>` you control, align the iframe’s heading structure with the parent document:\n - If the parent has a top-level `<h1>` at the top of content, the iframe should generally not start with another `<h1>`.\n - If the iframe content is a direct child section under the page’s main heading, start the iframe with `<h2>`.\n - If the iframe content belongs under a level-2 section, start the iframe with `<h3>`, and so on.\n- If the `<iframe>` content is third-party and cannot be changed, the rule guidance notes you may not be able to fully control heading hierarchy matching; add the `<h1>` to the main page content and match hierarchy where possible.",
"help_url": "https://dequeuniversity.com/rules/axe/4.11/page-has-heading-one?application=axeAPI",
"description": "Ensure that the page, or at least one of its frames contains a level-one heading",
"layman_help": "- Add a clear main title to the page near the start of the main content.\n- Make sure there’s usually only one main title for the whole page.\n- Use section headings underneath the main title to organize the content (for example, main title first, then section titles, then sub-section titles).\n- If your page includes embedded content (like an embedded page or widget) and you can edit it, try to make its headings fit with the rest of the page (so it doesn’t look like it starts a whole new page with a second main title).\n- If the embedded content comes from another company and you can’t change it, do what you can on your own page: include a clear main title and keep your sections well organized.",
"passed_title": null,
"dev_description": "The page must include at least one `<h1>` in the document, or within at least one embedded frame (`<iframe>`). Add a level-one heading near the start of the page’s main content and ensure the heading structure is logical.\n\nBest practice from the guidance: the main content typically starts with a single `<h1>`, followed by `<h2>` for major sections, then `<h3>`, etc. If an `<iframe>` is part of the content you control, its heading levels should fit into the parent page’s heading hierarchy (e.g., avoid starting the iframe with another `<h1>` when the parent already has the top-level `<h1>`).",
"layman_description": "This page should have a clear main title. That title is usually the first and most important heading on the page.\n\nA good page structure starts with one main heading at the beginning of the main content, and then uses smaller headings for sections and sub-sections. If the page includes embedded content (like a widget or embedded page), that embedded content should ideally follow the same heading structure as the rest of the page when you have control over it.",
"how_to_test": null
},
{
"rule_id": "presentation-role-conflict",
"standard_code": "best-practice",
"Notes": null,
"issue_severity": "low",
"wcag_version_number": null,
"wcag_level": null,
"affected_disabilities_json": "Blind | Low vision | Mobility",
"help": "Elements marked as presentational should be consistently ignored",
"title": "Elements marked as presentational should be consistently ignored",
"dev_help": "- Passing patterns include:\n - `<li role=\"none\"></li>`\n - `<li role=\"presentation\"></li>`\n- For every element with `role=\"none\"` or `role=\"presentation\"`, ensure it does not have either of the following:\n - Any global ARIA attribute (example failure: `<li role=\"none\" id=\"global-attr\" aria-hidden=\"true\"></li>`)\n - Any focusability:\n - Remove `tabindex` if present (example failure: `<img alt=\"\" id=\"tabindex\" tabindex=\"0\"/>`)\n - Don’t apply presentational roles to natively focusable elements like `<button>` (example failure: `<button id=\"natively-focusable\" role=\"none\"></button>`)\n- If the element must be focusable or needs ARIA, it should not be marked as presentational; remove `role=\"none\"`/`role=\"presentation\"` from that element.",
"help_url": "https://dequeuniversity.com/rules/axe/4.11/presentation-role-conflict?application=axeAPI",
"description": "Ensure elements marked as presentational do not have global ARIA or tabindex so that all screen readers ignore them",
"layman_help": "- Find items that are marked as “presentation / none” (this tells screen readers to ignore them).\n- Make sure those items don’t also:\n - contain extra accessibility notes meant for screen readers, or\n - become reachable by keyboard (for example, you can tab to them)\n- If an item needs to be clickable or reachable by keyboard (like a button), don’t mark it as “ignore this.”\n- If an item is only decorative and should be ignored, remove anything that makes it keyboard-reachable and remove any extra accessibility notes attached to it.",
"passed_title": null,
"dev_description": "Elements with `role=\"none\"` or `role=\"presentation\"` must be consistently ignored by assistive technology.\n\nIf a presentational element also has global ARIA attributes (for example, `aria-hidden`, `aria-label`, etc.) or is focusable (natively focusable elements like `<button>`, or anything made focusable with `tabindex`), screen readers may stop treating it as purely decorative.\n\nUpdate markup so any element using `role=\"none\"`/`role=\"presentation\"` has no global ARIA attributes and is not focusable (remove `tabindex`, or don’t apply the role to focusable controls).",
"layman_description": "Some parts of a page are meant to be ignored by screen readers because they’re only for visual layout. These are marked as “presentational.”\n\nThe problem happens when something is marked “ignore this,” but it also:\n- includes extra accessibility information, or\n- can be reached with the keyboard (gets focus)\n\nThat mix of signals can cause screen readers to treat the item inconsistently, which can confuse people who rely on them.",
"how_to_test": null
},
{
"rule_id": "region",
"standard_code": "best-practice",
"Notes": null,
"issue_severity": "medium",
"wcag_version_number": null,
"wcag_level": null,
"affected_disabilities_json": "Blind | Deaf Blind | Mobility",
"help": "All page content should be contained by landmarks",
"title": "All page content should be contained by landmarks",
"dev_help": "- Put all page content inside a landmark region so screen reader users can navigate by section.\n- Prefer native HTML5 landmarks:\n - Use `<header>` for the banner/header area.\n - Use `<nav>` for site/page navigation.\n - Use `<main>` for primary page content.\n - Use `<footer>` for footer/content info.\n- If you can’t use native elements, use ARIA landmark roles on containers:\n - `role=\"banner\"` (header)\n - `role=\"navigation\"` (nav)\n - `role=\"main\"` (main)\n - `role=\"contentinfo\"` (footer)\n- Example using native elements:\n - `<header>…</header>`\n - `<nav>…</nav>`\n - `<main>…</main>`\n - `<footer>…</footer>`\n- Example using ARIA roles:\n - `<div role=\"banner\">…</div>`\n - `<div role=\"navigation\">…</div>`\n - `<div role=\"main\">…</div>`\n - `<div role=\"contentinfo\">…</div>`\n- Don’t treat landmarks as a full replacement for skip links: they help screen reader users, but sighted users (including magnifier users) may not benefit.",
"help_url": "https://dequeuniversity.com/rules/axe/4.11/region?application=axeAPI",
"description": "Ensure all page content is contained by landmarks",
"layman_help": "- Break the page into clear sections, like:\n - Top area (the header)\n - Menu area (navigation)\n - The main part of the page (main content)\n - Bottom area (the footer)\n- Make sure everything on the page belongs to one of these sections, so nothing is “floating” outside them.\n- This helps screen reader users jump straight to the part they want (like the menu or the main content) instead of reading through everything in order.\n- If your site also provides a “Skip to content” link, keep it—these page sections help some users, but they don’t help everyone in the same way.",
"passed_title": null,
"dev_description": "Ensure all visible page content is contained within a landmark region so assistive technologies can navigate by page sections.\n\nWrap major sections using native HTML5 landmark elements where possible (preferred): `<header>`, `<nav>`, `<main>`, `<footer>`.\n\nIf native elements can’t be used, apply ARIA landmark roles to container elements instead: `role=\"banner\"`, `role=\"navigation\"`, `role=\"main\"`, `role=\"contentinfo\"`.\n\nFix by moving any “orphan” content that sits outside landmarks into the appropriate landmark container, rather than leaving it directly under `<body>` without a landmark wrapper.",
"layman_description": "Some parts of the page aren’t grouped into clear sections like “header,” “navigation,” “main content,” and “footer.”\n\nPeople who use screen readers often jump between these sections to understand and move around a page quickly. When content isn’t inside one of these sections, it can be harder to find, understand where you are, or navigate efficiently.",
"how_to_test": null
},
{
"rule_id": "tabindex",
"standard_code": "best-practice",
"Notes": null,
"issue_severity": "high",
"wcag_version_number": null,
"wcag_level": null,
"affected_disabilities_json": "Blind | Deaf Blind | Mobility",
"help": "Elements should not have tabindex greater than zero",
"title": "Elements should not have tabindex greater than zero",
"dev_help": "- Find elements with `tabindex` values greater than 0 (e.g., `tabindex=\"3\"`).\n- Prefer removing the positive tabindex:\n - Option A: Change to `tabindex=\"0\"` to include the element in the normal tab flow.\n - Option B: Remove `tabindex` and modify the page structure/DOM order so the desired tab order happens naturally.\n - Option C: Set `tabindex=\"-1\"` and use JavaScript to move focus when needed (and only add it back to the tab flow by changing to `0` when appropriate).\n- Use `tabindex=\"0\"` or `tabindex=\"-1\"` primarily for complex interactive widgets; avoid making non-interactive elements (e.g., `<p>`, `<span>`, `<th>`) tabbable unless necessary.\n- Verify the resulting focus order is logical:\n - Tab order should match source (DOM) order.\n - Don’t rely on visual positioning for focus order.\n- Watch for CSS that can visually reorder content and create a mismatch with DOM tab order: `position: absolute`, `position: relative`, `float: left`, `float: right`.",
"help_url": "https://dequeuniversity.com/rules/axe/4.11/tabindex?application=axeAPI",
"description": "Ensure tabindex attribute values are not greater than 0",
"layman_help": "- Check the page using only the Tab key (and Shift+Tab to go back).\n- If the focus jumps around in a strange order, remove the “special tab numbers” (numbers greater than zero) so items are reached in a normal, predictable sequence.\n- If something needs to be reachable by keyboard:\n - Put it in the regular tab order (so Tab goes to it naturally), or\n - Change the page so the keyboard order follows the same order as the content.\n- Sometimes something should not be reached by Tab until the page does something (like opening a dialog). In that case, it can be made focusable only when needed.\n- Re-test after changes and make sure the Tab order makes sense from a user’s point of view, even if the layout uses positioning that moves things around visually.",
"passed_title": null,
"dev_description": "Elements must not use a positive `tabindex` value (e.g., `tabindex=\"1\"`, `tabindex=\"2\"`, etc.). Positive `tabindex` creates a custom keyboard focus order that can conflict with the natural focus order.\n\nUpdate affected elements so their focus behavior follows normal DOM/source order:\n- Change `tabindex` to `0` to keep the element focusable in the normal tab sequence, or\n- Remove the `tabindex` attribute and adjust the markup/DOM order so keyboard users reach elements in the intended order, or\n- Use `tabindex=\"-1\"` only when the element should be focusable programmatically (e.g., via JavaScript) but not reachable by Tab by default.\n\nRemember: keyboard tab order follows DOM/source order (not visual layout). Visual reordering via CSS (e.g., `position`, `float`) can make focus order confusing.",
"layman_description": "Some parts of the page have been set up to use a special keyboard tab order (a number greater than zero). This can make the Tab key jump around in an unexpected way.\n\nWhen someone uses the keyboard to move through the page, the focus should normally move in a clear, predictable order that matches how the page is built. If a custom tab number is used, the keyboard order can become confusing and harder to use—especially if the visual layout doesn’t match the reading order.",
"how_to_test": null
},
{
"rule_id": "table-duplicate-name",
"standard_code": "best-practice",
"Notes": null,
"issue_severity": "low",
"wcag_version_number": null,
"wcag_level": null,
"affected_disabilities_json": "Blind | Deaf Blind",
"help": "Tables should not have the same summary and caption",
"title": "Tables should not have the same summary and caption",
"dev_help": "- Find tables where the `<caption>` text is identical to the table `summary` attribute value.\n- Change one so they are not the same text.\n- Use `<caption>` for the on-screen title of the table.\n- Use the `summary` attribute (read by screen readers) to describe the table structure (how it’s organized), not to repeat the caption.\n- Ensure the `summary` provides additional information beyond the caption when both are present.",
"help_url": "https://dequeuniversity.com/rules/axe/4.11/table-duplicate-name?application=axeAPI",
"description": "Ensure the <caption> element does not contain the same text as the summary attribute",
"layman_help": "- Look at the table’s title shown on the page (the caption).\n- Check whether there’s also a hidden description meant for screen reader users (often called a “summary”).\n- If the title and the hidden description say the exact same thing, change one of them.\n- Keep the on-page title as a short name for the table.\n- Make the hidden description add extra helpful detail about how the table is laid out (for example, what the rows and columns represent) instead of repeating the title.",
"passed_title": null,
"dev_description": "The table’s accessible description is duplicated because the `<caption>` element text matches the table’s `summary` attribute text.\n\nUpdate the HTML so the `<caption>` and `summary` are not identical. Keep the `<caption>` as the on-screen title, and use the `summary` attribute (screen-reader-only) to describe the table’s structure rather than repeating the same wording.",
"layman_description": "The table has two labels/descriptions that say the exact same thing. One is shown on the page (the caption), and the other is meant to help screen reader users (the summary).\n\nWhen both are identical, it can be repetitive and less helpful. The visible title should name the table, and the screen-reader-only description should add extra helpful detail instead of repeating the title.",
"how_to_test": null
},
{
"rule_id": "ibm-applet-alt-exists",
"standard_code": "1.1.1",
"Notes": null,
"issue_severity": "high",
"wcag_version_number": 2.0,
"wcag_level": "A",
"affected_disabilities_json": "[\"blind\", \"lowVision\", \"cognitive\"]",
"help": "Add an `alt` attribute and alternative description to `<applet>` elements",
"title": "<applet> elements must provide an 'alt' attribute and an alternative description",
"dev_help": "- For each `<applet>` element, add an `ALT` attribute that briefly describes the applet’s purpose.\n- Add an alternative description as fallback content inside `<applet>...</applet>` (plain text and/or HTML like `<p>`, `<ul>`, `<ol>`), describing the same information or function.\n- Keep `ALT` concise; put longer details in the inner fallback content.\n\nExample:\n\n```html\n<applet CODE=\"ticker.class\" ALT=\"Stock price ticker\" WIDTH=\"250\" HEIGHT=\"80\">\n Current prices shown in the ticker:\n <ul>\n <li>ACME: $123.45</li>\n <li>XYZ: $67.89</li>\n <li>QRS: $10.11</li>\n </ul>\n</applet>\n```",
"help_url": "https://unpkg.com/accessibility-checker-engine@4.0.13/help/en-US/applet_alt_exists.html",
"description": "Alternative text on `<applet>` elements is important for users who do not have a Java-capable browser or have disabled Java. In addition, providing a text alternative makes the same information accessible through audio or other channels.",
"layman_help": "1. Find the embedded Java applet on the page.\n2. Add a short label that describes what it is (for example: “Interactive sales chart”).\n3. Add a longer written explanation right where the applet appears, describing what the applet does or what information it shows (for example, a short list of the items or results the applet provides).\n\nThis way, if someone’s browser can’t run Java, they can still read the same information, and screen-reading tools can share it through audio.",
"passed_title": "<applet> elements provide an 'alt' attribute and an alternative description",
"dev_description": "Ensure every `<applet>` element includes:\n\n- An `alt` attribute with meaningful alternative text (e.g., `ALT=\"...\"`).\n- A text alternative inside the `<applet>...</applet>` element (inner HTML) that describes what the applet does or what information it presents, so users without Java can access the equivalent information.\n\nUpdate markup by adding the missing `ALT` attribute and/or adding descriptive fallback content between the opening and closing `<applet>` tags.",
"layman_description": "Some people can’t use Java in their browser (it may be unsupported or turned off). When that happens, an embedded Java applet may not show at all.\n\nThis issue occurs when the page doesn’t include a written description for the applet. Without that description, those users miss the same information or function that the applet provides, and it’s also harder for audio tools to explain what’s there.",
"how_to_test": null
},
{
"rule_id": "ibm-aria-activedescendant-valid",
"standard_code": "4.1.2",
"Notes": null,
"issue_severity": "high",
"wcag_version_number": 2.0,
"wcag_level": "A",
"affected_disabilities_json": "[\"blind\", \"lowVision\", \"cognitive\"]",
"help": "The `aria-activedescendant` property must reference the `id` of a non-empty, non-hidden active child element",
"title": "The 'aria-activedescendant' property must reference the 'id' of a non-empty, non-hidden active child element",
"dev_help": "- Find the element that has `aria-activedescendant` (commonly the composite container with `tabindex=\"0\"`).\n- Confirm the `aria-activedescendant` value exactly matches an existing element’s `id`.\n- Confirm the referenced element is the **current active child** (the one your keyboard navigation logic considers active).\n- Confirm the referenced element is **not hidden**:\n - Not `hidden`\n - Not `aria-hidden=\"true\"`\n - Not styled/managed in a way that removes it from the accessibility tree\n- Confirm the referenced element is **not empty** (has meaningful text/content or an accessible name).\n- Confirm relationship to the container:\n - The referenced element is a DOM descendant of the container, **or**\n - The container uses `aria-owns=\"...\"` to include the referenced element.\n\nExample (combobox popup owned via `aria-owns`, with active option identified):\n\n```html\n<label id=\"cb_label\" for=\"cb_input\">Country</label>\n<div id=\"cb\" role=\"combobox\" aria-haspopup=\"listbox\" aria-expanded=\"true\"\n aria-owns=\"country_list\" aria-activedescendant=\"opt_ca\">\n <input id=\"cb_input\" type=\"text\" aria-labelledby=\"cb_label\" />\n</div>\n\n<div id=\"country_list\" role=\"listbox\">\n <div id=\"opt_us\" role=\"option\">United States</div>\n <div id=\"opt_ca\" role=\"option\">Canada</div>\n <div id=\"opt_mx\" role=\"option\">Mexico</div>\n</div>\n```",
"help_url": "https://unpkg.com/accessibility-checker-engine@4.0.13/help/en-US/aria_activedescendant_valid.html",
"description": "In a composite component where the child elements are not normally able to take keyboard focus, the aria-activedescendant attribute can be used to identify the child element that currently has focus. This enables proper keyboard control of the component and allows assistive technologies to gather information about the component and its state.",
"layman_help": "1. Identify the part of the control that receives keyboard focus (often the “outer” container you tab to).\n2. Check what item the control says is currently active (it should point to one specific item inside the control).\n3. Make sure that item actually exists and is the one the user is currently on when using arrow keys.\n4. Make sure the active item is not hidden. If it’s hidden, a screen reader may not be able to announce it.\n5. Make sure the active item isn’t blank (it should have a real label like “Canada,” not an empty entry).\n6. Make sure the active item is truly part of the control—either it’s inside the control, or it’s explicitly connected to it.\n\nIf these don’t match, people using assistive technologies may hear the wrong active choice (or nothing) while navigating.",
"passed_title": "The 'aria-activedescendant' property references the 'id' of a non-empty, non-hidden active child element",
"dev_description": "Elements that use `aria-activedescendant` (often with `tabindex=\"0\"`) must point to a **real, active child** by `id`.\n\n- Ensure `aria-activedescendant=\"someId\"` matches an existing element’s `id=\"someId\"`.\n- Ensure the referenced element is the **currently active** item in the composite widget (e.g., the active `role=\"option\"`, `role=\"radio\"`, etc.).\n- Ensure the referenced element is **not hidden** (e.g., not `hidden`, not `aria-hidden=\"true\"`, not removed from rendering in a way that hides it from assistive tech).\n- Ensure the referenced element is a **descendant** of the container, or is **owned** by it via `aria-owns`.",
"layman_description": "When a group control (like a custom list or set of choices) uses the keyboard, it often keeps focus on the outer box but still needs to tell assistive technologies which item inside is currently “active.”\n\nThis issue happens when the control points to the wrong item (or an item that doesn’t exist), points to something that’s hidden, or points to an item that isn’t actually inside (or connected to) the control. As a result, screen reader users may not be told which choice they’re on while navigating.",
"how_to_test": null
},
{
"rule_id": "ibm-combobox-active-descendant",
"standard_code": "4.1.2",
"Notes": null,
"issue_severity": "high",
"wcag_version_number": 2.0,
"wcag_level": "A",
"affected_disabilities_json": "[\"blind\", \"lowVision\", \"cognitive\"]",
"help": "Use `aria-activedescendant` on the combobox text input to define focus within the popup",
"title": "'aria-activedescendant' must be used to define focus within the combobox popup, except when using a dialog popup",
"dev_help": "- Keep focus on the combobox text field: use an `<input>` (or text input element) with `role=\"combobox\"`.\n- If `aria-haspopup` is **not** `\"dialog\"`:\n - Add/update `aria-activedescendant` **on the `<input>`** to reference the active popup item’s `id`.\n - Ensure the referenced element exists and is in the controlled popup (commonly `role=\"listbox\"` with `role=\"option\"` children).\n - Update `aria-activedescendant` as the user navigates options (e.g., Arrow keys).\n - Pair with `aria-controls` to point to the popup container element.\n- If `aria-haspopup=\"dialog\"`, this rule does not require `aria-activedescendant` for the popup.\n\nExample (listbox popup; active option is referenced from the input):\n\n```html\n<label for=\"fruit_combo\">Fruit</label>\n<input id=\"fruit_combo\" type=\"text\"\n role=\"combobox\" aria-autocomplete=\"list\"\n aria-haspopup=\"listbox\" aria-expanded=\"true\"\n aria-controls=\"fruit_popup\" aria-activedescendant=\"opt_mango\">\n\n<ul id=\"fruit_popup\" role=\"listbox\">\n <li id=\"opt_apple\" role=\"option\">Apple</li>\n <li id=\"opt_mango\" role=\"option\">Mango</li>\n <li id=\"opt_pear\" role=\"option\">Pear</li>\n</ul>\n```\n\n- Avoid placing `aria-activedescendant` on the popup container (`ul/div`) instead of the combobox `<input>`.\n- Avoid moving focus into `<li role=\"option\">…</li>` elements for non-dialog popups; use `aria-activedescendant` to represent the active item.",
"help_url": "https://unpkg.com/accessibility-checker-engine@4.0.13/help/en-US/combobox_active_descendant.html",
"description": "A combobox is an interactive component that combines an input and another element, such as a listbox or grid, that can dynamically pop up to help the user set the value of the input. When a combobox receives focus, the focus should be set on the text `<input>` element. Unless using a dialog popup, the aria-activedescendant must be used to identify the currently focused selection in the popup, so people who use assistive technologies can accurately navigate and interact with the content.",
"layman_help": "- Find the text field that shows a list of suggestions (a common example is an autocomplete search box).\n- Make sure the typing cursor stays in the text field while you move through the suggestions.\n- Make sure assistive technologies are told which suggestion is currently highlighted as you move up/down.\n - In technical terms, the text field should point to the currently highlighted suggestion using something called **“active descendant”** (`aria-activedescendant`).\n- If the suggestions open as a separate dialog (a full popup window), this specific requirement may be handled differently; otherwise, the text field should still be the place that “tracks” which suggestion is active.\n\nHow to confirm it works (non-technical check):\n- Use the arrow keys to move through suggestions.\n- The highlighted suggestion should change.\n- A screen reader should announce the newly highlighted suggestion correctly, without jumping the cursor out of the text field.",
"passed_title": "The combobox uses 'aria-activedescendant' to indicate focus within the popup (or uses a dialog popup)",
"dev_description": "For a combobox (an `<input>` with `role=\"combobox\"` that controls a popup like a `role=\"listbox\"` or `role=\"grid\"`), keyboard/AT focus must remain on the text `<input>`.\n\n- When the popup is **not** a dialog (`aria-haspopup!=\"dialog\"`), the currently \"focused\" item **inside the popup** must be indicated by setting `aria-activedescendant` **on the combobox `<input>`**.\n- Ensure `aria-activedescendant` points to the `id` of the active popup item (e.g., an element with `role=\"option\"` / a grid cell).\n- Do not move DOM focus into the popup options; update the `aria-activedescendant` value as the active option changes.",
"layman_description": "When you type in a field that shows suggestions (like a dropdown list of matches), the cursor should stay in the text box.\n\nIf the suggestions open, the website also needs to clearly tell screen readers which suggestion is currently selected as you move through the list. If it doesn’t, people using assistive technology may hear the wrong item, get lost in the list, or be unable to choose the option they want.",
"how_to_test": null
},
{
"rule_id": "ibm-combobox-autocomplete-valid",
"standard_code": "4.1.2",
"Notes": null,
"issue_severity": "high",
"wcag_version_number": 2.0,
"wcag_level": "A",
"affected_disabilities_json": "[\"blind\", \"lowVision\", \"cognitive\"]",
"help": "Set `aria-autocomplete` only on the combobox text input element with a valid value",
"title": "A combobox that supports autocompletion behavior must have the 'aria-autocomplete' attribute only on its text input element with a valid value; a value of '\"inline\"' is not supported",
"dev_help": "- Remove `aria-autocomplete` from any **popup** element (for example: `role=\"listbox\"`, `role=\"menu\"`, or the popup container). Only the **editable text input** should have it.\n- Ensure the combobox’s editable element is the one with `role=\"combobox\"` and `aria-autocomplete` (commonly `<input type=\"text\" role=\"combobox\">`).\n- Choose a valid value based on behavior:\n - No autocomplete: omit `aria-autocomplete` (defaults to `none`).\n - Popup suggestions only: `aria-autocomplete=\"list\"`.\n - Inline completion + popup suggestions: `aria-autocomplete=\"both\"`.\n - Inline completion with **no popup**: do **not** use `role=\"combobox\"`; switch to `role=\"searchbox\"` or `role=\"textbox\"`, and then `aria-autocomplete=\"inline\"` is appropriate.\n- Do not set `aria-autocomplete=\"inline\"` on a combobox.\n- Do not dynamically change `aria-autocomplete` to indicate a suggestion exists.\n- When using `aria-autocomplete=\"list\"` or `aria-autocomplete=\"both\"`, toggle `aria-expanded=\"true|false\"` to reflect whether the popup suggestion collection is currently shown.",
"help_url": "https://unpkg.com/accessibility-checker-engine@4.0.13/help/en-US/combobox_autocomplete_valid.html",
"description": "Assistive technologies can present different types of comboboxes to their users according to their intended behavior. A combobox is usually an interactive component that combines an input and another element, such as a listbox that can dynamically pop up to help the user select a value (allowed or suggested) from a collection of possible values. Some comboboxes allow users to type and edit text and others do not.\n\nOnly the text input element can have the aria-autocomplete attribute, otherwise, assistive technologies may be unable to understand and present the component's autocomplete functionality effectively.\n\nThe inline model (aria-autocomplete=\"inline\") is used to present a value completion prediction string inside the text input, appearing inline after the user's input cursor. However, \"inline\" should not be used alone on a combobox because the assistive technologies and users are expecting a popup. A combobox can and often supports both inline forms of autocomplete in combination with having a popup element. Authors can use aria-autocomplete=\"both\". The inline completion string is visually highlighted and has a selected state.\n\nThe aria-autocomplete property is not intended to indicate the presence of a completion suggestion, and authors should not dynamically change its value in order to communicate the presence of a suggestion. When a text entry element has aria-autocomplete set to \"list\" or \"both\", authors should use the aria-expanded state to communicate whether the element that presents the suggestion collection is displayed.",
"layman_help": "1. Find the part the user types into (the text field). This is the only place the “autocomplete” setting should be applied.\n2. Check the suggestions panel/list that opens (the dropdown/popup). Remove the autocomplete setting from that panel/list if it’s there.\n3. Make sure the autocomplete mode matches what the control actually does:\n - If it does *not* suggest anything while typing, turn autocomplete off (use the default behavior).\n - If it shows a list of suggestions, use the mode that means “shows a list.”\n - If it both shows a list *and* completes text in the field while you type, use the mode that means “both.”\n - If it only completes text *inside the field* and there is no dropdown list, it should not be treated as a “combo box”; it should be treated as a normal text/search field.\n4. Don’t switch the autocomplete mode on and off while the person is typing to indicate whether suggestions exist. Instead, indicate whether the suggestions list is open or closed.",
"passed_title": "Combobox autocomplete is set only on the text input and uses a supported value",
"dev_description": "A combobox that supports autocompletion must follow these rules for `aria-autocomplete`:\n\n- **Only the text input element** (typically an `<input type=\"text\">` or editable element with `role=\"combobox\"`) may have `aria-autocomplete`.\n- **Do not place `aria-autocomplete` on the popup element** (for example, an element with `role=\"listbox\"`, `role=\"menu\"`, or other popup container).\n- `aria-autocomplete=\"inline\"` **must not be used on a combobox** (users/AT expect a popup for a combobox). If you need inline completion, use `aria-autocomplete=\"both\"` with a popup, or change the role to `searchbox`/`textbox` when there is no popup.\n\nIncorrect placement or an unsupported value can prevent assistive technologies from understanding and announcing the component’s autocomplete behavior.",
"layman_description": "This check looks at a “combo box” (a field you can type in that can also show a list of suggestions).\n\nThe problem happens when the setting that describes *how suggestions work* is put on the wrong part of the control, or is set to a mode that doesn’t fit a combo box.\n\nIf this setting is wrong, screen readers and other assistive tools may not understand whether suggestions will appear, where they appear, or how the control behaves. That can make it harder for someone using assistive technology to enter a value accurately.",
"how_to_test": null
},
{
"rule_id": "ibm-combobox-haspopup-valid",
"standard_code": "4.1.2",
"Notes": null,
"issue_severity": "high",
"wcag_version_number": 2.0,
"wcag_level": "A",
"affected_disabilities_json": "[\"blind\", \"lowVision\", \"cognitive\"]",
"help": "The combobox `aria-haspopup` value must match the role of its popup element",
"title": "The combobox attribute 'aria-haspopup' value must be appropriate for the role of the element referenced by 'aria-controls' (ARIA 1.2) or 'aria-owns' (ARIA 1.0)",
"dev_help": "- Find the element with `role=\"combobox\"`.\n- Identify the popup element it controls:\n - ARIA 1.2: follow `aria-controls=\"...\"` to the element with that `id`.\n - ARIA 1.0: follow `aria-owns=\"...\"` to the referenced element.\n- Check the popup element’s `role`.\n- Set the combobox’s `aria-haspopup` to the same value as the popup’s role.\n- Only these popup roles are valid for a combobox: `listbox`, `tree`, `grid`, `dialog`.\n- If needed, change the popup element’s `role` to one of the allowed roles (and keep it consistent with the widget you implemented).",
"help_url": "https://unpkg.com/accessibility-checker-engine@4.0.13/help/en-US/combobox_haspopup_valid.html",
"description": "An element with role=\"combobox\" may have a popup element with the role of \"listbox\", \"tree\", \"grid\", or \"dialog\". If the value for the aria-haspopup attribute does not match the value for the popup element's role attribute, people who use assistive technologies may see unexpected behavior and will not know how to interact with the content.",
"layman_help": "1. Find the field that lets someone type and also opens a set of choices.\n2. Check what kind of chooser opens:\n - a simple list of options,\n - a tree (choices with levels),\n - a grid (table-like chooser), or\n - a dialog (a separate pop-up window).\n3. Make sure the field’s “popup type” setting matches what actually opens.\n4. If they don’t match, update the setting so it correctly describes the popup.\n\nWhy this helps: screen readers rely on that “popup type” to tell users what opened and how to navigate it. When it’s accurate, users can interact with the choices more predictably.",
"passed_title": "The combobox aria-haspopup value matches the role of its popup element",
"dev_description": "A `role=\"combobox\"` must have an `aria-haspopup` value that matches the **actual `role` of its popup element**.\n\n- The popup is the element referenced by `aria-controls` (ARIA 1.2) or `aria-owns` (ARIA 1.0).\n- If `aria-haspopup` and the popup’s `role` don’t match, assistive technologies may announce the wrong type of popup and users may get unexpected interaction behavior.\n- Allowed popup roles: `listbox`, `tree`, `grid`, or `dialog`.\n\nChange either:\n- the combobox’s `aria-haspopup` value, **or**\n- the popup element’s `role`,\nso they match.",
"layman_description": "This input says it will open one kind of popup (like a list of choices), but the popup it actually opens is a different kind.\n\nWhen those don’t match, screen reader users can be told the wrong thing about what opened (for example, being told a “dialog” opened when it’s really a simple list). That makes it confusing to know how to move through the choices and select one.",
"how_to_test": null
},
{
"rule_id": "ibm-aria-eventhandler-role-valid",
"standard_code": "4.1.2",
"Notes": null,
"issue_severity": "critical",
"wcag_version_number": 2.0,
"wcag_level": "A",
"affected_disabilities_json": "[\"blind\", \"lowVision\", \"mobility\", \"cognitive\"]",
"help": "Elements with event handlers must have a valid ARIA role",
"title": "Elements with event handlers must have a valid ARIA role",
"dev_help": "- If the control should be a native HTML element, use the correct tag so the implicit role matches the behavior (e.g., use `<button>` for an action, `<a href=\"...\">` for navigation, `<input type=\"checkbox\">` for a checked/unchecked control).\n- If an element is missing the attribute that gives it its implicit role, add it (e.g., add `href` to `<a>` when it is meant to be a link).\n- If you must use a non-semantic element (like `<div>`/`<span>`) with event handlers, add a **valid** `role` that reflects the behavior (e.g., `role=\"button\"`, `role=\"link\"`, `role=\"switch\"`).\n- Verify the `role` value is a valid ARIA role (not a made-up role name) and matches what the control actually does.",
"help_url": "https://unpkg.com/accessibility-checker-engine@4.0.13/help/en-US/aria_eventhandler_role_valid.html",
"description": "When UI elements are programmed with scripting to receive focus and be interactive, setting a valid role attribute or using an element with an implicit role allows assistive technologies to provide information about and manage an interactive element appropriately, including providing keyboard operability.",
"layman_help": "- Find the page parts that act like controls (for example, items that you can click or that respond when you press keys).\n- Make sure each of those controls is clearly identified as what it is (a button, link, checkbox, switch, etc.), not just “some text” or “a generic box.”\n- The best fix is usually to build the control using the right built-in page element for the job (a real button for actions, a real link for going to another page).\n- If a custom-made control must be used, ensure it is labeled so assistive tools can recognize what kind of control it is and treat it correctly.\n- Re-check with a screen reader or keyboard-only use to confirm the control is announced as the right type and can be operated.",
"passed_title": "Elements with event handlers have a valid ARIA role",
"dev_description": "Interactive elements that can receive focus or respond to events (for example via `onclick`, `onkeydown`, or similar handlers) must expose a **valid accessible role** so assistive technologies can identify and operate them.\n\n- Prefer native elements with implicit roles (e.g., `<button>`, `<input>`, `<select>`, `<textarea>`, `<a href=\"...\">`).\n- If you use a non-semantic element (e.g., `<div>`, `<span>`) as an interactive control, add a valid `role` value that matches the behavior.\n- Ensure any element that should have an implicit role actually has the required attributes (e.g., `<a>` needs `href` to be a link).",
"layman_description": "Some parts of a page act like controls (things you can click, tap, or use with the keyboard). If those controls aren’t marked clearly, screen readers and other assistive tools may not recognize what they are or how to use them.\n\nThis issue happens when something behaves like a button, link, or switch, but isn’t identified as one. People who rely on assistive technology may not be told it’s interactive, may not know what it does, or may not be able to use it properly from the keyboard.",
"how_to_test": null
},
{
"rule_id": "ibm-combobox-design-valid",
"standard_code": "4.1.2",
"Notes": null,
"issue_severity": "high",
"wcag_version_number": 2.0,
"wcag_level": "A",
"affected_disabilities_json": "[\"blind\", \"lowVision\", \"cognitive\"]",
"help": "Implement the combobox using the ARIA 1.2 design pattern",
"title": "The combobox design pattern must be valid for ARIA 1.2",
"dev_help": "- Follow the ARIA Authoring Practices Guide **Combobox Pattern** (ARIA 1.2).\n- Ensure the text entry element is **single-line**: use `<input type=\"text\">` (or equivalent) as the editable field; do **not** use `<textarea>` for the combobox text field.\n- Ensure the combobox is made of two parts: the **text input** and a **popup** (e.g., a list of options) that helps set the input’s value.\n- Wire the input to the popup as shown in the APG pattern (e.g., manage `aria-expanded` and reference the popup with `aria-controls`), so assistive technologies can understand the relationship.\n- Avoid relying on the older ARIA 1.1 combobox approach; prefer the ARIA 1.2 pattern for better browser/AT support.",
"help_url": "https://unpkg.com/accessibility-checker-engine@4.0.13/help/en-US/combobox_design_valid.html",
"description": "A combobox combines a text input element and a popup element that helps the user set the value of the input. The text input element must be a single line text field with an appropriate role, otherwise assistive technologies may not be able to present and control the content correctly.\n\nThe ARIA 1.1 combobox pattern was not supported by browsers. The ARIA 1.2 pattern is best supported by browsers and assistive technologies.",
"layman_help": "1. Check that the “type here” part is a normal one-line text box (the kind used for names, search, or email), not a big multi-line box.\n2. Make sure the pop-up list of suggestions is clearly tied to that text box, so when the list opens and closes, assistive tools can tell what happened.\n3. If the control was built using an older method that doesn’t work well in many browsers, update it to the current recommended combobox design used in accessibility guidelines.\n4. After updating, test with a keyboard (Tab, arrow keys, Enter/Escape) and a screen reader to confirm the typing area and the suggestion list are both announced and usable.",
"passed_title": "The combobox design pattern is valid for ARIA 1.2",
"dev_description": "A combobox must follow the **ARIA 1.2 combobox pattern**: it combines a **single-line text input** with a **popup** that helps set the input value. The combobox’s text field must be an actual single-line text field (e.g., `<input type=\"text\">` or an equivalent single-line text input role). If the “text input” is not single-line (for example, a `<textarea>` or another non-text-field element), assistive technologies may not be able to present or control the content correctly.\n\nUpdate the markup to match the ARIA Practices **Combobox Pattern** (ARIA 1.2), since the older ARIA 1.1 pattern was not supported well by browsers.",
"layman_description": "This control is supposed to be a text box with a helpful pop-up list of choices (like suggested matches while you type). For it to work with screen readers and other assistive tools, the typing area must be a normal **single-line** text box. If it’s built in a different way (for example, like a multi-line comments box or a custom box), assistive tools may not announce it properly or let someone control it reliably.\n\nUsing the newer, widely supported design for this kind of control helps more people use it successfully.",
"how_to_test": null
},
{
"rule_id": "ibm-table-aria-descendants",
"standard_code": "4.1.2",
"Notes": null,
"issue_severity": "high",
"wcag_version_number": 2.0,
"wcag_level": "A",
"affected_disabilities_json": "[\"blind\", \"lowVision\", \"mobility\", \"cognitive\"]",
"help": "Do not specify an explicit `role` on table structure elements within table containers",
"title": "Table structure elements cannot specify an explicit 'role' within table containers",
"dev_help": "- Find containers that use `role=\"table\"`, `role=\"grid\"`, or `role=\"treegrid\"`.\n- Within those containers, inspect all `<tr>`, `<th>`, and `<td>` elements.\n- Remove `role=\"...\"` from `<tr>`, `<th>`, and `<td>` (do not replace it with another role).\n- Keep the native table markup for structure (`<table>`, `<thead>`, `<tbody>`, `<tr>`, `<th>`, `<td>`).\n- Example (correct pattern: role on the table container, no roles on table structure elements):\n\n```html\n<div id=\"inventoryCaption\">Inventory</div>\n<table role=\"grid\" aria-labelledby=\"inventoryCaption\">\n <thead>\n <tr>\n <th>Item</th>\n <th>Qty</th>\n </tr>\n </thead>\n <tbody>\n <tr>\n <td>Pens</td>\n <td>120</td>\n </tr>\n </tbody>\n</table>\n```",
"help_url": "https://unpkg.com/accessibility-checker-engine@4.0.13/help/en-US/table_aria_descendants.html",
"description": "The ARIA specification provides a set of accessibility roles as the main indicator of control's type. These roles support platform accessibility APIs. By assigning a valid ARIA role on an element, as defined in the ARIA specification, assistive technologies leverage the role's semantics to provide consistent object interaction and presentation.",
"layman_help": "1. Identify the table-like section on the page (it may be a table used for an interactive list, like a grid).\n2. Check the individual table parts: each row, header cell, and data cell.\n3. Make sure those parts don’t have extra “type labels” attached to them (these labels are often called a “role”).\n4. Keep the table’s normal structure the same; just remove the extra labels from the row and cell pieces.\n\nWhy this helps: screen readers already know what table rows and cells are. Removing the extra labels prevents confusing or conflicting information and makes the table easier to read and navigate.",
"passed_title": "Table structure elements do not specify an explicit 'role' within table containers",
"dev_description": "Within a container that declares `role=\"table\"`, `role=\"grid\"`, or `role=\"treegrid\"`, table structure elements **must not** specify an explicit `role`.\n\n- Affected elements: `<tr>`, `<th>`, `<td>`\n- Affected attribute: `role`\n- Required change: **remove** `role` from these elements when they are descendants of a table/grid/treegrid role container (keep the container role as-is).\n\nThese roles are the primary indicator used by accessibility APIs; overriding roles on row/cell/header elements inside a table-like container can create incorrect semantics for assistive technologies.",
"layman_description": "Some parts of a table (rows, headers, and cells) are already understood by screen readers as “table parts.”\n\nIf those table parts are given extra labels that change what they are (special “roles”) while they’re inside a table-like area, screen readers can get mixed signals. That can make the table harder to navigate or understand.\n\nThis issue happens when rows, header cells, or data cells are given an explicit role even though the table area already defines how the content should behave.",
"how_to_test": null
},
{
"rule_id": "ibm-svg-graphics-labelled",
"standard_code": "1.1.1",
"Notes": null,
"issue_severity": "high",
"wcag_version_number": 2.0,
"wcag_level": "A",
"affected_disabilities_json": "[\"blind\", \"lowVision\", \"cognitive\"]",
"help": "Provide an accessible name for non-decorative SVG elements",
"title": "A non-decorative SVG element must have an accessible name",
"dev_help": "- If the SVG is **informative** (not decorative), ensure it has a **non-empty accessible name**.\n- Prefer a **visible label** and connect it with `aria-labelledby`:\n - Add an `id` to the visible label text.\n - Add `aria-labelledby=\"that-id\"` to the `<svg>` (or the relevant SVG graphics element).\n- If there is no visible label, add `aria-label=\"Meaningful name\"` to the `<svg>`.\n- Alternatively, add a direct child `<title>Meaningful name ` inside the ``.\n- If the SVG is a link, you may use `xlink:title` on the link (only if applicable to your SVG/link implementation).\n- For SVG text container elements, ensure the **text content** is present so it can be used as the text alternative.\n- Use the HTML `title` attribute only when a visible label is not possible.\n\n- If a description is needed (extra detail beyond the name), provide a **non-empty accessible description** in this priority:\n - `aria-describedby` pointing to visible descriptive text\n - a direct child `` element\n - text content for text container elements\n - a `` used as a tooltip *only when* ARIA label attributes provide the name\n - `xlink:title` on a link if it was not used for the name\n\n- If the SVG is **decorative**, make that explicit:\n - `aria-hidden=\"true\"`, or\n - `role=\"none\"` / `role=\"presentation\"`.",
"help_url": "https://unpkg.com/accessibility-checker-engine@4.0.13/help/en-US/svg_graphics_labelled.html",
"description": "An SVG component with a graphics role can contain essential information as well as multiple shapes. When viewed together, these elements give the impression of a single image. Providing a text alternative (accessible name and description) makes the equivalent information available through assistive technologies. With the explicit use of roles and attributes, the author provides a clear indication that the content should convey meaning via the accessibility name and description to assistive technology users.",
"layman_help": "- Decide whether the SVG image is giving important information:\n - If it’s **important** (like a chart, an icon that indicates status, or anything you need to understand the page), it needs a clear text label.\n - If it’s **just decoration** (it doesn’t add meaning), it should be hidden from screen readers so it doesn’t distract.\n\n- For important SVGs, add a short label that describes what it is (for example, “Sales chart” or “Search icon”).\n - Best option: use nearby visible text as the label and connect the SVG to that text.\n - If you can’t add visible text, provide an invisible label so screen readers still announce something meaningful.\n\n- If the SVG needs extra explanation (for example, what a chart shows), add a longer description in addition to the short label.\n - Best option: write that explanation as normal visible text near the SVG and connect it as the description.\n\n- For decorative SVGs, mark them so assistive technologies ignore them (this prevents unnecessary announcements like “graphic” that don’t help the user).",
"passed_title": "The non-decorative SVG element has an accessible name",
"dev_description": "A non-decorative `<svg>` that conveys meaning (typically with a graphics role such as `role=\"graphics-document\"`, `role=\"graphics-object\"`, or `role=\"graphics-symbol\"`) must expose a non-empty accessible name.\n\nProvide the name via one of these mechanisms:\n- `aria-labelledby` referencing on-page text (preferred when a visible label exists)\n- `aria-label`\n- a direct child `<title>` element inside the `<svg>` (or inside the relevant graphics element)\n- `xlink:title` on an SVG link element (when applicable)\n- text content for text-container SVG elements\n- `title` attribute only when a visible label cannot be used\n\nIf the SVG is decorative/redundant, mark it as such using `aria-hidden=\"true\"` or `role=\"none\"` / `role=\"presentation\"` so it is ignored by assistive technologies.",
"layman_description": "If an SVG image is meant to communicate information (not just decoration), it needs a clear text label that assistive technologies can read. Without that label, people using screen readers may only hear “graphic” or nothing at all and miss the meaning.\n\nIf the SVG is only decorative and doesn’t add information, it should be hidden from assistive technologies so it doesn’t create extra noise.",
"how_to_test": null
}
]