WCAG to Silver Migration Map

From Silver

Introduction

At the CSUN 2019 Face to Face meeting, the members of the Silver task force and community group started planning the process for migrating WCAG 2.1 content to Silver. The group reviewed the WCAG 2.1 success criteria (SC) in order, referring to the Understanding WCAG 2.1 document for additional information on the intent and user need. The success criteria were grouped by similar or overlapping user need.

This document is a snapshot of the WCAG to Silver Outline Map working document.

Order of operations

  1. Map WCAG to Silver structure
  2. For each guideline-level grouping, identify user needs
  3. Identify tests to validate meeting user needs
  4. Write methods to meet the tests
  5. Write the top-level guideline to communicate what the methods provide

Notes to selves

  • Go through understanding documentation to collect and categorize user needs and intentions for each.
  • Everything should have an implicit “without loss of content or functionality”.

Map

The notes below the SC are not consistently completed. They capture the group discussion and are left blank where there was no discussion.


SC 1.1.1 Non-text Content, SC 1.4.5 Images of Text, Success Criterion 2.5.3 Label in Name

  • User need(s)
  • Guideline: Anything that isn’t text needs a text equivalent.
  • Methods
    • Evaluating the quality of text equivalent

SC 1.2.1 Audio-only and Video-only (Prerecorded), SC 1.2.8 Media Alternative (Prerecorded), SC 1.2.9 Audio-only (Live)

  • User need(s)
  • Guideline: ?
  • Methods
    • For audio or video, provide alternative content

SC 1.2.2 Captions (Prerecorded), SC 1.2.4 Captions (Live), SC 1.2.6 Sign Language (Prerecorded)

  • User need(s)
  • Guideline: ?
  • Methods
    • For audio, provide captions
    • For audio, provide sign language interpretation

SC 1.2.3 Audio Description or Media Alternative (Prerecorded), SC 1.2.5 Audio Description (Prerecorded), SC 1.2.7 Extended Audio Description (Prerecorded)

  • User need(s)
  • Guideline: ?
  • Methods
    • For video, provide transcript
    • For video, provide audio description (extended as necessary)
      • Maps up to captions

SC 1.3.1 Info and Relationships, SC 1.3.2 Meaningful Sequence, SC 1.3.5 Identify Input Purpose, SC 1.3.6 Identify Purpose, SC 3.3.2 Labels or Instructions

  • User need(s) The semantic needs for blind users, but also the understanding need for people with cognitive impairments.
  • Guideline: ?
  • Methods
    • Programmatically convey any semantics visually conveyed
    • More granular as well, beyond HTML & ARIA. Example: users swapping out icon sets
    • Programmatic order matches visual order
    • Programmatically declare the specific kind of data expected in a particular field @@EdNote: Declared input purposes, which we'll need to include as well @@
    • Labels or instructions are provided when content requires user input.

SC 1.3.3 Sensory Characteristics, SC 1.4.1 Use of Color

  • User need(s)
  • Guideline: ?
  • Methods
    • Use more than one sensory characteristic @@EdNote: don’t call it a sensory characteristic. Way of perceiving? Way of understanding? @@ of conveying cues for understanding and operating

SC 1.3.4 Orientation, SC 1.4.10 Reflow

  • User need(s)
  • Guideline: Viewport rendering customization something something?
  • Methods
    • Enable users to view and interact in whatever orientation they desire
    • Provide content that renders usably [within reasonable constraints] with scrolling only in one dimension. @@EdNote: "Except for parts of the content which require two-dimensional layout for usage or meaning." Let's tackle three+ dimensions later. @@
      • Vertical scrolling content at a width equivalent to 320 CSS pixels;
      • Horizontal scrolling content at a height equivalent to 256 CSS pixels.
      • International (e.g. vertical, or right-to-left) language use differences.

