How can we improve understanding of AccessModeSufficient

[avneeshsingh]

The schema.org property accessmodesufficient is very important to know how one can read the publications, by using screen readers, by listening to audio etc. But it looks that it is one of the confusing accessibility properties.

• The name is similar to another property accessmode.
• The name does not indicate its purpose very clearly.
• The representation of values is somewhat similar to that of accessmode.
• There may be other reasons also, which makes it confusing.

How can we reduce the confusion?

• Do we need better description and communication for it?
• Is it practical to think about updating/changing the name accessmodesufficient?

Suggestions are welcome.

[BenSchroeter]

For me, it is confusing not because of the name of the property, which I think conveys the intention, but rather the values.

How I can consume the publication depends not only how the content is presented (words, images, sound), but on my capabilities (perception and technology). This intersection cannot be expressed in the values. How the content is presented is covered in the accessmode property. accessmodesufficient attempts to inform how to consume the content using the same values, which doesn't really work.

[TzviyaSiegman]

I think @BenSchroeter explained this very well. I wonder if we might consider looking at Functional Needs (https://www.w3.org/WAI/GL/WCAG3/2020/functional-needs/) as a guide for both naming and an approach for values.

[clapierre]

I would prefer not to change the name of the property as this took years to get into schema.org

I think if we make clear examples of the most common types of books and outline how these books are coded internally and what the accessModeSufficient values are we should be good. There may be corner cases which we can work to improve as publishers bring them up.

e.g. Children's Picture book accessModeSufficient = visual

Trade Book (no content images) accessModeSufficient = textual

STEM Book (Images with alt text and extended descriptions) accessModeSufficient = visual,textual accessModeSufficient = textual

Then the publisher can look down the list to see what their book they are creating is closest to to use that. Maybe thats an over simplification and there are too many corner cases when you throw some audio into the mix then how does this impact these combinations.

Seems to me this is a flowchart where a number of questions are asked and depending on all the answers you get the resulting metadata.

Eg.

Is this book primarily text base?
Yes-> Are there content images in this book which are needed in the understanding of material?
    Yes -> Is there alternative text descriptions which describes these images completely
            Yes -> AccessModeSufficient = "textual" AND  AccessModeSufficient = "textual,visual"
             No-> AccessModeSufficient = "textual,visual"
     No -> AccessModeSufficient = "textual"
No -> Is this primarily a picture book?
     Yes -> AccessModeSufficient = "visual"
      No-> Is this an Audio book?
 etc...

[wareid]

100% agree with Ben, and I think Tzviya's suggestion is a good one.

A thing that has continually bothered me as I've been getting more familiar with the a11y metadata is how to present it to users in a useful and informative way. There are two things I look at, (please note this is really specific to retail, less so potentially to education): how is this going to work in search, and how is it going to work on the product page.

For search, metadata that aids in the search and discoverability needs to be in a boolean format to aid in filtering. Those filters need to be understandable to the average user. Accessible can be a boolean value at a high level (yes it's certified, no it's not), which for retail I think is as far as I'd go at least initially.

For product pages, there's more room to expand on granular information the user might need, like features or hazards. In a retail context needs to be clear, simple, and quick to find. The challenge for me with AccessModeSufficient (and to a certain extent, AccessMode) is that it's not immediately a clear field to the user. If the book is identified as accessible, I think that carries certain value on its own, especially if its identified as WCAG AA compliant. What is more important to the user is knowing if there are any exceptions or factors that may impact their interaction with the book or their experience reading it.

What might help us more here is actually performing some user testing. We're all professionals with too much exposure to this type of language. If we asked 10 people what they thought "this content can be accessed visually and textually" means, we might get a clearer answer.

[mattgarrish]

If this wants to be a discussion about changing the schema.org property, it should be transferred to the vocab group. Like @clapierre, I'm not a big fan of changing names or definitions given the work it took to get them in, plus the metadata is based on AccessForAll, so it's not really in our mandate to make that kind of change.

What we've done recently about emphasizing the single-value sufficient access modes should also help with understanding this property, which I fully agree is the hardest to wrap your head around initially. We can also do a better job of explaining the values, like "textual" equates to "screen-reader friendly".

[madeleinerothberg]

I have no desire to stir up anything, and I agree that making changes to the property name at Schema.org is likely a long process. But I'll just note that accessModeSufficient was added post-IMS Access for All, so that particular angle isn't a problem. We also renamed a number of properties when we moved from IMS to Schema.org. (Also FYI, IMS just re-branded as 1EdTech. I don't know if we need to change any of our references.)

I think suggestions above for improving our documentation and support materials may solve some of the problems.