Re: ARIA in CSS (Was: [user-context] What are the use cases for exposing screen reader or magnifier version info?)

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