Re: XTECH: ARIA in CSS for generated content (Was: CSSWG: Need fallback alternatives for CSS generated *text* content containing unicode glyphs)

As long as ARIA allows to generate content ARIA in CSS looks
reasonable. However I expect this can be a performance hit since
browsers need to watch both DOM and CSS, especially because a single
change in CSS can cause the thousands of accessibility events. If the
author is not cautious enough then ARIA in CSS can become a bottleneck
easily. Are there other alternatives to control accessibility mappings
of CSS generated content?

Thank you.
Alex.


On Fri, Mar 1, 2013 at 6:50 AM, James Craig <jcraig@apple.com> wrote:
> Not seeing much traction on this thread in the www-style group [1], so I'm
> moving to wai-xtech to discuss this in the context of an ARIA solution. This
> represents an accessibility and usability problem for Apple in several
> production environments, so we need to find a web standard solution to make
> this work. I'm leaving the www-style list in the BCC for this one message,
> so that any interested parties know to follow the thread on wai-xtech.
>
> Background:
>
> The issue of allowing ARIA in CSS has been raised and soundly rejected
> several times, as the general consensus (of both PFWG and CSSWG) is that
> functional information like ARIA should be available in the DOM. I generally
> agree with this consensus. However, it's recently come to my attention that
> sometimes this is not possible, particularly with regards to generated
> content and pseudo-elements that have no DOM node on which to hang ARIA
> attributes. For example:
>
> On Tuesday, 13 November 2012 22:42:29 GMT, James Craig wrote [1]:
>
>
> With the following markup:
>
> <li role="treeitem" aria-expanded="false" class="expandable">Vegetables</li>
>
> And this CSS:
>
> .expandable:before { content: "\25BA"; /* a.k.a. ► */ }
>
> The text character is exposed to accessibility trees according to the rules
> in the ARIA text alternative computation [2]. This character is spoken by
> some screen readers or text-to-speech engines as "Black right-pointing
> pointer" according to the unicode description for the character.
>
> So the expandable tree item is spoken like this:
>
> "Black right-pointing pointer, Vegetables, collapsed"
>
> This is obviously not ideal, as the glyph is intended as a style that is
> already conveyed semantically via the attributes, and should be spoken as
> this:
>
> "Vegetables, collapsed" (the 'collapsed' string varies by screen reader, but
> is generated based on aria-expanded="false")
>
> CSS allows for text alternative fallback content to CSS-generated images,
> like so:
>
> /* empty fallback text string, because the semantics are defined in the DOM
> */
> .expandable:before { content: url(./img/collapsed.png), ""; }
>
> /* similarly */
> .new:before { content: url(./img/star.png), "New!"; }
>
> /* or even better */
> .new:before { content: url(./img/star.png), attr(data-new); } /* allows DOM
> localized values for @data-new="New!" */
>
> However, there is no way to do the same thing with unicode characters
> exposed as text content.
>
> .new:before { content: "\2730", "New!"; } /* both are text, so no way to
> declare modality in fallback order */
> /* this character is ✰ which would be spoken as "black shadowed white star"
> instead of the intended "New!" */
>
> If this were an element (as opposed to a pseudo-element) we could override
> the label with @aria-label or hide the element entirely with @aria-hidden.
> Since, to my knowledge, there is no way to define modality-specific
> alternatives to unicode glyphs, we could potentially implement the "reader"
> media type.
>
> .expandable:before { content: "\25BA"; /* a.k.a. ► */ }
> @media reader { .expandable:before { content: ""; } }
>
> .new:before { content: "\2730";  /* a.k.a. ✰ */ }
> @media reader { .new:before { content: "New!"; } }
>
> However, the CSS 3 Reader draft [3] has made no progress since 2004, and
> appears to be stagnant.
>
>
> Also, as Dominic Mazzoni (Google), Jamie Teh (NVDA), and others have pointed
> out [4], even when it's possible to use the DOM for ARIA, it can represent a
> large number of DOM manipulations in certain circumstances which has
> potential performance implications.
>
> Proposal:
>
> It is for the above reasons that I am proposing allowing a limited set of
> ARIA properties into CSS interpreters as part of ARIA 2.0.
>
> .new:before { content: "\2730"; aria-label: "New!"; }
> .new:before { content: "\2730"; aria-label: attr(data-pseudo-alt); } /*
> would allow pseudo-element attrs to be defined on the parent node */
>
> In the case of true style information that is already adequately represented
> in the DOM, this would allow an author to explicitly prevent the generated
> content from being exposed to screen readers.
>
> .expandable:before { content: "\25BA"; /* a.k.a. ► */ aria-hidden: true; }
>
> In cases where alternatives or properties could be conveyed using existing
> CSS, don't use ARIA properties in CSS. This is more or less equivalent to
> what we recommend for HTML, too. E. g. if you can use @alt (as on an <img>)
> , there is no need to use @aria-label.
>
> /* No need to override with aria-label, b/c CSS supports image fallback
> text. */
> .new:before { content: url(./img/star.png), "New!"; }
>
> Thoughts? I'll raise the ARIA 2.0 issue in the PFWG tracker once any
> discussion settles.
>
> Thanks,
> James Craig
>
>
> 1. http://lists.w3.org/Archives/Public/www-style/2012Nov/0233.html
>
> 2. http://www.w3.org/WAI/PF/aria/complete#tac_gencss
> 3. http://www.w3.org/TR/css3-reader/
> 4. http://lists.w3.org/Archives/Public/public-indie-ui/2013Feb/0010.html
>

Received on Friday, 1 March 2013 01:49:30 UTC