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.

Do you have use cases where "unaccessible" CSS is actually a problem? And which 
actually needs  to be done in CSS?

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?

This discussion should probably also move to the W3C mailing list www-style 
unless you don't plan to expose it to the web.

Greetings,
Dirk

On Oct 1, 2013, at 7:08 AM, James Craig <jcr...@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@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Reply via email to