Re: HTML-A11Y TF Text Subteam Request

Thanks for mentioning the draw focus ring method.

So it seems that your demo from September 2010 [1] (in which you 
claimed that IE9 implements the interactive canvas subtree "as per the 
HTML5 specification") did not include the 'cut and dried' visible focus.

Another thing with that demo is that you set the <canvas> to role=img. 
Given that role=img means that the screen reader SHOULD see the element 
as textually empty - including that it it "flattens" interactive 
elements, that seems questionable, to me.

Btw, I found a demo that takes the opposite approach: Instead of 
creating a interactive subtree, it places a transparent image map above 
the canvas, with interactive image map spots above the interactive 
regions of the canvas. [2] This seems like a useful technique for 
making canvas accessible.

But I still wonder about aria-describedBY pointing to a invisible 
region: If activation of describedBY's idref *reveals* - make visible - 
that region, is there then a problem?

[1] http://www.paciellogroup.com/blog/misc/fronteers2010/example.html

[2] http://zreference.com/image-map-canvas/


Leif H Silli

Steve Faulkner, Sun, 1 Apr 2012 10:52:20 +0100:
> 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.
> 
> Regards
> Steve
> 
> 
> 
> Sent from my iPhone
> 
> On 31 Mar 2012, at 21:56, Leif Halvard Silli  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 14:00:55 UTC