Re: adapting-text SC rewrite

NB This thread is in two places, on github it is here:

David wrote:
> We've established it SHOULD be a user agent issue, and that user agents SHOULD allow users to do this.

No, we've established that the user-agent has a part to play, but there are things for the author as well. It cannot be solved just on the user-agent end as I'm sure Wayne will attest to.

I'd also say it is fairly easy to test: run a bookmarklet on the page with pre-determined values.

What real users might do is rather more "messy" (I think Wayne would say flexible), but we're bringing it into a reasonable-to-test area by using that as a proxy for finding issues. Kind of like keyboard accessibility is a proxy for several user-input devices.

Using that test, you find things like:

- Icon fonts that disappear.
- graphical backgrounds (single colour or gradients rather than pictures) that make text unreadable if you reverse the colour scheme.
- menus so tightly packed they collapse or overlap with a slight adjustment of line height/spacing.

That's just from the first few pages, I'm sure we'll find more, and generate quite a few techniques (and perhaps even failures ;-) ).

There is a real user need (adapting text) that currently does not work consistently due to things authors do in HTML/CSS/JS. There is already some external stakeholder support:


From: David MacDonald <>
Sent: 23 March 2017 00:54:05
To: Laura Carlson
Cc: Andrew Kirkpatrick; Jonathan Avila; Patrick H. Lauke; GLWAI Guidelines WG org; public-low-vision-a11y-tf
Subject: Re: adapting-text SC rewrite

I've read through the entire thread, and I'm not sure that we're accomplishing much with the SC.

- We've established that some browsers provide a way to override the author style sheets while other make it more difficult, in WCAG we only need one affordable stack to be relied upon to pass conformance
- We've established that on any HTML page, when using certain browsers, we can override the CSS, including "important".
- We've established that most of this can be done in PDF, and whatever can't be done, can't be solved in PDF, without the author creating a new PDF viewer.
- We've established it SHOULD be a user agent issue, and that user agents SHOULD allow users to do this. Some do most of it (i.e., Edge new Reading feature)
- It's kind of messy to test,
- There are problems with mentioning specific fonts, and there are problems with NOT making mentioning fonts. (i.e., different results for different fonts)
- There is a lot of head scratching about what it means for authors, making it a difficult SC to understand, and adding cognitive load to the 2.1

It seems hard to fail this in HTML, and hard to test this, confusing to understand what is required. It just seems to me that this should be punted to Silver, where User Agents are involved. Unless there is an elegant way out of the mess and real momentum from stakeholders responding the FPWD.

I'm interested in what other's opinions might be on this.

David MacDonald

CanAdapt Solutions Inc.

Tel:  613.235.4902



  Adapting the web to all users

            Including those with disabilities

If you are not the intended recipient, please review our privacy policy<>

On Wed, Mar 22, 2017 at 11:23 AM, Laura Carlson <<>> wrote:
Hello everyone,

After yesterday's discussion [1], Andrew's proposed rewrite [2] and
Jon's concerns with the rewrite [3] what do you think about rewriting
the current adapting-text SC, which is:

No loss of content or functionality on a webpage is caused by overriding:

1. font family to Verdana, or
2. foreground and background to white on black, or
3. line height of all text to 1.5, letter spacing to 0.12em, and word
spacing to 0.16em.

To read:

Either a mechanism exists to adapt textual information or no loss of
content or functionality exists when:

* font family is overridden by the user.
* foreground and background colors are overridden by the user.
* line spacing (leading) is at least space-and-a-half within
paragraphs, and paragraph spacing is at least 1.5 times larger than
the line spacing.
* letter spacing (tracking) is at least 0.12 em, and word spacing is
at least 0.16 em.

With this approach the offending hard coded metrics are removed and
the understanding and technique documents will have to provide the

Patrick and David this version incorporates Andrew's suggestion that
authors need to create mechanisms (as a last resort)... and just about
gets us back to where we started.

Thoughts? Ideas for improvement? Is this getting closer to what people
can live with?

Please reply in the GitHub issue:

Thank you.

Kindest Regards,


Laura L. Carlson

Received on Thursday, 23 March 2017 09:34:15 UTC