On Oct 7, 2013, at 11:55 PM, Chris Fleizach <cfleiz...@apple.com> wrote:
> 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)
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 <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
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
