Priority of supporting user control vs. authoring provided support in exploratory prerequisite levels

[rachaelbradley]

As we’ve discussed the possibility of creating levels of outcomes for WCAG 3, we have explored creating a “prerequisite layer.”

The current working proposal is that prerequisites would include outcomes at:

• cause safety Issues,
• allow AT to provide support, and
• prevent task completion even with ideal AT support

A question that has come up based on this is which should be prioritized:
• Outcomes that allow AT to provide support, or
• Outcomes that require Authors to provide support.

Some examples:

	Allow AT to provide support	Require authors to provide support
Summary	All content is provided in true text or text alternatives	Author writes and provides a summary
Color Contrast	Content is in true text whenever possible (avoid images of text) and doesn’t prevent platforms and AT from changing the colors	Author creates a color scheme that falls within a minimum and maximum color contrast
Motion	Contents respect motion related settings	Authors avoid motion or allow users to pause
Alt text on images of text	Authors avoid backgrounds and design that would prevent optical character recognition	Authors provide alt text

[rachaelbradley]

(Chair hat off) I support prioritizing outcomes that facilitate user control and falling back to author provided support when assistive technology, platforms, and/or browsers are unable to meet the need (What that looks like would need to be determined). As technology is better able to provide support to meet the needs of people with disabilities, authors will ideally have less work to complete. By prioritizing outcomes that support user control, I believe we make WCAG 3 more flexible with the goal of reducing author workload while still providing necessary accessibility.

[bruce-usab]

My only concern with anything in OP is for a "maximum color contrast" as (1) white on black text has been the default for decades, and (2) dark mode (and analogs) is now widely available. I submit that a widespread practice of near-white on near-black would be a worse user experience than the status quo. I am open to data and arguments to the contrary.

On the other hand, it's possible that the increasing availability of High Dynamic Range (HDR) will dramatical exacerbate this issue.

[mraccess77]

Thinking back to the days of DOS - I believe the text was not white but a light gray on dark. I believe this was similar with programs like Word Perfect with dark blue on grey. Full on white on black background could be more problematic for many.

[mraccess77]

One challenge with user control of things like contrast is the complexity and availability of those settings to the user. For example, say the requirement is to not prevent the user from changing the contrast of the text and background. The user is then left to change the color of text and background AND make sure it works across all websites and all functionality in the site.

There are 2 primary methods of addressing contrast - an updated style sheet and a filter that is applied over top of the page. The user then has to be able to apply those styles and filters on different browsers, mobile, desktop, perhaps via extension or perhaps built into the browser.

Even for a very knowledgeable person - trying to override the colors so it works correctly for all things on the page is problematic. Color is used for everything from states, highlighting, mouse pointers, and scrollbars, to focus indication, primary actions, disabled control, etc. AND this type of logic needs to be applied by the user on each site they visit and then needs to be on each device they use. Not to mention they need to fix this on the site that has low contrast - so being able to find and fix the issues is a problem.

There are solutions that site owners can put on their site that examine the colors and automatically adjust them to meet the requirements without requiring the user to make this decision. They are not perfect but these solutions would be the most likely option to be successful if you could show that these indeed did work across the site for all functionality then you could rely on them - if these features were available (upon activation) to all users and actionable in accessible way and also did not create a separate experience.

[julierawe]

Couple questions about how this debate applies to WCAG 3's "Text and wording" outcomes:

• Does "AT support" include AI tools like ChatGPT?
• Would using AI-generated summaries or rewording let authors off the hook for writing essential information that is very jargony or otherwise hard to understand?

[lseeman]

Recent reviews of AI for coga is that the support is patchy and still the wrong information or mistakes are often present. Unfortunately, it is often really hard or not possible, for coga users to recognize the mistakes because of their disability. So the support is sometimes worse then nothing as give the wrong information, and the user does not know that it is incorrect.

[lseeman]

note I tested a few popular AIs last month

[jmcsorle]

This is actually a very complex question. Given the current state of AT and other technologies (browsers, AI, etc.), I support prioritizing outcomes that require authors to be responsible for the accessibility of their content. I am in favor of user control, but not when that control is dependent on high levels of technical expertise in order to gain access to information.

I believe the ultimate goal is for us to achieve a state of design that allows users to have personalized experiences that are genuinely capable of meeting diverse needs. Progress is being made in this area, but it is far from perfect. In my opinion, if a solution uses AI to generate things like alternative text or to produce plain language summaries, it should be the author's responsibility to rigorously test those solutions to ensure that the outcome is usable by everyone and will not result in the exclusion of whole populations of people. I realize that authors have a heavy burden, but whether you accidentally or intentionally create something that is inaccessible, the result is the same for the person who is excluded (paraphrasing Judy Heumann).

