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

On Mar 9, 2013, at 5:25 AM, Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com> wrote:

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

This example demonstrates that it can be. The above example just makes it easier to read.

.new:before {
       content: "\2730";  /* a.k.a. ✰ */
       aria-label: attr(title), "New!";
}

> 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.

I disagree. If it’s rendered visibly, then screen readers should speak it by default. We just need a way to override that default, and CSS does not yet give us a way. 

Also, for what it’s worth, WebKit has always exposed the accessibility of generated content, so this issue predates the ARIA text alternative computation algorithm.

> Developers used to distinguishing between style and content tend to
> expect CSS to contain style and be surprised when it is treated as
> content.

As long as there is a “content” property in CSS, I don’t think we can claim CSS is still limited to providing “style” information only.

> 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.

I don’t understand this argument. The developers that care enough to fix it but don’t know how can look up the answer.

>> 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?

Shadow DOM is overkill for this. I don’t believe we should allow simple CSS to generate content, but then require a shadow DOM to make it accessible. 

> 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?

Perhaps, but you’re suggesting that an author can legitimately specify generated content in CSS with no way to make it accessible other than to replace that content completely with a shadow DOM web component.

[aria-expanded="false”]::after {
 content: "\25BA"; /* a.k.a. ► */
}

There is no way to prevent this from being spoken as the redundant and literal “black right-pointing pointer,” depending on the synthesizer, spoken as an empty space. You’re suggesting a full web component just to achieve what could be done with one additional CSS property.

 aria-hidden: true;

Don’t you think it’d be overkill to use a web component for this?

James