Conforming alternate versions / equivalents #623
Replies: 7 comments 11 replies
|
I think that confirming alternative diversion should be handled exactly the same way they were in WCAG2 A lot of thought went into that and I think it hit the sweet spot. That is it is not good, but sometimes it is necessary. But it should always be possible to get to the conforming alternative version from the non-conforming version in an accessible way. And of course, the conforming alternative has to be updated as much as the original and at the same time. |
|
As discussed in the meeting a few weeks ago, there are perhaps some fresher approaches to the wording that was bashed out almost 20 years ago for WCAG 2. I'd be particularly interested in looking at concepts that focus more on providing content suited to different modalities/uses. make them equipotent, rather than setting up an implicit hierarchy of "primary vs alternative". focus on ensuring that users can get to the same content/have comparable functionality/are able to achieve the same goal, regardless of the particular modality of content they need. and ensuring that users can easily find/get to/switch to the modality that best suits their current circumstance and needs. |
having a conforming alternative is never equal to having the original be accessible. It is not even a close second. It is a bad fallback where we can't make pages accessible. |
|
you clearly missed the part where i say let's not talk about primary vs alternative... different equipotent modalities of content... |
|
I did obviously. Since I quoted it in my reply. I think
your are arguing the opposite - yes? that is why I said: |
|
I think there are two scenarios that get conflated here. The first goes back to what I think we believed in the 90s, that as a last resort, a text-only version including all the same information provides access. I think @GreggVan is mostly talking about this scenario - although it is no-longer likely to be "plain text" (I would argue that rarely does the job - although I doubt I would have many people to argue against...). A common problem with alternatives of this nature is that they are created, but not maintained and so fail the basic requirement to provide access to the same content, and another common problem is that they are built for a specific modality, meaning some people get access (assuming the version is maintained), but some people fall between the two. The second scenario is now I believe much more common (although it existed even way back when) - the content is managed in a system that generates different views/interfaces. There is decades of work behind this, too. Problems still arise - for example where it is not possible to switch easily between modes, something @patrickhlauke mentioned explicitly. Done right (and that's the hard bit), either approach can in principle be equipotent. I would argue that the requirement we want is that they are in practice. I think (I believe the same as @patrickhlauke does) that the way we explain this is heavily biased toward the first scenario. In line with the rationales for using a "conforming alternate version" given in Understanding... I think it would be good to update the way we describe this. In many cases there really is no "primary" version, because content is created in a system that provides it in different versions with different characteristics. In other cases, there really is a "primary" version, and this often creates accessibility problems that can be, but are not, mitigated. I suspect some of this would be more obvious if we fleshed out some of the things the Understanding document marks as "future link". There is plenty of work work based on the idea that there isn't necessarily a primary version, but it is important to ensure users can readily find the representation that suits them. |
|
Sort of right @chaals -- but not really we never thought of the conforming alternative as being plain text. We had HTML in mind. We thought of the primary as being something like PDF or and IMAGE and the conforming alternative as being a normal accessible web page. PRIMARY - means the document you get if you go to a URL without any flag or handshake Anything else is secondary. There cannot be two primaries -- there cannot be two "Default" pages -- it defies the meaning of URL. NOW you raise the issue of "well the server can detect if mobile or not" or even "which browser" and that is fine. One could then think of that as the PRIMARY page for each of those platforms. But that does not relate to the topic of conforming alternative. So to go back to the rule - it is -- if what a person lands on by default (the primary) is not accessible then it fail UNLESS there is an accessible way to get from that page to a conforming alternative. And that works for all of the scenarios you point out above. |
|
except the idea goes much deeper than just "the server detects a particular platform". there can be specific preferences/settings at the user agent level that either get the server to send a more suitable variant, or the choice of what to display/present to the user is done by the user agent itself locally. all from the same URL. but yes, if you insist that there will ALWAYS be a PRIMARY then everything is then an ALTERNATIVE to it. my point, again, was that this thinking is limited, when the more flexible and future-proof way to look at things is as idempotent / equipotent modalities of content. and the second point i made above was about not limiting the scope to "on the same 'page', or linked from the 'page'", but widening the scope to a site/product as a whole. |
|
It's not always the primary and secondary versions. For example, there are several experience today where there is a desktop and mobile experience - both are primary - but only the mobile meet SC 1.4.10 reflow. |
I think it is not easy and maybe even wasteful to fill out the spreadsheet the way it is set up, so I am not surprised no one seems to have made a start here providing detail on a whooping 228 requirements. The reason is that it is content (of all sorts) that might have equivalents, not requirements. It would also help to have, at the top of such a spreadsheet, a definition of terms like "global equivalent". I am not sure what that is supposed to mean. It is also important to define the (implied) difference between "equivalent" and "conforming alternate version". Things that clearly need to be discussed and, if possible, nailed down are to what extent a product or content
could qualify / count as equivalent or conforming alternate version. And whether we want to retain the concept of in-page / in-view conforming alternate version. For all that, examples / cases are useful, but not in the exhausting breadth suggested by the spreadsheet. |
|
@detlevhfischer Maybe we need a rule someplace in conformance that talks about components of a page/view that are inaccessible need to have an accessible equivalent that is easily locatable from the inaccessible component, and the inaccessible component cannot in any way interfere with the use of the accessible component or the rest of the page. Think that would replace the whole table. |
|
I submit that we need substantively different phrasing because the CAV term/concept is too confusing for regulators. Here’s what DOJ put into their recent regulation for Web and Mobile Accessibility (28 CFR Part 35, Nondiscrimination on the Basis of Disability in State and Local Government Services) emphasis added:
DOJ’s rational for this from the preamble lays out their misunderstanding and evidences that they did not sufficiently digest Understanding Conformance. |
|
I don't understand what they're doing here. If web content and mobile apps do this:
they can already use conforming alternate versions, as the conformance requirements in WCAG 2.1 already allow for this, so you'd do this while conforming to WCAG 2.1, and therefore already comply with 35.200, b 1. |
|
FWIW, to add a datapoint: my team works for the regulator, and we recently updated our guidance on CAVs and found the spec text clear and not confusing (unless we grossly misunderstood it without realising). |
|
I am delighted that CRT is working with your team! That is great for both teams and for the public! My concern is that “technical and legal limitations” are already described by why permit alternate versions while the regulation phrasing gives the impression that this is something additive or a new constraint. The preamble implies that CAV are typically out of date when, if that is the case, such content is not CAV by definition! But the worse thing, in my opinion, is that the regulation phrasing is not compatible with the fact that:
Specialized versions designed to address low literacy, ESL, or maybe a “signing avatar edition” are vanishingly rare as it is — and now such initiatives are seemingly incompatible with the ADA. |
|
I think they are illegal only if the default version does not conform. If the default version conforms there is not prohibition on ALSO providing alternatives that are more accessibility to particular parties Having said that, however, I think that it is a mistake to make it illegal to have conforming. Alternative versions qualify as long as you can get to them in an accessible way from the original. There are some originals that just can't be made accessible. For example, a collection of pictures of the dead Sea scrolls. Are examples of inaccessible content. Archives of documents that were created in the past and our legal documents and we cannot alter them in any way. |
Those both fall under their “where it is not possible to make web content directly accessible due to technical or legal limitations” caveat at 35.202, but is not actually listed in exceptions. It‘s easy to miss and covered entities might waste a lot of time and energy on something moot. I strongly agree that alternative versions rightfully qualify as long as you can get to them in an accessible way from the original. +1 to the point that “default version” is underspecified to the point that that it‘s unhelpful. |
|
Notes from the meeting, starting with some example scenarios we should consider:
WCAG2 has a global alt-version for full page alternatives, we are also considering an alternatives for within-pages/views. It should be very clear what counts, it should be as easy to achieve/complete. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
At the AG meeting on Tuesday March 17th, we discussed how to incorporate conforming alternate version and equivalent into WCAG 3 as one universal mechanism (slide deck).
Our next step is to document the current use in WCAG 3:
Focusing on the provisions your sub-group works on would help to spread things out.
Please take some time to:
All reactions