We need to be able to define how author responsibilities will change as technical advancements are made. For example, what assumptions can we make about the impact of current user agents (e.g. browsers and various assistive technologies) on content development and how might those assumptions change within the next x# of years? How is AI affecting AT today and how do we anticipate it will affect it in the future?

We cannot completely future-proof our guidance, but we can make reasonable assumptions about what may or may not cause harm to people with disabilities - especially with high-stakes content such as emergency messages or high stakes assessments. I think we need to proceed with caution about relying on user control that may or may not require unexpectedly high levels of technical expertise, or may or may not be supported by AI or other technical advancements. Yes, I want to make authors' jobs easier, but not at the expense of users.

[rachaelbradley]

6 August 2024 Summary of Conversation to Date

Note: I am using "Platform" to mean all support that does not originate from the author, such as the support from the operating system, browser, assistive technology, authoring tools, or a combination of these.

There is some support for writing a standard that prioritizes methods that meet outcomes through a combination of platform support and authors avoiding breaking that support. This would likely be done by placing the methods to avoid breaking platform support within the prerequisite level. That said, there are concerns that:

• The ability to of the author to rely on platform support assumes a platform stack provides adequate support
• In many cases the platform does not yet provide adequate support
• The platform may provide support but only through a means that is expensive or technically difficult for the user
• When platform support is not adequate or is expensive/difficult, author support must be provided
• Authors need a way to determine when platform support is adequate
• Some situations such as emergency information should always require author support.

[mraccess77]

I would add the complexity of the support - how easy/automatic is it vs. something complex that in theory could be done but in practice would require the user to have to create something like a customs stylesheet.

[DuffJohnson]

Thanks for posing this question.

We believe there are prerequisites for accessibility in documents that differ from prerequisites for accessible web content. Some examples (for document content presented in a browser-integrated document viewer) are provided below.

Document features (that don’t have direct web equivalents)	Allow AT to provide support
Semantic ordering (In PDF, rendering order and semantic order are often not the same)	Logical content order is provided to AT
Precisely typeset text	Text meaning is represented via Unicode and language identifiers
Annotations (e.g., markup, notes, etc.)	Annotations are available to AT in context
Artifacts (e.g. for pagination)	Artifacts such as page headers and footers can be skipped
Optional content (layers)	Awareness of layers
Semantic constructs:Endnote vs footnoteRedactionBates Numbers	Awareness of document-specific constructs
Descriptive Page Labels (e.g. i, ii, iii, iv)	Awareness of page labels
Associated Files (e.g. MathML, ChemML)	Context of files provided to AT
Document SecurityDigital SignaturesPasswordsDocument access permissions	Awareness of document security features

[bruce-usab]

@DuffJohnson I really appreciate this table! I note you write "Some examples...are provided below."

Is there a longer listing you might point us to?

[DuffJohnson]

There's no such list per se. I mentioned "examples" to be clear that this list was not intended to be exhaustive.

[DuffJohnson]

...but as I think about it, all of the above examples are reflected in various provisions of PDF/UA (at least where we have supportive features in the format).

So, if it's useful, I could work on developing a more comprehensive list .

[alastc]

I'd like to summaries the challenges (from these comments and the meetings) with this approach to prioritization of requirements. In the next post I'll make a proposal.

• Requirements (such as adjusting contrast) where there is a complex interplay between the authored content the user's settings. How much would authors need to test this? For example:
  • The user's styles could interact in many ways with the authored styles of a site, and the site could change over time.
  • The ability for tools such as LLMs (Large Language Models) to summarize content or provide alt-text could change over time or be different between different products.
• High technical ability required to setup some AT settings to achieve things (like adjusting contrast).
• Cost of AT may be an issue that prevents widespread usage of that AT, and could vary hugely by region.
• Some situations such as emergency information should always require author support.
• Different platforms (e.g. Web/HTML, PDF, Native app, etc) may provide different levels of AT support, so that dimension would need to be accounted for in the structure.

Proposal in the next post.

[alastc]

As a proposal for how we could account for the above challenges, I'm going to draw from the Accessibility Supported discussion.

Given our structure of Outcomes, Methods, Techniques, and a decision tree to guide people to the relevant methods and techniques, we could use a model of the responsibility shifting as you go up the levels. I.e. shifting from user and user-agent responsibility to author responsibility.

If and when user-agents meet pre-requisite items, then authors would not need to fulfill the baseline requirements.

Prerequisite

The tech-specific techniques that are provided by WCAG3 could be assumed (by authors) to work for the given technology (HTML, PDF, ePub, App etc). As a group we would have to take a lowest-common-denominator approach so that we are reasonably sure that a technique works across technologies, regions, and is widely available to users for free without a high level technical understanding needed.

