Hi Dirk,
On Oct 7, 2013, at 12:36 AM, Dirk Schulze <dschu...@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)
> 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!"
>
> 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.
>
> 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
> 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
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
