Closed wareid closed 1 year ago
Edits intended to amend the current document so it lays out the goals and challenges without yet providing specific techniques
The abstract reflects a technical focus. Since we want a non-technical focus for this document, how about—
This document, EPUB Fixed Layout Accessibility, outlines the goals for accessible fixed layout ebooks while acknowledging the challenges unique to the FXL format.
We could add that we will be sharing techniques and best practices—
After further study and testing, [the group] will produce an additional document that includes techniques and best practices for ebook creators.
This note serves to help authors and publishers
try toaddress…
The sentence is less discouraging without "try to"
Fixed Layout publications present
some uniquechallenges for accessibility that are more straight-forward to address in reflowable ebooks.
2nd paragraph, first sentence. Should we make the epub issue the focus of the sentence?
It is almost impossible to implement text transformation within the fixed layout format, making it difficult to accommodate people who rely on that accommodation, such as people with low vision or dyslexia.
Since we’re no longer putting code examples here, we should change the 3rd paragraph. And we want reading systems to up their game, too.
We want to recognize these challenges for content creators and reading systems. We encourage content creators to explore the full range of accessibility options when making fixed layout publications.
Make it clear in the heading that we are addressing reading order
2.1 Page Position and Reading Order
state the accessibility ideal
For complex designs, the position of objects on the fixed-layout page is not a reliable indicator of their reading order. All users should encounter information in the same order, even if accommodations like a screen reader are required. A keyboard user should be able to predict where the focus will go next when the source order does not match the visual order.
We don't want to lead keyboard users randomly around the page/screen, but what if there is a quirky order in which the author/illustrator intended the text to be read?
This and the following sections are really helpful implementation information. Shall we move this to the future techniques and code examples document?
Github allow me to comment only on changed sections, so here are my comments for unchanged section:
@gregoriopellegrino @sueneu I made some changes to the document, let me know what you think.
For me: a big step forward!
Some small things:
A few minor notes:
Also, you can link right to the level AA definition now that 2.2 is a recommendation: https://www.w3.org/TR/WCAG2/#cc1_AA
(Alas, the url isn't working unless you strip the "2", which is not the url you'd want, but I've opened an issue about this in https://github.com/w3c/wcag/issues/3515)
As discussed in the last minute, I've made some editorial changes to the language in the document to clarify it's purpose. I've also removed any mentions of specific software/production tools.
Feel free to use this PR to make comments on the document.