Flexibility in Meeting Accessibility Requirements Across Software Modes (Clause 11)

REFERENCE: Clause 11, Software

In software, it might not be possible—or even desirable—to meet all clauses in all modes of operation. Users with different types of disabilities might benefit from one mode, while others may require another mode. However, this clause does not currently allow for such flexibility.

This change ensures that accessibility requirements accommodate different user needs without enforcing a one-size-fits-all approach in all software modes of operation.

PROPOSED CHANGE

Modify occurrences of “shall satisfy” in this clause to “shall provide a mode of operation that satisfies”, particularly for clauses that impact visual design, such as:

• 11.1.4.3
• 11.1.4.11
• 11.2.5.8

An extremely important observation that I believe may resolve a number of other issues.

A concern with all such "shall be a mode of operation" conditions is uncertainty about whether that mode of operation will be activated when appropriate. Failure to activate that mode of operation when applicable would mean that the essential accessibility needs are not met.

This thinking is well aligned with the WCAG concept of "conforming alternate version" and the reasons why that should be allowed.

Maybe the "shall provide a mode of operation" is a path suitable for clause 11?

If so, I think the same preconditions should apply that are present in the WCAG definition of "conforming alternate version". Because a mode of operation that is accessible is not good enough unless that mode is easy to find and activate for those who need it, and offers the same functionality in the same language, and is as up to date as the other non-conforming mode of operation.

I think that this probably is the path that should be applied to a number of the clause 11 requirements, but you are absolutely right in your last paragraph. I have a concern that users who need the relavant mode of operation might not be either beaware that it exists or they cannot find a clear way of reaching it/activating it. Perhaps the WCAG definition of "conforming alternate version" may hold the clue.

Doesn't 5.2 Activation of Accessibility Features ensure activation of the features for those who need it?

Not really. It does ensure that those who need an accessibility feature that addresses a specific accessibility need will always be able to activate that feature, but it doesn't address the issue that users need to be aware that the accessibility feature is available and that they also know how to access the operation that activates/deactivates that feature.

My comment above expresses this concern.

That issue, in turn, would be for 12.1 to address.

Again, I don't think that this can adequately address the typical user who might benefit from accessibility feature, but be unaware that such a feature exists. If a user is totally unaware of a potential accessibility feature that they might benefit from, they would not be looking in a listing of accessibility features (that 12.1 or another HEN might mandate shall exist) to discover the existence of such a feature to discover how to activate it.

Hmm. The problem is that we now have so many different accessibility features, it is extremely difficult to make them all prominently visible without overloading the users with useless information about things they have no interest in. Awareness is a two-edged sword. In Microsoft products we try to explore what users might find useful through the various OOBEs (out-of-box-experience, think initial setup) through to hopefully clear menus with options, so it isn't a one-and-done process, but not everything can be highlighted.