publ-a11y
publ-a11y copied to clipboard
w3c
What should be in AccessibilitySummary
AccessibilitySummary is the only human readable accessibility metadata, which makes it very important for conveying information in a user friendly way. The question is what should be in AccessibilitySummary?
- Should it highlight the important information which is provided in the machine readable accessibility metadata?
- Should it provide the information which is not very well conveyed by the machine readable accessibility metadata (additional information)?
- Should it have another role beyond the above two?
I think we should assume implementation of the User Experience guide guidelines, which should help uest
As conceived:
- Should it highlight the important information which is provided in the machine readable accessibility metadata?
Yes.
- Should it provide the information which is not very well conveyed by the machine readable accessibility metadata (additional information)?
Yes.
The summary is supposed to be there for people who can't read the machine metadata, especially when we had those indecipherable URLs for conformance. I think there's a valid question of whether vendors, etc. who can process and display the machine-readable metadata also need to render the summary, but if we start targeting those use cases then we minimize the original intended use for having a summary.
So the question I would ask first is whether the original use case is still our goal? Do we expect any users to be accessing the package document and reading the raw metadata, or are there targets that need a simplified description? (e.g. maybe for a library catalogue?)
If we're only targeting the summary as a supplement to tools that can process and simplify reading the raw data, then we don't need to use it to repeat the information that is already there.
@GeorgeKerscher the User Experience guide states: A plain language explanation of the overall accessibility of the publication. The accessibility summary should contain information that would make it easy for an end user to determine if the publication is accessible to them. Educators would also be able to determine if the publication was accessible for use in a classroom or an online course.
It is not stating explicitly that it is to convey the machine readable accessibility metadata that is already provided, in a user friendly way. However one can interpret that it is implicit in this definition.
@mattgarrish this definition is very clear that the audience of Accessibility Summary are the users and educators. i.e. people at the end of supply chain. It is looking appropriate to me.
Thoughts are welcome.
I have mixed feelings about this. On one hand I hate duplication and repeating the technical metadata in a user friendly way well that is our Guild to displaying the metadata is really about. However on the other hand if a library or bookstore was to only show one thing showing the accessibilitySummary should be enough to inform the user how accessible this publication is which probably would repeat some of that other metadata in a user friendly way. Also Publishers wants an automated way to generate this metadata otherwise they are just going to copy and paste from previous books and won't be of any use.
Case in point we are working with a publisher in Canada for GCA, their first book had audio clips so we added in metadata about audio both the accessModes etc. and in the accessibilitySummary, well everything was repeated in the second book which had no audio :(
What I am envisioning is that based on the accessibility features hazards modes, and conformance level every publisher could use this algorithm and it would generate an appropriate human readable accessibilitySummary as a starting point and if they choose to add additional information such as "Only the appendix additional charts have just a simple alt text description"
Some accessibility characteristics cannot be captured by any of the machine-readable pieces of metadata. JDC has thought that Accessibility Summary can be used in such cases. For example, we might want to indicate (1) CJK ideographic characters beyond JIS X0213 are used, and (2) image is used instead of characters.
On one hand I hate duplication
I think this is key. The summary shouldn't be a simple rote restating of all the other properties. You shouldn't be listing every feature again in the summary, for example, but if there's some meaningful statement you can infer from the features, that would be useful to add.
The metadata guide is a helpful example. Instead of putting something like "This publication has alternative text and extended descriptions and transcripts and ..." you state the more obvious "This publication is screenreader friendly". (I know this isn't the best example given the translation issue we've already covered, but you get the idea.)
The hardest metadata for a human to read are arguably the access modes and sufficient access modes.
+1 to Matt’s comment.
Ben
On Mar 9, 2022, at 3:45 AM, Matt Garrish @.***> wrote:
On one hand I hate duplication
I think this is key. The summary shouldn't be a simple rote restating of all the other properties. You shouldn't be listing every feature again in the summary, for example, but if there's some meaningful statement you can infer from the features, that would be useful to add.
The metadata guide is a helpful example. Instead of putting something like "This publication has alternative text and extended descriptions and transcripts and ..." you state the more obvious "This publication is screenreader friendly". (I know this isn't the best example given the translation issue we've already covered, but you get the idea.)
The hardest metadata for a human to read are arguably the access modes and sufficient access modes.
— Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you are subscribed to this thread.
I like the point that Matt makes -- that the accessibility summary does not simply restate a series of properties but should integrate the information into the most general statement possible such as "screenreader friendly." The summary could then go on to give more details if necessary. But the most important piece of information for the user is at the beginning in a succinct form.
@GeorgeKerscher had a question in previous call: Now we have user experience guide for a11y metadata, which presents the machine readable accessibility metadata in user friendly way. Do we still need AccessibilitySummary. https://www.w3.org/publishing/a11y/UX-Guide-metadata/principles/
Some e-mails from my JDC colleagues mention the use of AccessibilitySummary for representing the information that is not very well conveyed by the machine-readable accessibility metadata (additional information).
- Full ruby, partial ruby, or none
- Switchability of vertical and horizontal writing
- Whether space is inserted as delimiters
Here are some other possibilities:
- Which uncommon CJK character is used
- Whether img elements within p elements are used to represent rasterized text (Note: In his talk, somebody from a Japanese publishing industry mentioned a book having such img elements for representing the name of the main character)
In all cases, I think that machine readable accessibility metadata should be introduced. But AccessibilitySummary is all what we have now.
I agree with the repetition concern and that AccessibilitySummary may not be mandatory in a world where all other accessibility metadata are displayed (by distribution web pages and reading systems). This may take time to be implemented and displaying AcessibilitySummary could be a meanwhile quickfix.
It could also be a place where publishers can inform about the accessibility choices made or innovation intents.
Exemples :
- There is no page correspondence to the printed source but both have numbered paragraphs that allows correspondence.
- Complex graphics are not fully described, but raw data is accessible at this adress. However the information essential for comprehension is included as part of the text.
- This file is not accessible but an alternative file is proposed, contact@publisher to get access to it.
- This file proposes different level of image display mode
I would stick with the actual definition and propose this summary to include :
- a quick and brief accessibility statement (This file is readable by eyes, ears and fingers without loose of information and usable in a scholar multi support context) the difficulty here is to avoid repetition but provide a useful resume and make sure it correspond to others metadata.
- additional information as Publisher choice about accessibility ; Innovations or any not well described feature.
Some issues I see in accessibilitySummary, as it' s handled now, I hope can help the discussion:
- each content creator generates accessibilitySummary differently, for a user browsing a catalog this is very inconsistent, in LIA Foundation we developed a script to generate the text automatically from the accessibility metadata, in this way the accessibilitySummary are homogeneous, but so the information is repeated (it is a transposition in simple words of machine-readable metadata)
- some content creators copy-paste the text of the accessibilitySummary from the previous publication, often with little attention, the question is: do content creators have the will/time to work on the accessibilitySummary?
- accessibilitySummary is tied to a specific language, while all other accessibility metadata can potentially be displayed in any language.
