System settings as sufficient techniques?

[julianmka]

The requirements of some Success Criteria can be met by supporting system settings.

Examples:

• High contrast mode for 1.4.3 and 1.4.11
• Extend time of toasts (Android) for 2.2.1 Timing Adjustable
• Reduce motion (iOS), remove animations (Android) for 2.2.2 Stop, Pause, Hide

As discussed in meeting of July 31, general consensus seems to be that apps should also also meet WCAG requirements without system settings. E.g. apps should have sufficient contrast without the need to turn on "High contrast mode". However, developers should be encouraged to support system settings for enhanced accessibility.

Share your thoughts for applying to mobile apps as a comment below.

Conversation between @alastc and @JJdeGroot in #32. There is precedent in WCAG for accepting system-level settings as sufficient.

JJ: For 2.2.1 Timing Adjustable, the user is able to adjust some timing related settings at the system level on Android and iOS

Is this an acceptable "mechanism"? Note 1 in the definition mentions: "The mechanism may be explicitly provided in the content, or may be relied upon to be provided by either the platform or by user agents, including assistive technologies."
This not only includes user agents, but also the platform, in this case Android and iOS; therefore it's a sufficient technique to conform?
But... users might not be aware of such system settings, because they can be buried multiple levels deep

AC:
I’m a bit confused, do you mean for 2.2.2 Pause, Stop, Hide? 2.2.1 doesn’t mention a mechanism. If there were a system level thing that allowed users to turn-off/adjust/extend, I think that could be used.

JJ:
Sorry, the note is indeed for 2.2.2. There is a system setting on new Android versions to increase the time limit of toasts.

AC:
In which case, I think you could allow for a system level thing that allowed users to turn-off/adjust/extend.

JJ: Okay, the question is when is a setting considered widely-available? Would auditors need to write this down in the "Accessibility support baseline" section? E.g. some settings are only available on newer Android version, and some settings be buried deep in the settings screens.

AC:
In WCAG 2.x we’ve taken that on a case by case basis but, for example, a system setting is sufficient to pass Animation from interactions in C39. This sounds similar.

This topic is a constant discussion, there isn’t a clear and concrete answer for a world-wide standard. However, if the setting is free (once the base device and OS are paid for), and on more than 66% of used devices it should be a fairly safe option.

[AlainVagner]

For me this is a little bit of a chicken and egg issue. On one hand, the users may not be aware that some settings exist, on the other hand, if systems settings are never considered as a sufficient technique, they will be rarely supported and thus leading to a limited usage. At some point, we should consider if it makes sense to promote these settings, in order to avoid having different and custom settings in every app.

Not sure how we will evaluate if a setting is widely available though.
Does the setting need to be widely available on iOS and Android at the same time to be considered as sufficient?

I have listed here the settings we consider when testing different SC on mobile apps in Luxembourg:

• 1.4.1
  • Differentiate Without Colour on iOS
• 1.4.3
  • Increase Contrast on iOS
• 1.4.4
  • Larger Text on iOS
  • Font size on Android
• 2.4.7
  • Focus styles on iOS

We should also probably evaluate on a case by case basis if the setting proposed by the OS good enough is. For example, when we tested them 3 years ago, there were some issues with the high contrast mode on Android. Maybe @audreymaniez remembers more about this.

