W3C home > Mailing lists > Public > w3c-wai-au@w3.org > July to September 2008

Jeanne comments on Part A

From: Jeanne Spellman <jeanne@w3.org>
Date: Mon, 14 Jul 2008 15:10:04 -0400
Message-ID: <487BA48C.4080609@w3.org>
To: AUWG <w3c-wai-au@w3.org>

Still going through Michael's and Reed's comments, but I wanted to at 
least get my first pass of comments on Part A out to the group.

There are a lot so I put them on a web page, Comments on Editors Draft 
of 9 Jul 2008 <http://www.w3.org/WAI/AU/2008/IssuesED20080714>. If it 
makes sense to others, I could take Reeds and Michael's comments and add 
them there, too. Jan, if there is a listing that you would like to see 
them in, let me know and I'll move it all there.

The text follows for those who prefer to read them that way.

It took much longer than I expected, so I don't have comments for Part B 
yet.

jeanne


  Comments on ATAG Editors Draft of 9 Jul 2008

7/14/08


    Introduction:


      Organization

Definition of Authoring tool is normative, but it doesn't say where the 
normative section ends. If the organization part is normative, them we 
need to make sure the “must” and “should” in the Organization section 
conforms to the RFC of Keywords.


      Success Criteria

   1.

      Use of “[Sufficient]” and “[Advisory]”: Why both “” AND [] ? If
      there is something significant about it, it isn't clear what it
      means.

   2.

      Success Criteria Level General: I don't like defining the level of
      support for Accessibility by talking about the restrictions on the
      tool. I don't think it is correct (Universal Design) and could
      easily become a detriment to marketing a product rather than an
      asset. (Most accessible=most limited.) I recommend that we stick
      with the WCAG Level guidelines and define it in terms of the
      barriers to use.

   3.

      A Part A. “Thus people with the widest range of disabilities using
      a wide range of assistive technologies, from voice input and
      eye-tracking devices to screen readers and screen magnifiers, are
      able to access tools in different ways” It would seem to me that
      the “widest range” would apply to AAA, not A.

   4.

      Success Criteria Level AA – Part A. Isn't clear. I couldn't figure
      out what made something AA instead of A or AAA.


      Relationship to WCAG