SC 1.4.4 Resize text, SC 1.4.5 Images of Text, SC 1.4.9 Images of Text (No Exception)@@EdNote: Examples of images of text: Historical text, cave wall writings, etc. @@, SC 1.4.8 Visual Presentation, SC 1.4.12 Text Spacing

  • User need(s)
  • Guideline: Text rendering customization something something?
  • Methods
    • Enable the user to resize text [within reasonable limits]
    • Text can be resized without assistive technology up to 200 percent in a way that does not require the user to scroll horizontally to read a line of text on a full-screen window.
    • Enable users to set all of the following and by changing no other style property: @@EdNote: Check & validate research. @@
      • Line height (line spacing) to at least 1.5 times the font size;
      • Spacing following paragraphs to at least 2 times the font size;
      • Letter spacing (tracking) to at least 0.12 times the font size;
      • Word spacing to at least 0.16 times the font size.

SC 1.4.2 Audio Control, Success Criterion 2.2.4 Interruptions

  • User need(s): (Lucy: non-consensual sound should not be permitted)
  • Guideline: ?
  • Methods
    • Enable the user to initiate the audio playing themselves
    • Enable the user to control the audio output

SC 1.4.3 Contrast (Minimum), SC 1.4.6 Contrast (Enhanced), SC 1.4.8 Visual Presentation, SC 1.4.11 Non-text Contrast

  • User need(s)
  • Guideline: ?
  • Methods
    • Provide enough contrast to enable people to see things
    • Customization of foreground/background color

SC 1.4.7 Low or No Background Audio

@@EdNote: This needs research. @@

  • User need(s)
  • Guideline: ?
  • Method
    • Provide spoken audio with no background sounds
    • Enable users to adjust/customize or turn off background sounds
    • Provide spoken audio with background sounds [at a sufficiently lower level]

SC 1.4.8 Visual Presentation

  • User need(s)
  • Guideline: Text rendering guidance something something?
  • Methods @@EdNote: All true, rather than separate methods. @@
    • Width of a line of continuous text is no more than 80 characters or glyphs (40 if CJK).
      • Note: Irrelevant if you can reflow the text.
    • Text is not [fully] justified (aligned to both the left and the right margins).
      • Note: Avoid “rivers of white”.
    • Line spacing (leading) is at least space-and-a-half within paragraphs.
    • Paragraph spacing is at least 1.5 times larger than the line spacing.

SC 1.4.13 Content on Hover or Focus

  • User need(s)
  • Guideline: ?
  • Methods
    • Only display additional content at explicit user action to request it. @@EdNote: Or something. Maybe with more points than the current WCAG. @@
    • When content appears on hover/focus…
    • Dismissable: A mechanism is available to dismiss the additional content without moving pointer hover or keyboard focus, unless the additional content communicates an input error or does not obscure or replace other content;
    • Hoverable: If pointer hover can trigger the additional content, then the pointer can be moved over the additional content without the additional content disappearing;
    • Persistent: The additional content remains visible until the hover or focus trigger is removed, the user dismisses it, or its information is no longer valid.

SC 2.1.1 Keyboard, SC 2.5.6 Concurrent Input Mechanisms, [ SC 2.1.2 No Keyboard Trap], SC 2.1.3 Keyboard (No Exception)

@@EdNote: Concurrent input may need a security exception

  • User need(s)
  • Guideline: Users can use whichever input mechanism is preferred and available to them.?
  • Methods
    • Fundamental support of different input mechanisms
    • Timing of interactions with different input mechanisms
    • Avoid input mechanism traps @@EdNote: Word positively, maybe linking to non-interference? @@

[ SC 2.1.4 Character Key Shortcuts]

  • User need(s)
  • Guideline: Customizability of interactions?
  • Methods
    • Turn off: A mechanism is available to turn the shortcut off;
    • Remap: A mechanism is available to remap the shortcut to use one or more non-printable keyboard characters (e.g. Ctrl, Alt, etc);

[ SC 2.1.4 Character Key Shortcuts]

  • User need(s)
  • Guideline: Context of interactions?
  • Methods
    • Active only on focus: The keyboard shortcut for a user interface component is only active when that component has focus.

Success Criterion 2.2.1 Timing Adjustable, Success Criterion 2.2.3 No Timing, Success Criterion 2.2.5 Re-authenticating, Success Criterion 2.2.6 Timeouts

@@EdNote: Check the "20 seconds" bit. @@

  • User need(s)
  • Guideline:
  • Methods
    • Users are warned of the duration of any user inactivity that could cause data loss.
    • For any time limit, the user needs the ability to turn it off or extend it.
    • Don’t have time limits.

