W3C

Site Navigation

Nearby

Results of Questionnaire Add real world accessibility as placeholder

The results of this questionnaire are available to anybody.

This questionnaire was open from 2022-06-01 to 2022-06-07.

13 answers have been received.

Jump to results for question:

Background
Adding Placeholder Text

1. Background

We would like to begin work on approaches to real-world accessibility. This topic focuses on developing an approach that allows for minor accessibility issues to exist within conformant web content, as long as those issues do not impact the ability of an individual to use content.

Please list all questions, concerns, and thoughts you would like the subgroup to consider when crafting exploratory content. This list will help them get started and also be incorporated into a draft editor's note.

Details

Responder
John Foliot
Jeanne F Spellman
Shawn Lauriat
Mary Jo Mueller	A lot of the scenarios are being worked in the conformance sub-group which can help with the analysis of ideas and how they might influence the approaches. - user submitted content (e.g. blogs, social media, video repositories) - Archives of older material or scans of paper material - Large-scale web-based software - All software has some level of bugs and intentionally ship that way. Commercial software typically ships code with an average of 15 bugs for every 1,000 lines of code. Realize that for 1 million lines of code (not uncommon for commercial enterprise software), that's 15,000 bugs! Bugs are triaged and prioritized and Sev. 1 bugs are fixed, but others may be delayed or deemed not crucial to fix. There is a level of risk accepted when shipping with known bugs. - Potentially build in tolerances into conformance. Even nuclear power plants have certain tolerances in many measurements. A lot of focus goes into the processes to meet requirements within those tolerances and triaging out-of-tolerance issues for its importance - safety is highest priority (which reminds me of some WCAG criteria like flashing, or maybe additional requirements to avoid causing motion sickness). In the real world there is a level of analysis of cost-benefit when considering which issues to fix and when. I think the notion of critical errors for particular user workflows or scenarios could be worked in. - Potentially credit for use of good processes in design, development and test. There's lots of quality processes that have existed for many years (six sigma, ISO 90001) that I learned many, many years ago.
Michael Gower	I understand the problem: there's no such thing as a perfect page. Contrasting with that is that it's hard for someone not immersed in accessibility to understand what 'minor' accessibility issues might result from any particular bug. I think that focusing on user processes as part of the evaluation for content should help. If we come up with a list of common user processes, AND teams apply those to their assessment of their pages, the emphasis should be that bugs in components that are part of that process (or impede navigation to that process) are more critical. Sometimes I worry a lot about someone failing an otherwise beautifully functioning user experience because of one missing alt for an unimportant image. On the other hand, I don't know what the REAL impact has been. I don't know what kind of data exists, both for how teams assess their own content for 'pass' and to what degree a procurer or user of a page encounters something and raises a flag for it. My anecdotal experience is that dev teams address the stuff they believe to be more important (and treat deemed-less-important stuff just like other low-level bugs), and that assessors/users raise flags when something actually prevents their work. So maybe the 'vague' system in place works okay, and all we need is some language in the Conformance section explaining this in sufficient language both to 1) prevent sites from saying Pass to problematic content and 2) prevent assessors from saying Fail to something that is on the whole very usable and accessible.
Makoto Ueki
Todd Libby
David MacDonald	In general, I'm not crazy about the term "Real-World Accessibility". It seems to imply that WCAG was not intended for the real world and that it is aloof from the realities on the ground; that we need to make an explicit course correction in a dedicated section that basically says... "we've provided guidelines which are not realistic, and so here's a discussion of reality." I'm not averse to a discussion in the standard of complex situations, and ways to reward organizations that are trying hard but have insurmountable complexities to meeting our current model, I'm averse to the pejorative connotation "Real World Accessibility" creates for WCAG. I would rather the emphasis be on the extraordinary situation that the web page or technology is in, rather than the aloofness of the "unrealistic" standard. Maybe something like this would be better: "Discussion of complexities in the application of guidelines for some sites" (or "for some situations")
Bruce Bailey	+1 for emphasis on real-world accessibility. Recent DOJ CRT and ED OCR skews heavily towards a functional approach. See: https://beta.ada.gov/web-guidance/ https://adata.org/ocr-videos
Sarah Horton
Alastair Campbell	At Nomensa we create a 'barrier score', which is a subjective score based on what the blockers/severe issues are for the main tasks of the site/section. I.e. it is a combination of the issue (e.g. missing alt text) and how severe an issue is the task, e.g. buy a jacket. If it is missing alt on a logo, that doesn't contribute much. However, missing it on the 'buy' button would be a blocker. If we have a baseline of guidelines/methods which are true/false (e.g. has alt text), we do need something on top of that which is more about the equivalence of the alt-text. On top of that, it would be useful to have some level of importance to task(s), which allows some to be missing and some to be critical.
Gregg Vanderheiden	this is a conformance issue or a policy issue. I really think it is a policy issue since it involves "time to repair" - which will vary under a lot of reasons. This is being looked at by the conformance group - along with Bulk Occurrences of content, real-time content and many other things.
Laura Carlson