Last sentence in first paragraph is missing words, or doesn't make 
sense. “...to mean for the particular Web content technologies 
<http://www.w3.org/WAI/AU/2008/WD-ATAG20-20080709/WD-ATAG20-20080709.html#def-Web-Content-Technology> 
that an authoring tool produces and is implemented using (if applicable).“


    Part A


      Guideline A.1 – Facilitate access by AT

   1.

      I think it would be more clear if A.1 were moved to the end of
      Part A, as the last Guideline instead of the first. Then all the
      other things would already be covered, and this is sweeping up the
      last of the functionality by saying that all functionality is
      implemented in the Accessibility API. It duplicates much of A.2.3
      which adds to the confusion.

   2.

      “User Interface “Chrome””. Same problem as UAAG. We need to pick
      terms and be consistent with them. If we use chrome, don't put it
      in quotes. Define it and make it a term. User Interface Chrome is
      redundant.

   3.

      If we are going to put “*(user interface "chrome"
      <http://www.w3.org/WAI/AU/2008/WD-ATAG20-20080709/WD-ATAG20-20080709.html#def-UI-Chrome>,
      content display
      <http://www.w3.org/WAI/AU/2008/WD-ATAG20-20080709/WD-ATAG20-20080709.html#def-UI-Content-Display>)*“
      with each SC, then let's clarify it, e.g. “Applies to user
      interface” or “Applies to content display” or “Applies to both
      user interface and to content display.”

   4.

      Guideline A.1.2 should be the parallel of A.1.1: Ensure that
      non-web based functionality is implemented using the accessibility
      architecture appropriate to the platform.

   5.

      All titles in A.1.2 need editorial work.

   6.

      All the SC for A.1.2 need to be focused on the Accessibility
      Architecture. The word “platform” should be reserved for the “OS”.

   7.

      A.1.2.1 Don't understand: “or leverage existing implementations of
      the architecture.” Recommend we reserve “architecture” for
      “accessibility architecture”. Or find a better word for
      Accessibility APIs (which I know is Windows-centric).

   8.

      I think A.1.2.2 is level AA and A.1.2.3 is level A, but it would
      help if they were explained more clearly.

   9.

      A.1.3: Why should they cite conventions? How does that improve
      accessibility?

  10.

      A.1.3.2: What is Keyboard Configuration? Is that Keyboards
      shortcuts, or is that a standard keyboard, vs. Enhanced vs. Dvorak?


      Guideline A.2 – Perceivable

   1.

      Switch order of SC A.2.1.1 and A.2.1.2.

   2.

      SC A.2.1.1 (existing #) should focus on the view mode rather than
      on the content. For example “An Editing view that renders non-text
      objects also has a view or option where the text-equivalent of the
      object is displayed and is available to accessibility
      architecture. (or whatever word we standardize on)”

   3.

      SC A.2.1.2 (a) should reference A.2.3.1 or we should merge the two.

   4.

      SC A.2.1.2 (b) Can we help Time-Based Media with an in-line
      explanation as well as a link to the definition? It's the first
      time the term is used, and it isn't explained. I suggest “
      Time-Based Media (Audio-Video)”. I like the referral to A.2.2.

   5.

      A.2.2 Success Criteria needs numbering.

   6.

      A.2.2.5(?) Time-based content renderings doesn't seem to belong here.

   7.

      We need to clarify when an audio description is needed and when
      captioning is needed. This whole section seems unclear.

   8.

      SC A.2.3.1 seems to be more applicable to A.1.

   9.

      Need consistent use of “platform”. Recommend that “platform” be
      used when we are discussing the OS/Hardware and a different term
      when referring to the A11y APIs.

  10.

      SC A.2.3.3 needs a better title. Suggest: Alternate Presentation
      of Modified Content.

  11.

      SC A.2.3.4 needs a better title. Access to Text Styling Properties

  12.

      *SC A.2.3.5 needs clarification: Suggest: Meaningful Sequence:*
      When the sequence in which user interface components
      <http://www.w3.org/WAI/AU/2008/WD-ATAG20-20080709/WD-ATAG20-20080709.html#def-UI-Component>
      are presented affect their meaning, the semantic equivalent of
      that sequence is available via the accessibility architecture.

  13.

      SC A.2.3.7 has a typo “edtiable”

  14.

      SC A.2.3.7 belongs in Part B or in A.1 – I don't see why it is here.


      Guideline A.3 – Operable

   1.

      SC A.3.1.1 Keyboard. Add the line from UAAG, “this does not forbid
      and should not discourage providing mouse input or other input
      methods in addition to keyboard operation.”

   2.

      SC A.3.1.6 should be Level A.

   3.

      G A.3.1 Remove Note #2 as it is now part of A.3.1.1. Are Notes
      normative?

   4.

      SC A.3.2.1 Suggest: Data Saved. If the authoring tool ends an
      authoring session due to a time limit, then the user is given an
      interrupting warning and given an option to save the data. If the
      user doesn't act on the warning within several minutes, then the
      data can be expired.

   5.

      SC A.3.6.1 overlaps with A.2. Needs some work to separate and
      discriminate between them.

   6.

      Recommend adding a new AC for Level AAA. “Customized sets of
      keyboard shortcuts [or whatever word we decide to use] can be
      imported and exported.”


      Guideline A.4 – Understandable

   1.

      Merge A.4.1 and A.4.4. Take the SC for Guideline A.4.4 and make
      them the Level A SC for Guideline A.4.1. Broaden the rationale to
      include Documentation.

   2.

      A.4.2.1 also belongs in Operable Keyboard (A.3.1)

   3.

      A.4.3.3 Error is passed in text and available to accessibility
      architecture.

   4.

      Guideline A.4.3 broaden beyond text. Suggest: Note 2. It is
      acceptable to group like actions (e.g typed words, a series of
      backspaces, a series of right-arrow for positioning) ....
Received on Monday, 14 July 2008 19:10:53 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 22 September 2008 15:53:08 GMT