Ideally, we would include prerequisite items that the user-agents could do but currently don't, so long as this is clear to authors. That way if/when user-agents do fulfill them, it is a change to the state of the requirement rather than creating new content for WCAG3.

Baseline

(Copied directly from the Accessibility supported proposal)
Techniques published by the working group at silver level would include some information about AT compatibility. For example, Method X is supported since Jaws v16, NVDA 2022, Dragon v15. This would be a tagging mechanism in the WCAG 3 content management system.

If authors use other methods to meet the outcome there would be a requirement for testing by the author (or other party).

The set of user-agents needed for that testing (and conformance) would be set by the author (or their regulator), with some informative guidance from the working group. That guidance would be to assess the common assistive technologies in your region, or by asking stakeholders (such as charities who support people with disabilities), or due to the environment (e.g. a corporate environment where only certain AT are supported).

If the set of user-agents for your conformance includes one(s) not covered by the working-groups information, there would be a requirement for testing. E.g. If you are in Japan and a method doesn’t include a key japanese screenreader, you would need to test it to rely on that method.

There should be a process where interested parties (e.g. an accessibility group in Japan) could add compatibility information to the WCAG3 methods.

The compatibility information should not be too detailed to make maintenance an arduous task. For example, once a particular feature is supported by a product (e.g. NVDA) it would be tagged with the version that first supported the feature (e.g. NVDA 2022.1). If it later drops support for that feature, the tag would be removed.

(Additional to the Accessibility supported proposal)
This level would not include techniques which require complex testing, for example a colour scheme against variable user-settings, or the quality of alt-text produced by AI.

Enhanced

At this level the methods/techniques could make authors primarily responsible for AT testing and / or usability testing in order to meet the requirement (e.g. an assertion).

[detlevhfischer]

I wonder where in this scheme (in prerequisites?) you would place things that require users to activate settings (and know about them) that then meet outcomes without further author-provided baseline methods. This is the famous "there is a mechanism" approach which introduces significant leeway in defining what can count as acceptable (discoverable, equitable, equivalent) mechanism.

Some examples:

• Reduced motion settings in mobile OSs
• User agent settings to enforce visible keyboard focus contrast (think of a permanently visible version of Chrome's focus highlight setting)
• "Increase contrast" settings (e.g. in iOS) that make native switch controls with low default contrast meet (the future equivalent of) 1.4.11
• Software-provided accessibility accommodations that add controls to meet certain outcomes (the way the airbnb app has something tucked away under profile > settings > accessibility that adds controls for the map zoom to the maps and presumably then meets (the future equivalents of) 2.5.1 Pointer gestures (pinch to zoom) and 2.5.7 Dragging Movements (drag map)

In all these cases, users need to know (and may often not know) that there are accommodations available in the app/software, the user agent, or the OS which would meet outcomes that the default might not meet. So this boils down to the question whether the "there is a mechanism" approach of WCAG 2.X is carried over to WCAG 3, and whether we will (or even can, in a general way) define requirements for both the discoverability, documentation, and equivalence of such a mechanism.

[alastc]

Hi Detlev,

Part of the idea is that things which the user-agent side can do are at prerequisite level. If we don't think they are sufficiently wide-spread / easy / available, we'd also include baseline level methods that authors need to do.

[DuffJohnson]

In your summary you say:

Different platforms (e.g. Web/HTML, PDF, Native app, etc) may provide different levels of AT support, so that dimension would need to be accounted for in the structure.

This statement appears to locate the "level of support" on the format rather than the user agent. I’d prefer the following framing:

"Different platforms (e.g. Web/HTML, PDF, Native app, etc) may be accessibility-supported to varying extents, so that dimension would need to be accounted for in the structure.”

Regarding your proposal, you say:

Ideally, we would include prerequisite items that the user-agents could do but currently don't, so long as this is clear to authors. That way if/when user-agents do fulfill them, it is a change to the state of the requirement rather than creating new content for WCAG3.

I think this is a VITAL point and a great suggestion, not merely a “nice-to-have”.

Ensuring that authors understand that an accessibility problem with given content is a function of limited accessibility support - and is NOT necessarily due to the author and / or authoring system and / or format - is critical to ensuring that all parties get the right signals.

Generally speaking, it may be useful for guidance pertaining to prerequisites to disambiguate between….

• Capable formats with inadequate accessibility support, and
• Incapable formats that are nonetheless fully accessibility-supported.

[u9000-Nine]

I love this approach.

My only concern is that the level titles no longer make sense. For example, one could assume that WebVTT-based audio description works at the prerequisite level, but then at the baseline level be responsible for a separate audio track with descriptions. In that situation, the prerequisite-level method isn't actually a prerequisite to the baseline method.