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

On Mar 7, 2013, at 11:09 PM, Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com> wrote:

> On 4 March 2013 19:21, James Craig <jcraig@apple.com> wrote:
>> Not necessarily heavy customization. For example, this could be used to indicate a visible "required" state on required form elements:
>> 
>> [required]::after, [aria-required="true"]::after {
>>        content: attr(data-loc-required), "required"; /* Visibly display "required" or localized equivalent. */
>>        aria-hidden: true; /* The required attr(s) already convey this info to the accessibility APIs, so don't convey it twice. */
>> }
>> 
>> Web Components seem like overkill for this case.
> 
> Is the scenario here one in which future browsers style @required by
> default *and* support application of ARIA from stylesheets, and a
> future developer wants to hide the default style and supply their own
> without compromising the accessibility of @required?

That particular example seems somewhat contrived, but that's a possible scenario, yes. See below for more practical examples.

> A way to create CSS generated content that is not inserted into the
> accessibility hierarchy would be useful, because it’s currently
> difficult to generate decorative text with CSS:
> 
>    decorative-content: attr(data-loc-required), "required"

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!";
}

Which has nothing to do with exposing an ARIA attribute from the parent node.

> Are there use cases for applying the other ARIA states and properties?

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" */ 
}

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.

James

Received on Friday, 8 March 2013 08:48:51 UTC