Views on views

If WCAG 3 would adopt the word “view” instead of “web page”, the standard would be more useful in non-web contexts like native apps, documents and XR. Because many wish to understand how accessible such environments are, we should consider adopting a unit that isn’t “web page”. To me, “view” is the strongest contender.

Context: as part of the Accessibility Guidelines Working Group (AGWG) work on WCAG 3, I'm leading a subgroup on (re)defining “views” for WCAG 3. This group builds further on a discussion at TPAC 2024, which builds on discussions over many years about WCAG and WCAG2ICT. Opinions in this post do not reflect those of the subgroup, or of my clients.

I would love any feedback in wcag3/discussions/286.

The web page#heading-1

In WCAG, and most WCAG-related documents, the notion of a “web page” does quite a lot of work: it's in the name of some success criteria and it's WCAG 2's “unit of conformance”, i.e. the thing people can claim conformance about.

A web page, in WCAG 2, is unambiguously scoped to something to obtain from a single URI:

a non-embedded resource obtained from a single URI using HTTP plus any other resources that are used in the rendering or intended to be rendered together with it by a user agent

It's so unambiguous that we'd struggle to come up with examples where one person would draw the boundary between two web pages differently than the next. Well done, team WCAG!

Inevitably, though, a unit of conformance that can apply more broadly will be more ambiguous.

In other places

No less than 16 success criteria in WCAG 2.2 mention web pages: 1.4.2 Audio control, 2.1.2 No keyboard trap, 2.3.1 Three flashes or below threshold, 2.3.2 Three flashes, 2.4.1 Bypass blocks, 2.4.2 Page titled, 2.4.3 Focus order, 2.4.5 Multiple ways, 2.4.8 Location, 2.5.6 Concurrent input mechanisms, 3.1.1 Language of page, 3.2.3 Consistent navigation, 3.2.4 Consistent identification, 3.2.6 Consistent help, 3.3.4 Error prevention (legal, financial data) and 3.3.6 Error prevention (all).

It's also used in documents like WCAG-EM, the evaluation method.

Conformance

“Web page” is WCAG 2's “unit of conformance”, meaning that if you want to say something “conforms” to WCAG, that something should be a web page, and not something else, like a date picker component that you've built. You can use WCAG to reason about the accessibility of that date picker component, but a claim that it conforms to WCAG would not make sense.

Note, the phrase “unit of conformance” isn't actually mentioned or defined in WCAG itself, but WCAG2ICT explains it clearly:

(…) the unit of conformance in WCAG 2 is a single web page (…)

(From Interpretation of Web Terminology in a Non-web Context)

Conformance claims are also specifically about full web pages, not parts of them. They can be about more than a single page, though:

a conformance claim may be made to cover one page, a series of pages, or multiple related web pages.

(From: WCAG 2.2, section 5.3: conformance claims)

That's common too: in fact, accessibility conformance reports usually cover a whole website.

Views#heading-2

“Views” could be a new unit to use, meaning web pages on websites and other things in non-web contexts. View are not defined in WCAG 2 (they are in UAAG and in ATAG, interestingly, and a 1999 doc defines “page view”). The latest WCAG 3 draft also has a definition for view, we'll get to that later.

Views as a unit of conformance for WCAG have been considered before, most nobably in the WCAG2ICT groups, see for instance the discussion in reply to the concept of User Interface Context. In all those years, the group could not think of a definition that wouldn’t introduce problems of its own.

Has anything really changed since then? Well, one thing that is different now, is that we have more variety in products that need accessibility conformance evaluated than ever. There seems to be a growing desire to bring our units of conformance up to date with that reality. It would make conformance assessments more practical to their writers and readers and simplify monitoring by governments.

I feel the balance between theoretical purity and practical need has shifted.

Requirements for a new definition

When we set off thinking about views, we discussed requirements, including that we want “views” to:

• Not confuse people who have an existing understanding of the word ‘view’, which is a word used by many, including developers (like views in React Native, views in Django, views that CSS view transitions transition and views in MySQL)
• Not reduce accessibility requirements: a new definition shouldn't cause things to meet WCAG that don't today.
• ‘Work’ for a variety of different contexts, like web pages, (native) applications, VR/AR and documents (I know, a long wishlist)
• Useful for people who do conformance assessments (accessibility specialists/consultants), or use them in some way (designers, developers, monitoring agencies, judges in some areas).

