4 - Robust Flashcards
What is Robust?
Content must be robust enough that it can be interpreted by a wide variety of user agents, including assistive technologies.
4.1.1 Parsing
What? to ensure that user agents, including assistive technologies, can accurately interpret and parse content.
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.
Problem: Some user agents use “repair techniques” to render poorly coded content.
How? Validate web pages, conform to specs, use HTML per spec, H74: Ensuring that opening and closing tags are used according to specification AND H93: Ensuring that id attributes are unique on a Web page AND H94: Ensuring that elements do not contain duplicate attributes, H75: Ensuring that Web pages are well-formed
FAILURES: due to incorrect use of start and end tags or attribute markup, due to duplicate values of type ID
4.1.2 Name, Role, Value
A
What? 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.
standard HTML controls already meet this success criterion when used according to specification.
ensure that Assistive Technologies (AT) can gather information about, activate(or set) and keep up to date on the status of user interface controls in the content.
If custom controls are created, however, or interface elements are programmed (in code or script) to have a different role and/or function than usual, then additional measures need to be taken to ensure that the controls provide important information to assistive technologies and allow themselves to be controlled by assistive technologies.
How?
Standard components in markup: Use aria-label where a visible label cannot be used, Using aria-labelledby to provide a name for user interface controls,
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 frame and iframe elements
H65: Using the title attribute to identify form controls when the label element cannot be used
H88: Using HTML according to spec
Script or code to re-purpose a standard user interface component: Using aria-labelledby to provide a name for user interface controls
If using a standard user interface component in a programming technology: Using the accessibility API features of a technology to expose names and notification of changes
If creating your own user interface component in a programming language:
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
ARIA16: Using aria-labelledby to provide a name for user interface controls
4.1.2 Name, Role, Value
Failures:
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
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
4.1.3 Status Messages
AA
What? 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.
make users aware of important changes in content that are not given focus, and to do so in a way that doesn’t unnecessarily interrupt their work.
What is a status message?
1. the message provides information to the user on the success or results of an action, on the waiting state of an application, on the progress of a process, or on the existence of errors;
2. the message is not delivered via a change in context.
Search results are not status messages but “Searching…” is (if it does not take focus)
This Success Criterion specifically addresses scenarios where new content is added to the page without changing the user’s context.
Changes of context, by their nature, interrupt the user by taking focus.
How?- see another card
4.1.3 Status Messages (Examples)
This Success Criterion was intentionally worded to apply primarily when visible text is added to (or becomes visible on) the page. The reason for this is that where new text is displayed, it is intended to be visible to all users.
Status Message Examples
After a user presses a Search button, the page content is updated to include the results of the search, which are displayed in a section below the Search button. The change to content also includes the message “5 results returned” near the top of this new content. This text is given an appropriate role for a status message. A screen reader announces, “Five results returned”.
After a user presses an Add to Shopping Cart button, a section of content near the Shopping Cart icon adds the text “5 items”. A screen reader announces “Five items” or “Shopping cart, five items”.
After a user enters incorrect text in an input called Postal Code, a message appears above the input reading “Invalid entry”. The screen reader announces, “Invalid entry” or “Postal code, invalid entry”.
After a user activates a process, an icon symbolizing ‘busy’ appears on the screen. The screen reader announces “application busy”.
An application displays a progressbar to indicate the status of an upgrade. The element is assigned a suitable role. The screen reader provides intermittent announcements of the progress.
After a user submits a form, text is added to the existing form which reads, “Your form was successfully submitted.” The screen reader announces the same message.
After a user unsuccessfully fills in a form because some of the data is in the incorrect format, text is added to the existing form which reads “5 errors on page”. The screen reader announces the same message.
After a user puts a photo in an album in an online photo app, a snackbar displays the message “Saved in ‘Wedding’ album”, which is also read by a screen reader.
NOT status messages:
Non-displayed text specific to AT users;
Modification of status text;
Removal of status text; and
Non-textual status content, such as images.
4.1.3 Status Messages - HOW/Failures
A. Advises on the success or results of an action, or the state of an application:
ARIA22: Using role=status to present status messages in combination with any of the following:
G199: Providing success feedback when data is submitted successfully
B. Conveys a suggestion, or a warning on the existence of an error:
ARIA19: Using ARIA role=alert or Live Regions to Identify Errors in combination with any of the following:
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
NOTE: Not all examples in the preceding general techniques use status messages to convey warnings or errors to users. A role of “alert” is only necessary where a change of context does not take place.
C. Conveys information on the progress of a process:
ARIA23: Using role=log to identify sequential information updates
Using role=”progressbar” (future link)
ARIA22: Using role=status to present status messages in combination with G193: Providing help by an assistant in the Web page
Failures:
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)
