angus/WCAG
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Initial commit

Browse Source
This commit is contained in:
Angus Kola
2025-12-22 00:21:10 -05:00
commit 2bd947dfe5
91 changed files with 3819 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
4-robust/4.1.1-parsing.md
+30
View File
@@ -0,0 +1,30 @@
[Back to 4 Robust index](index.md)
# 4.1.1 Parsing
- Level: A
- Guideline: 4.1 Compatible
- Principle: 4 Robust
## What it is
In content implemented using markup languages, elements have complete start and end tags, elements are nested according to their specifications, elements do not contain duplicate attributes, and any IDs are unique, except where the specifications allow these features.
## How to test
- Check: In content implemented using markup languages, elements have complete start and end tags, elements are nested according to their specifications, elements do not contain duplicate attributes, and any IDs are unique, except where the specifications allow these features.
- Validate representative pages with the W3C Markup Validation Service: https://validator.w3.org/.
## Notes
- Note 1: This success criterion should be considered as always satisfied for any content using HTML or XML.
- Note 2: Since this criterion was written, the HTML Living Standard has adopted specific requirements governing how user agents must handle incomplete tags, incorrect element nesting, duplicate attributes, and non-unique IDs. [HTML] Although the HTML standard treats some of these cases as non-conforming for authors, it is considered to "allow these features" for the purposes of this success criterion because the specification requires that user agents support handling these cases consistently. In practice, this criterion no longer provides any benefit to people with disabilities in itself. Issues such as missing roles due to inappropriately nested elements or incorrect states or names due to a duplicate ID are covered by different success criteria and should be reported under those criteria rather than as issues with 4.1.1.
- Deprecated/obsolete in WCAG 2.2; retained for backward compatibility. See Understanding 4.1.1 for details.
## Resources
- WCAG 2.2 SC: https://www.w3.org/TR/WCAG22/#parsing
- Understanding: https://www.w3.org/WAI/WCAG22/Understanding/parsing.html
- Quick reference: https://www.w3.org/WAI/WCAG22/quickref/?versions=2.2#parsing
[Back to 4 Robust index](index.md)
4-robust/4.1.2-name-role-value.md
+58
View File
@@ -0,0 +1,58 @@
[Back to 4 Robust index](index.md)
# 4.1.2 Name, Role, Value
- Level: A
- Guideline: 4.1 Compatible
- Principle: 4 Robust
## What it is
For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies.
## How to test
- Check: For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies.
- Use the sufficient techniques below as acceptable methods when applicable.
- Confirm none of the common failures apply.
## Sufficient techniques (W3C)
- ARIA14: Using aria-label to provide an invisible label where a visible label cannot be used
- ARIA16: Using aria-labelledby to provide a name for user interface controls
- G108: Using markup features to expose the name and role, allow user-settable properties to be directly set, and provide notification of changes
- H91: Using HTML form controls and links
- H44: Using label elements to associate text labels with form controls
- H64: Using the title attribute of the iframe element
- H65: Using the title attribute to identify form controls when the label element cannot be used
- H88: Using HTML according to spec
- G135: Using the accessibility API features of a technology to expose names and roles, to allow user-settable properties to be directly set, and to provide notification of changes
- PDF10: Providing labels for interactive form controls in PDF documents
- PDF12: Providing name, role, value information for form fields in PDF documents
- G10: Creating components using a technology that supports the accessibility API features of the platforms on which the user agents will be run to expose the names and roles, allow user-settable properties to be directly set, and provide notification of changes
- ARIA4: Using a WAI-ARIA role to expose the role of a user interface component
- ARIA5: Using WAI-ARIA state and property attributes to expose the state of a user interface component
## Common failures (W3C)
- F59: Failure of Success Criterion 4.1.2 due to using script to make div or span a user interface control in HTML without providing a role for the control
- F15: Failure of Success Criterion 4.1.2 due to implementing custom controls that do not use an accessibility API for the technology, or do so incompletely
- F20: Failure of Success Criterion 1.1.1 and 4.1.2 due to not updating text alternatives when changes to non-text content occur
- F42: Failure of Success Criteria 1.3.1, 2.1.1, 2.1.3, or 4.1.2 when emulating links
- F68: Failure of Success Criterion 4.1.2 due to a user interface control not having a programmatically determined name
- F79: Failure of Success Criterion 4.1.2 due to the focus state of a user interface component not being programmatically determinable or no notification of change of focus state available
- F86: Failure of Success Criterion 4.1.2 due to not providing names for each part of a multi-part form field, such as a US telephone number
- F89: Failure of Success Criteria 2.4.4, 2.4.9 and 4.1.2 due to not providing an accessible name for an image which is the only content in a link
- F111: Failure of Success Criteria 1.3.1, 2.5.3, and 4.1.2 due to a control with visible label text but no accessible name
## Notes
- Note: This success criterion is primarily for web authors who develop or script their own user interface components. For example, standard HTML controls already meet this success criterion when used according to specification.
## Resources
- WCAG 2.2 SC: https://www.w3.org/TR/WCAG22/#name-role-value
- Understanding: https://www.w3.org/WAI/WCAG22/Understanding/name-role-value.html
- Quick reference: https://www.w3.org/WAI/WCAG22/quickref/?versions=2.2#name-role-value
[Back to 4 Robust index](index.md)
4-robust/4.1.3-status-messages.md
+53
View File
@@ -0,0 +1,53 @@
[Back to 4 Robust index](index.md)
# 4.1.3 Status Messages
- Level: AA
- Guideline: 4.1 Compatible
- Principle: 4 Robust
## What it is
In content implemented using markup languages, status messages can be programmatically determined through role or properties such that they can be presented to the user by assistive technologies without receiving focus.
## How to test
- Check: In content implemented using markup languages, status messages can be programmatically determined through role or properties such that they can be presented to the user by assistive technologies without receiving focus.
- Use the sufficient techniques below as acceptable methods when applicable.
- Confirm none of the common failures apply.
## Sufficient techniques (W3C)
- ARIA22: Using role=status to present status messages
- G199: Providing success feedback when data is submitted successfully
- ARIA19: Using ARIA role=alert or Live Regions to Identify Errors
- G83: Providing text descriptions to identify required fields that were not completed
- G84: Providing a text description when the user provides information that is not in the list of allowed values
- G85: Providing a text description when user input falls outside the required format or values
- G177: Providing suggested correction text
- G194: Providing spell checking and suggestions for text input
- ARIA23: Using role=log to identify sequential information updates
- Using role="progressbar" (future link)
- G193: Providing help by an assistant in the web page
## Advisory techniques (W3C)
- Using aria-live regions with chat clients (future link)
- Using aria-live regions to support 1.4.13 Content on Hover or Focus (future link)
- Using role="marquee" (future link)
- Using role="timer" (future link)
- ARIA18: Using aria-alertdialog to Identify Errors
- SCR14: Using scripts to make nonessential alerts optional
## Common failures (W3C)
- F103: Failure of Success Criterion 4.1.3 due to providing status messages that cannot be programmatically determined through role or properties
- Using role="alert" or aria-live="assertive" on content which is not important and time-sensitive (future link)
## Resources
- WCAG 2.2 SC: https://www.w3.org/TR/WCAG22/#status-messages
- Understanding: https://www.w3.org/WAI/WCAG22/Understanding/status-messages.html
- Quick reference: https://www.w3.org/WAI/WCAG22/quickref/?versions=2.2#status-messages
[Back to 4 Robust index](index.md)
4-robust/index.md
+13
View File
@@ -0,0 +1,13 @@
# 4 Robust
Content must be robust enough that it can be interpreted by a wide variety of user agents, including assistive technologies.
## Guidelines
### 4.1 Compatible
Maximize compatibility with current and future user agents, including assistive technologies.
- [4.1.1 Parsing](4.1.1-parsing.md) — In content implemented using markup languages, elements have complete start and end tags, elements are nested according to their specifications, elements do not contain duplicate attributes, and any IDs are unique, except where the specifications allow these features. (Level A)
- [4.1.2 Name, Role, Value](4.1.2-name-role-value.md) — For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies. (Level A)
- [4.1.3 Status Messages](4.1.3-status-messages.md) — In content implemented using markup languages, status messages can be programmatically determined through role or properties such that they can be presented to the user by assistive technologies without receiving focus. (Level AA)