Re: dynamic content

At 06:59 AM 1/27/99 , you wrote:
>
>> 1.  Provide a fallback page, mechanism, or other form of presentation for
>> dynamic content
>> (HTML examples:  NOFRAMES at the end of each frameset, NOSCRIPT
>> for every script, server-side scripts instead of client-side). [Priority 1]
>
>I disagree with requiring NOFRAMES and NOSCRIPT all the time.
>
I agree with your comment about NOSCRIPT, but at this time I can't see how
we can get around *not* having NOFRAMES as P1.  At some point this should
be handled by the user agent, but until then it is a big enough problem
that I can't see making it a P2.  


>For NOFRAMES, see
>http://lists.w3.org/Archives/Public/w3c-wai-gl/1999JanMar/0044.html 
>(note that I still would like A.9.1 to be lowered to P2, I can't find
>it in the current issue list)
>
I moved it to the closed issues since I thought others agreed that at this
time it needs to be a P1.  If this was a misinterpretation we should put it
on the agenda for tomorrow's call.


>For NOSCRIPT, I don't see what it would be required in the case the
>information in the script is not necessary for the comprehension of
>the page, for example a script that change the color of some button
>when onMouseOver is fired. A.9.3 is better worded currently (only
>required for important information).
>
>More on SCRIPT and DHTML in fact: I think we can spare a checkpoint in
>A.9 or at least of technique on explaining in more details what is
>acceptable (I wouldn't say good) event management. See the message
>  http://lists.w3.org/Archives/Public/w3c-wai-au/1999JanMar/0043.html
>for a start (generated HTML thru script and onLoad vs. purely

>decorative script done with onMouseOver).
>
A discussion on event management is definately needed, but I believe it
goes in the Techniques document.  I believe a checkpoint in either A.11 or
A.12 is the most logical place for it (see below).

>Another example that comes to mind is the case where the HTML event
>mechanism is abused with one event handler for a whole table and a
>script that looks at the x,y mouse coordinate of the click, vs. a set
>of discrete events on each cell.
>
>I agree this is included in other checkpoints as it is general
>accessibility, but we could have a more specific checkpoint on event
>and scripting, like
>  A.9.7 When using HTML events and scripting, ensure this is done in 
>        a way that will not preclude device independent navigation.
>

In looking at A.11 and A.12, I propose rewriting them as follows (i.e.,
including your proposed A.9.7 in A.12.4).  

A.11 Elements that contain their own user interface
  should have accessibility built in.

The accessibility of objects with their own interface is independent of
the accessibility of the user agent. Accessibility must therefore be
built into the objects or an alternative must be provided. See the WAI User
Agent guidelines for details. 

Checkpoint:

  1.Where possible, make programmatic elements, such as scripts
     and applets, directly accessible (e.g.,  keyboard operable,
self-voicing) or compatible with assistive technologies (See also A.9).
[Priority 1] if
     information or functionality is important, and not presented
     elsewhere, otherwise [Priority 2]. 
  

A.12 Use features that enable activation of page
  elements via input devices other than a pointing
  device (e.g., via keyboard, voice, etc.).

Someone who is using the page without sight, with voice input, or
with a keyboard (or input device other than a mouse such as  a braille
display) will have a difficult time navigating a page
if operation requires a pointing device (such as a mouse). If a page is
usable via a
keyboard, it is likely that it will also be operable via speech
input, or a command line interface. Access to image maps is
impossible for these users if alternatives are not provided.

Checkpoints:

  1.For image maps, provide alternative text for links. (See also A.1)
     [Priority 1] 
  2.Create a logical tab order through links, form controls, and
     objects (e.g., in HTML, via the "tabindex" attribute or through
     logical page design). [Priority 3] 
  3.Provide keyboard shortcuts to links, including those in
     client-side image maps, form controls, and groups of form
     controls (e.g., in HTML, via the "accesskey" attribute).
     [Priority 3] 
  4. For scripts, watch for logical rather than device-dependent events.
[Priority 1?]


This is more specific that your proposed A.9.7, which may or may not be a
good thing.  also, it seems to fit best here, but I'm open for suggestions.
 I felt that it fit better here because it is not as much an issue of
graceful degredation as it is non-pointing device operable.  also, I didn't
feel that it fit in A.11 because, while it is something that needs to be
done for direct access, A.11 targets objects with their own interface.  I
suppose we could argue if a script creates its own interface, but since the
browser is involved it doesn't seem as separate as what is implied in A.11. 

thoughts?
--wendy

Received on Wednesday, 27 January 1999 10:43:45 UTC