ARIA roles (in somes places) in EPUB 3.0.1 is fine for Epubcheck 4.1.1 but not with 4.2.0 alpha

[garconvacher]

Hi,

According to this article, I added role="figure" in figure tags.
Epubcheck-4.1.1 validate the EPUB but 4.2.0-alpha-1 returns errors.

ERROR(RSC-005): myEPUB.epub/OEBPS/txt/myEPUB-055.xhtml(74,31): Erreur lors de l'analyse du fichier: la valeur de l'attribut "role" n'est pas valide ; doit être égal à "group", "none" ou "presentation"

Same thing with DPub role in <nav epub:type="landmarks">:
<a role="doc-toc" epub:type="toc" href="toc.xhtml"> is fine with 4.1 but 4.2 returns:

ERROR(RSC-005): myEPUB.epub/OEBPS/txt/toc.xhtml(505,99): Erreur lors de l'analyse du fichier: la valeur de l'attribut "role" n'est pas valide ; doit être égal à "button", "checkbox", "doc-backlink", "doc-biblioref", "doc-glossref", "doc-noteref", "link", "menuitem", "menuitemcheckbox", "menuitemradio", "option", "radio", "switch", "tab" ou "treeitem"

This EPUB contains lot of ARIA or Dpub-ARIA roles, 4.2 returns errors only with figure and landmarks.

[rdeltour]

Thanks for the report Ludovic, we'll look into it.

[mattgarrish]

According to this article, I added role="figure" in figure tags.

The reason you get a warning about role="figure" on figure elements is because that semantic is implicit to figure elements and implicit semantics should not be explicitly declared. The ARIA in HTML document describes the proper use of ARIA semantics if you're ever in doubt - it's not something epubcheck has defined.

Same thing with DPub role in <nav epub:type="landmarks">:

ARIA roles shouldn't be used on landmarks links unless they're valid link roles (e.g., doc-backlink or doc-noteref). So, in general, they shouldn't ever be used.

What you're doing by putting doc-toc on a link is effectively indicating to AT that that link is actually a navigation element and should be treated as such.

Epubcheck 4.2 incorporates the NU schemas, which provide proper validation of ARIA roles - something that has been lacking until now.

[garconvacher]

Thanks for the clarifications @mattgarrish :)

[rdeltour]

I quickly checked on https://validator.w3c.org and yeah the reports are the same there.

The reason you get a warning about role="figure" on figure elements is because that semantic is implicit to figure elements and implicit semantics should not be explicitly declared.

This one is bugging me a little however, as it's kinda counter productive to report an error for something that otherwise increases the accessibility support of the markup. But in any case, this issue would need to be discussed elsewhere, to the ARIA in HTML spec group or to the Nu Html Checker.

I'll close this as invalid, feel free to reopen or keep commenting if you think something else should be done!

[rdeltour]

So I had slightly deeper look at how validator.nu handles this. In fact, they implement HTML in ARIA to the letter, which in section 5.1 “Conformance Checker implementers” says:

Documents MUST NOT use any role values with elements in the Document conformance requirements for use of ARIA attributes in HTML table, other than the corresponding role value (if any) as listed for that element in the third column, other than those indicated in the second column, which SHOULD NOT be used.

For instance if you have a button with an overridden "button" role:

<button role="button">press me</button>

They would only report a warning:

Warning: The 'button' role is unnecessary for element 'button'.

I suppose this warning is implemented as a Java-coded assertion, and not as a schema rule.

However, in the case of the figure element, an error is also reported, in addition to the warning, if the role is duplicated:

Error: Bad value 'figure' for attribute role on element 'figure'.

I think this is a bug in their schema, which should allow figure as an acceptable role value. I'll submit an issue or PR in their repo.

[mattgarrish]

However, in the case of the figure element, an error is also reported, in addition to the warning

Ah, good point. I didn't look closely at the level reported, but it should only be a warning for redeclaring an implicit semantic.

[garconvacher]

BTW (and off topic), @mattgarrish, do you know any trick to force VoiceOver on iOS to read aria-label in span?
We use role="text" in our EPUBs. We know it's not an ARIA role so it's wrong...
e.g.:
<span role="text" aria-label="meaning of the glyph">(a glyph unknown by TA)</span>
Without this fake role, VoiceOver don't read the aria-label in Books :/

[mattgarrish]

Are these icon fonts? If so, my first thought would be to use role="img". There's a page describing how to do this here: https://www.w3.org/WAI/GL/wiki/Providing_a_Semantically_Identified_Icon_Font_with_role%3Dimg

[garconvacher]

No, mostly phonetic symbols from Unicode IPA range: https://unicode.org/charts/PDF/U0250.pdf

I'll test this role tomorrow.

[danielweck]

A number of "icon fonts" allow developers to use ligatures (i.e. named glyphs) as an easier-to-read alternative to unicode references. In several projects I have seen the span elements with both role="presentation" and aria-hidden="true", and aria-label="xxx" or aria-labelledby on the parent container (for example, a clickable button). I'm not sure that it works with all/most screen readers. Note that the title attribute is often used as well, so that tooltips are displayed.

[rdeltour]

See also some interesting testing done by David MacDonald in the article “What happens with aria-labelledby, aria-label and aria-describedby on static HTML elements?”.

[garconvacher]

Thank you all :)
Unfortunately, none of these do the trick :(

Some tests with:
<span aria-label="banana">bəˈnɑːnə</span>
Result must be 'banana', not 'B N N'.

iOS 12 with Lisa and R2-reader (Books with VoiceOver (VO) is useless, iBooks on iOS 11 was better)
NVDA (latest version) with Readium (Chrome extension)

• without role, VO and NVDA(1) fail;
• role="text">banana</span>, VO and NVDA pronounce well;
• role="img">banana</span>, VO and NVDA are fine BUT 'image' or 'graphic' are logically added;
• role="presentation" or aria-hidden="true", alone or both, do their job: hidding.

(1) NVDA was fine without role in Chrome (so Readium 1, at least on Windows) not anymore.

Found this: w3c/html-aria#26

[mattgarrish]

<span aria-label="banana">bəˈnɑːnə</span>
Result must be 'banana', not 'B N N'.

The EPUB ssml:* attributes were intended for this case of clarifying pronunciation, but they never gained any adoption that I know of. Another effort at adding SSML to the web has been started here: w3c/pronunciation#108

• role="presentation" or aria-hidden="true", alone or both, do their job: hidding.

Right, I think the idea with this approach is that you also have to have a hidden alternative that AT will read out (i.e., hide the actual glyphs from AT and hide the description from non-AT using clipping or off-screen positioning or a technique like that).

[garconvacher]

SSML support would be great !
PLS has never been implemented either.

About aria-hidden, our EPUB have lot of phonetics inside texts or tables. All stuff should be duplicated, it don't seem good.

[rdeltour]

FYI the Nu HTML Checker now accept an explicit figure role on the figure element (albeit with a warning), see validator/validator#757.

This change will be integrated in EPUBCheck v4.2.0, since 8d3c77e