[WG: Accessibility] Fwd: Accessibility with invisible links/text

[Beth Kirschner]

[re-sending to accessibility list, now that I'm a member]

Begin forwarded message:

> From: Beth Kirschner <bkirschn at umich.edu>
> Date: April 21, 2010 8:59:13 AM GMT-04:00
> To: "Richwine, Brian L" <brichwin at indiana.edu>
> Cc: "accessibility at collab.sakaiproject.org WG" <accessibility at collab.sakaiproject.org 
> >, "Humbert, Joseph A" <johumber at iupui.edu>, "Stores, Mary A." <mstores at indiana.edu 
> >
> Subject: Re: Accessibility with invisible links/text
>
> Brian,
>
>   Thanks so much for the very informative overview of the issues  
> with displaying and hiding text. It gives us much food for thought  
> for our application. The element we are alternatively displaying and  
> hiding is a link to "edit the selected form". When the link is  
> hidden, static text is displayed in it's stead. The link is hidden/ 
> displayed based on the ownership of the selected form (is the user  
> authorized to edit the selected form). We'll take a look at all the  
> other issues you mention here to make sure the page is as accessible  
> as possible.
>
> Thanks,
> - Beth
>
> On Apr 20, 2010, at 11:41 AM, 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
>>
>>
>>
>