- From: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
- Date: Sat, 9 Mar 2013 13:25:00 +0000
- To: James Craig <jcraig@apple.com>
- Cc: "wai-xtech@w3.org WAI-XTECH" <wai-xtech@w3.org>, Dominic Mazzoni <dmazzoni@google.com>
On 8 March 2013 08:48, James Craig <jcraig@apple.com> wrote: > That would be nice, but not as robust as allowing specific ARIA attributes on generated content, such as: > > .new:before { > content: "\2730"; /* a.k.a. ✰ */ > aria-label: "New!"; > } [snip] > You may have missed the related thread where I mentioned some other examples exposing ARIA: > http://lists.w3.org/Archives/Public/wai-xtech/2013Feb/0027.html > > Here's one example. Screen readers will already speak "expanded" or "collapsed" b/c of aria-expanded, so it'd be better to have the pointer characters not spoken redundantly. > > [aria-expanded="false"]:before { > content: "\25BA"; /* a.k.a. ► */ > aria-hidden: true; /* would otherwise be spoken as "black right-pointing pointer" */ > } > [aria-expanded="true"]:before { > content: "\25BC"; /* a.k.a. ▼ */ > aria-hidden: true; /* would otherwise be spoken as "black down-pointing pointer" */ > } Aren’t these essentially layering violations? Shouldn’t “New!” be in the DOM (because it’s textual information that should be in the document) and the disclosure triangle in the shadow DOM (because it’s widget chrome)? In your original wai-xtech message, you mention: > This represents an accessibility and usability problem for Apple in several production environments I think that this is becoming a problem for some developers may suggest ARIA 1.0 probably should either not have included screen-targeted CSS in text alternative computation or not have included CSS generated text in text alternative computation at all. (Note that’s not the same as saying there should be no programmatic access to the text — that’s what CSSOM provides.) See also older discussions: http://lists.w3.org/Archives/Public/www-style/2010Nov/0432.html http://lists.w3.org/Archives/Public/www-style/2010Nov/0436.html http://lists.w3.org/Archives/Public/www-style/2010Nov/0437.html http://lists.w3.org/Archives/Public/www-style/2012Nov/0323.html It would be interesting to know what happened with: http://www.w3.org/WAI/PF/Group/track/issues/425 mentioned as intended to address non-visual modalities at: http://www.w3.org/WAI.new/PF/comments/details?comment_id=334 Developers used to distinguishing between style and content tend to expect CSS to contain style and be surprised when it is treated as content. Developers not used to distinguishing between style and content are unlikely to know when or how to add additional properties to hide CSS generated text from the accessibility hierarchy. > This example would work with your "decorative-content" property idea, but I think it'd be more robust to allow a few static ARIA roles (note, text, img, maybe more) and attributes (hidden, label, labelledby, maybe more) to apply to generated content nodes, since there is no DOM element on which to hang them. Why do we need this if we can create shadow DOM? Aren’t people working to specify access to the Shadow DOM: https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html Don’t we already have experimental implementations? http://blog.chromium.org/2013/01/content-security-policy-and-shadow-dom.html Aren’t developers already being encouraged to use it: http://www.html5rocks.com/en/tutorials/webcomponents/shadowdom/ I quote with approval from the above: > One rule of thumb … is that you shouldn’t put content in Shadow DOM. Content must be in the document to be accessible to screen readers, search engines, extensions and so on. Shadow DOM is for all of the semantically meaningless markup you need to create an attractive, usable widget. But the content should stay in the page. If Safari implemented the same Shadow DOM API, could not Apple’s production environments make use of this to solve the problems they are running into without introducing yet another way to create accessibility semantics to an over-complicated web platform? -- Benjamin Hawkes-Lewis
Received on Saturday, 9 March 2013 13:25:52 UTC