How changes in visibility are dealt with

classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: How changes in visibility are dealt with

Aaron Leventhal-3
Regarding display: none vs. visibility: hidden

Display: none completely removes the object from the layout.
Visibility: hidden objects still take up space

In the example of a calendar application with a tabbed
day/week/month/year view, the script could hide the 3 non-current views
by either:
1) removing them from the DOM
2) using display:none

We don't know what the author is going to do, but option 2 is the most
common from what I've seen. It's more convenient for Mozilla to remove
display: none objects from the object hierarchy completely because we
get NULL for the layout object. All of our code in the accessibility
module that uses the layout object would need to get null checks added.
Besides, I think it's easier for the AT to see items 1 & 2 the same way,
since it should be the same for the user.

Visibility:hidden is really in the same boat. We currently remove this
from the object hierarchy currently because it's convenient for us to
treat all hidden objects the same way. The author's intention was to
hide it, and it's a bug in SVG that it's in the tab order (it's not in
the tab order for HTML). Although we could keep it in the accessibility
object hierarchy and simply mark it INVISIBLE (or not VISIBLE in the
case of ATK), I see no real clear reason to do that at the moment.

Here are some techniques that can be used to put hidden text for screen
reader users in a page:
http://www.webaim.org/techniques/css/invisiblecontent

- Aaron
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: How changes in visibility are dealt with

Jonathan Chetwynd
Aaron,

Is there a standards based reason for stating that hidden objects  
should not be in the tab order?

Your assertion that the authors intention to hide a link from the  
sighted audience seems reasonable, however to make claims about there  
intentions regarding keyboard users does not carry a similar conviction.

regards

Jonathan Chetwynd



On 2 May 2006, at 15:24, Aaron Leventhal wrote:

Regarding display: none vs. visibility: hidden

Display: none completely removes the object from the layout.
Visibility: hidden objects still take up space

In the example of a calendar application with a tabbed day/week/month/
year view, the script could hide the 3 non-current views by either:
1) removing them from the DOM
2) using display:none

We don't know what the author is going to do, but option 2 is the  
most common from what I've seen. It's more convenient for Mozilla to  
remove display: none objects from the object hierarchy completely  
because we get NULL for the layout object. All of our code in the  
accessibility module that uses the layout object would need to get  
null checks added. Besides, I think it's easier for the AT to see  
items 1 & 2 the same way, since it should be the same for the user.

Visibility:hidden is really in the same boat. We currently remove  
this from the object hierarchy currently because it's convenient for  
us to treat all hidden objects the same way. The author's intention  
was to hide it, and it's a bug in SVG that it's in the tab order  
(it's not in the tab order for HTML). Although we could keep it in  
the accessibility object hierarchy and simply mark it INVISIBLE (or  
not VISIBLE in the case of ATK), I see no real clear reason to do  
that at the moment.

Here are some techniques that can be used to put hidden text for  
screen reader users in a page: http://www.webaim.org/techniques/css/ 
invisiblecontent

- Aaron
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility

_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: How changes in visibility are dealt with

Aaron Leventhal
Jonathan Chetwynd wrote:
>
> Is there a standards based reason for stating that hidden objects
> should not be in the tab order?
This is the best that I know of for it, but we should ask someone from WCAG.


    § 1194.21 Software applications and operating systems.

(c) A well-defined on-screen indication of the current focus shall be
provided that moves among interactive interface elements as the input
focus changes. [ ... ]

It seems that putting visibility:hidden in the tab order require a not
well-defined (confusing), on-screen indication of focus.

- Aaron

_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

RE: How changes in visibility are dealt with

jsp (Bugzilla)
In reply to this post by Aaron Leventhal-3
If there's no standard, it may help to apply the principle of least astonishment (http://c2.com/cgi/wiki?PrincipleOfLeastAstonishment).  Personally, as a user with normal vision, I'd be astonished if a) I could tab to a part of a page that is to all appearances empty and/or b) activating it caused some behavior that I couldn't determine in advance (as could happen if, for example, the active element is a button).

Note that if hidden elements are included in the tab order, the question of whether or not to allow activation with a pointer must be addressed.  Allowing it provides consistency, but the behavior is potentially even more astonishing.  Suppose a user makes a spurious mouse click on the affected region for whatever reason.  Without a focus rectangle indicating that the region is live, he or she will have no way to understand why navigation occurred.  Disallowing pointer activation means some elements are only available for keyboard activation, which makes the page less accessible for pointer users.

In summary, it makes sense to me that hidden elements should not be in the tab order because it minimizes the potential for astonishing behavior.

I suppose I should introduce myself now.  I'm a software engineer responsible for the Web implementation of a medical guidance system (see www.pkc.com), and I've been lurking on this list for years to monitor developments that may affect the accessibility of our product.

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Aaron Leventhal
Sent: Tuesday, May 02, 2006 11:09 AM
To: [hidden email]
Subject: Re: How changes in visibility are dealt with

Jonathan Chetwynd wrote:
>
> Is there a standards based reason for stating that hidden objects
> should not be in the tab order?
This is the best that I know of for it, but we should ask someone from WCAG.


    § 1194.21 Software applications and operating systems.

(c) A well-defined on-screen indication of the current focus shall be
provided that moves among interactive interface elements as the input
focus changes. [ ... ]

It seems that putting visibility:hidden in the tab order require a not
well-defined (confusing), on-screen indication of focus.

- Aaron

_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: [Bulk] RE: How changes in visibility are dealt with

Jonathan Chetwynd
well the reasons why hidden might be excluded from the tab order have  
had a small consideration.

However we now need to consider the authors intention in implementing  
hidden, and how the user is intended to reach hidden links.
Is it likely that someone without vision might be able to take this  
action?
Is there any conceivable benefit in them taking this action?

To state it another way, presumably the author intends it to be  
possible for every user to reach every link.
how would a blind user benefit from not being able to visit a  
(hidden) link?
how would they perform an appropriate action that enabled them to  
visit the previously hidden link?
for comparison the sighted user might mouseover an area, thus  
revealing a link.

furthermore it is not inconceivable that tabbing to a hidden link,  
would reveal it. **

WCAG may have formed some opinion on this matter, as suggested,  
however without a consensus it will be more difficult to progress.


regards

Jonathan Chetwynd

**the borders of links at http://www.peepo.co.uk currently perform  
this function for visible links.



_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
12