- From: Alastair Campbell <acampbell@nomensa.com>
- Date: Thu, 6 Oct 2022 11:21:19 +0000
- To: Gregg Vanderheiden RTF <gregg@raisingthefloor.org>
- CC: "w3c-waI-gl@w3. org" <w3c-wai-gl@w3.org>
- Message-ID: <PR3PR09MB53470C231272F0BFF100DA8FB95C9@PR3PR09MB5347.eurprd09.prod.outlook.com>
Hi Gregg, One overall comment on the topic: People creating digital products have to deal with & work through these issues regardless of whether WCAG provides guidance on them. For example, prioritising accessibility fixes. They can’t do everything at once. Therefore, they cannot treat everything as equally important. We need to acknowledge that and draw from the experience of that process. On the comments: > This is where I have the problem. Why is it assumed that a functional button is always more important than a content image. It won’t be 100% accurate, but we can draw on experience, typical usage, and typical designs to inform a likely impact. For example, WCAG 2 treats a duplicate ID on a component not visible to the user (or AT) at the same level as a missing accname on a button. In over 90% of cases (maybe 99.9%?) the accname will be more important, but WCAG 2 puts it at the same level. Would our more granular severity approach be 100% accurate? No, but based on how interfaces are typically put together we could apply more granularity than in WCAG 2. When you break down the requirements to a lower level that becomes more realistic. Not perfect, but potentially the basis for more a granular ruler. > Not sure I understand. Lower level than what? A lower level than SCs. In the sub-group we were looking at the test level and applying severity there, rather than at the guideline or method level. If we take that approach, then we’d need to work through how the severity would be used to pass/fail at the guideline level. > making the SC more technology specific DOES make them easier to to read and apply — to those technologies. But it makes them less technology agnostic —which 1) makes them less useful for general guidelines like WCAG 2 and 2) makes them less future proof. As new technologies come out - they aren’t covered. Note in WCAG 3 we’re talking about guidelines/outcomes/methods/tests. Those concerns have been discussed, an so far the guidelines & outcomes are tech agnostic and methods are tech specific (or general). So the tricky aspect of applying severity at the test level is whether that would need to be normative, and how you score (or otherwise use the severity) for passing guidelines. > It is just that when you start saying context - there are millions or billions of them. Where do you start and end? If you just use the ones you think of ?— what of all the ones you don’t? By context, I mean the context you can draw from the page/app/task, not the user’s context. For example, if you are on an shopping site the context is buying things, so there is inherent prioritisation that you can apply with that context that WCAG cannot predict. It is something that needs to be set by the person making an accessibility claim, potentially with guidance from WCAG or an associated doc. > Selecting pages can be gamed by an author for self assignment — but an external evaluator would not - so it would not be game-able in a way that would protect anyone. Good, then the same should apply for people going through a process of selecting tasks/processes. Kind regards, -Alastair -- @alastc / www.nomensa.com<http://www.nomensa.com>
Received on Thursday, 6 October 2022 11:22:22 UTC