2. Adding Placeholder Text

Please review the draft placeholder text in Section 6.2 Real World Accessibility.

Reminder that you have to use the "Reveal placeholder & exploratory sections" button at the top of the table of contents to view placeholder content

Summary

Choice	All responders
Choice	Results
I approve adding the placeholder text to the editor's draft.	4
I approve adding the placeholder text to the editor's draft with the following adjustments.	4
Something else (see comments)	5

Details

Responder	Adding Placeholder Text	Comments
John Foliot	I approve adding the placeholder text to the editor's draft.
Jeanne F Spellman	I approve adding the placeholder text to the editor's draft with the following adjustments.	I think that the title is broad and could mean many things. I would like to recommend that we add a paragraph under the placeholder title. "The Silver Research project and WCAG Challenges document noted use cases for passing certain accessibility errors under restricted circumstances. This idea does not yet have consensus support and will be worked on in the upcoming months."
Shawn Lauriat	I approve adding the placeholder text to the editor's draft with the following adjustments.	The title of this section likely needs adjusting, as those without the background info, above, will not understand what "Real world conformance" means. Maybe "Conformance in relation to real-world accessibility" or something along those lines?
Mary Jo Mueller	I approve adding the placeholder text to the editor's draft.	A suggested addition: If there's a known sub-group working on a certain aspect of the content, the placeholder could state it. That way those who are most interested can monitor and/or participate in its creation.
Michael Gower	Something else (see comments)	The link isn't working for me. Even after finding the Reveal button, it's just a heading and no content. Can it be updated to point to exactly what needs to be reviewed please?
Makoto Ueki	I approve adding the placeholder text to the editor's draft with the following adjustments.	Readers might get confused with the term "Real world". If this section is about accepting minor accessibility issues when making a conformance claim, "Exceptions" or "Minor Accessibility Issues" might be more appropriate title for the intent of this section. If we can add some editor notes which describe the intent and what we are working on, it would be better to get more understanding.
Todd Libby	I approve adding the placeholder text to the editor's draft.
David MacDonald	Something else (see comments)	Not sure about it as a topic that we commit to including in the future drafts. I think we can certainly explore ways to deal with these difficult issues, but expect there might be a fair amount of concern if the WCAG team is perceived as allowing sites to claim "exceptions" ... perhaps text should not be "Section status: Placeholder. We will be addressing this topic." But rather something less committed such as: Section status: Placeholder. This is a place were we may explore issues about the complexities of implementing accessibility, when after much accessibility work on a site, there are factors that make that difficult or impossible to claim strict conformance, in the context of a WCAG 2.x model. Also, I'm not sure about the term "real world" it appears to imply that WCAG is not addressing the real world and we have to have a special section to address "the Real World". What about something like: "Discussion of complexities in the application of guidelines for some sites"
Bruce Bailey	I approve adding the placeholder text to the editor's draft with the following adjustments.	Right now I am seeing: Real World Conformance I would rather it be: Real World Accessibility
Sarah Horton	Something else (see comments)	The work sounds important but pursing it as “approaches to real-world accessibility” may introduce ambiguity about whether we’ve been working on approaches to addressing real accessibility issues all along. Another way to explore this further within the WCAG 3 structure would be to work on defining critical errors for outcomes: https://rawgit.com/w3c/silver/real-world-accessibility-placeholder/guidelines/index.html#dfn-critical-error. The aim is the same, to identify issues that could prevent a person with a disability from independently using content or completing a task and prioritize those for conformance.
Alastair Campbell	I approve adding the placeholder text to the editor's draft.
Gregg Vanderheiden	Something else (see comments)	This should not be a part of the guidelines. it is a global comment like "things that meet WCAG are also not accessible to all". in the preamble maybe Think like a safety standard. If there is a but that make something unsafe -- it should not be called safe as long as bugs get fixed. it is not safe as long as the bug is there. We should if anything put this as a placeholder in the INTRO (not a section) or in a policy recommendations section People should not be sued for a bug if they agree to fix it in a reasonable amount of time <-- but that is policy not a measure of accessibility
Laura Carlson	Something else (see comments)	I agree with Gregg. Accessibility bugs should be fixed.