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

2013-10-08 Thread Dirk Schulze

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
 

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

2013-10-08 Thread James Craig

 On Oct 8, 2013, at 1:02 AM, Dirk Schulze dschu...@adobe.com wrote:
 
 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.

Withe the exception of NVDA, the other screen reader vendors are typically 
uninvolved in the standards process, so I would not expect feedback. As for 
NVDA, none of the other browsers expose even plain text generated content, so 
this likely just represents a problem that they don’t know they have yet. I did 
discuss this solution in the PF working group before proposing it to CSS.

That said, this change would not require the screen readers (including 
VoiceOver) to do anything special. It just changes the way the UAs expose a bit 
of text (or an image text alternative) to the accessibility APIs, so I don’t 
think buy-in from screen reader vendors is critical. This is a browser issue, 
and all the browser vendors have representatives in CSS.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev