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


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

2013-10-07 Thread Dirk Schulze
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


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

2013-10-07 Thread Chris Fleizach
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


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

2013-10-04 Thread Dean Jackson

On 3 Oct 2013, at 4:46 am, Christian Biesinger cbiesin...@chromium.org wrote:

 On Tue, Oct 1, 2013 at 8:26 PM, Ryosuke Niwa rn...@webkit.org wrote:
 On Tue, Oct 1, 2013 at 4:53 PM, James Craig jcr...@apple.com wrote:
 
 Follow-up question:  Since this hasn’t made it into the CSS4 spec yet,
 should we temporarily use “-webkit-alt” for the property name? I know there
 has been a push to move away from vendor prefixes lately, so if there are no
 objections, I propose we use the unprefixed version.
 
 
 I think that's what Mozilla and Google are doing but I don't think we
 necessary have to follow the suit.
 
 FYI, because IMO this is an important clarification - Mozilla and
 Google use unprefixed versions only *behind a (runtime) flag*, until
 the spec is stable. That way experimental features are not exposed to
 the web at large until it is unlikely that the spec will change, to
 avoid cross-browser compatibility risks.

We decided on a slightly different approach, which is to prefix things
but enable them by default in nightly builds. That way a port must still
decide at their shipping time whether or not to enable the feature.

In the Moz + Google case, the experimental form is exposed unprefixed to a small
number of users on the Web. In our case, the experimental form is exposed
prefixed. We concluded that we’ve changed things enough times while prefixed
that it was worth the extra “this is experimental and may change” notice.

Dean


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


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

2013-10-04 Thread Adam Barth
On Fri, Oct 4, 2013 at 12:08 PM, Dean Jackson d...@apple.com wrote:
 On 3 Oct 2013, at 4:46 am, Christian Biesinger cbiesin...@chromium.org 
 wrote:
 On Tue, Oct 1, 2013 at 8:26 PM, Ryosuke Niwa rn...@webkit.org wrote:
 On Tue, Oct 1, 2013 at 4:53 PM, James Craig jcr...@apple.com wrote:

 Follow-up question:  Since this hasn’t made it into the CSS4 spec yet,
 should we temporarily use “-webkit-alt” for the property name? I know there
 has been a push to move away from vendor prefixes lately, so if there are 
 no
 objections, I propose we use the unprefixed version.

 I think that's what Mozilla and Google are doing but I don't think we
 necessary have to follow the suit.

 FYI, because IMO this is an important clarification - Mozilla and
 Google use unprefixed versions only *behind a (runtime) flag*, until
 the spec is stable. That way experimental features are not exposed to
 the web at large until it is unlikely that the spec will change, to
 avoid cross-browser compatibility risks.

 We decided on a slightly different approach, which is to prefix things
 but enable them by default in nightly builds. That way a port must still
 decide at their shipping time whether or not to enable the feature.

 In the Moz + Google case, the experimental form is exposed unprefixed to a 
 small
 number of users on the Web. In our case, the experimental form is exposed
 prefixed. We concluded that we’ve changed things enough times while prefixed
 that it was worth the extra “this is experimental and may change” notice.

Does this imply that you'll remove the prefixes before shipping the
features in a production release?

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


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

2013-10-04 Thread Dean Jackson

