Thread Subject: Group A: holes in addressing Web-basedapplications

From: Walser, Kate
Date: Sun, Oct 22 2006 1:05 PM

• Return to this mailing list's archives
• View all messages in this thread
• Next message in thread: Jonathan Avila: "Re: Group A: holes in addressingWeb-basedapplications"
• Previous message in thread: None
• Messages sorted by: Author | Thread | Date

In the thread that started with discussion about accessibility features
(1194.21 b), Alex Li wrote:

"there are still many simple government websites that would not fit so
well with application standards"



Travis Roth added:

"It would seem logical to have some separation between web applications
and content. Some websites are content-oriented whereas others are
applications.

"Also the line between software and web applications is blurring. While
keeping the guidelines separate for now may be most logical, I
anticipate many of the guidelines will overlap as the current trend is
for web applications to simulate the functionality formerly only found
in software applications."



<adding on>

The lines between software and Web applications will continue to blur
though there will still be some pure content sites. It'll be helpful to
identify specific issues related to Web applications versus content
sites and then figure out what we need to do as a solution, be it add,
change, or combine standards.



Adding to the ongoing discussion, here are some holes:

1) The lack of a keyboard provision for Web-based applications has come
up already. This will continue to be an issue with newer rich Internet
applications that have drag and drop capabilities.



2) Entire page or parts of the page refreshing when user takes some
action such as selecting an item from a drop-down list. Savvy developers
have created ways to address this (e.g., have the refresh point to an
anchor tag near the element that caused the refresh so the assistive
technology picks up from there) This will become more important with
rich Internet applications and ability to change screen elements without
server calls. No clear synergy with existing standard - maybe some
synergies with 1194.21 c (input focus).



3) Elements that are hidden from view but still available to the
assistive technology due to how the page has been coded (e.g.,
display:none means it may not show up in the visual version of the site,
but the assistive technology doesn't interpret display:none and will
still present those elements to user). An example is a show/hide toggle
feature where the user with assistive technology never really has the
"hide" option since the assistive technology still finds the "hidden"
elements. Framework-generated sites (e.g., portals) have this problem to
a larger extent when lots of extra code is included and the assistive
technology picks it up. (may have potential synergy with 1194.22 d (info
about identity, function, etc., of element)).



I'll add these to the Wiki Group A page, under a heading "Holes".



Best regards,

Kate



-----------------------------------------------

Kate Walser

Usability Center of Excellence

SRA International, Inc.

4300 Fair Lakes Court

Fairfax, VA 22033

• Next message in Thread: Jonathan Avila: "Re: Group A: holes in addressingWeb-basedapplications"
• Previous message in Thread: None