Re: [whatwg] Allow alt attribute with the span element

[Michael A. Peters]

On 10/06/2017 08:44 AM, Léonie Watson wrote:


On 06/10/2017 11:26, Michael A. Peters wrote:

Nope, no problem at all. That looks like a simple solution I did not
find. Thank you.


Note that you need to provide an explicit role on the span if you use
aria-label to provide its accessible name.


I assume if I instead put the aria-label on the button rather than span 
that contains the pictograph, that would work too without needing a role 
since it is an actual button.

Re: [whatwg] Allow alt attribute with the span element

[Michael A. Peters]

Nope, no problem at all. That looks like a simple solution I did not 
find. Thank you.


On 10/06/2017 08:23 AM, Jonathan Garbee wrote:

Is there a problem with using aria-label
 for
this use case? It seems like this should do exactly what you're asking
for in the given scenario.

On Fri, Oct 6, 2017 at 11:15 AM, Michael A. Peters
> wrote:

With images, the alt attribute can and should be used to give a
description of an image for users who can not see the image.

With text, some glyphs are pictographs that have a meaning. For
example, U+1F502 is a pictograph indicating single loop, but it is
meaningless if you can not see it.

Even if screen readers can specify the codepoint and/or map the
codepoint to a description (do they?) sometimes fonts define PUA
codepoints for pictograph glyphs that are not official.

A span element with a title attribute does not always solve this
problem, sometimes the glyph is in a button element that has a title
attribute describing what the button will do rather than the what
the current state is.

For example, a button may show a single loop indicating the media is
currently in single loop mode but have a title attribute specifying
that pressing it enables continuous loop mode.

If there was an alt attribute on a span inside the button, screen
readers could treat the span with a pictograph the same way it would
treat an image child of a button attribute and describe the current
pictograph to the end user.

If there is already a solution to this issue, I apologize, I could
not find one.

We (er, WhatWG / W3C) could just add alt to the global attribute
list too, rather than just span. Or come up with a semantic
pictograph element specifically for this (just like we have tt and
code).

Thank you for opinions.

Re: [whatwg] Allow alt attribute with the span element

[Jonathan Garbee]

Is there a problem with using aria-label
 for this
use case? It seems like this should do exactly what you're asking for in
the given scenario.

On Fri, Oct 6, 2017 at 11:15 AM, Michael A. Peters 
wrote:

> With images, the alt attribute can and should be used to give a
> description of an image for users who can not see the image.
>
> With text, some glyphs are pictographs that have a meaning. For example,
> U+1F502 is a pictograph indicating single loop, but it is meaningless if
> you can not see it.
>
> Even if screen readers can specify the codepoint and/or map the codepoint
> to a description (do they?) sometimes fonts define PUA codepoints for
> pictograph glyphs that are not official.
>
> A span element with a title attribute does not always solve this problem,
> sometimes the glyph is in a button element that has a title attribute
> describing what the button will do rather than the what the current state
> is.
>
> For example, a button may show a single loop indicating the media is
> currently in single loop mode but have a title attribute specifying that
> pressing it enables continuous loop mode.
>
> If there was an alt attribute on a span inside the button, screen readers
> could treat the span with a pictograph the same way it would treat an image
> child of a button attribute and describe the current pictograph to the end
> user.
>
> If there is already a solution to this issue, I apologize, I could not
> find one.
>
> We (er, WhatWG / W3C) could just add alt to the global attribute list too,
> rather than just span. Or come up with a semantic pictograph element
> specifically for this (just like we have tt and code).
>
> Thank you for opinions.
>