W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > October to December 1999

Re: grammatical/typographical corrections to UA guidelines

From: Ian Jacobs <ij@w3.org>
Date: Tue, 23 Nov 1999 23:52:26 -0500
Message-ID: <383B6F0A.962385DC@w3.org>
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."

> 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."

> 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)."

> 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."

> 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."


> 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."


> "For people with visual impairments who <remove> are </remove> enlarge
> text on the screen to improve readability, frames become distorted and
> unusable."

> "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."

> 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."

> 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..."

> 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."

> 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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:38:24 UTC