Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Editorial changes for clarity and removing tool names #2587

Merged
merged 8 commits into from
Oct 30, 2023

Conversation

wareid
Copy link
Contributor

@wareid wareid commented Oct 6, 2023

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.

@sueneu
Copy link

sueneu commented Oct 14, 2023

Edits intended to amend the current document so it lays out the goals and challenges without yet providing specific techniques

Abstract

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.

1.1 Overview

This note serves to help authors and publishers try to address…

The sentence is less discouraging without "try to"

1.2 The limits of fixed layout accessibility

Fixed Layout publications present some unique challenges 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.

2.1 The page position problem

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?

@gregoriopellegrino
Copy link
Contributor

Github allow me to comment only on changed sections, so here are my comments for unchanged section:

  • I would group sections Reading Order, Images in fixed layout, Navigation, Legibility in something like Challenges
  • Reading Order and Navigation sections seem technical on how to create the files (HTML only, not SVG) and how to work in InDesign, perhaps the more technical parts should be moved to another document?
  • the Legility section looks interesting to me, but several things indicated are not WCAG requirements (at least for AA level), maybe we need to flag that?
  • the Accessibility metadata section seems to me to be largely a repetition of EPUB Accessibility 1.1 techniques, maybe we could just put meaningful metadata to put or not to put for FXLs?
  • we have to write the whole section on Reading Systems: is there any spec we can refer to?

@wareid
Copy link
Contributor Author

wareid commented Oct 16, 2023

@gregoriopellegrino @sueneu I made some changes to the document, let me know what you think.

@gregoriopellegrino
Copy link
Contributor

For me: a big step forward!

Some small things:

  • there is an error in ReSpec (maybe a header is missing?).
  • in the Abstract I would add the word "EPUB": "... for EPUB accessible fixed layout ebooks..."
  • I would start "Overview" with the word "EPUB": "EPUB Fixed Layout (FXL) publications..."
  • in the Overview, second paragraph, I have a doubt about mentioning media overlays: they are a non-mandatory but very useful feature, maybe it is better to specify it?
  • in the Overview I would remove the sentence "In addition, accessible FXL EPUBs need to be able to adjust their font settings and/or color themes to accommodate a variety of reading needs."
  • in The limits of fixed layout accessibility the sentence "Fixed Layout publications present some unique challenges for accessibility. The requirements laid out in [epub-a11y-11] recommend [wcag2] AA, but for many use cases in fixed layout, that might not be possible without fundamental changes to the content." seems a bit misleading to me: FXL documents can be compliant with WCAG 2, level AA, even without "fundamental" changes
  • In the list "In addition, there may be additional text and image objects on the fixed-layout page which are not required to be included in reading order, such as:" perhaps "Section or chapter headings" means "running headers"?
  • Under "Images in fixed layout" > "Overview" I would move the phrase "" to the techniques "As much as possible, we recommend making the text on the page its own layer, using technologies such as SVG and CSS to achieve the desired styling and placement, while also making the text more accessible to the user."
  • I would move "Images in fixed layout" > "SVG (Scaleable Vector Graphics)" and "Images in fixed layout" > "HTML" into the techniques
  • In "EPUB navigation document" > "Page lists" the note seems superfluous to me, as it is outdated
  • I would move "Navigation" > "XHTML page titles" to the techniques
  • "Navigation" > "No NCX requirement", "Navigation" > "EPUB package document", "Navigation" > "Publication reading order", "Navigation" > "Hiding content" in my opinion are not related to accessibility
  • "Navigation" > "Structural hierarchy" in my opinion the example should be moved to techniques
  • "Navigation" > "Region-based navigation": what is the actual status of this document?
  • "Legibility," I would specify that this guidance is beyond WCAG 2 level AA.
  • In "Legibility" it seems to me that many of the directions are subjective, rather than objective and supported by scientific references
  • In "Legibility" > "Font selection" > "Font sizing" the indications on the use of em and rem seem to me superfluous, given the impossibility of changing the font size within the page
  • "Color contrast" is a "copy-paste" of WCAG, insert a link for value references?
  • Directions in "Text layout": the part about semantic structure should be moved to "Structural hierarchy", the other directions seem to me very subjective, in my opinion we cannot give directions that "limit" creativity, unless objectively supported (e.g. color contrast)
  • "Tables": I would move from the second paragraph onwards into techniques along with "ARIA roles for tables"
  • in "Package metadata" I would indicate the fact that not blocking orientation is a requirement of WCAG (https://www.w3.org/TR/WCAG22/#orientation), so the indication not to block orientation is not a "suggestion" but a "requirement"
  • "3.1 Accessibility features" I would explain more clearly NOT to use "displayTransformability" in FXL publications
  • "3.2 Access mode", I would specify "A picture book without live text would only have an accessMode of visual"
  • "3.4 Accessibility hazards," perhaps we can remove? I don't see it adding anything for FXLs
  • "3.5 Accessibility summary" the role of accessibility summary has changed a bit, I don't know if this section adds anything specifically for EPUBs

@wareid
Copy link
Contributor Author

wareid commented Oct 23, 2023

I am able to generate previews now!

@mattgarrish
Copy link
Member

A few minor notes:

  • It's hard to read references in place of specification names. (For example, "The requirements laid out in [epub-a11y-11] recommend [wcag2] AA", I'd switch to "The requirements laid out in EPUB Accessibility 1.1 [epub-a11y-11] recommend WCAG 2 level AA [wcag2]".) It's better to use references only after something that is citable or if you're only talking generally about a referenced standard, with a clear short name, and not some specific aspect of it (e.g., "There is no font size guideline in [wcag2],..." would be okay because you're just going to replace the reference with "WCAG 2 [wcag2]").
  • We dropped the uppercasing of proper nouns in EPUB in 3.3 so you can probably do the same here (e.g., "An accessible Fixed Layout EPUB file" can be "An accessible fixed layout EPUB publication"). The document jumps back and forth between upper and lower case for "Fixed Layout", but I doubt any of the upper cases are necessary.
  • Heading case is a bit of a mix still. Sections 2 and 5 have title cases headings but W3C style is to use sentence case.

@mattgarrish
Copy link
Member

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 w3c/wcag#3515)

@wareid wareid merged commit 13ae15d into main Oct 30, 2023
1 check passed
@wareid wareid deleted the fxl-a11y-eaa-revision branch October 30, 2023 14:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants