W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > January to March 2005

RE: Javascript question

From: John Foliot - WATS.ca <foliot@wats.ca>
Date: Thu, 6 Jan 2005 11:16:35 -0500
To: "'John Carpenter'" <John.Carpenter@pdms.com>, <w3c-wai-ig@w3.org>
Message-ID: <000801c4f40b$196e4090$6601a8c0@bosshog>

John Carpenter wrote:
> "8.1 Make programmatic elements such as scripts and applets directly
> accessible or compatible with assistive technologies [Priority 1 if
> functionality is important and not presented elsewhere, otherwise
> Priority 2.]" 
> The popup menu is not really compatible with, say, a screen-reader as
> such.  However, its existence does not seem to do any harm to these
> users (it's simply invisible to them).  Would the fact that
> the menu is
> invisible to users with assistive technologies fail us on this
> checkpoint? 

John, the issue is, is the same "functionality" available to the users of
adaptive technology?  Expecting an identical user experience is not (IMHO)
the goal, but rather a functionally similar experience.  The flyout menu
links are to: "Budget, Banking, Business, E-Business..."  however, if I
click on the "main" link - Business - (if JS were disabled say), then it
*should* take me to a page which provides links to those very same
"sub-links" (It doesn't... I cannot see/find a link to Business or
E-Business).  8.1 further addresses applets (remember them?), or other
objects which may contain independent user interfaces (say for example an
embedded RealMedia file)... Are the embedded controls accessible to adaptive
tech. (This is often an issue with improperly built Flash files that cannot
be stopped or started by AT agents).  Your flyout menu has more to concern
itself with in Checkpoint 6.3 "Ensure that pages are usable when scripts,
applets, or other programmatic objects are turned off or not supported. If
this is not possible, provide equivalent information on an alternative
accessible page." (see my comment above)  As others have pointed out, there
are other ways of achieving this same type of effect, using CSS

> "9.3 For scripts, specify logical event handlers rather than
> device-dependent event handlers."
> I'm still unsure as to the difference between 8.1 and 9.3,
> but as far as
> I can tell HTML does not have adequate event handlers for doing this.
> Would making the menu accessible via a keyboard be enough compliance
> with this checkpoint? 

On-mouseover is a device dependant event handler (what happens if you are
not using a mouse?);  on-focus is device independent, so essentially yes,
(although it could be argued that keyboards are "devices" as well <grin>,
but the intent is to make it device agnostic...)  Currently, when tabbing
through your menu items, I do not get the "flyout" when I focus on
"Business" (for example)

> "3.4 Use relative rather than absolute units in markup language
> attribute values and style sheet property values."
> Are pixels classified as relative units?  (For menu width, not font
> size) 

The grand debate.  By definition, pixels are relative, however, we don't
believe that it is pragmatic to treat pixels as a relative unit like % or
em, despite the fact that it may technically be a relative unit. (see:
http://wats.ca/articles/pixelsarerelative/65 for further discussion).  That
said, there are appropriate times to use pixels (images for example), and
possibly page elements such as "menus".  However, what happens when text is
enlarged on your page?  Does the "fixed" width of your Menu impact on
display/usability/accessibility?  Then you have a problem.  But using
pixels, in and of itself, is not an issue, as long as it "degrades"
gracefully.  (See also: http://wats.ca/resources/relativesizing/20)


John Foliot  foliot@wats.ca
Web Accessibility Specialist / Co-founder of WATS.ca
Web Accessibility Testing and Services
http://www.wats.ca   1.866.932.4878 (North America) 
Received on Thursday, 6 January 2005 16:16:42 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 13 October 2015 16:21:30 UTC