[WG: Accessibility] Accessibility with invisible links/text

Tue Apr 20 09:31:03 PDT 2010

Hi Everyone--

Two quick thoughts. First, Brian, this is a great description of the 
issues with "display:none" and enabling/disabling content!

Second, Beth can you describe why you are enabling/disabling content and 
the circumstances for doing so? That may also help our understanding of 
the implications for screen reader users.

Thanks!

Mike

Richwine, Brian L wrote:
> Hello Beth,
>
> Thanks for your question.
>
> We have experience with the two most popular screen readers on the windows platform, JAWS and WindowEyes. Both of these screen readers honor the "display:none" CSS rule. 
>
> In our experience, problems with page content that is alternately "enabled/disabled" with CSS isn't with CSS's role in the technique, but in three other places: 
>   1. The user needs to be aware they can enable/disable the content
>   2. The method used to trigger the toggling of the enabling/disabling
>   3. Whether or not the user is aware of the content when it becomes "enabled"
>
> First, the user needs to be aware that they can enable the disabled content. If a graphic icon is used as the triggering element, then this can be through an appropriately descriptive alt attribute on image tag. If the triggering element is a link, be sure the link text itself is unique to the page and adequately describes what activating the link will do.
>
> Second, if the enabling and disabling of the content is triggered by a user action (clicking on an "expand/close" icon, etc.), then that trigger action needs to be fully operable by the keyboard alone and not a mouse only function. Three things need to be considered here:
>   1. The element with the JavaScript event handler that performs the toggling function must be able to receive keyboard focus.
>   2. The toggle function should not be triggered by the element receiving or losing focus. This is so the user can navigate the page (i.e.: tab through it) and not trigger any unwanted page actions.
>   3. The toggle event itself can be triggered by the keyboard (pressing "Enter").
>
> Third, once the content is enabled, it should be apparent to the screen reader user. This usually means using JavaScript to set focus on the newly enabled content. New techniques using the WAI-ARIA live region technologies are being developed that may work here as well, but are new enough that how they work in all of the Web browser / adaptive technology combinations isn't yet well known. 
>
> Obviously, a lot of the above depends on the role the content and the function that enabling and disabling of the content plays in the use of the tool. After ensuring the coding techniques used are sound, the best way to know that a particular feature is accessible is to have it tested with real adaptive technology. We'd be happy to test any designs you come up with. The Sakai Accessibility Working Group has many participants who are native users of adaptive technologies and would be happy to test a design for you and make sure it is both functionally accessible and provides a good user experience.
>
> Feel free to join the Accessibility Working Group's email list if you haven't already, and ask the group your accessibility questions:
> http://collab.sakaiproject.org/mailman/listinfo/accessibility
>
> The working group also hosts a bi-monthly teleconference where you would be free to ask any questions. The next teleconference is this Thursday, April 22 at 2 PM Eastern time. The number is (812) 856-3600 and the PIN is 002264# 
>
> p.s.: For more information on accessible mouse and keyboard events, see these techniques for WCAG 2.0:
>
> SCR2: Using redundant keyboard and mouse event handlers:
>   http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/SCR2
>
> SCR20: Using both keyboard and other device-specific functions
>   http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/SCR20
>
> SCR35: Making actions keyboard accessible by using the onclick event of anchors and buttons
>   http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/SCR35
>
> Sincerely,
> The ATAC Web Accessibility Team
> UITS Adaptive Technology and Accessibility Centers
>
> Joe Humbert           Mary Stores           Brian Richwine         Margaret Londergan
> johumber at iupui.edu    mstores at indiana.edu   brichwin at indiana.edu   londerga at indiana.edu 
> Office 317-274-4378   Office 812-856-2760   Office 812-856-2757    Office 812-856-2763
>
> -----Original Message-----
> From: Beth Kirschner [mailto:bkirschn at umich.edu] 
> Sent: Monday, April 19, 2010 4:14 PM
> To: Richwine, Brian L; Humbert, Joseph A
> Subject: Accessibility with invisible links/text
>
> Hi Brian & Joe,
>
>     I've got what I hope is a quick accessibility question: would  
> either of you have an opinion on some HTML markup we've just put into  
> our OSP tools? We have a link that we alternately "enable/disable"  
> with a "display: none;" style. Do you think this sort of markup would  
> cause any trouble with Screen Readers?
>
> Thanks,
> - Beth
>
> _______________________________________________
> accessibility mailing list
> accessibility at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/accessibility
>
> TO UNSUBSCRIBE: send email to accessibility-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
>
>
>   