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

Re: HTML-A11Y TF Text Subteam Request

From: Steve Faulkner <faulkner.steve@gmail.com>
Date: Sun, 1 Apr 2012 10:52:20 +0100
Message-Id: <09F1CF6C-E00A-4E87-9897-1D98AB9FA5FF@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" <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>
To: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
A focusable element in the canvas subtree needs to have a programmatically defined focus ring if it receives focus. That is what the canvas draw focus ring method is for.


Sent from my iPhone

On 31 Mar 2012, at 21:56, Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> wrote:

> 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 Sunday, 1 April 2012 09:56:42 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 1 April 2012 09:56:43 GMT