Interactive Content? Escaping the linear Page/Form/linear media paradigm.

[brennanyoung]

I would greatly appreciate some clear recognition in WCAG 3 that not all in-browser content is oriented towards linear page/document/form abstractions. We produce medical simulation software (for training nurses and lifesavers) which runs in the browser, and I must say it has been an uphill struggle to find clear guidance which were not all about pages and forms.

In particular, the browsable/operable distinction (which is central to many AT implementations) is poorly represented in WCAG for those who need to build anything with an interaction model based on something more rich than just form-filling and submission. The time-based media guidelines in earlier versions of WCAG seemed only vaguely applicable to content such as games and simulations. Time-based media is neither Prerecorded nor Live when scripted animations have their own logic, or include random elements, often with a huge variety of unpredictable output. Where do these kinds of multimedia fit in? How do we approach the construction of audio descriptions for something which is different for every user, every single time?

Or, say, if you have a cutaway view of some complex machine or organ, which allows you to 'open' layers and reveal parts within, is it more appropriate to say that the user 'browses' or 'operates' this content? You're not 'operating' the heart when you inspect a diagram of the valves and atria, surely?

Or, say, you have a lifesaving algorithm, explaining which steps should be taken depending on the symptoms you observe. How can you talk about a 'meaningful sequence', when there are multiple possible sequences through the algorithm, and the only truly meaningful sequence is the one which saves the life of the patient, yet WCAG says "only one meaningful sequence is sufficient" in this case. This particular piece of guidance is useless, but we can earn compliance by compromising the quality of our content to a potentially lethal degree.

I do understand the historical emphasis in guiding people in accessible page construction, and media players since so much of the web is about that, but I hope that other kinds of content, especially more fluid application-like interactions will get explicit attention in the new WCAG.

I've been advised that there are ongoing efforts elsewhere to produce 'accessible game design' guidelines, which would be very useful for training simulations too, but where is the w3c in that effort? And what use are those separate efforts, if our games and simulations are nonetheless legally obliged to be WCAG compliant?

[jspellman]

Thank you for your comment. Project members are working on your comment. You may see discussion in the comment thread and we may ask for additional information as we work on it. We will mark the official response when we are finished and close the issue.

[rachaelbradley]

This has been captured in our core questions list.

[bbrown0]

Isn't this covered in technique G69 of Time Based Media? @alastc

[brennanyoung]

@bbrown0 no G69 talks about synchronisation with a linear timeline. Every time you run the video, the a11y experience will be identical. Yes, branching is briefly mentioned, but overall it describes experiences which are "on rails".

I am calling for some way to accommodate modes of browsing and interaction which are non-linear - in short, any case where a meaningful sequence or synchronised media chunk is constructed on the fly (e.g. by front-end scripting), for example

• a text alternative for a sound located in 3d space, whose audio presentation relies on live stereo panning
• alternatives for simultaneous onscreen actions where that very simultaneity is essential to the content
• priority of status messages triggered while the UI is being operated, but not because of user operation
• qualitative difference of status messages, compared to UI feedback
• content which is only made fully meaningful by the AT "virtual cursor" interrupting, looping back or jumping in the DOM order (e.g. flowcharts, maps, charts, diagrams)
• menus which contain dialog-like parts, such as volume sliders or radio button groups
• scrollbars for rich text content which appears inside an operable element
• robust association between a control which opens/controls something, and the thing which it opens/controls
• controls with "secondary actions" (such as close boxes that remove the control), or data badges (e.g. notification counts)

It's not so much that WCAG fails entirely here, rather that documents, forms and time-based media are privileged over these kinds of content, leading to the false impression that certain kinds of design are necessarily bad or unsuitable because no guidance is available.

In WCAG 2.x the most relevant criteria are 1.3.1 info and Relationships 4.1.3 Status Messages

Understanding WCAG includes this terse little section on SC 4.1.3

There may be cases where the addition of visible text does not by itself convey sufficient information to the user of assistive technology. For example, the proximity of new content to other pieces of information on the screen may provide a visual context that is lacking in the text alone.

In such cases, authors may wish to designate additional content for inclusion in the status message, including non-displayed text which can be provided to the assistive technologies, for added context.

Hmm, having struggled with accessible RIA development (real time medical simulation) for some years, I'd really like some better guidance about this additional status content may be included without generating too much chatter, for example, how best to emphasize the distinction between UI control label/kind/state announcement and the announcement of status changes, or alternatively, guidance as to why this distinction does not matter.

[alastc]

From the sub-group: The scope of WCAG3 is pretty broad, covering "digital content" and "complex applications" as well as emerging technologies like XR.

Therefore I'm going to remove this from the "Requirements" work as it is covered there. However, there is still a 'core' question for the development of WCAG 3, so I won't close the issue.