User agent or built-into-site, was #117

[alastc]

To avoid a tangent, I'd like to convert the conversation from #117 into a discussion, over here.

The context is this comment from @ashleemboyer.

[alastc]

Hi @ashleemboyer,

(This is a chair-hat off conversation, I'm speaking only as a member of AGWG, these are just my opinions.)

WCAG 2.x has minimum contrast requirements, but no maximum.

I'm not 100% sure, but I think that's due to a lack of (known) research on what a maximum contrast would be?

It is also an area that clashes (as some people want/need maximum contrast), and prevents certain designs. In those circumstances it tends to be seen as a personalization issue because there isn't a clear 'ask' from authors (i.e. site-creators, designers etc).

When I have a migraine, for example, I can’t use/read content that’s high contrast and it also makes the migraine worse. I get migraines because of multiple disabilities (i.e. I have several triggers across the sensory spectrum), so it’s not specific to one disability. Nor is it predictable.

It is however one requirement, i.e. the ability to limit contrast when you want to.

what would enable a path to access are in-site/app settings that I can use to adjust contrast, font size, font weight, etc. I say within the site/app, as opposed to device or browser settings, because notions from 2.x in the tune of “at least one mechanism” leads to products that don’t have any built-in mechanisms in practice, because the creators expect devices, browsers, and assistive technology to handle customized experiences.

This aspect of accessibility has rumbled along for many years, as it is the reason I named this discussion "User agent or built-into-site".

There are some pretty solid arguments against building contrast and text controls into sites on a per-site basis. Hypothetically, imagine sites were required to build in controls, there are two likely strategies:

1. Create your own widget, which would have different controls for every site. Different in the location and appearance of the controls, but also different in capability. E.g. some might have different colours schemes available.
2. Buy an overlay widget. Where a site just buys / includes a standard widget that may work to some degree. It probably wouldn't work very well because it is not customised to the site, and might break layouts or create unreadable text. That's the experience I've seen with overlay widgets so far.

The first option is unlikely to get traction due to cost and poor user-experience and uptake.

I did some research in the mid-2000s (before zoom and media queries) where we created a 'zoom layout' widget aimed at people with low vision. It increased the text-size, reflowed the layout to 1 or 2 columns, and increased the contrast. Custom-done for this website, and almost all the participants (12 people with low vision) thought it was really useful.

Then in the second part of the session I took them to a well known website (I think it was a newspaper site in the UK) where I'd hacked-in the same widget to appear in the same position as the custom website they had just been using for 20+ minutes. I asked them to do an unrelated task (find a particular news story). None of them spontaneously used the widget. Not one.

Another experience was with the BBC who did have an on-site method of customising the text size, style and colour-scheme. They eventually dropped it, and what I heard was that it was due to lack of uptake, and cost of maintaining multiple displays across a large digital estate.

The second option (buying some standard widget in) is no better than using the browser or a plugin, and (IMHO) is the most likely outcome of requiring sites to have display-controls.

You also have to consider: Where do they stop? How many other on-screen controls would be needed for other disabilities? You end up with a dashboard of options, like the overlay widgets have done.

I hypothesize changing built-in presentation settings requires less energy/effort than changing device/browser settings.

I take the point about having to switch between devices often, and there being an overhead with the differences.

However, I am skeptical that having on-site controls (which either vary by site, or are no better than user-agent controls) is going to be a better experience.

I do think the browsers and user-agents need to improve in this area, it sounds like you need those controls to hand more easily, especially on smaller screen devices.

To cite some research: a scoping review by Vidya Sundar identified 433 different types of workplace accommodations ... and concludes the need for “further examination of our perception and understanding of disability itself” (152).

I read the discussion (horrible PDF version), but the context was what their study did not include, and what is considered a work-place accommodation.

I agree that access needs can be transitory and arise at any moment of time, but we still have to translate those into concrete requirements for people creating digital technologies. Whether the need is transitory or not, the website author has to build something in (or not) on a permanent basis.

I think it’s important to have an explicit list of audience beyond creators and testers

We do, I'm not sure if this sheet is publicly available, but the Silver research identified about 30 profiles and cross-referenced them with the type of activity they might do related to WCAG. It is just a bit long to include in the requirement, and "widest audience" seems to capture that.

(In case it's not available, the roles identified were: Accessibility consultant/advisor, Accessibility designer, Accessibility developer, Accessibility influencer, Accessibility specialist/helper/org, AT developer, Authoring tool developer, Call center representative, Chief Accessibility Officer, Content provider/producer, Designer, Developer, Disability organization, Evaluation tool developer, Government policy, Influencer in disabilities, Instructor/trainer,
IT manager, Lawyer, Organizational policy, People with disabilities, Platform developer (hardware, os, browser), Product manager, Professional/Industry Org/Assoc, Project manager, QA specialist, Researcher, Standards developer, Teaching resource developer, Technology innovator, WCAG WG)

[ashleemboyer]

Still reading your response @alastc, just commenting to paste the entirety of my comment (#117 (comment)) for easier reference.

---

@alastc

This is a tangent to the topic, but I'm interested in where you might have experience of issues which only happen because of multiple disabilities? I.e. is there a requirement missing from WCAG which is aimed at people with "intersectional needs"?

Speaking from my own lived experience -- Color contrast and text customization are great examples. WCAG 2.x has minimum contrast requirements, but no maximum. The minimum is helpful for me because of a few factors of my poor vision, but there are multiple situations that can arise throughout my day when too much contrast causes me different types of pain.

When I have a migraine, for example, I can’t use/read content that’s high contrast and it also makes the migraine worse. I get migraines because of multiple disabilities (i.e. I have several triggers across the sensory spectrum), so it’s not specific to one disability. Nor is it predictable.

In many of these situations, what would enable a path to access are in-site/app settings that I can use to adjust contrast, font size, font weight, etc. I say within the site/app, as opposed to device or browser settings, because notions from 2.x in the tune of “at least one mechanism” leads to products that don’t have any built-in mechanisms in practice, because the creators expect devices, browsers, and assistive technology to handle customized experiences.

And the reason why that’s a nice thought in theory, but not in practice, is because it doesn’t work for people who switch between modalities as their access needs change throughout a day. Just speaking in terms of viewport size, I switch between my phone, tablet, laptop, and desktop multiple times a day, based on how my access needs change. Depending on the device, trying to adjust contrast and/or text is tends to be more taxing on mobile devices. For example, there’s no keyboard that enables using CTRL/CMD and the +/- keys to change page-level zoom.

Related, I hypothesize changing built-in presentation settings requires less energy/effort than changing device/browser settings. If that is true (and it wouldn’t have to be true for every person), then the impact of encountering whatever is inaccessible in the moment is reduced, and so is the likelihood that there will be rippling, compounding effects after.

For example, I'm very aware that some people use screen readers (or other text-to-speech) due to cognitive impairments, and obviously there are people with cognitive impairments who are blind or low-vision. But what issue would only appear because of that combination?

To reiterate/relate some of what I’ve written earlier in this comment (I don’t want to leave this question implicitly answered), it’s not about specific disabilities, but about the access needs that arise in a moment of time as a result of many combinations of factors. It’s really not possible to enumerate, nor has it shown to be very useful to attempt.

To cite some research: a scoping review by Vidya Sundar identified 433 different types of workplace accommodations in the review of 47 studies (2017, 135). Sundar consulted existing research literature to create a clearer picture of how workplace accommodations are used in practice and identify knowledge gaps in how they’re conceptualized. They found several gaps that suggest systematic exclusion of groups of people and types of support, and concludes the need for “further examination of our perception and understanding of disability itself” (152).

Functional needs is a way to say: The requirements people with a particular disability have. In standards such as EN 301-549, they call them "Functional performance statements", meaning things like "Usage without vision". They map those to WCAG in Annex B from the link above.

Thank you for this context and links! I’ll be doing some reading to better understand use of the term and its intentions.

In the context of a standard aimed at people creating or testing web-technology, yes. So it is aimed at people creating websites (including those with disabilities), but not people consuming those websites (with or without disabilities). Not to say those people couldn't read it, and it would be great if it were understandable, but as a standard the primary audience is the creators and testers (which is an umbrella term that covers about 35 roles).

I took some time to re-read this doc, and realized where my lack of clarity stems from. In the “Usability” section under “Opportunities for WCAG 3.0” there’s an “Advocacy Tool” paragraph. I traced this back to the “Problem Statements” page in the Silver wiki, where I found a few mentions of advocacy, advocates, lawyer, policy makers in particular. I read some of the research at the bottom of the page and also looked at the Requirements for WCAG 2.0 doc (linked in the “Comparison to WCAG 2.x Requirements” section above).

The “Write to a more diverse audience” requirement lists more than creators and testers as examples. I think changing “a non-technical audience” to “the widest possible audience” is a step backwards to where we are now. I don’t think “non-technical audience” is right answer either, but it’s a step forward. In short, I think it’s important to have an explicit list of audience beyond creators and testers because that list can be a great tool for making sure those kinds of audience members are included throughout the research, design, development, and testing of WCAG 3.

---

Sundar, Vidya. 2017. “Operationalizing Workplace Accommodations for Individuals with Disabilities: A Scoping Review.” Work 6 (1): 135–55. https://doi.org/10.3233/WOR-162472.

[ashleemboyer]

Also pasting my initial comment (#117 (comment)) on #117 since I'll reference it in my comments here.

---

Hello! 👋🏻 I've been reading around this repo for a couple of days (mostly the Discussions tab). I hope it's OK to chime in here! If there will be an opening for public comment, happy to hold on to feedback until then too. I'm just really excited about WCAG 3! 🥳

I've used blockquotes to reference specific words and sentences from the page. I have more thoughts than this, but trying to stick to the generated diff. Thanks for your time!

---

There are needs of people with disabilities, especially cognitive and low vision disabilities, that are better captured by a different type of measurement.

An area where I’ve found WCAG guidelines significantly lacking is around people who have dynamic, multiple, or even conflicting access needs.

I say this as a person with physical, visual, auditory, cognitive, and neurological disabilities and as an accessibility practitioner. The outcome of this, in my experience, is that most people have a narrow, rigid, and biased perspective of what disability and accessibility are.

For example: believing screen readers are only used by people with vision-related disabilities. Another example: not knowing that flashing and layout shift can harm people with vestibular disabilities.

I think it would be valuable to include mention of this here alongside the mentions of cognitive and low vision disabilities, or in the “Broad disability support” section.

Provide requirements to address functional needs, while avoiding or minimizing negative impacts on other functional needs.

What is the language “functional needs” in reference to?

Broad disability support

What’s the origin of this language? Is it new?

Multiple ways to display
…

Readability
…

Both of these section mention different/wide audience, but it’s not clear to me what that means from this page. Are disabled people included this audience, in a variety of contexts (self advocacy, disabled practitioners of accessibility, etc.)?