On 5 Oct 2013, at 6:22 am, Adam Barth aba...@webkit.org wrote:

 On Fri, Oct 4, 2013 at 12:08 PM, Dean Jackson d...@apple.com wrote:
 On 3 Oct 2013, at 4:46 am, Christian Biesinger cbiesin...@chromium.org 
 wrote:
 On Tue, Oct 1, 2013 at 8:26 PM, Ryosuke Niwa rn...@webkit.org wrote:
 On Tue, Oct 1, 2013 at 4:53 PM, James Craig jcr...@apple.com wrote:
 
 Follow-up question:  Since this hasn’t made it into the CSS4 spec yet,
 should we temporarily use “-webkit-alt” for the property name? I know 
 there
 has been a push to move away from vendor prefixes lately, so if there are 
 no
 objections, I propose we use the unprefixed version.
 
 I think that's what Mozilla and Google are doing but I don't think we
 necessary have to follow the suit.
 
 FYI, because IMO this is an important clarification - Mozilla and
 Google use unprefixed versions only *behind a (runtime) flag*, until
 the spec is stable. That way experimental features are not exposed to
 the web at large until it is unlikely that the spec will change, to
 avoid cross-browser compatibility risks.
 
 We decided on a slightly different approach, which is to prefix things
 but enable them by default in nightly builds. That way a port must still
 decide at their shipping time whether or not to enable the feature.
 
 In the Moz + Google case, the experimental form is exposed unprefixed to a 
 small
 number of users on the Web. In our case, the experimental form is exposed
 prefixed. We concluded that we’ve changed things enough times while prefixed
 that it was worth the extra “this is experimental and may change” notice.
 
 Does this imply that you'll remove the prefixes before shipping the
 features in a production release?

I can’t speak for anyone other than the Apple port, and even there I’m
definitely not the official word on the topic, but I don’t think that is
implied. It’s likely going to depend on perceived stability of the feature,
testing, community feedback, etc.

The important thing is that our goal is to get to the unprefixed stable form
as soon as possible.

Also, our prefixing/unprefixing rules are not set in stone. I think the 
community
will evaluate them case by case.

Dean


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


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

2013-10-04 Thread Adam Barth
On Fri, Oct 4, 2013 at 1:37 PM, Dean Jackson d...@apple.com wrote:
 On 5 Oct 2013, at 6:22 am, Adam Barth aba...@webkit.org wrote:
 On Fri, Oct 4, 2013 at 12:08 PM, Dean Jackson d...@apple.com wrote:
 On 3 Oct 2013, at 4:46 am, Christian Biesinger cbiesin...@chromium.org 
 wrote:
 On Tue, Oct 1, 2013 at 8:26 PM, Ryosuke Niwa rn...@webkit.org wrote:
 On Tue, Oct 1, 2013 at 4:53 PM, James Craig jcr...@apple.com wrote:

 Follow-up question:  Since this hasn’t made it into the CSS4 spec yet,
 should we temporarily use “-webkit-alt” for the property name? I know 
 there
 has been a push to move away from vendor prefixes lately, so if there 
 are no
 objections, I propose we use the unprefixed version.

 I think that's what Mozilla and Google are doing but I don't think we
 necessary have to follow the suit.

 FYI, because IMO this is an important clarification - Mozilla and
 Google use unprefixed versions only *behind a (runtime) flag*, until
 the spec is stable. That way experimental features are not exposed to
 the web at large until it is unlikely that the spec will change, to
 avoid cross-browser compatibility risks.

 We decided on a slightly different approach, which is to prefix things
 but enable them by default in nightly builds. That way a port must still
 decide at their shipping time whether or not to enable the feature.

 In the Moz + Google case, the experimental form is exposed unprefixed to a 
 small
 number of users on the Web. In our case, the experimental form is exposed
 prefixed. We concluded that we’ve changed things enough times while prefixed
 that it was worth the extra “this is experimental and may change” notice.

 Does this imply that you'll remove the prefixes before shipping the
 features in a production release?

 I can’t speak for anyone other than the Apple port, and even there I’m
 definitely not the official word on the topic, but I don’t think that is
 implied. It’s likely going to depend on perceived stability of the feature,
 testing, community feedback, etc.

 The important thing is that our goal is to get to the unprefixed stable form
 as soon as possible.

 Also, our prefixing/unprefixing rules are not set in stone. I think the 
 community
 will evaluate them case by case.

I would encourage you (and others) not to ship new vendor-prefixed
APIs in production releases.  If the feature isn't stable enough to
ship without a prefix, it's also harmful to the web ecosystem to ship
with a vendor prefix.

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


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

