Re: [webkit-dev] AX: Implement CSS -webkit-alt property (text alternative for generated content pseudo-elements ::before and ::after)
> On Oct 8, 2013, at 1:02 AM, Dirk Schulze 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)
On Oct 7, 2013, at 11:55 PM, Chris Fleizach wrote:
> Hi Dirk,
>
>
> On Oct 7, 2013, at 12:36 AM, Dirk Schulze 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 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
>>
>> ___
Re: [webkit-dev] AX: Implement CSS -webkit-alt property (text alternative for generated content pseudo-elements ::before and ::after)
Hi Dirk,
On Oct 7, 2013, at 12:36 AM, Dirk Schulze 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 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)
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 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)
On 5 Oct 2013, at 6:45 am, Adam Barth 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)
On Fri, Oct 4, 2013 at 1:37 PM, Dean Jackson wrote: > On 5 Oct 2013, at 6:22 am, Adam Barth wrote: >> On Fri, Oct 4, 2013 at 12:08 PM, Dean Jackson wrote: >>> On 3 Oct 2013, at 4:46 am, Christian Biesinger >>> wrote: On Tue, Oct 1, 2013 at 8:26 PM, Ryosuke Niwa wrote: > On Tue, Oct 1, 2013 at 4:53 PM, James Craig 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)
On 5 Oct 2013, at 6:22 am, Adam Barth wrote: > On Fri, Oct 4, 2013 at 12:08 PM, Dean Jackson wrote: >> On 3 Oct 2013, at 4:46 am, Christian Biesinger >> wrote: >>> On Tue, Oct 1, 2013 at 8:26 PM, Ryosuke Niwa wrote: On Tue, Oct 1, 2013 at 4:53 PM, James Craig 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)
On Fri, Oct 4, 2013 at 12:08 PM, Dean Jackson wrote: > On 3 Oct 2013, at 4:46 am, Christian Biesinger > wrote: >> On Tue, Oct 1, 2013 at 8:26 PM, Ryosuke Niwa wrote: >>> On Tue, Oct 1, 2013 at 4:53 PM, James Craig 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)
On 3 Oct 2013, at 4:46 am, Christian Biesinger wrote: > On Tue, Oct 1, 2013 at 8:26 PM, Ryosuke Niwa wrote: >> On Tue, Oct 1, 2013 at 4:53 PM, James Craig 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)
On Tue, Oct 1, 2013 at 8:26 PM, Ryosuke Niwa wrote: > On Tue, Oct 1, 2013 at 4:53 PM, James Craig 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)
On Tue, Oct 1, 2013 at 4:53 PM, James Craig 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
Re: [webkit-dev] AX: Implement CSS -webkit-alt property (text alternative for generated content pseudo-elements ::before and ::after)
Sounds ok to add it prefixed.
- Maciej
On Oct 1, 2013, at 4:53 PM, James Craig 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 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)
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 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)
On Mon, Sep 30, 2013 at 10:56 PM, James Craig 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 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