Success Criterion 2.2.2 Pause, Stop, Hide, Success Criterion 2.2.4 Interruptions, Success Criterion 2.3.3 Animation from Interactions

@@EdNote: Check the "at least five seconds" bit. @@

  • User need(s) [visual equivalent of non-consensual sound]
  • Guideline:
  • Methods
    • For anything that automatically moves or blinks for at least five seconds, the user needs the ability to stop or hide it.
    • Don’t make anything that moves or blinks in the first place.
    • Motion animation triggered by interaction can be disabled, unless the animation is essential to the functionality or the information being conveyed.

Success Criterion 2.2.4 Interruptions

  • User need(s) [from Understanding documentation]
    • Individuals with attention deficit disorders can focus on content without distraction.
    • Individuals with low vision or who use screen readers will not have content updated while they are viewing it (which can lead to discontinuity and misunderstanding if they start reading in one topic and finish in another).
    • Notification fatigue, even in circumstances where each one is an emergency (hospital setting, etc.).
  • Guideline:
  • Methods
    • Visual interruptions
    • Audio interruptions
    • Focus interruptions
    • Announcement interruptions

Success Criterion 2.2.5 Re-authenticating, Success Criterion 2.2.6 Timeouts

@@EdNote: Look into the 20 hours bit. @@

  • User need(s)
  • Guideline: Any interruption to a user’s task should not lose what they’ve done @@EdNote: Data input, steps in a process, etc. @@ until then, and they can continue from where they left off after the interruption.
  • Methods
    • Being able to download the work to that point?
    • Saving a shopping cart
    • Saving complex search files
    • Error notification where the user needs assistance

Success Criterion 2.3.1 Three Flashes or Below Threshold, Success Criterion 2.3.2 Three Flashes

  • User need(s):
  • Guideline: “Do not design content in a way that is known to cause seizures.”
  • Methods
    • 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.
    • Web pages do not contain anything that flashes more than three times in any one second period.

Success Criterion 2.3.3 Animation from Interactions

  • User need(s): (physical reactions, vestibular, etc.) @@EdNote: Can we add: Information provided in animation should also be provided without the animation (e.g. in structured text, audio/video w transcript, etc.) Also: Warning about risks of looking at animation (e.g. may cause dizziness, etc.)Consider concerns re: 360 View, mapping applications, VR -- especially VR. @@

Success Criterion 2.4.1 Bypass Blocks

  • User need(s)
  • Guideline:
  • Methods
    • A mechanism is available to bypass blocks of content that are repeated in multiple screens or contexts.
    • skipto, landmarks, etc.

Success Criterion 2.4.2 Page Titled

  • User need(s)
  • Guideline:
  • Methods
    • [Screens or contexts] have titles that describe topic or purpose.

Success Criterion 2.4.3 Focus Order

@@EdNote: Related point: focus order of the things themselves makes sense. @@

  • User need(s): Not only move in a sequence, but it needs to be a predictable & logical sequence to the user. @@EdNote: Consider shifting this criteria to a guideline about promoting a focus order that is more user-centric and facilitates task-based completion and assessment. @@
  • Guideline: [In-context navigation?]
  • Methods
    • If the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability.

Success Criterion 2.4.4 Link Purpose (In Context), Success Criterion 2.4.9 Link Purpose (Link Only)

  • User need(s)
  • Guideline:
  • Methods
    • Purpose of a link can be determined either by link text alone.
    • Purpose of a link can be determined either by link text together with immediate link context. @@EdNote: Here be dragons. @@

[ Success Criterion 2.4.5 Multiple Ways], [ Success Criterion 2.4.8 Location]

  • User need(s)
  • Guideline:
  • Methods
    • Provide multiple ways to navigate to content or functionality within a larger context (site or application).
    • Information about the user's location in content or functionality within a larger context (site or application) is available.
    • Good example for ATAG methods

{ Success Criterion 2.4.6 Headings and Labels], [ Success Criterion 2.4.10 Section Headings]

@@EdNote: See Headings. NOTE: Move Labels to its own guideline and merge 2.4.6 and 2.4.10 @@

  • User need(s)
  • Guideline:
  • Methods
    • Headings describe topic or purpose.
    • Section headings are used to organize the content.

