W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > January to March 2012

Re: HTML-A11Y TF Text Subteam Request

From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Date: Sat, 31 Mar 2012 22:56:39 +0200
To: Steve Faulkner <faulkner.steve@gmail.com>
Cc: James Nurthen <james.nurthen@oracle.com>, Joshue O'Connor <joshue.oconnor@cfit.ie>, Protocols and Formats Working Group WG <w3c-wai-pf@w3.org>, w3c-wai-gl@w3.org, HTML Accessibility Task Force <public-html-a11y@w3.org>, John Foliot <john@foliot.ca>, Judy Brewer <jbrewer@w3.org>, Laura Carlson <laura.lee.carlson@gmail.com>
Message-ID: <20120331225639689024.f7035972@xn--mlform-iua.no>
Steve Faulkner, Thu, 29 Mar 2012 15:51:17 +0100:

I may have misunderstood a detail or two here, but, some questions:

> in regards to non visible tab stops, its pretty cut and dried.
> 
> this is a violation of 
> WCAG 2.0 2.4.7 Focus Visible: Any keyboard operable user interface 
> has a mode of operation where the keyboard focus indicator is 
> visible. (Level AA) 

OK. But in case of a link in the fallback of a canvas element, then why 
does it not break with WCAG 2.0 that the link (in canvas’ visually 
hidden fallback) is included in the tabbing order of the page? (Tested 
in IE9, and this is also how I understand that it is planned to work.)

Secondly, with regard to aria-describedBY pointing to hidden content, 
then isn't the aria-describedBY comparable to @longdesc in the sense 
that only *some* users see it/care for it? I ask because, with regard 
to @longdesc, then it can point to a hidden section (hidden via CSS - 
let's keep @hidden out of this) which, as soon as the longdesc link is 
activated, becomes visible, with the consequence that possible tab 
stops inside then made visible content, is made available. And 
likewise: *If* to follow an aria-describedBY "link" to a hidden section 
makes the hidden section visible, then what is the problem?

I relate these two issue because, when Maciej and Jonas discussed 
aria-describedby pointing to hidden content, then they too did the same.

A problem in the debate is @hidden versus hidden: Currently HTML5 says 
that @hidden implies that @aria-hidden=true is also set - which, to me, 
means that e.g. doing div[hidden]{display:block} means that the element 
becomes visible — but still hidden to AT, due to the @aria-hidden=true. 
(Am I not right in this?)

Therefore, might it not actually have been simpler if @hidden did *not* 
imply @aria-hidden=true? Because, in that case one could simply use CSS 
to make it visible - and accessible - to anyone.

Leif H Silli


> On 28 March 2012 19:56, Janina Sajka <janina@rednote.net> wrote:
>> James, Joshue, and All:
>> 
>> The Text Subteam of the HTML-A11Y Task Force has been discussion the
>> on-screen behavior of tab accessible hidden data. We believe it would be
>> very helpful if the HTML Techniques TF could provide appropriate
>> guidance to authors regarding the UI implications of doing this.
>> 
>> I believe Laura Carlson is aware of problematic examples in the wild, so
>> I've cc'd her and request that she reply with a pointer or two.
>> 
>> Here's the relevant extract from our minutes at:
>> http://lists.w3.org/Archives/Public/public-html-a11y/2012Mar/0389.html

>> 
>> <begin excerpt>
>> 
>>   JF - this *does* work, but with lousy UI interaction
>> 
>>      if you place tab-focusable content off screen it breaks UI
>>      behavior
>> 
>>         so it *does* work, but it introducing contraventions to WCAG
>>         reqs
>> 
>>            and so for that reason is unacceptable
>> 
>>               Janina - Josh and James have begun an HTML5 / WCAG
>>               techniques Task Force (joint TF with PF)
>> 
>>                  JF - so this needs to be captured in that group as
>>                  well
>> 
>>                     <janina> x/co-chair/co-chair/
>> 
>>                        Janina - be sure to capture that a table with 6
>>                        rows, 6 columns would introduce 36 tab-stops off
>>                        screen
>> 
>> <end excerpt>
>> 
>> Thank you for your consideration on this issue.
>> 
>> Janina
>> 
>> --
>> 
>> Janina Sajka,   Phone:  +1.443.300.2200
>>                sip:janina@asterisk.rednote.net
>> 
>> Chair, Open Accessibility       janina@a11y.org
>> Linux Foundation                http://a11y.org

>> 
>> Chair, Protocols & Formats
>> Web Accessibility Initiative    http://www.w3.org/wai/pf

>> World Wide Web Consortium (W3C)
>> 
>> 
> 
> 
> 
> -- 
> with regards
> 
> Steve Faulkner
> Technical Director - TPG
> 
> www.paciellogroup.com | www.HTML5accessibility.com | 
> www.twitter.com/stevefaulkner
> HTML5: Techniques for providing useful text alternatives - 
> dev.w3.org/html5/alt-techniques/
> Web Accessibility Toolbar - 
> www.paciellogroup.com/resources/wat-ie-about.html 
> 
Received on Saturday, 31 March 2012 20:57:22 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 31 March 2012 20:57:24 GMT