Re-examine appropriateness of 11.7 for websites and mobile applications

changed the description

Matthias Schneider provided the following response to Monika Miazdrová:

Dear Mrs. Miazdrová,

let me try to explain the reason for the different section that you are addressing in your email.

Section 11.7 of EN 301549 (version 2.1.2 or later) deals with user preferences in software:

“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.”

In principle this is applicable to all software, independent on where and how it is implemented (in “normal” softeare or mobile apps). It will even apply to web browsers, i.e. software being installed in computers or stationary devices. The exact definition of devices and software for which chapter 11 applies can be found in

Sections 9.1.4.8 and 11.1.4.8 are VOID as they refer to Success Criterion 1.4.8 in WCAG 2.x. This criterion is a “AAA” criterion in WCAG, and the authors of EN 301 549 have decided not to include AAA criteria in the set of testable requirements in the EN as there might be AAA criteria which cannot be guaranteed to be fulfilled in all possible situations.

For that reason 9.1.4.8 and other x.1.4.8. sections are void and there are no corresponding tests defined in Annex C of the EN. There is, however, a test defined in C.11.7 for requirement 11.7 which can applied to all software that fulfills the definition in 11.0: “platform software; software that provides a user interface including content that is in the software; authoring tools; software that operates as assistive technology; mobile applications”.

Therefore: 11.7 is applicable to the above listed software which includes mobile apps, but not web pages. The test in C.11.7 can be used to show compliance with EN 301549 for any software. (Test for compliance/non-compliance). Also, 11.7 is a mandatory requirement for the Web Accessibility Directive (Directive 2016/2102). x.1.4.8 are not “mandatory” as the related criteria in WCAG 2.x are only integrated in the EN as recommendations (see section 9.5 for further information).

I hope this answers your question(s). If not, please don’t hesitate to send another email with your additional questions!

Best regards, Matthias Schneider

I think that the following two notes to 11.7 are relevant:

NOTE 1: Software that is isolated from its underlying platform has no access to user settings in the platform and thus cannot adhere to them. NOTE 2: For web content, the underlying platform is the user agent.

I think that, today, web content is isolated from the user agent (browser) with regards to being able to reset things like the size of the fonts. So, today, there is nothing to test for compliance to 11.7 (and it is probably not strictly necessary). However, W3C is looking at personalization and it is possible that, in the future, it may be possible to change elements of a website to suit individual user preferences.

Thanks for the response!

In many cases it is true that web content is isolated from the platform (browser) settings. The mere existence of a CSS rule specifying colour, font name and focus cursor usually has that effect.

But for font size, the situation is different!

If the CSS rule specifies font sizes using relative units of measurement only (such as rem, em, %, ... ) - then the web content is not isolated from the browser settings. Actual size will depend on both CSS rules and user preferences. Size being a scalar, it can be computed as the product of a user specified base font size and a CSS rule to distinguish between elements of the page.

In my opinion, the very fact that web browsers provide user settings for font size should be a reason for web designers to be respectful of any such expressed user preferences. Therefore, I want to interpret 11.7 as a requirement for digital services to be very restrictive with using absolute sizes (such as px or cm) for fonts. Absolute sizes are only necessary in some special cases, for example when font size must be precisely coordinated with pixel based (bitmap) graphics, or sometimes when the target media is print. This opinion is aligned with W3C documents about absolute sizes, eg. https://drafts.csswg.org/css2/#absolute-length but it is far from aligned with the current situation on the web.

Best regards Pär

