search

w3c / a11y-discov-vocab

Repository for the maintenance of the schema.org accessibility property values for discoverability.
https://www.w3.org/community/a11y-discov-vocab/
Other
15 stars 8 forks source link

Add specific requirements for setting display transformability #86

Closed mattgarrish closed 1 week ago

mattgarrish commented 1 year ago

Here's a start on possible improvements to the definition.

Feedback welcome from anyone interested.

Preview | Diff

GeorgeKerscher commented 1 year ago

This is looking good. Where it says: The property must not be set for content for which no user agents are available that can modify the text.

Should it be modify the appearance or presentation of the text?

Should we say anything about text on images that have alt text or extended descriptions would support display transformability?

mattgarrish commented 1 year ago

Should it be modify the appearance or presentation of the text?

Sure, that sounds more precise.

Should we say anything about text on images that have alt text or extended descriptions would support display transformability?

Ya, I was only thinking of alt text when I drafted it, which isn't often made available to visual readers. I think we could add an exception about the text also being available in a form that allows for modification.

gregoriopellegrino commented 1 year ago

My question is: in case a publisher can't render a chapter header via HTML and CSS (to have the same look-and-feel of the printed book) as the paper and inserts it as an image (bitmap or SVG) with alternate text (this is a technique we see a few times), can the displayTrasformability property be set or not?

Perhaps we should rely on common sense and say that when most of the content is transformable, then use the displayTransformability property?

mattgarrish commented 1 year ago

But if the user can't read a book's headings because they're bitmaps that they can't make legible, how does that help them?

Common sense isn't a helpful guide as it opens the door to any interpretation of what a user should accept.

What EPUB needs is reading systems that provide a way to turn off images to get the alt text, like browsers allow you to do.

gregoriopellegrino commented 1 year ago

Ok.

Do you think that we can assume that if an EPUB is reflowable and WCAG 2.1 AA compliant (in particular with Success Criterion 1.4.5 Images of Text), we can say that displayTrasformability should be present?

mattgarrish commented 1 year ago

WCAG 2.1 AA compliant (in particular with Success Criterion 1.4.5 Images of Text), we can say that displayTrasformability should be present?

I was thinking about whether we could link into 1.4.5 last night rather than talk about images of text ourselves here. It limits the ability to use images of text to only those that are essential to the presentation. I'll see if I can adapt it.

I don't know that we can assume a book that meets level AA would automatically be transformable. 1.4.12 is the closest thing AA has, but it's more limited in what can be changed. It doesn't require that users be able to change the font family or size, for example, or the foreground and background colours (you only have to meet the minimum contrast, not allow them to be changed). You seemingly need to combine 1.4.12 with 1.4.8, but even that leaves out font family and size.

murata2makoto commented 1 year ago

There are visual adjustments specific to CJK. Switching from vertical writing to horizontal writing and vice versa, hiding or exposing ruby, addition or deletion of space characters as word separators. changing the ruby color, etc. I can imagine that other languages have such specialized requirements. Is one value (displayTransfomability) good enough for international users?

mattgarrish commented 1 year ago

It's a lot of stuff for one property regardless of language, but the concern with getting more specific is that we could proliferate a lot of metadata that in the end says mostly the same thing to users.

I was thinking yesterday, for example, that we could split what we have right now in three: spacing transformability, contrast transformability, and text transformability. That's what the old slash syntax was allowing for every property (displayTransformability/font-size), but do users really want that specific of information or do they just want to know that the display is modifiable? My guess is the latter, so we're just making more work for everyone to get to the same destination.

I can add the characteristics you've identified and note that the definition is open to further refinement, and then see where we're at.

gregoriopellegrino commented 1 year ago

I was thinking yesterday, for example, that we could split what we have right now in three: spacing transformability, contrast transformability, and text transformability. That's what the old slash syntax was allowing for every property (displayTransformability/font-size), but do users really want that specific of information or do they just want to know that the display is modifiable? My guess is the latter, so we're just making more work for everyone to get to the same destination.

My other question is: for content creators, is there really a way (not too complex) to enable/disable transformation of only some of these graphical features?

mattgarrish commented 1 year ago

is there really a way (not too complex) to enable/disable transformation of only some of these graphical features?

What do you mean, like DRM to block transformability? I believe Word and PDF can both block any display transform by locking the file, but outside of FXL in EPUB I'm not sure authors can prevent users from modifying styles.

gregoriopellegrino commented 1 year ago

I mean, can you make a publication (I would focus on EPUBs) that allows spacing transformability but not text transformability?

mattgarrish commented 1 year ago

Other than incorporating frameworks/stylesheets outside your control, which isn't very common in EPUB, who wouldn't fix the problems that prevent some properties from not being transformable? If you rely on the cascade rather than important declarations and style attribute overrides, it's not a complicated requirement to meet.

I'm not sure there's a real world case for publications that only meet some aspects but not others.

clapierre commented 2 months ago

@gregoriopellegrino I had to resolve some conflicts before I could merge, have a look and make sure you still approve this PR.

mattgarrish commented 2 months ago

I wonder if we should take this back to the CG before merging, at least to ask for a final review?

That's sort of why it never got added. We had a few discussions about this a year or so ago but then the metadata guide has taken priority since. I believe this captures where we were in the discussions, but it's been so long now I can't say so definitively.

gregoriopellegrino commented 2 months ago

I like the idea of asking the CG for feedback.

clapierre commented 1 week ago

There are a number of changes in here references to WCAG 2.2 and correcting ARIA etc. I don't believe there is anything truly controversial here and think we should merge this so everyone can see this when we do our final release / media blitz next week.

Any objections?

mattgarrish commented 1 week ago

The worst that can ever happen with a vocabulary definition is we have to walk back the change...

Don't forget that we have to publish through the cg-reports process, so add a couple of days to make sure these documents get republished on time for any announcements next week. I'd suggest wrapping it up today and getting a release ready later this afternoon or early tomorrow.