@@EdNote: Section headings are written with the intention of focusing more on the container semantics rather than the organized content within. @@

Success Criterion 2.4.7 Focus Visible

  • User need(s)
  • Guideline: “Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is highly visible.”
  • Methods

Success Criterion 2.5.1 Pointer Gestures, SC 2.1.1 Keyboard, Success Criterion 3.1.6: Pronunciation (maybe)

  • User need(s) Also consider: Speech input. Speech input and being able to correct interpretation (deaf people with pronunciation issues being interpreted by machines)
  • Guideline:
  • Methods
    • All functionality that uses multipoint for operation can be operated with a single pointer.
    • All functionality that uses path-based gestures for operation can be operated without a path-based gesture.
    • “All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes”

Success Criterion 2.5.2 Pointer Cancellation, Success Criterion 2.5.6 Concurrent Input Mechanisms?? (possible technique overlap)

  • User need(s): prevent/avoid unintentional actions
  • Guideline:
  • Methods
    • No Down-Event: The down-event of the pointer is not used to execute any part of the function.
    • Abort: Completion of the function is on the up-event, and a mechanism is available to abort the function before completion.
    • Undo: Completion of the function is on the up-event, and a mechanism is available to undo the function after completion.
    • Up Reversal: The up-event reverses any outcome of the preceding down-event.

Success Criterion 2.5.3 Label in Name

  • User need(s): voice command software support, for example
  • Guideline:
  • Methods
    • For user interface components with labels that include text or images of text, the name contains the text that is presented visually.

Success Criterion 2.5.4 Motion Actuation

  • User need(s)
  • Guideline:
  • Methods
    • Functionality that can be operated by device motion or user motion can also be operated by user interface components
    • Users can disable responding to the motion to prevent accidental actuation

Success Criterion 2.5.5 Target Size

  • User need(s): fine motor control
  • Guideline:
  • Methods
    • The size of the target for pointer inputs is at least 44 by 44 CSS pixels. @@EdNote: Find the research to read up on how we arrived at 44x44 and what other sizes would mean. Discussion: MATF research shows that Android and iOS had different sizes. AGWG split the difference. Spacing between targets also important, look into that (maybe on the 2.2 or MATF list?). @@

Success Criterion 2.5.6 Concurrent Input Mechanisms

  • User need(s): variety of inputs, may switch between inputs at any time. See if there is overlap with pointer cancellation
  • Guideline:
  • Methods
    • Allow users to switch input modalities mid-task.

[ Success Criterion 3.1.1 Language of page], 3.1.2 Language of parts

@@EdNote: rewrite the handle - page doesn't apply in non-web @@

  • User need(s) Inform assistive technology what the human language it is
  • Guideline: Human language can be programmatically determined
  • Methods: see prototype for Information Architecture