Thanks for the above. CSS is a subject about which I have very limited personal knowledge (although I've probably learned more about it in the last 10 minutes skimming the CSS2.2 editors draft that you linked to above), so this explanation is very helpful.

11.7 is certainly difficult to interpret given the issue you've highlighted above and in the context of the contrast between actual practice and W3C recommended best practice. It seems to me that it is probably still correct to have 11.7 included, but is it possible that an additional note could be added to it to give more guidance on how it should be interpreted. Failing that, can you see a way in which 11.7 could be redrafted to make it easier to apply to web content whilst still retaining its much more comprehensive aim of ensuring that user preferences are respected in all forms ICT.

I think 11.7 is a very good reminder of the importance of respecting user preferences. In an ideal world, every developer/designer would adhere to it. However, we are far from that situation. Most web developers do not know that by using absolute measures for font size they override the browser-setting for font. Another complicating factor is that browsers behave differently in this regard: With Chrome or Edge the user is stuck with whatever pixel size the web developer has chosen, but with Firefox the user can still scale up text. Of course, users can install add-ons/AT that can override font size for them. This is probably the way most users with substantial resizing needs cope today.

I will try to come up with formulations, but no time for that today.

made the issue visible to everyone

While further researching this issue, I have found documentation from the US Access Board at https://www.access-board.gov/ict/#503-applications-1 regarding possible application of the Section 508 criterion "503.2 User preferences" (https://www.federalregister.gov/d/2017-00395/p-627) to web content.

The US criterion "503.2 User preferences" corresponds directly to EN "11.7 User preferences", but explicitly excludes "web applications". The rationale for this is primarily that it is technically infeasible in many cases. Also, they argue that this entire section is about software - not web.

To some extent, it IS feasible for web applications to adhere to user preferences defined in the underlying platform. As already mentioned in this thread, font sizes can be specified in a way that will respect user preferences. More recently, CSS features such as forced-colors and prefers-color-scheme have appeared, that make it feasible to respect user preferences for colors at least in some web browsers. However, these new options are not W3C Recommendations and forced-colors, for example is supported only by approximately 25% of browsers according to Caniuse.com.

Therefore, how about adding a note to 11.7 saying something like this?:

Web content shall be considered as designed to be isolated from the underlying platform only to the extent that relevant standardized markup languages do not explicitly allow inheritance of preferences from the platform.

The intention of such a formulation is that web page designers

should use relative units of measurement (rem, em, %, large, small...) since this is explicitly offered in mature versions of CSS as a way to let font size correspond to font sizes specified in underlying platform.
should make use of forced-colors, prefers-color-scheme et cetera once those specifications have reached standard status, if they ever do, but until then there will be no requirement - just a reminder of the possibility.

If this is not a viable solution, perhaps instead 11.7 should be removed from table A.1 (until technical options have matured more) in order to reduce confusion for web designers and to better align with Section 508?

A further issue on this, some web designers will insist that the font/size/colours etc., are a fundamental part of their artistic/design aesthetic and should not be changed without permission. In some countries there are legal exceptions to such creative rights when changes are made solely for purposes of accessibility, but not everywhere. That's not a problem we should be trying to solve, but we should be aware of it, perhaps with a "where legally permitted" escape clause?

It definitely looks like a good case for adding a "where legally permitted" escape clause.

Interesting perspective, but I am not sure to what extent the specification itself should state that exceptions can be made due to other laws. Accessibility is a legal requirement, too (and EN301549 can be used as guidance for interpreting what this requirement means in practice).

Whenever accessibility requirements may conflict with other legal requirements, I think it is up to the legal system to determine what requirement should take precedence. I am not a lawyer, but I don't think the EN301549 should contain a statement that any conflicting requirement in any other law should trump clause 11.7.

But maybe we can add a note acknowledging that 11.7 might in extreme cases be considered to be in conflict with eg. copyright or freedom of expression regulation (and possibly add that in such cases the conflict should be resolved by the legal system).

I could go along with that approach. The main point is to ensure any implementers are aware that there might be legal issues. This has long been a challenge going back to the very early days of "talking books" on tape where publishers objected to these being made without their prior permission. The UK and some other countries introduced a legal right to make copies specifically for use by disabled persons, but that isn't always available and in some cases is drawn very narrowly in a way that isn't helpful with modern technology. The issue surfaced again in the 2000s with the introduction of digital rights management (DRM) technology which made it difficult or impossible for accessibility providers to do things like adding missing subtitles to protected videos, hence one of the motivations for the EFF and some others to ask that DRM be banned (which of course it wasn't, but the issue was largely made moot by the arrival of streaming media). Anyway, I am happy with Pär's suggestion.

I was typing a response to Pär myself, but this is useful. I think that the thing we need to avoid is that people following EN 301 549 requirements are unaware of any legal consequences that might potentially arise. We do already have the wording "Where permitted by security requirements" as the introduction to some of the clause 11.5 requirements, and a Note 1 on 11.5.2.16 that gives some examples of where such strict security requirements might exist. There are certainly some cases where certain potential accessibility requirements that benefit some users might actually compromise the security/privacy of all users. An example would be having public-access ICT that speaks out all information the user enters. If this was allowed to apply to entry fields for passwords, or other security codes, where any passing person could hear this very private information, everyone's personal data would be compromised.

I agree @pluke: Security is a relevant analogy. In similarity with other laws, security is also a domain that can potentially introduce conflicts with accessibility requirements. Indeed, for some accessibility requirements there is substantial risk that such conflicts can occur, and EN301549 could prevent many problems by reminding readers of such risks. So I am in favour of informative notes. In some cases the nature of the risks are so obvious that we can even make explicit requirements (such as not to speak out loud personal information unless requested by the user). But in general I think it is wise for EN301549 to avoid normative statements regarding the intersecting domains, because those domains can sometimes be very large and complex. In such cases I believe it is better to let readers use their own judgement in their specific context than to try to predict and regulate every possible situation in EN301549.

Sidebar: We once had a situation where a draft law (EU?) stated that televisions HAD to require a four digit PIN code before allowing access to some features (early apps maybe? this was over a decade ago). Anyway, someone had obviously assumed everyone was using a handheld remote control, and not realised that this was a STUPID idea for anyone that needed to use voice or a visual keypad on screen, such as many ATs needed to use. This was also at a time when voice-control was coming in for non-accessibility things as well. Basically the draft required people to give away this supposedly secure PIN code if there was anyone else in the room, and didn't allow for an alternative mechanisms. Wiser heads got that one redrafted, thank heavens.

I would like to lift this issue back into focus @pluke, because I often get questions about it.

In my opinion, there are several different issues with 11.7, including the following:

Unclear applicability to web content and web apps

11.7 is referenced in table A.1 (web) and note 2 indicates that it is relevant to web content. I do appreciate this, because users really benefit from being able to set preferences in platform software.

But many people are wondering how to interpret 11.7 on the web, and the inclusion in table A.1 does not seem to align very well with the US equivalent: Clause 503.2 in Section 508 explicitly states that "Applications that are designed to be isolated from their underlying platform software, including Web applications, shall not be required to conform...".

On the other hand, web applications are not necessarily isolated from their underlying platform. Font size, for example, is usually possible to configure in the user agent, and sometimes on operating system level. This is also true for color and contrast preferences.

Inconsistent terminology

Speaking about "underlying platform": Notes 1 and 2 use that term, while the clause uses the term "platform". Do the terms refer to the same thing?

Note 2 explicitly states that the user agent is the "underlying platform", but interpretation can still be quite confusing, since in a web context, there are usually at least two layers of platforms on the client side: The user agent and the underlying operating system. If the user agent is the underlying platform, what then is the operating system?

What, exactly, is required?

What, exactly, does it mean to "follow the values of the user preferences" for color? If, for example, the user has selected "Dark mode" at operating system level (this can be detected by the website via CSS) does the requirement mean that the website must provide a set of CSS colour settings that are dark? How dark? Or does "color" not refer to colour-schemes but rather to font color settings in, for example, a user-agent css?
And what, exactly, does 11.7 require from a website (or an app) if the user has selected High Contrast Mode at operating system level? A long discussion thread over at W3C has been wrestling with this issue over several years. In 2021, there was a decision made that WCAG could not (at that time) address high-contrast mode.

A way forward?

Perhaps we could split 11.7 into 11.7 (for software) and 9.7 (for web content)? (For documents, I guess platform settings should not apply, so probably no need for a 10.7.)

That way, 11.7 could be made simpler, with less confusing notes about how to apply (or not to apply) the clause in a web context, and better alignment with Section 508 clause 503.2. At the same time, 9.7 could mention more clearly how settings in the user agent and/or operating system should affect web content.

The handling of this issue will probably benefit from adding it as a topic to discuss at an STF614 meeting. I will add it to the agenda for the 23rd January meeting.

I just wanted to mention, that in Luxembourg we have interpreted the 11.7 criterion as not applicable to web content in our current national accessibility framework. In Germany, the BITV framework provides tests for 11.7 for websites.

I agree with Pär Lannerö's general take that 11.7 is useful to apply to web content since browsers do allow the change of text size and possibly (depending on the browser) other settings such as color schemes. The normative text says "...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." This enumeration contains settings that (in current browsers) cannot be set. Also, it may also not include some things that can be set in some platforms.

We have been struggling with applying 11.7 mainly for two reasons:

How to treat partial adaptability across settings enumerated? We commonly have the situation only a subset if settings enumerated can be modified. If text scales and the rest cannot be customised, does that constitute a PASS? If text scales ony when "mimimum font size" is cranked up (this works even when sites are given in px) would this be a minimum pass?
How to treat a partial adaptation of content with respect to one setting? The most commonly adaptable setting, font size, may be respected in only part of the content under test (say, in body text) but not in others (say, label text in size-restricted tool bars). Lacking any definition of the type of content that must follow user settings, each PASS/FAIL decision has a rather arbitrary feel to it.
In many cases where content follows user settings, content will become unusable. Does 11.7 warrant any judgment as to whether content remains usable after customisation via user settings? Just two frequent examples:

Custom checkboxes or radio controls are implemented in a way that the state is no longer visible when users select a custom color scheme in a browser like Firefox.
A navigation menu icon (a "hamburger" icon) item has been implemented without a dedicated background color, or in a way where its foreground color does not follow the text color (e.g. by using CSS currentColor in an inline SVG). On a white-text-on-dark-background scheme, the icon becomes invisible.

For text resizing caused by changes browser settings, it often happens that content becomes unusable at larger magnification. We therefore commonly discount any changes to content caused by user settings and merely verify that the change of setting itself is honored by content (text gets bigger, color schemes are applied).

mentioned in issue #236 (closed)

mentioned in issue #255

Re-examine appropriateness of 11.7 for websites and mobile applications

Designs

Child items ...

Activity

Re-examine appropriateness of 11.7 for websites and mobile applications

Relates to

Activity