(this issue is also related to #64)

[JJdeGroot]

Insight I had during a discussion:

What if we check who has to do the work when enabling system settings.

E.g.

• When users activates the zoom function, they have to do the work to zoom text
• When a user activates the screen reader, they have to use gestures, but developers also have to implement accessibility support
• When users activate high contrast, the developers have to take the settings into account, otherwise the text contrast remains unchanged
• When users activate dark mode, the developers have to implement a dark theme, otherwise the app remains in light colors
• When users activate text scaling, developers have to implement larger text scaling, otherwise text remains normal sized.

When categorizing assistive technology/feature when can check if activating burdens the user or the app developer.

If the developers have to do the work, using the system setting is sufficient to pass. E.g. high contrast toggle to reach sufficient contrast is a pass.

If the user has to do the work, the system setting does not pass. E.g. using zoom function to enlarge text is a fail.

Edit: If the developers depend on system settings to reach WCAG conformance, they must include a page in the app that lists the implemented system settings.

This allows user to find out which settings are supported, and also allows auditors to test with appropriate settings.

We could phrase this similar to EN 301 549 chapter 12.1.1

12.1.1 Accessibility and compatibility features
Product documentation provided with the ICT whether provided separately or integrated within the ICT shall list and
explain how to use the accessibility and compatibility features of the ICT.
NOTE 1: Accessibility and compatibility features include accessibility features that are built-in and accessibility
features that provide compatibility with assistive technology.
NOTE 2: It is best practice to use WebSchemas/Accessibility 2.0 [i.38] to provide meta data on the accessibility of
the ICT.
NOTE 3: The accessibility statement and help pages are both examples of the provision of product information

[julianmka]

I was thinking about a similar rule but kept getting stuck on handling something like increased contrast settings. I like this idea of establishing a practice of listing out supported accessibility settings, @JJdeGroot.

And for more controversial settings like increased contrast, we could still include a note that meeting the SC without the user having to enable an accessibility feature is preferable. This feels like a good way forward.

[jeroendevrind]

@JJdeGroot There are also settings that improve without needing the developer to do anything. If the user uses the Accessibility > Keyboards and typing > Full Keyboard Access > High Contrast setting on iOS the hardware keyboard focus indicator's visibility improves throughout all apps. Without the dev needing to do anything, it solves a lot of low contrast issues with the hardware keyboard indicator specifically. Shouldn't this OS setting be taken into account when mentioned in the accessibility statement for example?

[PaulvanWorkum]

@jeroendevrind, that is true, but so far I understand this only works on unadjusted keyboard focus indicators. If a developer did not change the standard focus indicator the indicator already falls under the exception.

[detlevhfischer]

Does the setting need to be widely available on iOS and Android at the same time to be considered as sufficient?

To us this is a non-issue since we would audit iOS and Android apps independently.

[detlevhfischer]

@JJdeGroot wrote:

If the user has to do the work, the system setting does not pass. E.g. using zoom function to enlarge text is a fail.

For some things like zoom / magnification functions, I do not agree. As far as I am aware, many companies providing app audits today consider 1.4.4 a PASS by default because of that OS AT function (probably recommending the support of OS settings based text sizing at the same time). (Having said that, of course this practice could be challenged.)

The normative text 1.4.4 does not differentiate between body text and other types of text like icon labels, headings etc., so in many cases making all text scale to 200% would break layouts / have undesirable consequences - so content would nominally fail 1.4.4 if not everything is equally resizable.

Listing Accessibility and compatibility features is good but I don't quite see the point of listing zoom / magnification since it always works, independent of the app. So wouldn't people relying on it be aware if the function anyway?

[detlevhfischer]

@PaulvanWorkum wrote:

So far I understand this only works on unadjusted keyboard focus indicators. If a developer did not change the standard focus indicator the indicator already falls under the exception.

Are you referring here to the exception in 1.4.11: "except for inactive components or where the appearance of the component is determined by the user agent and not modified by the author"?

I have so far understood "state" to be referring to attributes proper of the component, like checked or selected, but it is true that the definition of "state" includes focus. So all the light grey and light blue keyboard focus indications in apps would automatically pass via this exception in 1.4.11?

[PaulvanWorkum]

@detlevhfischer , I also didn't know it was possible to adjust other peoples comments. Not a problem.

Definition of state according to WCAG:

state
dynamic property expressing characteristics of a user interface component that may change in response to user action or automated processes

States do not affect the nature of the component, but represent data associated with the component or user interaction possibilities. Examples include focus, hover, select, press, check, visited/unvisited, and expand/collapse.

The developer cannot adjust the appearance of the focus-state of the keyboard at the moment. Although the developer can adjust the appearance of the component in other ways.

At Abra we indeed do not fail our clients at this at the moment, but we give it as a suggestion for improvement. We do not fail on it because the author did not adjust the appearance of the focus-state. It is determined by the "user agent".

[detlevhfischer]

@PaulvanWorkum

The developer cannot adjust the appearance of the focus-state of the keyboard at the moment

Hmm... I am not sure I understand. On appt.org you state for iOS:

On iOS, you can adjust colors when an element receives focus.

And there is the same sentence in the Android section. But I guess it is the difference between changing the color of the elements focused (e.g. changing background color of a button when focused) vs . being able to change the color of the system-provided focus mechanism (light grey or blue background, or focus ring in accent color).

[PaulvanWorkum]

@JJdeGroot wrote:

If the user has to do the work, the system setting does not pass. E.g. using zoom function to enlarge text is a fail.

For some things like zoom / magnification functions, I do not agree. As far as I am aware, many companies providing app audits today consider 1.4.4 a PASS by default because of that OS AT function (probably recommending the support of OS settings based text sizing at the same time). (Having said that, of course this practice could be challenged.)

The normative text 1.4.4 does not differentiate between body text and other types of text like icon labels, headings etc., so in many cases making all text scale to 200% would break layouts / have undesirable consequences - so content would nominally fail 1.4.4 if not everything is equally resizable.

Listing Accessibility and compatibility features is good but I don't quite see the point of listing zoom / magnification since it always works, independent of the app. So wouldn't people relying on it be aware if the function anyway?

WCAG 1.4.4 understanding doucment states:

The intent of this Success Criterion is to ensure that visually rendered text, including controls and labels using text, can be made larger so that it can be read more easily by people with milder visual impairments, without requiring the use of assistive technology (such as a screen magnifier).

The working group feels that 200% is a reasonable accommodation that can support a wide range of designs and layouts, and complements older screen magnifiers that provide a minimum magnification of 200%. Above 200%, zoom (which resizes text, images, and layout regions and creates a larger canvas that may require both horizontal and vertical scrolling) may be more effective than text resizing. Assistive technology dedicated to zoom support would usually be used in such a situation, and may provide better accessibility than attempts by the author to support the user directly.

So zoom is not intended to be used to conform to 1.4.4.

WCAG 1.4.4 states:

text can be resized without assistive technology up to 200 percent

I think Zoom is an assistive technology. Also in the definition of @JJdeGroot it remains Assistive technology as intended by 1.4.4.

Using zoom to pass 1.4.4 by default is to my opinion incorrect. From a guideline perspective, but also from a user perspective, as up to 25% of users is using this setting in the Netherlands.

In my opinion the need to use zoom to scale text to 200% is not sufficient to pass 1.4.4.

But I am very curious how this is done by others.

[detlevhfischer]

@PaulvanWorkum The 1.4.4 normative text is agnostic regarding ways to achieve 200%. Zooming is one of them: Sufficient techniques include zoom, by far the most common way to meet 1.4.4 for web content. The statement that above 200%, zoom may be more effective does not imply that up to 200%, zoom cannot be used to conform.

As to the "is native Zoom AT?" question: Often (e.g. in the EN 301 549) the OS for software is regarded as equivalent to the UA for web content. So when Zoom as a built-in UA feature allows you to meet 1.4.4 in the web context, the implication is not far-fetched that zoom as a built-in OS function operates basically in an equivalent way and can meet 1.4.4 here.

The alternative (requiring all text to be scalable to 200% via text size settings) will in practice mean that hardly any app will ever conform (because due to the layout-busting consequences of scaling up text, it is hardly ever applied across ALL text content).

See also views in this lengthy discussion: Looking for guidance regarding SC 1.4.4, Resize Text, on mobile native apps

The result that went into WCAG2ICT22 is that "...without needing to use assistive technologies...means that the application provides some means for enlarging the text 200% (zoom or otherwise) without loss of content or functionality, or that the application works with the platform accessibility features to meet this success criterion (my stress). OS Zoom / Magnification is such a platform accessibility feature.

[JJdeGroot]

@detlevhfischer

The developer cannot adjust the appearance of the focus-state of the keyboard at the moment

Hmm... I am not sure I understand. On appt.org you state for iOS:

On iOS, you can adjust colors when an element receives focus.

And there is the same sentence in the Android section. But I guess it is the difference between changing the color of the elements focused (e.g. changing background color of a button when focused) vs . being able to change the color of the system-provided focus mechanism (light grey or blue background, or focus ring in accent color).

To confirm: yes the different is the appearance of focused elements vs the appearance of the keyboard focus indicator.

On web, you can use :focus to change the focus appearance, including the keyboard focus indicator.

On Android/iOS you can use accessibility events to keep track of focus and change the focus appearance, but only of the element itself. Only users can change the appearance of the keyboard focus indicator (e.g. high contrast version)

And as Paul mentioned, because of the user-agent exception in 1.4.11 we do not fail the low contrast of the default keyboard focus indicator.

@detlevhfischer

The alternative (requiring all text to be scalable to 200% via text size settings) will in practice mean that hardly any app will ever conform (because due to the layout-busting consequences of scaling up text, it is hardly ever applied across ALL text content).

My experience is that apps can reasonably support 200% text scaling for main content. Text scaling is problematic in the navigation bar and tab bar. iOS has the Large Content Viewer to show the text enlarged in a pop-up (similar to zoom). Android doesn't have this feature at this moment. In those places, it's acceptable to need to use zoom.

In my opinion zoom should not be sufficient to pass 1.4.4 if the platform does have support for text scaling.

W3C, Low Vision Task Force

User Need - Text Size:
Users can change the text size (font size) of all text, without zooming the entire interface.

Google, Android UI Design Guide

Follow these guidelines to design for vision accessibility.
To allow users to adjust the font size, specify font size in scalable pixels (sp)

Apple, Human Interface Guidelines

Support Dynamic Type. When you support Dynamic Type — a system feature that lets people choose the size of visible text on their device — your app or game can respond appropriately when people adjust text to a size that works for them.

Allowing zoom to meet 1.4.4 does not align with industry best-practices and user needs.

[detlevhfischer]

In my opinion zoom should not be sufficient to pass 1.4.4 if the platform does have support for text scaling.

@JJdeGroot Well, in terms of the normative language, and given my argument above which is confirmed by the WCAG2ICT take, OS zoom is sufficient to meet 1.4.4, even if supporting text scaling is certainly a recommended best practice.

Allowing zoom to meet 1.4.4 does not align with industry best-practices and user needs.

That may be true, but it does not change the position that OS zoom alone would meet the normative text of 1.4.4.

[JJdeGroot]

@detlevhfischer Yes, I do agree that zoom is sufficient when you follow the language in WCAG2ICT. However, given that WCAG2ICT itself is not-normative, just like guidance of the MATF, I think that in a mobile-context, we should deviate from language in WCAG2ICT when needed. In my opinion, this would be one of those cases.

Given the enormous amounts of accessibility features and assistive technologies that ship with Android and iOS, an app would automatically pass many Success Criteria; while burdening the user.

We need to strike a balance between what's reasonable to expect from developers and what's reasonable to expect from users.

That will be hard to define without cherry picking certain features such as Zoom.

[JJdeGroot]

FYI: I've closed #64 because it's a duplicate of the system settings topic.

Merged the content of both issue's description into one.

Comment from @AlainVagner that's missing in this thread:

In our evaluation method in Luxembourg we only check contrasts with the enhanced contrast mode activated.
By default on iOS at least, it seems that some OS level UI components are not compliant until the "increase contrast" mode is activated.

[detlevhfischer]

@JJdeGroot wrote:

However, given that WCAG2ICT itself is not-normative, just like guidance of the MATF, I think that in a mobile-context, we should deviate from language in WCAG2ICT when needed. In my opinion, this would be one of those cases.

Sure. It is just important to be clear that non-normative docs cannot extend normative requirements as worded. Currently, our normative point of departure for app audits is EN 301 549 V.3.2.1 clause 11 which has the same unambiguous text "...or that the application works with the platform features that meet this requirement." So there is no way we could normatively fail an app relying on OS zoom if our normative reference is the current EN. Of course an audit procedure may deviate from the EN and ask for more -- that can be useful but it is then not a EN 301 549 conformance audit.

BTW the next EN version draft V4.1.1b (so far) does not change that note in 11.1.4.4.1 Resize text (open functionality). This may change of course, and it may be the time to raise an issue on the ETSI Github to request such a change.

[JJdeGroot]

@detlevhfischer - Yes I understand the boundaries of our guidance. I did not realize that both updated WCAG2ICT and the draft of EN 301 549 contains this new clause to allow platform features for 1.4.4.

Android and iOS have two "Zoom" features:

1. Screen zoom, which enlarges all content on the screen and this does result in reflow. Developers have to account for small screens, otherwise there will be text truncation and overlapping elements.
2. Screen magnify, which enlarges a section of the screen without reflow. Users have to scroll horizontally and vertically at the same time to read content.

In my opinion, it is not desirable that Magnification is sufficient, you will encounter the problems described in 1.4.10 Reflow, e.g. scrolling horizontally and vertically at the same time. This burdens the user.

I have fewer problems with screen zooming, but I'm not sure if it achieves 200% text scaling. This burdens the developers, but mainly to support smaller screens, not for supporting larger text; because the operating system does the work instead of the app.

What's your opinion on these two accessibility features?

To clarify the available options I've attached screenshots below.

1. Screen zoom category

Android "Screen zoom"

iOS "Display Zoom"

2. Screen magnify category

Android "Magnification"

iOS "Zoom"

[JJdeGroot]

In Chapter 11.7 of EN 301 549 v3.2.1 there are additional requirements, that also relate to Resize Text, among others.

Where software is not designed to be isolated from its platform, and provides a user interface, that user interface shall follow the values of the user preferences for platform settings for: units of measurement, colour, contrast, font type, font size, and focus cursor except where they are overridden by the user.

Meaning that:

• Following the normative text of WCAG2ICT, system zoom would be a way to pass 1.4.4, even if text does not scale.
• Following the normative text of EN 301 549, you would not pass because you would not honor the user preferences for font size.

cc @detlevhfischer - seems like a change for EN 301 549 V4.1.1b is not needed?