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

Return to this mailing list's archives

From: Walser, Kate
Date: Sun, Oct 22 2006 1:05 PM
Subject: Group A: holes in addressing Web-basedapplications

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

From: Jonathan Avila
Date: Sun, Oct 22 2006 1:35 PM
Subject: Re: Group A: holes in addressingWeb-basedapplications

//[Kate Walser wrote] 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)). //

[my additions] JAWS for several versions now ignore display:none and
visibility:hidden on elements. If a screen reader doesn't obey these items
I believe it is the fault of the screen reader or assistive technology and
not any standards. The only case I know of that JAWS see these elements is
when they are inside a label tag, then JAWS assigns this text as the label
of a form field.

However, you do bring up a good point with positional CSS. Many people will
place data off the screen visually but it is still read/interpreted by
assistive technology because it does not use display:none or
visibility:hidden. I believe this is an incorrect use of positional CSS and
does cause accessibility issues.

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

[my addition] It's not so much with focus changing but focus changing
without user knowledge. For example, when I press up/down arrow in a combo
box I do not expect focus to change. However, if I enter data into a combo
box and then tab, I my expect the portions of the page to refresh with
updated data. In this case using the .focus() method is entirely acceptable
because it will then causes assistive technology to alert the user of the
new location on the page. It may be helpful then to include text on the
page alerting the user that the form dynamically updates etc. Hence a
greater need for 1194.41.

Jonathan

_____

From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Walser,
Kate
Sent: Sunday, October 22, 2006 3:01 PM
To: = EMAIL ADDRESS REMOVED =
Subject: [teitac-websoftware] Group A: holes in addressing
Web-basedapplications



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