Shouldn't this be "accessibility metadata" not just metadata?
... including color contrast, reading order, font layout, structural navigation, metadata, and text alternatives.
maybe both since we do have page orientation mentioned as well.
In 1.4.1
Shouldn't we also include "textual"?
This principle requires fixed layout content be built in a way that supports multiple reading methods - visual, audible, and tactile.
2.1
Should we also include reference that the DPUB-ARIA should also be considered?
In addition to the core technologies mentioned in the EPUB 3.3 recommendation, EPUB accessibility may also require the use of the Accessible Rich Internet Applications
wai-aria-1.2
] standard.
We do mention this is 5.3.2
Reading system developers also need to integrate the accessibility properties and values provided by the Accessible Rich Internet Applications 1.1 [
wai-aria-1.1
] and Digital Publishing WAI-ARIA 1.1 [
dpub-aria-1.1
] recommendations.
2.5.2
Is this document using US or Canadian spellings?
Programmatically, we use elements like <h1> and <p> to achieve this. Visually, we do this by styling headings with larger text, different colours, or a different font face.
2.5.4.3
Since I and l look identical in the font used should we clarify?
In the Latin alphabet, letters like (upper case i) I and (lower case l) l, b and d, or a o and e can look very similar to one another depending on the style of the font.
4.3 Example 4
I think we should also include
<meta property="schema:accessModeSufficient">textual, auditory</meta>
as we do state in the accessibilitySummary "This publication contains synchronized audio along with the text."
4.4
We say there is video with no audio descriptions, but does the video contain regular audio? If so we should probably include both
<meta property="schema:accessMode">auditory</meta>
<meta property="schema:accessModeSufficient">visual,textual</meta>
<meta property="schema:accessModeSufficient">visual,auditory, textual</meta>
and
<meta property="schema:accessModeSufficient">visual,auditor</meta>
While I do like this, be aware we are pointing to the updated "draft" in a specific folder of the User Experience guide for displaying Metadata as this is a new concept "Supports Nonvisual reading that is actively being worked on currently
The user should be informed if the content does not have accessibility metadata that would provide clarity on whether alternate renderings are supported, such as dcterms:conformsTo with a value for WCAG, or metadata values that conform to properties like Supports nonvisual reading from the User Experience Guide for Displaying Accessibility Metadata.
1.1
Shouldn't this be "accessibility metadata" not just metadata? ... including color contrast, reading order, font layout, structural navigation, metadata, and text alternatives. maybe both since we do have page orientation mentioned as well.
In 1.4.1 Shouldn't we also include "textual"?
This principle requires fixed layout content be built in a way that supports multiple reading methods - visual, audible, and tactile.
1.4.4
Should we maybe mention EPUBCheck here? Just a thought 4.1.1 Parsing (note: this success criteria is no longer applicable in WCAG 2.2, but may remain important to EPUB rendering).
2.1 Should we also include reference that the DPUB-ARIA should also be considered? In addition to the core technologies mentioned in the EPUB 3.3 recommendation, EPUB accessibility may also require the use of the Accessible Rich Internet Applications wai-aria-1.2 ] standard.
We do mention this is 5.3.2 Reading system developers also need to integrate the accessibility properties and values provided by the Accessible Rich Internet Applications 1.1 [ wai-aria-1.1 ] and Digital Publishing WAI-ARIA 1.1 [ dpub-aria-1.1 ] recommendations.
2.5.2
Is this document using US or Canadian spellings?
Programmatically, we use elements like
<h1> and <p>to achieve this. Visually, we do this by styling headings with larger text, different colours, or a different font face.2.5.4.3
Since I and l look identical in the font used should we clarify?
In the Latin alphabet, letters like (upper case i) I and (lower case l) l, b and d, or a o and e can look very similar to one another depending on the style of the font.
4.3 Example 4
I think we should also include
<meta property="schema:accessModeSufficient">textual, auditory</meta>as we do state in the accessibilitySummary "This publication contains synchronized audio along with the text."4.4 We say there is video with no audio descriptions, but does the video contain regular audio? If so we should probably include both
5.3
enable resizing a page up to 200 per cent;
percent is split up.
5.3.4 Missing an H2? Everything is underlined in red. Enable access to alternative text and extended descriptions
5.3.7
While I do like this, be aware we are pointing to the updated "draft" in a specific folder of the User Experience guide for displaying Metadata as this is a new concept "Supports Nonvisual reading that is actively being worked on currently
The user should be informed if the content does not have accessibility metadata that would provide clarity on whether alternate renderings are supported, such as dcterms:conformsTo with a value for WCAG, or metadata values that conform to properties like Supports nonvisual reading from the User Experience Guide for Displaying Accessibility Metadata.