Media Accessibility User Requirements

From Education & Outreach

Nav: EOWG wiki main page

Relationship with How People with Disabilities Use the Web

Media Accessibility User Requirements, Disabilities section relationship with How People with Disabilities Use the Web, Diversity of Web Users page

EOWG Suggestions

  1. clarify not comprehensive — Consider changing the section title from "Accessible Media Requirements by Type of Disability" to "Overview of Accessible Media Requirements by Type of Disability" or "Summary of Accessible Media Requirements by Type of Disability" or "Examples of Accessible Media Requirements by Type of Disability" or such.
    Also, make clear in the first sentence that this section provides examples and is not comprehensive.
  2. deaf first — Put Deafness and Hard of hearing first (before Blindness).
    rationale: More people are aware of blindness related to accessibility. With multimedia, deafness may be a much more significant issue, and one that is thought of less.
  3. Atypical color perception — Reconsider "a significant percentage". Consider adding: (often called "color blindness"). Consider including a more clear example(s) related to media requirements, such as colors in media controls or text overlays.
  4. Cognitive and neurological disabilities — Consider cutting out the long list of conditions in the first sentence and tightening up the examples of accessibility requirements for media to meet the needs of people with cognitive and neurological disabilities. [EOWG had some concerns with the list, yet also the thought that some readers might recognize some conditions in the list but would not think of them with just "cognitive and neurological disabilities".] Consider consulting the Cognitive Accessibility Task Force for suggestions for this paragraph (and encouraging them to keep it fairly succinct like the others).
    Rationale: This is a challenging area and the terminology and implications of it are complex. Probably it is best to just avoid those issues in this section.
  5. link to How People with Disabilities Use the Web resource — Add something like:

    For a more in-depth exploration of how people with different disabilities interact with web content and tools, How People with Disabilities Use the Web.

  6. copyedit & disability wording review — Edit for more succinct language. Consider using the wording from http://www.w3.org/WAI/intro/people-use-web/diversity where appropriate. A few examples:
    • first paragraph — Reconsider the opening paragraph (that starts "Comprehension of media may be affected by…"). It seems a bit rambling, unfocused, repetitive in itself and of the sections below, and not to have much "meat". (Also, an issue: "may be affected by loss of visual function, loss of audio function" doesn't account for people who are born without such function.) Maybe all you want for an opening paragraph is something like:

      This section provides examples of the accessibility requirements of people with auditory, cognitive, neurological, physical, speech, or visual disabilities to access and comprehend media, including requirements for media formats and media player technologies. For a broader exploration of how people with different disabilities interact with web content and tools, How People with Disabilities Use the Web.

    • current wording:

      People with physical disabilities such as poor dexterity, loss of limbs, or loss of use of limbs may use the keyboard alone rather than the combination of a pointing device plus keyboard to interact with content and controls, or may use a switch with an on-screen keyboard, or other assistive technology. The player itself must be usable via the keyboard and pointing devices. The user must have full access to all player controls, including methods for selecting alternative content.

      Could be edited to something like:

      Some people with physical disabilities such as limited muscle control (including tremors, lack of coordination, and paralysis), pain that impedes movement, or missing limbs cannot use a keyboard or mouse to interact with content and controls. Some use a keyboard but not a pointing device, some use a switch with an on-screen keyboard, and some use other assistive technology. The media player must be usable with only a keyboard, including access to all player controls and selecting alternative content.

    • current wording:

      People who are blind cannot access information if it is presented only in the visual mode. They require information in an alternative representation, which typically means the audio mode, although information can also be presented as text. It is important to remember that not only the main video is inaccessible, but any other visible ancillary information such as stock tickers, status indicators, or other on-screen graphics, as well as any visual controls needed to operate the content. Since people who are blind use a screen reader and/or refreshable braille display, these assistive technologies (ATs) need to work hand-in-hand with the access mechanism provided for the media content.

      Could be edited to something like:

      People who are blind cannot access visual information in videos, player controls, status indicators, etc. They need the information in an alternative representation of audio or text. People who are blind use a screen reader and/or refreshable braille display, and media content needs to be operable with these assistive technologies (ATs).

    • Chunking information — Consider breaking up longer sections into paragraphs &/or using bullets. e.g.:

      People who are hard of hearing may be able to use some audio material, but may have difficulties:

      • Certain types of sound may be hard to discriminate, such as ???;
      • If the audio contains frequencies they can't hear, they may miss those parts;
      • Audio masked by background noise or distortion;
      • Audio which is too quiet, or of poor quality.

      Speech may be challenging if it is too fast and cannot be played back more slowly. Information presented using multichannel audio (e.g., stereo) may not be perceived by people who are deaf in one ear.

  7. categories — WAI has been using the following categorization: auditory, cognitive, neurological, physical, speech, or visual disabilities. While we like the breakdown of the categories in this document, please consider adding a higher level to the subheads so that they more clearly align with How People with Disabilities Use the Web and other WAI material—
    either
    2.1 Auditory: Deafness
    2.2 Auditory: Hard of Hearing
    or
    2.1. Auditory
    2.1.1. Deafness
    2.1.2.Hard of hearing

Options EOWG Discussed

EOWG discussed the following options and decided to suggest the third option:

  1. Link to Diversity — Rather than having much text in MAUR, refer readers to Diversity of Web Users.
    Pro: We generally prefer to have information in one place and point to it from other places, rather than have similar information in multiple documents.
    Cons: Some readers won't follow the link so it's good to give them some info in this doc. Diversity of Web Users has much more info than people need for the context of this doc and that could be distracting.
  2. Use wording from Diversity — In MAUR section, use the categories and intro wording from the Diversities doc. Then include the specific related to media from MAUR and Diversities docs.
    Pros: Diversities wording is well vetted. Consistency is good.
    Cons: For MAUR, EOWG likes the categories broken down into the lower levels (e.g., Blindness, Low vision, Deafness, Hard of hearing,…) rather than the higher levels in the Diversities doc (Auditory, Cognitive and neurological, Physical, Speech, Visual).
  3. Leave MAUR structure & edit — Edit MAUR section to use wording from Diversities page where it fits, and to clean up the language.




Archived Old Comments

Comments from EOWG on Media Accessibility User Requirements W3C Editor's Draft 14 December 2011

EOWG:

Comments:

  • Section 1, Media Accessibility CheckList: Suggestion: The media accessibility checklist is a treasure trove of detail for developers and implementers. This seems like a good place to mention something like: "Developers and implementers may want to refer directly to this checklist when implementing audio and video elements". {Paul, Feb 4, 2014}
  • Section 3.1, Described video: DV-7: Clarification: Is the term "provider" meant to be the same as an author or user, or something else? Provider may be interpreted as broadcaster or cable company. {Paul, Feb 4, 2014}
  • Section 3.5, Content navigation by content structure, Navigating ancillary content: Suggestion: The Mozilla Popcorn examples flow perfectly with this section...however, should specific examples like this be included? They might appear dated to future readers of this document. {Paul, Feb 4, 2014}
  • General content: nit-picky suggestion: The words "alternate" (used 5 times) and "alternative" (used 54 times) are used in this document interchangeably. Instances of "alternate" as used in this document should be changed to "alternative". {Paul, Feb 4, 2014}
  • copyediting:
    • comment {name}
    • Abstract: Typo: "...to the needs of users with disabilties..." {Paul, Feb 4, 2014}
    • Abstract: Suggestion: language "Technology listed here is here because..." > "Technology is listed here because..." {Paul, Feb 4, 2014}
    • Abstract: Suggestion: language "This document is our inventory..." > "This document is an inventory..." {Paul, Feb 4, 2014}
    • Section 3.5, Content navigation by content structure: typo/grammar: "...newscasts have individual stories usually wrapped within a larger structures called news, weather..." > "...newscasts have individual stories, usually wrapped within larger structures called news, weather..." {Paul, Feb 4, 2014}
    • Section 3.8, Sign translation: typo: "Strong authoring guidance for content creator will..." > "Strong authoring guidance for content creators will..." {Paul, Feb 4, 2014}
    • Section 4.1, Access to interactive controls / menus, KA-6, note: typo: "...encouraging publishers to us @autoplay..." > "...encouraging publishers to use @autoplay...". {Paul, Feb 4, 2014}
    • Section 4.4, Production practice and resulting requirements: paragraph 6: typo: "It is a understood" > "It is understood..." {Paul, Feb 4, 2014}
    • Section 4.7, Requirements on the use of the viewport: VP-5: typo: "...where also controls are also usually rendered..." > "...where controls are also usually rendered..." {Paul, Feb 4, 2014}