2013-10-04 Thread Dean Jackson

On 5 Oct 2013, at 6:45 am, Adam Barth aba...@webkit.org wrote:

 Also, our prefixing/unprefixing rules are not set in stone. I think the 
 community
 will evaluate them case by case.
 
 I would encourage you (and others) not to ship new vendor-prefixed
 APIs in production releases.  If the feature isn't stable enough to
 ship without a prefix, it's also harmful to the web ecosystem to ship
 with a vendor prefix.

We’re well aware of the risks and benefits. This ain’t our first
time at the rodeo.

Dean

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


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

2013-10-02 Thread Christian Biesinger
On Tue, Oct 1, 2013 at 8:26 PM, Ryosuke Niwa rn...@webkit.org wrote:
 On Tue, Oct 1, 2013 at 4:53 PM, James Craig jcr...@apple.com wrote:

 Follow-up question:  Since this hasn’t made it into the CSS4 spec yet,
 should we temporarily use “-webkit-alt” for the property name? I know there
 has been a push to move away from vendor prefixes lately, so if there are no
 objections, I propose we use the unprefixed version.


 I think that's what Mozilla and Google are doing but I don't think we
 necessary have to follow the suit.

FYI, because IMO this is an important clarification - Mozilla and
Google use unprefixed versions only *behind a (runtime) flag*, until
the spec is stable. That way experimental features are not exposed to
the web at large until it is unlikely that the spec will change, to
avoid cross-browser compatibility risks.

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


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

2013-10-01 Thread Ryosuke Niwa
On Mon, Sep 30, 2013 at 10:56 PM, James Craig jcr...@apple.com wrote:

 Did you realize you sent this off-list? Keeping my reply off-list, too.


Oops, I must have pressed the wrong button.

On Sep 30, 2013, at 10:42 PM, Ryosuke Niwa rn...@webkit.org wrote:

 Are you going to add a build flag for this feature?

 For the feature detection purposes, it seems desirable not to build this
 feature on platforms/ports where the property value is not properly exposed
 to AT.

 Or will your implementation work on all ports that has accessibility
 support?


 I expect this to work on all ports that include accessibility support. The
 end result for the platform accessibility API is that it will expose a
 different string of text, where it’s already exposing some text. Not
 anything challenging for a platform API.


Excellent! Thanks for the clarification.

- R. Niwa
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


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

2013-10-01 Thread James Craig
Follow-up question:  Since this hasn’t made it into the CSS4 spec yet, should 
we temporarily use “-webkit-alt” for the property name? I know there has been a 
push to move away from vendor prefixes lately, so if there are no objections, I 
propose we use the unprefixed version.

On Sep 30, 2013, at 10:08 PM, 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


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

2013-10-01 Thread Maciej Stachowiak

Sounds ok to add it prefixed.

 - Maciej

On Oct 1, 2013, at 4:53 PM, James Craig jcr...@apple.com wrote:

 Follow-up question:  Since this hasn’t made it into the CSS4 spec yet, should 
 we temporarily use “-webkit-alt” for the property name? I know there has been 
 a push to move away from vendor prefixes lately, so if there are no 
 objections, I propose we use the unprefixed version.
 
 On Sep 30, 2013, at 10:08 PM, 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


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

2013-10-01 Thread Ryosuke Niwa
On Tue, Oct 1, 2013 at 4:53 PM, James Craig jcr...@apple.com wrote:

 Follow-up question:  Since this hasn’t made it into the CSS4 spec yet,
 should we temporarily use “-webkit-alt” for the property name? I know there
 has been a push to move away from vendor prefixes lately, so if there are
 no objections, I propose we use the unprefixed version.


I think that's what Mozilla and Google are doing but I don't think we
necessary have to follow the suit.

Regardless, that should be discussed on a separate thread.

- R. Niwa
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev