w3c
Does CSS textual content include unicode characters?
In Step F ii, what exactly is meant by "CSS textual content"?
Does this include Unicode characters? Often Unicode characters in the private use range are used for the purpose of font icons. These Unicode characters would then be included as step F and a screen reader may try to interpret the Unicode character. For example, Voiceover will say "unpronounceable" when it comes across a Unicode character for which it has no definition.
Should the algorithm only be concerned with ASCII characters?
I think we need to allow for strings in any language, which would make ASCII too restrictive.
The CSS string data type uses Unicode, so currently, that's what Step F ii would allow.
What is pronounceable may also depend on the language of the page,
e.g. <html lang='en'> or <html lang='es'> or <html lang='fr'>
I'm not sure if restricting the string to "only pronounceable characters" is possible, but maybe we could refrain from passing through characters in the private use range?
The Auto WCAG effort has created a glossary page in which they have attempted to define the term "non-empty text string". They have defined a range of unicode characters which constitute text strings: https://auto-wcag.github.io/auto-wcag/pages/glossary/non-empty.html
Ll: Letter, Lowercase Lu: Letter, Uppercase Lt: Letter, Titlecase Lo: Letter, Other Lm: Letter, Modifier Nd: Number, Decimal Digit For more details on unicode categories, check out www.fileformat.info/info/unicode/category/
Hi, The algorithm will need to include any form of printable character, so unicode characters would need to be handled in the same way as standard letters and numbers. This is important since, in some cases, it is necessary to customize labels on elements within sub element structures so that the total when computed makes sense.
Take for example a link that includes a dollar amount, but there is a background image being used to represent the decimal like so.
$10000
The accessible name for this link is: "$100.00"
So, whitespace would be any form of non-printable character including tabs and line breaks, but any other form of printable character would have to be recognized as part of the computation. This is also important for braille displays where all such printable characters have to be represented.
Within the Terminology section it states: "Flat string A string of characters where all carriage returns, newlines, tabs, and form-feeds are replaced with a single space, and multiple spaces are reduced to a single space. The string contains only character data; it does not contain any markup."
This seems clear to me, but would it make more sense to change this to the following instead?
"Flat string A string of characters where all carriage returns, newlines, tabs, and form-feeds are replaced with a single space, and multiple spaces are reduced to a single space. The string contains only printable character data; it does not contain any markup."
Hi, It looks like I replied to the wrong issue here, but I think the principle remains the same for CSS content.
E.G if the above example I icon did not use aria-label but used a CSS :before or :after pseudo element instead, the accessible name for the link should be the same. "$100.00"
If textual content is rendered, then it needs to be represented by printable characters even when CSS content is used, so this would include unicode characters as well. The same requirements for braille support would need to be applied.
I'm just trying to figure out where in the algorithm this is currently defined and what would make this clearer.
Thanks, Bryan
I would definitely be wary of standardizing too many assumptions about which CSS content is text or which is decorative.
Currently, the correct accessible markup for font icons is to use an aria-label to override the icon characters with alternative text, or aria-hidden="true" to mask them complete, whether those characters are included in the markup or via CSS generated content. The downside of this approach is that it requires a separate element: you can't mark CSS content as presentational while keeping the markup text for the same element accessible.
There are currently two proposals for allowing authors to provide an "alt text" for CSS generated content, within the CSS. The latest draft spec for the content property supports two values, with the second value being the alternative text (which could be an empty string). As far as I know, this isn't supported in any browsers. However, Safari supports a separate alt property to have the same effect. I would encourage everyone to put pressure on their favourite browser devs to get these proposals standardized & widely implemented. Further discussion of the proposals should take place in the CSS A11y repository: https://github.com/w3c/css-a11y/issues (there are some existing issues that may be relevant, but I haven't looked at them closely).
So, would you consider this issue best handled by the CSS group instead of leaving this an open issue in AccName?
As far as I know, this isn't supported in any browsers
Alternative text for CSS pseudo content is now supported by Chrome (https://github.com/FreedomScientific/VFO-standards-support/issues/367)
There is another important area where AccName will have to account for alt text within pseudo element content, when the pseudo element includes an image reference and an assigned tooltip for that image.
Example:
<style>
#test:after {
content: url(./close.png) / " Opens in new Window";
}
</style>
<a id="test" href="bob" target="_blank">CSUN presentation</a>
You can test this in the latest Chrome Beta and see by examining the accessibility tree, that the pseudo element consists of an image role with accessible alt text for that image, much like an image with an alt attribute. However, JAWS 2020 cannot recognize this at all.
Regarding AccName, since this is a supported naming mechanism, it needs to be accounted for when computing the accessible names of such content. I have already added support for this at: https://whatsock.github.io/w3c-alternative-text-computation/Editable%20Live%20Input%20AccName%20Test.html
JAWS 2020 cannot recognize this at all
JAWS has problems with this when the CSS graphic pseudo content is added to a link. The alternative text is output correctly with other elements (for example, button) and also with a link when the CSS pseudo content is not a graphic. This is a JAWS bug. With NVDA it works without problems, as far as I have tested