- From: Ian Jacobs <ij@w3.org>
- Date: Tue, 23 Nov 1999 23:52:26 -0500
- To: keren beth moses <kmoses@students.uiuc.edu>
- CC: w3c-wai-ua@w3.org
keren beth moses wrote:
>
> Guideline 4:
> "In order to access content, some users may require that it be rendered in
> a manner other than <remove> what </remove> <add> that which </add> the
> author intended."
> "Note. The checkpoints in this guideline apply to all content,
> <remove> in </remove> including alternative representations of content."
yes.
> Checkpoint 5.2 Techniques:
> "Write output to and take input from standard system APIs rather than
> <remove> direct </remove> <add> directly </add> from hardware controls
> where possible."
yes.
> Checkpoint 5.6 Techniques:
> "It is important to note that DOM is designed to be used on a server as
> well as a client and therefore <remove> many </remove> <add> a lot of
> </add> user interface-specific information such as screen coordinate
> information is not relevant and not addressed by the DOM specification."
> "Note. The WAI Protocols and Formats Working Group is focusing its
> efforts on the DOM as the conduit from which to extract accessibility
> information <remove> from and to </remove> <add> and </add> enhance the
> accessibility of a rendered document through a user agent. <remove> It is
> this are should concentrate on </remove> <add> We should concentrate in
> this area </add> for providing access to user agent documents."
I propose removing the last sentence entirely.
> Checkpoint 5.8 Techniques:
> "Most major operating system platforms provide a series of design and
> usability guidelines <remove> , </remove> <add> ; </add> these should be
> followed when possible (see platforms below)."
Yes.
> Checkpoint 6.1 Techniques:
> "The "accesskey" attribute ([HTML40], section 17.11.2) for assigning
> keyboard commands to active components such as links <remove> , </remove>
> and form controls."
Yes.
> Guideline 7:
> "Sequential access (e.g., line scrolling, page scrolling, tabbing access
> through active elements, etc.) means advancing through rendered <add> text
> </add> in well-defined steps (line by line, screen by screen, link by
> link, etc.) forward and backward."
Yes.
> Frame Techniques (link from Checkpoint 7.1 Techniques):
> "If a page does not have a list of links within <remove> in </remove> a
> frame available outside the frame, make the list available outside the
> frame."
Yes.
> "For people with visual impairments who <remove> are </remove> enlarge
> text on the screen to improve readability, frames become distorted and
> unusable."
Yes.
> "If <remove> no frames </remove> <add> NOFRAMES (all caps) </add>
> information is present it should also be rendered so the user can
> optionally use that view of the information."
Yes.
> Checkpoint 7.3 Techniques:
> "Providing table summary information <remove> , </remove> when first
> navigating to a table allows the nature of a table to be easily
> determined."
I propose other edits as well to make less passive.
> "The user would have the option of navigating to the <remove> forth
> </remove> <add> fourth </add> cell of the parent table, or burrowing into
> the table within this cell."
yes.
> Checkpoint 7.6 Techniques:
> "Allow users to search closes time stamp from <awkward> a text stream or a
> media elements or links </awkward> and find other media elements active at
> the same time." (I'm not sure how to fix that one. At least make media
> element singular (to go with the article "a"), but there may be more
> corrections needed.)
How about:
Allow users to find all media elements active at
a particular time in the presentation.
> Guideline 8:
> "Provide information about the resource structure, viewport structure,
> element summaries, etc. that will <remove> assist </remove> <add> help
> </add> the user understand <remove> their </remove> <add> his or her
> </add> browsing context."
How about (I was just working on this one!):
Provide information about resource structure,
viewport structure, element summaries, etc. to help the
user understand browsing context.
> "Orientation mechanisms such as these are expecially important to users
> who view content through serial means such <add> as </add> speech or
> braille..."
yes.
> Checkpoint 9.3 Techniques:
> "If the submit button is not the last control in the form, and no controls
> after it have been <remove> focussed </remove> <add> focused </add>, put
> up a dialog pointing this out/asking if the user has filled in the
> information after the button."
yes.
> Checkpoint 11.3 Techniques:
> "For example, documentation of what user agent features may be activated
> with a single <remove> keystoke </remove> <add> keystroke </add>, voice
> command, or button activation is an important part of the user interface
> to users <add> with </add> visual impairments, some types of movement
> impairments, or multiple disabilities."
Yes, I had already fixed this.
Thank you again Keren for the very helpful review, complete with
suggested changes!
- Ian
--
Ian Jacobs (jacobs@w3.org) http://www.w3.org/People/Jacobs
Tel/Fax: +1 212 684-1814
Cell: +1 917 450-8783
Received on Tuesday, 23 November 1999 23:51:58 UTC