WCAG 2.2 Robust Flashcards
How is content made compatible with the current and future user tools?
Robust content is compatible with different browsers, assistive technologies, and other user agents. Examples of how this can be achieved include:
- Ensuring markup can be reliably interpreted, for instance by ensuring it is valid
- Providing a name, role, and value for non-standard user interface components
Meeting this requirement helps maximize compatibility with current and future user agents, including assistive technologies. In particular, it enables assistive technologies to process the content reliably, and to present or to operate it in different ways. This includes non-standard (scripted) buttons, input fields, and other controls.
What are examples of compatibility?
Examples of compatible include:
Ensuring markup can be reliably interpreted, for instance by ensuring it is valid
Providing a name, role, and value for non-standard user interface components
What is meant by Robust?
Content must be robust enough that it can be interpreted by a wide variety of user agents, including assistive technologies.
Guideline 4.1
Guideline 4.1 Maximize compatibility with current and future user agents, including assistive technologies.
SC 4.1.1 Parsing (This has been deprecated)
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.
Note 1: This criterion has been removed from WCAG 2.2. In WCAG 2.1 and 2.0 this Success Criterion should be considered as always satisfied for any content using HTML or XML.
SC 4.1.2 Name, Role, Value - Level A
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.
Note 1: 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.
SC 4.1.3- Status Messages- Level AA(- Added in 2.1)
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.
Adding WAI-ARIA will change the way your website appears on a device screen.
False
WAI-ARIA only adds semantical meaning to your code. It will only change the way the website appears if you add styling code to your website to appear in the desired way.
Which of the following assistive technology devices can benefit from robust code? (Check all that apply.)
- screen readers
- speech recognition software
- braille output devices
- screen magnifiers
-keyboards
All of the above; We can all benefit from robust code.
Robust means your content is compatible with different browsers, assistive technologies, and other user agents. (True or False)
True
It is important to test your websites and apps for robustness.
When you implement non-standard HTML user components, you need to refer to W3C Accessibility Standards such as: (Check all that apply.)
WAI-ARIA
WAI-ARIA is your go-to resource for non-standard HTML user components.
WAI-ARIA defines additional accessibility requirements for people with disabilities. (true or false)
False
WAI-ARIA only adds semantical meaning to your code, to help meet accessibility requirements for people with disabilities.
WCAG Quick Reference Guide includes which of the following? (Check all that apply.)
- all of the WCAG guidelines
- all of the success criteria
- techniques for authors
- techniques for designers
- techniques for developers
We can all benefit from the WCAG Quick Reference Guide.