Success Criterion 3.1.3: Unusual Words, Success Criterion 3.1.4: Abbreviations. [https:// www.w3.org/TR/WCAG21/#pronunciation Success Criterion 3.1.6: Pronunciation (maybe)], also proposal for Clear Words in 2.2?

  • User need(s) - both Unusual words, abbreviations or acronyms need to a way for users to understand the meaning of words in their context. Language barriers are also served by this. How literal a word is in context is also an issue for people with cognitive disabilities.
  • Guideline:
  • Methods

Success Criterion 3.1.4: Abbreviations

  • User need(s) -
  • Guideline:
  • Methods

Success Criterion 3.1.5: Reading Level

@@EdNote: Needs updated research and major re-analysis. @@

  • User need(s) -
  • Guideline:
  • Methods

Success Criterion 3.1.6: Pronunciation

  • User need(s) - ambiguous interpretation of words. Does it also apply to speech input? Would this apply more to people who are deaf, whose words may not be easily understood by machines. Speech as a mode of input should be linked to Pronunciation, so that people don’t have to look in two places. (example: read, read, red)
  • Guideline:
  • Methods

SC 3.2.1 On Focus, SC 3.2.2 On Input, SC 3.2.5 Change on Request

@@EdNote: On Input has an out via a warning, but On Focus does not? @@

  • User need(s) -
  • Guideline:
  • Methods
    • When any user interface component receives focus, it does not initiate a change of context.
    • When the user interacts with a component, context remains the same.
    • Warn the user that context will change when they interact with a component.
    • Only change context on user request.

SC 3.2.3 Consistent Navigation, SC 3.2.4 Consistent Identification, Success Criterion 2.5.6 Concurrent Input Mechanisms

  • User need(s) - Consistency in menus and navigation benefits people with cognitive impairments and people who are blind. Consistency in the access to navigation is also important. Consistency in interactions with components is also important. Task-based assessment will be important here.
  • Guideline:
  • Methods
    • Navigational/interaction mechanisms that are repeated in multiple contexts occur in the same relative order each time they are repeated.
    • Components that have the same functionality within multiple contexts are identified consistently.

SC 3.3.1 Error Identification, SC 3.3.3 Error Suggestion

  • User need(s) - Avoid and correct mistakes.
    • People who cannot see need to perceive the text.
    • Error messages need to be in simple language.
    • People also need to be directed back to the input where the error occurred.
    • There is a breadcrumb perspective of returning to the point of the error.
    • Errors demand additional assistance for blind and cognitive.
  • Guideline:
  • Methods
    • 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.
    • If an input error is automatically detected and suggestions for correction are known, then the suggestions are provided to the user.
    • Identify the error immediately in context, and return focus to the input.

@@EdNote: Rethink wording here around "automatically detected" and "known". @@

Success Criterion 2.4.6 Headings and Labels, SC 3.3.2 Labels or Instructions, SC 3.3.5 Help

@@EdNote: Note from Denis to include during content/method creation: "sufficient labels for form field elements are provided for all users (sighted and non-sighted)" Also, "labels, instructions, or error messages must be provided when form fields require user input." - under 3.3.2 @@

  • User need(s) -
  • Guideline:
  • Methods
    • Labels describe topic or purpose.
    • Labels are provided when content requires user input.
    • Instructions are provided when content requires user input. @@EdNote: Suggestion: Instead of "Instructions are provided when content requires user input." Would "Instructions are provided when content requires understanding in order to complete desired user input." Be a better method? @@
    • Context-sensitive help is available. @@EdNote: We'll likely need to write up a user need around help as well as the mechanisms. @@

SC 3.3.4 Error Prevention, SC 3.3.6 Error Prevention (All)

@@EdNote: From the intent of the SC User Controllable data is " data that is intended to be accessed by users". Also from intent: the intent is to prevent mass loss of data such as deleting a file or record. It is not the intent to require a confirmation for each save command or the simple creation or editing of documents, records or other data. Blog post comment, log in screen, google search are all examples of trivial stuff that are not part of what 334 means to cover.. @@

@@EdNote: This is an example where Silver could reduce testing costs by removing the need to manually check if the data is legal or financial. Setting for all, give an option for resubmittable and an exception for trivial? @@

  • User need(s) -
  • Guideline:
  • Methods
    • 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.

SC 4.1.1 Parsing, SC 4.1.2 Name, Role, Value (and State), SC 4.1.3 Status Messages

@@EdNote: Note: AG WG considering deprecating Parsing SC. @@

@@EdNote: Note: Start off with Understanding documentation: https://www.w3.org/WAI/WCAG21/Understanding/parsing.html @@

  • User need(s) - Intent from Understanding documentation (consumable & actionable by all)
  • Guideline: Use the given tech stack correctly, adhere to the accessibility guidance of the platform/technology.
  • Methods
    • Scope of Current SC guidance
      1. Complete Start and End Tags: Elements MUST have complete start and end tags.
      2. Nested According to Specification: Elements MUST be nested according to their specifications.
      3. Duplicate Attributes: Elements MUST NOT contain duplicate attributes.
      4. Unique IDs: Element IDs MUST be unique.
    • Use valid markup / ARIA (DOM, ending up in accessibility tree).
    • Use messaging that results in the accessibility tree events so AT know about them
      • 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;
      • the message is not delivered via a change in context.
Retrieved from "https://www.w3.org/WAI/GL/task-forces/silver/wiki/index.php?title=WCAG_to_Silver_Migration_Map&oldid=741"