WCAG 2.1 Understanding and Techniques Development
This page includes links to all of the accepted SC, and a table of information to help the WG understand what work is needed for each:
Current Editor's Draft (Rendered as HTML): http://rawgit.com/w3c/wcag21/master/guidelines/index.html
- 1 Understanding Document
- 2 Techniques
- 3 OLD Techniques List
WCAG 2.1 Master List Across all Taskforces:
OLD Techniques List
Everything below this line is for reference only, please use the WCAG 2.1 master list – see link above.
Character Key Shortcuts
- Turn off, Remap
- Single key shortcut
Label in Name
- Ensuring that visible labels match their accessible names | View in rawgit (Drafted by Detlev)
- Label contained in accessible name
- Accessible name does not contain visible text
- Target size for buttons, links and controls
- Target size less than 44 x 44 CSS px for buttons and controls
- Ensuring that functionality triggered by multipoint or path-based gestures can be operated with a single pointer (Completed by @detlevhfischer 2018-02-28)
- No single-point activation
- Activating a control using the up-Event
- Ensuring that drag-and-drop gestures can be cancelled (Completed by @detlevhfischer 2018-03-07)
- Activation events are not triggered when touch is removed from a control (Completed by Chris 2018-03-29)
- Failing due to activating a button on initial touch location rather than the final touch location
Concurrent Input Mechanisms
- Using CSS Media Queries Level 4 Interaction Media Features to determine what the UA deems to be the "primary" input mechanism and assuming no other input mechanisms are present/may be added/may be used.
- Using CSS to set the orientation to allow both landscape and portrait.
- Use of show/hide controls to allow access to content in different orientations.
- Use of the flexible box model to change the meaningful sequence order of content to match the visual order in different orientations.
- Locking the orientation.
- Non-essential functionality that is only available in one orientation.
- Do not use the device motion event to activate content functionality
- Ensure that alternative means of input exist when using device motion sensor input to activate content functionality
- Functionality/content must not solely rely on device inputs (e.g. an alternative which does not require the user to manipulate their device/use these device inputs must be available)
- Functionality/content solely relies on device inputs (e.g. shaking or tilting)
- using role="status"
- Using role="log"
- Using role="timer"
- Using role="progressbar"
- Using role="alert" or aria-live="assertive" on content which is not critical and time-sensitive