UA guidelines comments

> Table of Contents
> 
>    * 1 Rating and Classification

I think I'd come up with this title a while ago in PA when we had two
different categories (timeliness and priority). Now that we have just
one (Priority level), maybe we could just use "Prioritization" as the
title of the section (I'll make the same comment for the PA guidelines)

>    * 2 General principles of accessible design
>    * 3 Terms and definitions
>    * 4 Provide mechanisms to control rendering
>    * 5 Help the user remain oriented
>    * 6 Help the user navigate
>    * 7 Ensure that user agent accessibility features are apparent
>    * 8 Ensure compatibility with existing accessibility recommendations and
>    * 9 Acknowledgments
>    * 10 References

I would prefer some more catchy heading, as in:
 4 Adjustability 
 5 Predictability 
 6 Navigability 
 7 Visibility 
 8 Compatibility 

> [Priority 1]
>      This guideline must be implemented by user agents as a built-in feature
>      or through compatibility with assistive technology, 

I read that as saying it's OK for UAs to just support an API that
gives access to the document and the browser internals to a level
that a third-party piece can use to implement the guideline.

So when I want to check that a particular UA "Allow the user to
control document style", and if it happens that this UA supports DOM1
- which gives access to the markup, therefore allowing a third party
to take this markup and present it in some other way/style - then I
should conclude that this UA is fine with this guideline.

Maybe that's what we want to say.

I think we need to be a little more specific about the things we think 
have to be built-in and the things we think can be delegated to a
third party. Especially for P1.

This should depend on whether or not there is a "standard" API that
support exposing the feature (unlikely for nagivation things for
instance, therefore they should be built-in), whether or not this is a
feature that's generic enough that it is useful for more than users
going thru an assistive technology, and probably also how complex it
is for the UA developer to implement.

Maybe the technique section (not the technique document) following
each guideline is a good place for us to say what we think should be
built-in and what can be deferred thru an API of some sort.

> the associated guideline. For example, a Priority 3 technique must be
> implemented to provide accessibility, while a Priority 3 technique, may be
> implemented to provide further assistance.

typo I guess.

> All users must be able to access all functionalities of a user agent.
>      Users access these functionalities through controls (menus, buttons,
>      keyboard shortcuts, etc.). Controls should be arranged in a manner
>      consistent with their importance.

I don't really parse this last sentence about consistent/important.
Is that a pure usability issue  ?

> The user interface should be accessible to all users.

sounds like a repeat of the previous heading

>      The interface must be easy to understand regardless of the user's
>      experience, knowledge, language skills, or current concentration level.
>      Where the interface is not accessible, inaccessible functionality must
>      be made available through accessible controls. Part of accessible
>      access includes prompting the user effectively for input and providing
>      useful feedback during and after each task.

If it's about easyness, then this should be reflected in the heading
of the paragraph

> The user interface must accommodate a wide range of individual preferences
> and abilities.
>      Therefore, user interfaces must have redundant controls for the same
>      functionality (e.g., menu, mouse, and keyboard equivalents) and must
>      avoid, for example, mouse-only controls. Redundancy includes offering
>      visual as well as aural representations of a control. User agents must
>      also allow users to customize and configure the controls to meet their
>      needs.

again, the heading sounds too similar, if it's about redundancy, it
should mention it in the heading.

> The user agent must render information in accessible forms.

sounds like another repeat to me

> 3 Terms and definitions

personally, I would push this list at the end. Get the guidelines as
fast as we can.
 
> 4.1 Allow the user to control document styles
> 
> The user must be able to control the colors, fonts and other stylistic
> aspects of a document and to override author styles and user agent default
> styles. Otherwise, users who are blind, have low vision, some types of
> learning disabilities, or any user who cannot or has chosen not to view the
> primary representation of information will not know content of the
> information on the page.
> 
> Techniques
> 
>   1. Allow the user to override author styles and browser defaults, and in
>      particular those properties affecting: font face, font size, foreground
>      and background colors, background images, user selection highlight
>      colors, and user interaction (e.g., hover styles). [Priority 1] [Go to
>      user-preference]
>   2. Allow the user to turn off blinking text or images for all cases when
>      the user agent knows that text or images are blinking. [Priority 1] [Go
>      to user-blink]
>   3. Allow the user to specify custom settings in profiles that may be
>      shared (by other users or software). Preferably, this should be done
>      via style sheets. Furthermore, for convenience, users should be able to
>      name groups of settings and be able to apply them all at once (e.g., by
>      selecting a group by name from a menu). This should also be achieved
>      with style sheets. [Priority 3] [Go to user-portable]
>   4. Allow the user, through a keyboard command, to switch between browser
>      default values and the user profile. [Priority 3] [Go to user-switch]

So here, to be more specific about built-in vs. exposed, I would say
all 4 (maybe the grouping can be taken aside) need to be built-in.


Also, 8.2.2 should be there: ability to turn off CSS.  (in fact, 8.2
should just mention things to support in the language, not thing to do
in the UI)
 
> General techniques
> 
>   1. Give the user access to alternative content (e.g., the "alt" or
>      "longdesc" attributes in HTML or SMIL, the content of OBJECT in HTML
>      4.0). [Priority 1] [Go to alt-content]

built-in

>   2. Allow the user to specify that alternative text and/or long
>      descriptions be rendered in place of primary content. [Priority 1] [Go
>      to alt-rendering]

built-in

>   3. When no alternative text representation is available, indicate what
>      type of object is present. [Priority 1] [Go to alt-no-alt]

I think this technique is too limited.

In the Tool group, we've been working a technique document for
extracting textual equivalents out of a bunch of things.
  http://www.w3.org/WAI/ER/text-equiv
   
We need to say that in the absence of the "normal" textual equivalent, 
UA can try their best using these other techniques. Judgment of
whether or not they comply will be human call anyway.
 
> Techniques for other types of objects
> 
>   1. Allow the user to specify that alternatives to a script be rendered
>      (e.g., in HTML, the content of NOSCRIPT). [Priority 1] [Go to
>      alt-no-script]
>   2. Allow the user to specify that alternatives to a frame be rendered
>      (e.g., in HTML, the content of NOFRAMES). [Priority 1] [Go to
>      alt-no-frame]
>   3. Allow the user to specify that alternatives to a table be rendered
>      (e.g., the value of the "summary" attribute on TABLE in HTML 4.0).
>      [Priority 1] [Go to alt-table-summary]

all built-in
 
> 4.3 Allow the user to choose formatting solutions
> 
> By offering several formatting solutions to users, user agents allow them to
> select the solution most adapted to their needs. For instance, users with
> screen readers will have difficulty understanding some tables whose cell
> contents exceed one line. In this case, if the independent user agent can
> serialize the table (i.e., render it one cell at a time), the screen
> reader's output will not cause confusion. Similarly, some users may require
> that a user agent present an outline view of a document so they may have an
> easier time navigating the document.
> 
> Techniques
> 
>   1. Allow users to specify that tables be formatted serially, based on the
>      type of information in the table. [Priority 1] [Go to
>      table-serialization]
>   2. Allow users to view a document outline constructed from its structural
>      elements (e.g., from header and list elements in HTML). [Priority 2]
>      [Go to document-outline]

I think we should split the table into 
  - just ignore the table markup
  - provide table linearization service
  
and make the first one built-in and the second one thru exposed.
 
> 5.1 Provide information about the content and structure of a document
> 
> Techniques
> 
>   1. When a document is loaded or when requested by the user, make available
>      document summary information. [Priority 2] [Go to orientation-summary]
>   2. Provide a mechanism to indicate visually the presence of an "accesskey"
>      attribute defined for a link or form control. [Priority 2] [Go to
>      orientation-accesskey]
>   3. Provide the user with audio feedback about document loading
>      information. Such information includes whether loading has stalled,
>      whether enough of the page has loaded to begin navigating, whether
>      following a link involves a fee, etc. [Priority 3] [Go to
>      orientation-audio-feedback]
>   4. Provide a mechanism to distinguish visited links from unvisited links.
>      [Priority 3] [Go to orientation-visited-links]
>   5. Allow the user to specify that images used in links must have borders.
>      [Priority 3] [Go to orientation-link-borders]

Sounds like these all need to be built-in, but since they are P2 or
P3, do we care ?

> 5.2 Provide information about elements with associated scripts
> 
> Techniques
> 
>   1. Provide a mechanism for assistive technologies to identify which
>      elements have associated scripts. [Priority 1] [Go to
>      orientation-scripting]

here we already call out "exposed". That's fine.

>   2. Provide information when a script is executed. [Priority 2] [Go to
>      orientation-elements]
>   3. Provide information about document changes resulting from the execution
>      of a script. [Priority 1] [Go to orientation-scripting-changes]

Somehow, I think we need to say that these 2 apply only to UA supporting
scripting languages. If they don't, or don't support this scripting
language, then they just need to expose the fact that there is
something there with a script behavior.

>   1. Provide the user with information about how much of the document has
>      been viewed. [Priority 2] [Go to orientation-doc-position]
>   2. Provide the user with information about which table cell is the current
>      table cell. [Priority 2] [Go to orientation-table-position]
>   3. Support the "rel" and "rev" attributes defined in HTML ([HTML40],
>      section 12.1.2). [Priority 2] [Go to compatibility-html-rel-rev]

rel and rev are more for navigation, no ? at least in LINK
 
> Techniques
> 
>   1. Allow the user to navigate sequentially between links (including
>      elements with long descriptions) or between form controls in the same
>      view. [Priority 1] [Go to navigation-sequentially]
>   2. Allow the user to navigate views (notably those with frame viewports).
>      Navigating into a view makes it the current view. [Priority 1] [Go to
>      navigation-views]

built-in 

> [Ed. In the following text searches, what happens when the search succeeds?
> Is the user selection updated? The focus? Is the viewport moved?]

My preferences: the selection no, focus/viewport yes
 
> Techniques
> 
>   1. Allow the user to search for an element in the current document by its
>      text content. [Priority 1] [Go to navigation-search]
>   2. Allow the user to search for a link in the current document based on
>      its link text or alt text. [Priority 2] [Go to navigation-search-links]
>   3. Allow the user to move the focus directly to a specific link in the
>      current document. [Priority 2] [Go to navigation-link-list]
>   4. Allow the user to move the user selection directly to a specific
>      element in the current document that is not an active element.
>      [Priority 2] [Go to navigation-direct-elements]
>   5. Allow the user to search for an element in the current document by its
>      alternative content (e.g., the value of the "alt" and "title"
>      attributes). [Priority 2] [Go to navigation-search-alt]
>   6. Allow the user to include the text contents of any long descriptions in
>      the text searches described above. However, if matched text occurs
>      within a long description, focus should be moved to the first element
>      in the main document for which the long description was written.
>      [Priority 3] [Go to navigation-search-longdesc]

The result of these search being moving the focus/view, I wonder how
much can be done thru an external piece without having this piece also
doing the presentation. In other words, is it possible for a
third-party using an API to first trap user input, process it, and
then update the focus in the main view.

>   1. Allow users to configure accessibility features easily and directly.
>      [Priority 2] [Go to visibility-configuration]
>   2. Furnish predefined accessibility profiles for common disabilities.
>      [Priority 2] [Go to visibility-profiles]

I guess these two are built-in by transitivity: either the documented
features is built-in, or it isn't, if it is, then the config should be
built-in.
 
> 7.3 Provide accessible documentation

same remark as above: built-in doc if built-in feature
 
>   1. Completely implement Cascading Style Sheets, level 1 [Priority 1] [Go
>      to compatibility-css1]

I'm worried that with a guideline like this one, we declare lynx not
compliant while it is the UA of choice for a lot of blind users...

Does pwWebSpeak implement CSS, I doubt it.

Should we introduce the concept of "mainstream" UA at that point,
vs. specialized UA, and insist on the fact that it's important that
mainstream browsers (NS, IE, Opera, AOL, etc) implement CSS because it
will help author following good design practices ?

In any case, what's really bad is people reinventing their own SS
language.

>   2. Allow the user to turn off author styles represented by author style
>      sheets. [Priority 1] [Go to compatibility-css2-style]
>   3. Allow the user to adjust default values represented by browser style
>      sheets. [Priority 1] [Go to compatibility-css2-default]

should be up in adjustability

>   6. Allow the user to specify user styles through style sheets (see [CSS2],
>      section 6.4). [Priority 2] [Go to compatibility-css2-user]

isn't it the same as
    3. Allow the user to specify custom settings in profiles that may be
      shared (by other users or software). Preferably, this should be done
      via style sheets. 
?

>   1. Support the "longdesc" attribute defined for IMG elements ([HTML 4.0],
>      section 13.2). This attribute may be used to attach additional
>      descriptive information to images. [Priority 1] [Go to
>      compatibility-html-longdesc]
>   2. Support the CAPTION element ([HTML40], section 11.2.2) for rich table
>      captions. [Priority 2] [Go to compatibility-html-caption]
>   3. Support the "summary" attribute for TABLE ([HTML40], section 11.2.1)
>      for table summary information. [Priority 2] [Go to
>      compatibility-html-summary]
>   4. Support the NOSCRIPT element ([HTML40], sections 18.3.1 and 16.4.1) for
>      accessible alternatives to scripts. [Priority 2] [Go to
>      compatibility-html-noscript]
>   5. Support the NOFRAMES element ([HTML40], sections 18.3.1 and 16.4.1) for
>      accessible alternatives to frames. [Priority 2] [Go to
>      compatibility-html-noframes]
>   6. Support the "lang" attribute ([HTML40], section 8.1). [Priority 3] [Go
>      to compatibility-html-lang]
>   7. Support the "tabindex" attribute ([HTML40], section 17.11.1) for
>      assigning the order of keyboard navigation within a document.
>      [Priority 3] [Go to compatibility-html-tabindex]
>   8. Support the "accesskey" attribute ([HTML40], section 17.11.2) for
>      assigning keyboard commands to active elements such as links, and form
>      controls. [Priority 3] [Go to compatibility-html-accesskey]

We shouldn't go into details here: Support HTML4.0 strict
DTD. Both for mainstream and specialized UA.

I think we should mention support of DOM1 too and maybe support for
ECMAScript. 
 
> [WAI-GL-TECHNIQUES]
>      Techniques for "WAI Accessibility Guidelines: Page Authoring", G.
>      Vanderheiden, W. Chisholm, and I. Jacobs, eds. This evolving document
>      is available at:
>      http://www.w3.org/WAI/GL/wai-gl-techniques.

Should not be referenced directly I think. Only thru PA guidelines.

Received on Thursday, 22 October 1998 07:26:49 UTC