List of detailed Accessibility Requirements for Web-based internet and intranet system
- The procuring authority should check that the Functionality Accessibility Requirements listed below relate to the functionality required for its specific procurement. Use the "Accessibility Requirements Generator" to change this list.
- The list of requirements is suitable for use as Technical Specifications and/or Award Criteria.
- The Column "Clauses met: Fully/Partially/Not" should only be used/included for Award Criteria.
- Where the Functional Accessibility Requirements are used for the Technical Specification, it is presumed that all requirements are met, and therefore this column is not necessary.
This example consists of the procurement of a web-based internet and intranet system, which includes web content, two-way voice and video communication (e.g. between employees), video capabilities, and the necessary content management system used to maintain and publish new content.
The rendering (display) and interaction with the web content is not part of this procurement, as this functionality is addressed by user agents, such as web browsers and media players, and assistive technologies used by some people with disabilities.
The following aspects are covered in the list of accessibility requirements:
- generic requirements, such as activation of accessibility features, biometrics, preservation of accessibility information, operable parts, locking or toggle controls, key repeat, double-strike key acceptance and simultaneous user actions;
- two-way voice or video communication;
- video capabilities: playback, transmission, conversion of recording of video with synchronized audio;
- web content success criteria that are equivalent to conformance with WCAG 2.0 level AA;
- other software-related requirements, such as interoperability with assistive technology, documented accessibility usage, user preferences;
- authoring tools;
- documentation and support services.
The following aspects are not covered in the list of accessibility requirements:
- closed functionality;
- hardware;
- non-web documents and non-web software;
- web browsers and assistive technologies;
- relay service provision.
- "EN 301 549 Clauses" includes all Clauses of EN 301 549 "Accessibility requirements suitable for public procurement of ICT products and services in Europe" that may apply to the ICT product or service
- "Notes" is for brief notes by the procuring authority about the Clauses of EN 301 549 or additional requirements that may wish to add.
- "Clause met:" should be included ONLY where the procurer wishes to use Functional Accessibility Requirements as Award Criteria; the criteria should be based on the number of listed requirements which are fully met. It is to be filled in by the supplier.
- "Not Applicable" may be used by the supplier to note if this Functional Accessibility Requirement does not apply to (as opposed to is not met by) the offered solution
- "Explanations" is where the supplier can note explanations for any of the preceding columns
These are the core aspects that the offered product / service must meet, either by meeting the relevant Functional Accessibility Requirements listed below, or outlining how the product / service would fulfil these Statements.
- 4.2.1. Usage without vision: Where ICT provides visual modes of operation, some users need ICT to provide at least one mode of operation that does not require vision.
- 4.2.2. Usage with limited vision: Where ICT provides visual modes of operation, some users will need the ICT to provide features that enable users to make better use of their limited vision.
- 4.2.3. Usage without perception of colour: Where ICT provides visual modes of operation, some users will need the ICT to provide a visual mode of operation that does not require user perception of colour.
- 4.2.4. Usage without hearing: Where ICT provides auditory modes of operation, some users need ICT to provide at least one mode of operation that does not require hearing.
- 4.2.5. Usage with limited hearing: Where ICT provides auditory modes of operation, some users will need the ICT to provide enhanced audio features.
- 4.2.6. Usage without vocal capability: Where ICT requires vocal input from users, some users will need the ICT to provide at least one mode of operation that does not require them to generate vocal output.
- 4.2.7. Usage with limited manipulation or strength: Where ICT requires manual actions, some users will need the ICT to provide features that enable users to make use of the ICT through alternative actions not requiring manipulation or hand strength.
- 4.2.8. Usage with limited reach: Where ICT products are free-standing or installed, the operational elements will need to be within reach of all users.
- 4.2.9. Minimize photosensitive seizure triggers: Where ICT provides visual modes of operation, some users need ICT to provide at least one mode of operation that minimizes the potential for triggering photosensitive seizures.
- 4.2.10. Usage with limited cognition: Some users will need the ICT to provide features that make it simpler and easier to use.
- 4.2.11. Privacy: Where ICT provides features that are provided for accessibility, some users will need their privacy to be maintained when using those ICT features that are provided for accessibility.
The following Functional Accessibility Requirements are applicable to the Functional Performance Statements above. If a solution meets all of these it is considered to have met the Functional Performance Statements and is therefore deemed to conform with EN 301 549.
NOTE: "Web pages that conform to WCAG 2.0 Level AA are deemed to have met the web content requirements of clause 9.2 and the conformance requirements of clause 9.3".
EN 301 549 Clauses
Notes
Clause met (Y/N)
Not Applicable
Explanations
5.2 Activation of accessibility features
Where ICT has documented accessibility features, it shall be possible to activate those documented accessibility features that are required to meet a specific need without relying on a method that does not support that need.
5.3 Biometrics
Where ICT uses biological characteristics, it shall not rely on the use of a particular biological characteristic as the only means of user identification or for control of ICT.
5.4 Preservation of accessibility information during conversion
Where ICT converts information or communication it shall preserve all documented non-proprietary information that is provided for accessibility, to the extent that such information can be contained in or supported by the destination format.
5.6.1 Tactile or auditory status
Where ICT has a locking or toggle control and that control is visually presented to the user, the ICT shall provide at least one mode of operation where the status of the control can be determined either through touch or sound without operating the control.
5.6.2 Visual status
When ICT has a locking or toggle control and the control is non-visually presented to the user, the ICT shall provide at least one mode of operation where the status of the control can be visually determined when the control is presented.
5.7 Key repeat
Where ICT with key repeat is provided and the key repeat cannot be turned off:
a) the delay before the key repeat shall be adjustable to at least 2 seconds; and
b) the key repeat rate shall be adjustable down to one character per 2 seconds.
6.2.1.2 Concurrent voice and text
Where the ICT, or set of ICT, provided to a user, supports two-way voice communication and enables a user to communicate with another user by RTT, it shall provide a mechanism to select a mode of operation allowing concurrent voice and text.
6.2.2.1 Visually distinguishable display
Where ICT has RTT send and receive capabilities, displayed sent text shall be visually differentiated from and separated from received text.
6.2.2.2 Programmatically determinable send and receive direction
Where ICT has RTT send and receive capabilities, the send/receive direction of transmitted text shall be programmatically determinable, unless the RTT has closed functionality.
6.2.3 Interoperability
Where ICT with RTT functionality interoperates with other ICT with RTT functionality (as required by 6.2.1.1) they shall support at least one of the four RTT interoperability mechanisms described below:
a) ICT interoperating over the Public Switched Telephone Network (PSTN), with other ICT that directly connects to the PSTN as described in Recommendation ITU-T V.18 [i.23] or any of its annexes for text telephony signals at the PSTN interface;
b) ICT interoperating with other ICT using VOIP with Session Initiation Protocol (SIP) and using real-time text that conforms to RFC 4103 [i.13];
c) ICT interoperating with other ICT using RTT that conforms with the IP Multimedia Sub-System (IMS) set of protocols specified in TS 126 114 [i.10], TS 122 173 [i.11] and TS 134 229 [i.12];
d) ICT interoperating with other ICT using a relevant and applicable common specification for RTT exchange that is published and available. This common specification shall include a method for indicating loss or corruption of characters.
6.2.4 Real-time text responsiveness
Where ICT utilises RTT input, that RTT input shall be transmitted to the ICT network supporting RTT within 1 second of the input entry.
6.3 Caller ID
Where ICT provides caller identification and similar telecommunications functions are provided, the caller identification and similar telecommunications functions shall be available in text form and in at least one other modality.
6.4 Alternatives to voice-based services
Where ICT provides real-time voice-based communication and also provides voice mail, auto-attendant, or interactive voice response facilities, the ICT should offer users a means to access the information and carry out the tasks provided by the ICT without the use of hearing or speech.
6.5.2 Resolution
Where ICT that provides two-way voice communication includes real time video functionality, the ICT:
a) shall support at least QCIF resolution;
b) should preferably support at least CIF resolution.
6.5.3 Frame rate
Where ICT that provides two-way voice communication includes real-time video functionality, the ICT:
a) shall support a frame rate of at least 12 frames per second (FPS);
b) should preferably support a frame rate of at least 20 frames per second (FPS) with or without sign language in the video stream.
6.5.4 Synchronization between audio and video
Where ICT that provides two-way voice communication includes real-time video functionality, the ICT should ensure a maximum time difference of 100 ms between the speech and video presented to the user.
6.6 Alternatives to video-based services
Where ICT provides real-time video-based communication and also provides answering machine, auto attendant or interactive response facilities, the ICT should offer users a means to access the information and carry out the tasks related to these facilities:
a) for audible information, without the use of hearing;
b) for spoken commands, without the use of speech;
c) for visual information, without the use of vision.
7.1.1 Captioning playback
Where ICT displays video with synchronized audio, it shall have a mode of operation to display the available captions. Where closed captions are provided as part of the content, the ICT shall allow the user to choose to display the captions.
7.1.2 Captioning synchronisation
Where ICT displays captions, the mechanism to display captions shall preserve synchronization between the audio and the corresponding captions.
7.1.3 Preservation of captioning
Where ICT transmits, converts or records video with synchronized audio, it shall preserve caption data such that it can be displayed in a manner consistent with clauses 7.1.1 and 7.1.2.
Additional presentational aspects of the text such as screen position, text colours, text style and text fonts may convey meaning, based on regional conventions. Altering these presentational aspects could change the meaning and should be avoided wherever possible.
7.2.1 Audio description playback
Where ICT displays video with synchronized audio, it shall provide a mechanism to select and play available audio description to the default audio channel.
Where video technologies do not have explicit and separate mechanisms for audio description, an ICT is deemed to satisfy this requirement if the ICT enables the user to select and play several audio tracks.
7.2.2 Audio description synchronisation
Where ICT has a mechanism to play audio description, it shall preserve the synchronization between the audio/visual content and the corresponding audio description.
7.2.3 Preservation of audio description
Where ICT transmits, converts, or records video with synchronized audio, it shall preserve audio description data such that it can be played in a manner consistent with clauses 7.2.1 and 7.2.2.
7.3 User controls for captions and audio description
Where ICT primarily displays materials containing video with associated audio content, user controls to activate subtitling and audio description shall be provided to the user at the same level of interaction (i.e. the number of steps to complete the task) as the primary media controls.
9.2.1 Non-text content
Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 1.1.1 Non-text content.
WCAG 2.0 Success Criterion 1.1.1 Non-text content
All non-text content that is presented to the user has a text alternative that serves the equivalent purpose, except for the situations listed below:
- Controls, Input: If non-text content is a control or accepts user input, then it has a name that describes its purpose. (Refer to WCAG 2.0 Guideline 4.1 for additional requirements for controls and content that accepts user input.)
- Time-Based Media: If non-text content is time-based media, then text alternatives at least provide descriptive identification of the non-text content. (Refer to WCAG 2.0 Guideline 1.2 for additional requirements for media.)
- Test: If non-text content is a test or exercise that would be invalid if presented in text, then text alternatives at least provide descriptive identification of the non-text content.
- Sensory: If non-text content is primarily intended to create a specific sensory experience, then text alternatives at least provide descriptive identification of the non-text content.
- CAPTCHA: If the purpose of non-text content is to confirm that content is being accessed by a person rather than a computer, then text alternatives that identify and describe the purpose of the non-text content are provided, and alternative forms of CAPTCHA using output modes for different types of sensory perception are provided to accommodate different disabilities.
- Decoration, Formatting, Invisible: If non-text content is pure decoration, is used only for visual formatting, or is not presented to users, then it is implemented in a way that it can be ignored by assistive technology.
9.2.2 Audio-only and video-only (pre-recorded)
Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 1.2.1 Audio-only and Video-only (Pre-recorded).
WCAG 2.0 success criterion: Audio-only and video-only (pre-recorded)
For pre-recorded audio-only and pre-recorded video-only media, the following are true, except when the audio or video is a media alternative for text and is clearly labelled as such:
- Pre-recorded Audio-only: An alternative for time-based media is provided that presents equivalent information for pre-recorded audio-only content.
- Pre-recorded Video-only: Either an alternative for time-based media or an audio track is provided that presents equivalent information for pre-recorded video-only content.
9.2.3 Captions (pre-recorded)
Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 1.2.2 Captions (Pre-recorded).
WCAG 2.0 success criterion: Captions (pre-recorded)
Captions are provided for all prerecorded audio content in synchronized media, except when the media is a media alternative for text and is clearly labeled as such.
9.2.4 Audio description or media alternative (pre-recorded)
Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 1.2.3 Audio Description or Media Alternative (Pre-recorded).
WCAG 2.0 success criterion: Audio description or media alternative (pre-recorded)
An alternative for time-based media or audio description of the pre-recorded video content is provided for synchronized media, except when the media is a media alternative for text and is clearly labeled as such.
NOTE 1: The WCAG 2.0 definition of "audio description" says that "audio description" is "Also called 'video description' and 'descriptive narration'".
NOTE 2: Secondary or alternate audio tracks are commonly used for this purpose.
9.2.5 Captions (live)
Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 1.2.4 Captions (Live).
WCAG 2.0 success criterion: Captions (live)
Captions are provided for all live audio content in synchronized media.
9.2.6 Audio description (pre-recorded)
Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 1.2.5 Audio Description (Pre-recorded).
WCAG 2.0 success criterion: Audio description (pre-recorded)
Audio description is provided for all pre-recorded video content in synchronized media.
9.2.7 Info and relationships
Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 1.3.1 Info and Relationships.
WCAG 2.0 success criterion: Info and relationships
Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.
9.2.8 Meaningful sequence
Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 1.3.2 Meaningful Sequence.
WCAG 2.0 success criterion: Meaningful sequence
When the sequence in which content is presented affects its meaning, a correct reading sequence can be programmatically determined.
9.2.9 Sensory characteristics
Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 1.3.3 Sensory Characteristics.
WCAG 2.0 success criterion: Sensory characteristics
Instructions provided for understanding and operating content do not rely solely on sensory characteristics of components such as shape, size, visual location, orientation, or sound.
NOTE: For requirements related to colour, refer to WCAG 2.0 Guideline 1.4.
9.2.10 Use of colour
Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 1.4.1 Use of Color.
WCAG 2.0 success criterion: Use of colour
Colour is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.
**NOTE: **This success criterion addresses colour perception specifically. Other forms of perception are covered in WCAG 2.0 Guideline 1.3 including programmatic access to colour and other visual presentation coding.
9.2.11 Audio control
Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 1.4.2 Audio Control.
WCAG 2.0 success criterion: Audio control
If any audio on a Web page plays automatically for more than 3 seconds, either a mechanism is available to pause or stop the audio, or a mechanism is available to control audio volume independently from the overall system volume level.
NOTE: Since any content that does not meet this success criterion can interfere with a user's ability to use the whole page, all content on the Web page (whether or not it is used to meet other success criteria) shall meet this success criterion. See Conformance Requirement 5: Non-Interference.
9.2.12 Contrast (minimum)
Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 1.4.3 Contrast (Minimum).
WCAG 2.0 success criterion: Contrast (Minimum)
The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for the following:
- Large Text: Large-scale text and images of large-scale text have a contrast ratio of at least 3:1.
- Incidental: Text or images of text that are part of an inactive user interface component, that are pure decoration, that are not visible to anyone, or that are part of a picture that contains significant other visual content, have no contrast requirement.
- Logotypes: Text that is part of a logo or brand name has no minimum contrast requirement.
9.2.13 Resize text
Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 1.4.4 Resize text.
WCAG 2.0 success criterion: Resize text
Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality.
9.2.14 Images of text
Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 1.4.5 Images of Text.
WCAG 2.0 success criterion: Images of text
If the technologies being used can achieve the visual presentation, text is used to convey information rather than images of text except for the following:
- Customizable: The image of text can be visually customized to the user's requirements.
- Essential: A particular presentation of text is essential to the information being conveyed.
NOTE: Logotypes (text that is part of a logo or brand name) are considered essential.
9.2.15 Keyboard
Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 2.1.1 Keyboard.
WCAG 2.0 success criterion: Keyboard
All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints.
NOTE 1: This exception relates to the underlying function, not the input technique. For example, if using handwriting to enter text, the input technique (handwriting) requires path-dependent input but the underlying function (text input) does not.
NOTE 2: This does not forbid and should not discourage providing mouse input or other input methods in addition to keyboard operation.
9.2.16 No keyboard trap
Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 2.1.2 No Keyboard Trap.
WCAG 2.0 success criterion: No Keyboard Trap
If keyboard focus can be moved to a component of the page using a keyboard interface, then focus can be moved away from that component using only a keyboard interface, and, if it requires more than unmodified arrow or tab keys or other standard exit methods, the user is advised of the method for moving focus away.
NOTE: Since any content that does not meet this success criterion can interfere with a user's ability to use the whole document, all content on the Web page (whether or not it is used to meet other success criteria) must meet this success criterion.
9.2.17 Timing adjustable
Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 2.2.1 Timing Adjustable.
WCAG 2.0 success criterion: Timing Adjustable
For each time limit that is set by the content, at least one of the following is true:
- Turn off: The user is allowed to turn off the time limit before encountering it; or
- Adjust: The user is allowed to adjust the time limit before encountering it over a wide range that is at least ten times the length of the default setting; or
- Extend: The user is warned before time expires and given at least 20 seconds to extend the time limit with a simple action (for example, "press the space bar"), and the user is allowed to extend the time limit at least ten times; or
- Real-time Exception: The time limit is a required part of a real-time event (for example, an auction), and no alternative to the time limit is possible; or
- Essential Exception: The time limit is essential and extending it would invalidate the activity; or
- 20 Hour Exception: The time limit is longer than 20 hours.
NOTE: This success criterion helps ensure that users can complete tasks without unexpected changes in content or context that are a result of a time limit. This success criterion should be considered in conjunction with WCAG 2.0 Success Criterion 3.2.1, which puts limits on changes of content or context as a result of user action.
9.2.18 Pause, stop, hide
Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 2.2.2 Pause, Stop, Hide.
WCAG 2.0 success criterion: Pause, Stop, Hide
For moving, blinking, scrolling, or auto-updating information, all of the following are true:
- Moving, blinking, scrolling: For any moving, blinking or scrolling information that (1) starts automatically, (2) lasts more than five seconds, and (3) is presented in parallel with other content, there is a mechanism for the user to pause, stop, or hide it unless the movement, blinking, or scrolling is part of an activity where it is essential; and
- Auto-updating: For any auto-updating information that (1) starts automatically and (2) is presented in parallel with other content, there is a mechanism for the user to pause, stop, or hide it or to control the frequency of the update unless the auto-updating is part of an activity where it is essential.
NOTE 1: For requirements related to flickering or flashing content, refer to WCAG 2.0 Guideline 2.3.
NOTE 2: This success criteria is applicable to all content (whether or not there is an alternate accessible version of the content) since any content that does not meet this success criterion can interfere with a user's ability to use the whole page (including a link to the alternate version).
NOTE 3: Content that is updated periodically by software or that is streamed to the user agent is not required to preserve or present information that is generated or received between the initiation of the pause and resuming presentation, as this may not be technically possible, and in many situations could be misleading to do so.
NOTE 4: An animation that occurs as part of a preload phase or similar situation can be considered essential if interaction cannot occur during that phase for all users and if not indicating progress could confuse users or cause them to think that content was frozen or broken.
9.2.19 Three flashes or below threshold
Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 2.3.1 Three Flashes or Below Threshold.
WCAG 2.0 success criterion: Three Flashes or Below Threshold
Web pages do 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.
NOTE: This success criterion is applicable to all content on the Web page (whether or not there is an alternate accessible version of the content) since any part of a document that does not meet this success criterion can interfere with a user's ability to use the whole page (including a link to the alternate version).
9.2.20 Bypass blocks
Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 2.4.1 Bypass Blocks.
WCAG 2.0 success criterion: Bypass Blocks
A mechanism is available to bypass blocks of content that are repeated on multiple Web pages.
9.2.21 Page titled
Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 2.4.2 Page Titled.
WCAG 2.0 success criterion: Page Titled
Web pages have titles that describe topic or purpose.
9.2.22 Focus Order
Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 2.4.3 Focus Order.
WCAG 2.0 success criterion: Focus Order
If a Web page can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability.
9.2.23 Link purpose (in context)
Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 2.4.4 Link Purpose (In Context).
WCAG 2.0 success criterion: Link Purpose (In Context)
The purpose of each link can be determined from the link text alone or from the link text together with its programmatically determined link context, except where the purpose of the link would be ambiguous to users in general.
9.2.24 Multiple ways
Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 2.4.5 Multiple Ways.
WCAG 2.0 Success criterion: Multiple Ways
More than one way is available 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.
9.2.25 Headings and labels
Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 2.4.6 Headings and Labels.
WCAG 2.0 Success Criterion: Headings and Labels
Headings and labels describe topic or purpose.
9.2.26 Focus visible
Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 2.4.7 Focus Visible.
WCAG 2.0 Success Criterion: Focus Visible
Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible.
9.2.27 Language of page
Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 3.1.1 Language of Page.
WCAG 2.0 Success Criterion: Language of Page
The default human language of each Web page can be programmatically determined.
9.2.28 Language of parts
Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 3.1.2 Language of Parts.
WCAG 2.0 Success Criterion: Language of Parts
The human language of each passage or phrase in the content can be programmatically determined except for proper names, technical terms, words of indeterminate language, and words or phrases that have become part of the vernacular of the immediately surrounding text.
9.2.29 On focus
Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 3.2.1 On Focus.
WCAG 2.0 Success Criterion: On Focus
When any component receives focus, it does not initiate a change of context.
9.2.30 On input
Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 3.2.2 On Input.
WCAG 2.0 Success Criterion: On Input
Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behaviour before using the component.
9.2.31 Consistent navigation
Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 3.2.3 Consistent Navigation.
**WCAG 2.0 Success Criterion: Consistent Navigation
**
Navigational mechanisms that are repeated on multipleWeb pageswithin aset of Web pagesoccur in the same relative ordereach time they are repeated, unless a change is initiated by the user.
9.2.32 Consistent identification
Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 3.2.4 Consistent Identification.
**WCAG 2.0 Success Criterion: Consistent Identification
**
Components that have thesame functionalitywithin a set ofWeb pagesare identified consistently.
9.2.33 Error identification
Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 3.3.1 Error Identification.
WCAG 2.0 Success Criterion: Error Identification
If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text.
9.2.34 Labels or instructions
Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 3.3.2 Labels or Instructions.
WCAG 2.0 Success Criterion: Labels or Instructions
Labels or instructions are provided when content requires user input.
9.2.35 Error suggestion
Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 3.3.3 Error Suggestion.
WCAG 2.0 Success Criterion: Error Suggestion
If an input error is automatically detected and suggestions for correction are known, then the suggestions are provided to the user, unless it would jeopardize the security or purpose of the content.
9.2.36 Error prevention (legal, financial, data)
Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 3.3.4 Error Prevention (Legal, Financial, Data).
WCAG 2.0 Success Criterion: 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:
- Reversible: Submissions are reversible.
- Checked: Data entered by the user is checked for input errors and the user is provided an opportunity to correct them.
- Confirmed: A mechanism is available for reviewing, confirming, and correcting information before finalizing the submission.
9.2.37 Parsing
Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 4.1.1 Parsing.
WCAG 2.0 Success Criterion: Parsing
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: Start and end tags that are missing a critical character in their formation, such as a closing angle bracket or a mismatched attribute value quotation mark are not complete.
9.2.38 Name, role, value
Where ICT is a web page, it shall satisfy WCAG 2.0 Success Criterion 4.1.2 Name, Role, Value.
WCAG 2.0 Success Criterion: Name, Role, Value
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: 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.
9.3 WCAG 2.0 conformance requirements
Where ICT is a web page, it shall satisfy all the following five WCAG 2.0 conformance requirements at Level AA.
- Conformance level
- Full pages
- Complete processes
- Only Accessibility-Supported Ways of Using Technologies
- Non-interference
11.3.2.3 Use of accessibility services
Where the software provides a user interface it shall use the applicable documented platform accessibility services. If the documented platform accessibility services do not allow the software to meet the applicable requirements of clauses 11.3.2.5 to 11.3.2.17, then software that provides a user interface shall use other documented services to interoperate with assistive technology.
11.3.2.5 Object information
Where the software provides a user interface it shall, by using the services as described in clause 11.3.2.3, make the user interface elements' role, state(s), boundary, name, and description programmatically determinable by assistive technologies.
11.3.2.6 Row, column, and headers
Where the software provides a user interface it shall, by using the services as described in clause 11.3.2.3, make the row and column of each cell in a data table, including headers of the row and column if present, programmatically determinable by assistive technologies.
11.3.2.7 Values
Where the software provides a user interface, it shall, by using the services as described in clause 11.3.2.3, make the current value of a user interface element and any minimum or maximum values of the range, if the user interface element conveys information about a range of values, programmatically determinable by assistive technologies.
11.3.2.8 Label relationships
Where the software provides a user interface it shall expose the relationship that a user interface element has as a label for another element, or of being labelled by another element, using the services as described in clause 11.3.2.3, so that this information is programmatically determinable by assistive technologies.
11.3.2.9 Parent-child relationships
Where the software provides a user interface it shall, by using the services as described in clause 11.3.2.3, make the relationship between a user interface element and any parent or children elements programmatically determinable by assistive technologies.
11.3.2.10 Text
Where the software provides a user interface it shall, by using the services as described in clause 11.3.2.3, make the text contents, text attributes, and the boundary of text rendered to the screen programmatically determinable by assistive technologies.
11.3.2.11 List of available actions
Where the software provides a user interface it shall, by using the services as described in clause 11.3.2.3, make a list of available actions that can be executed on a user interface element, programmatically determinable by assistive technologies.
11.3.2.12 Execution of available actions
When permitted by security requirements, software that provides a user interface shall, by using the services as described in clause 11.3.2.3, allow the programmatic execution of the actions exposed according to clause 11.3.2.11 by assistive technologies.
11.3.2.13 Tracking of focus and selection attributes
Where software provides a user interface it shall, by using the services as described in clause 11.3.2.3, make information and mechanisms necessary to track focus, text insertion point, and selection attributes of user interface elements programmatically determinable by assistive technologies.
11.3.2.14 Modification of focus and selection attributes
When permitted by security requirements, software that provides a user interface shall, by using the services as described in clause 11.3.2.3, allow assistive technologies to programmatically modify focus, text insertion point, and selection attributes of user interface elements where the user can modify these items.
11.3.2.15 Change notification
Where software provides a user interface it shall, by using the services as described in 11.3.2.3, notify assistive technologies about changes in those programmatically determinable attributes of user interface elements that are referenced in requirements 11.3.2.5 to 11.3.2.11 and 11.3.2.13.
11.3.2.16 Modifications of states and properties
When permitted by security requirements, software that provides a user interface shall, by using the services as described in clause 11.3.2.3, allow assistive technologies to programmatically modify states and properties of user interface elements, where the user can modify these items.
11.3.2.17 Modifications of values and text
When permitted by security requirements, software that provides a user interface shall, by using the services as described in 11.3.2.3, allow assistive technologies to modify values and text of user interface elements using the input methods of the platform, where a user can modify these items without the use of assistive technology.
11.4.1 User control of accessibility features
Where software is a platform it shall provide sufficient modes of operation for user control over those platform accessibility features documented as intended for users.
11.4.2 No disruption of accessibility features
Where software provides a user interface it shall not disrupt those documented accessibility features that are defined in platform documentation except when requested to do so by the user during the operation of the software.
11.5 User preferences
Where software provides a user interface it shall provide sufficient modes of operation that use user preferences for platform settings for colour, contrast, font type, font size, and focus cursor except for software that is designed to be isolated from its underlying platforms.
11.6.1 Content technology
Authoring tools shall conform to clauses 11.6.2 to 11.6.5 to the extent that information required for accessibility is supported by the format used for the output of the authoring tool.
11.6.2 Accessible content creation
Authoring tools shall enable and guide the production of content that conforms to clauses 9 (Web content) or 10 (Non-Web content) as applicable.
11.6.3 Preservation of accessibility information in transformations
If the authoring tool provides restructuring transformations or re-coding transformations, then accessibility information shall be preserved in the output if equivalent mechanisms exist in the content technology of the output.
11.6.4 Repair assistance
If the accessibility checking functionality of an authoring tool can detect that content does not meet a requirement of clauses 9 (Web content) or 10 (Documents) as applicable, then the authoring tool shall provide repair suggestion(s).
11.6.5 Templates
When an authoring tool provides templates, at least one template that supports the creation of content that conforms to the requirements of clauses 9 (Web content) or 10 (Documents) as applicable shall be available and identified as such.
12.1.1 Accessibility and compatibility features
Product documentation provided with the ICT whether provided separately or integrated within the ICT shall list and explain how to use the accessibility and compatibility features of the ICT.
12.1.2 Accessible documentation
Product documentation provided with the ICT shall be made available in at least one of the following electronic formats:
a) a Web format that conforms to clause 9, or
b) a non-web format that conforms to clause 10.
12.2.2 Information on accessibility and compatibility features
ICT support services shall provide information on the accessibility and compatibility features that are included in the product documentation.
12.2.3 Effective communication
ICT support services shall accommodate the communication needs of individuals with disabilities either directly or through a referral point.
12.2.4 Accessible documentation
Documentation provided by support services shall be made available in at least one of the following electronic formats:
a) a Web format that conforms to clause 9, or
b) a non-web format that conforms to clause 10.
13.2 Access to relay services
Where ICT systems support two-way communication and a set of relay services for such communication is specified, access to those relay services shall not be prevented for outgoing and incoming calls.
13.3 Access to emergency services
Where ICT systems support two-way communication and a set of emergency services for such communication is specified, access to those emergency services shall not be prevented for outgoing and incoming calls.