[webkit-dev] AX: Implement CSS -webkit-alt property (text alternative for generated content pseudo-elements ::before and ::after)

[Dirk Schulze]

On Oct 7, 2013, at 11:55 PM, Chris Fleizach <cfleizach at apple.com> wrote:

> Hi Dirk,
> 
> 
> On Oct 7, 2013, at 12:36 AM, Dirk Schulze <dschulze at adobe.com> wrote:
> 
>> I am all for accessibility! But isn't the idea to keep content out of CSS so that it does not interfere with accessibility as much as possible?
>> 
>> The main problem with the 'content' property is that it is not accessible. Why I really think it should not be used for more than symbols. ARIA and class names on the element can help screen readers to make the styling accessible as needed.
>> 
> Is this a question? I'm not sure what you're driving at. Yes ARIA can be used to provide labels, but when CSS "content" is used, there's nothing to label (ie DOM Node)

I see.

> 
>> Do you have use cases where "unaccessible" CSS is actually a problem? And which actually needs  to be done in CSS?
> 
> We come across scenarios like
> 
>> [data-new]::after {
>> 		content: "\2730”; /* a.k.a. ✰ , literally “shadowed white star”  */
>> 		alt: attr(data-new); /* allows for localized content from the DOM, e.g. @data-new="New!" */
>> 	}
> 
> Where we don't want the screen reader to say "shadowed white star" -- we want to label it with the semantic description  -- "New!"

Understand.

> 
> 
>> 
>> Also, did you speak with people from screen reader software and societies for people with different needs and preferences? Are they willing to adapt this feature and on board?
> 
> Apple makes a screen reader for Mac and iOS, so this is not an issue for us. Moreover, there's nothing for them to adapt or be on board with. WebKit can start vending the right information and everyone benefits.

I hope you understand that I am not particularly concerned about Apples screen reader solution. It is one implementation. I would like to know if JAWS, NVDA, Dolphin and other are aboard.

> 
>> 
>> This discussion should probably also move to the W3C mailing list www-style unless you don't plan to expose it to the web.
>> 
> 
> Inside the webkit bug, the first comment states:
> 
> Description From James Craig 2013-08-22 17:59:42 PST (-) [reply]
> AX: Implement CSS -webkit-alt property
> 
> Not in a spec yet, but discussion was positive and the issue is being tracked by the CSS WG. Since this is holding up several projects, I propose implementing the vendor-prefixed form: -webkit-alt.
> 
> 
> http://lists.w3.org/Archives/Public/www-style/2012Nov/0319.html

Ah thanks! I couldn't find it on the mailing list and missed your link.

Greetings,
Dirk

> 
> 
> 
>> Greetings,
>> Dirk
>> 
>> On Oct 1, 2013, at 7:08 AM, James Craig <jcraig at apple.com> wrote:
>> 
>>> AX: Implement CSS -webkit-alt property
>>> https://bugs.webkit.org/show_bug.cgi?id=120188
>>> 
>>> This is blocking 20+ bugs on one of our higher profile content sites and we’d like to start work on it. To clarify, the problem is that with CSS generated content in pseudo-elements like this:
>>> 
>>> 	.expandable::before { content: "\25BA"; /* a.k.a. ► */ }
>>> 
>>> …there is no way to prevent VoiceOver from speaking the literal character description, “right pointing black pointer.” If this were an actual DOM node, we could hang some ARIA attributes on it, but there is no node for pseudo-elements, so the property has to be defined in CSS.
>>> 
>>> The CSS Working Group discussion indicates the editors (Tab from Google, and Elika from Mozilla) are generally on board with the concept of accessible text alternatives for CSS generated content and Tab suggested the property name. It is not in a CSS4 draft yet, but some usage examples are below.
>>> 
>>> Rendering a decorative disclosure triangle on a "collapsed” ARIA treeitem:
>>> 
>>> 	[aria-expanded="false”]::before {
>>> 		content: "\25BA"; /* a.k.a. ► , literally “right pointing black pointer” */
>>> 		alt: ""; /* aria-expanded="false" already in DOM, so this pseudo-element is decorative */
>>> 	}
>>> 
>>> And this, where a style indicates new content, screen readers can speak “New” instead of “shadowed white star”:
>>> 
>>> 	[data-new]::after {
>>> 		content: "\2730”; /* a.k.a. ✰ , literally “shadowed white star”  */
>>> 		alt: attr(data-new); /* allows for localized content from the DOM, e.g. @data-new="New!" */
>>> 	}
>>> 
>>> Any questions or concerns?
>>> 
>>> Thanks,
>>> James
>>> 
>>> 
>>> PS. Related to this one is bug 122138, where the “alt” can be specified inline after url() image content:
>>> 
>>> AX: WebKit does not expose text alternative of CSS generated image content
>>> https://bugs.webkit.org/show_bug.cgi?id=122138
>>> 
>>> 	.new::after {
>>> 		content: url(./star.png), "New!";
>>> 	}
>>> 
>>> 
>>> _______________________________________________
>>> webkit-dev mailing list
>>> webkit-dev at lists.webkit.org
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>> 
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev