- 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>
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:15 UTC