Editorial Feedback for UX Guidelines document

[wareid]

My colleagues and I at Kobo reviewed the UX Guidelines document draft, and have some feedback on some of the content. Much of this is editorial and given with consideration to improving the usability and comprehensibility of the document. I've done my best to link the feedback to specific sections in the document, there are some common themes, so apologies for any repetition.

2. General Overview

• Incorporate the text of the “Note” into the general overview, and specifically name the metadata standards we provide techniques for to aid understanding, inclusion of the note makes the section a little bit challenging to parse.

2.3 Metadata Techniques

• Unsure what the “note” text provides here for the reader, I would suggest removing it.

3. General Information

• Language here is a bit confusing and I think assumes a lot of reader knowledge about metadata display and the other documents in this group, I think I would recommend more introductory language into the content of this document.
• In light of the content of the second paragraph/list, and then the content of 3.1, I wonder if this section should be reframed as focusing on product information and benefits to accessibility? It’s not clear that is section is meant to refer to general metadata.

4. Key Information

• The usage of "Note" for key information in this section, like where to place information or whether or not to show it feels inappropriate, I would recommend removing the notes and making that text the first sentence or prominent in the sections.
• In reading the whole section, I am unclear who the intended audience for this information is. In parts it feels directed at displayers of metadata, in other parts it seems to explain the usage. I think clarifying the audience or audiences, and targeting them would aid in the understandability of the document.
• The order of the properties does not seem to follow a pattern, and it’s unclear why properties are ordered in this way. Parts of the things listed in “additional accessibility information” appear to apply to previous sections (i.e. page breaks should be in navigation).
• 4.2.1 - I know I have made comments in the past about the usage of “read aloud” and clarity for users, but I’ll reiterate them here. I don’t think this language is clear enough for users of AT, and it might be better to be more specific.
• 4.3 “Conformance” - Because this note is repeated, I wonder if there is a better way to communicate the message, either by grouping all of the sections under a “always display” grouping or some other means of tagging outside of using a note.
• 4.4 - This feels redundant to state for standalone audiobooks vs ebooks with synchronized media.

6. Localization

• It’s great that testing for the strings is mentioned, but is there a possibility of adding links to the testing (if possible) or some reporting on the results to help people see what was tested and what kind of feedback was received? Alternately, some insight into the process may also be helpful or informative.

[gautierchomel]

About the localization part, the JSON metadata/description key has this task.

We can consider to add a "project URL" key but I'm not sure those projects will have persistent URLs in time.

[jonaslil]

As to 4.2.1, my colleagues and I at Celia agree that "read aloud" does not clearly cover screen reader use.

[gautierchomel]

Regarding 4.2, we've tried to define the action as possible (you can read with your ears and fingers) without technical vocabulary (Assistive technology, screen reader, TTS).

An ebook does not block screen reader use when all the content is available as text. It can enhance the experience by using ARIA roles (detailed in 4.10). However, using a screen reader also depends on the reading system and the AT/RS/OS combination.

In our workshops, we've met users willing to know if this works with NVDA or with Voice Over. The "screen reader" information alone was not sufficient and meaningful. However, we cannot respond to this question from the sole ebook point of view; more parameters are necessary. This approach can be implemented by a platform with knowledge of the user's setup. The Canadian Accessible Title Database did the experiment (it is not available now, but I heard there is a project to follow that experiment).

We should take all precautions if we want to add something to indicate that the ebook will not block assistive technologies. And for most implementers, it will mean to add an explanatory somewhere.

At 4.2 level, it could be a note, but the document is already heavily annotated.

At 4.10, I feel we could better explain what power ARIA provides to the user.

In the end, why should we not have an entire section to address assistive technology, with a definition, explanation of combinations, possible blockers, and some flexibility in presenting that information?

[gautierchomel]

See also #469