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

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

> On Tue, Feb 5, 2013 at 1:14 AM, James Craig <jcraig@apple.com> wrote:
>> (Since this thread has moved off of the IndieUI topic, I've moved it to the ARIA (wai-xtech) list, and put IndieUI in the BCC for this message.)
>> 
>> FWIW, am not opposed to doing some of ARIA 2 in a more CSS-like way
> 
> The problem this is supposed to solve is the verbosity facing web
> authors who want to provide the same accessibility for heavily custom
> widgets as their HTML-native equivalents, right?

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.

> Wouldn't the implementation of Web Components, especially decorators,
> address this problem very directly?

In the cases where web components are a requirement to achieve the desired UI or modularization of the control, yes, but I don't think we should require an author to use web components to make an otherwise simple interface accessible.

James

Received on Monday, 4 March 2013 19:21:29 UTC