Steve Faulkner's suggestion

As mentioned, there is an existing draft definition in the latest WCAG 3 draft. I agree with Steve Faulker that it is wooly.

What the exact definition needs to be is yet to be determined, but after the initial (less-wooly) definition we presented to the Working Group, Steve proposed to base the definition around “change of context”.

Steve's proposed definition:

Conformance scope that includes all content visually and programmatically available without a change of context

In addition, he suggests updating “change of context” to be:

Major change in the content of the view that, if made without user awareness, can disorient users who are not able to view the entire view simultaneously

Changes in context include changes of:

• user agent;
• viewport;
• content that changes the meaning of the view.

A change of content is not always a change of context. Changes in content, such as an expanding outline, dynamic menu, opening a non-modal dialog, or a tab control do not necessarily change the context.

Example: Opening a new window, opening a modal dialog, going to a new view (including anything that would look to a user as if they had moved to a new view) or significantly re-arranging the content of a view are examples of changes of context.

I like where that is going.

Needless to say, I don't think anyone envisions this to be a find/replace in all documents that mention “web page” today.

Subviews?#heading-3

Sometimes it makes sense to talk about specific parts of a UI or view, like a modal overlay, drawer or full screen search functionality. We looked at a number of examples within the group and found we were internally conflicted about some cases, there was a lot of gray area.

For this reason, I think we should in fact not define “subview”, contrary to what we intitially thought. I'd love to know what others think, please add your thoughts to the subview part of the discussion.

Possible issues#heading-4

There are some disadvantages to “view”, and we got some excellent feedback from the Working Group in our initial discussion. You can see all in the minutes of 18 February, but I'll highlight two here.

More subjectivity

Among the feedback we got from the Accessibility Guidelines Working Group, was Gregg Vanderheiden's feedback that I'll summarise as: “web page“ is objective and “view” is not.

I think he's technically correct that we lose some objectivity. But I don't think that's as much of a change to the status quo. Accessibility practioners define scopes for tests today already, and, if we're honest, subjectivity already exists in accessibility conformance reports. Bad actors can act bad today, that's not a reason to avoid making things more usable for all actors. Especially if a new term would help with clarity about accessibility or inaccessibility of products.

Besides, the cat is out of the bag already: companies and governments need other environments than web apps assessed, and whether they do that with an unambiguous but inapplicable definition for “web page” or with a broader definition for “view” is unlikely to make the difference.

In app development

In native app development, a world I’ll admit I’m not very familiar with, the word “view” seems to refer not to a whole screen or page, but to parts of it, as I understand similar to what on websites, you’d call components. I learned this when I presented some of these ideas in the Mobile Accessibility Task Force (MATF), where “page” was offered as an alternative to “web page” that could work as a unit of conformance for (native) apps.

This may get into “confusing people with existing definitions of view” territory, I am not sure what's the best way out, I worry “page” could introduce similar problems in terms of future proofing. A potential solution, from Jan Jaap de Groot, could be that a different word than view is used in a document like WCAG2Mobile, which then points at WCAG's “view” for the definition. Others I talked to suggested something similar, we could have different units of conformance for different contexts, that all point to one broader unit.

SC meaning

One issue that we didn't get to much, but that is essential: what about all the SCs that mention web pages today? The published note WCAG2ICT covers mappings from “non-web software and documents” to WCAG 2 success criteria and EN 301 549 (clause 10 and 11) harmonises with that. Mapping is not be in the scope for the task of defining “views” per se, but it deserves our attention to consider what requirements would look like if we used a word like view.

Feedback wanted#heading-5

In this post, I've tried to summarise some of the discussion around “view“ it happened over the last few months. It's a lot of information, with one goal: please share your thoughts.

It doesn't have to be “views”, it could be “purple zebras”, as Alastair suggested, but modernising what WCAG's unit(s) of conformance are will be more helpful to users than avoiding it.

I'd love more feedback (by email or in the GitHub discussion) on what views can be and what the potential risks are, especially from accessibility practitioners (including evaluators), folks from monitoring agencies and designers and developers who want to meet WCAG.