Re: Notes re a roadmap to reaching consensus

Is there any chance of continuing this without my email getting pulled into this rabbit hole, please?

While I respect the conversation you're all having, my inbox is being inundated with W3C emails today at a record setting pace.

Thank you.

---
Best,

Todd Libby
Senior Accessibility Engineer
W3C Invited Expert
toddlibby@protonmail.com
https://toddl.dev

------- Original Message -------
On Friday, October 7th, 2022 at 10:37 AM, Gregg Vanderheiden RTF <gregg@raisingthefloor.org> wrote:

>> On Oct 6, 2022, at 4:21 AM, Alastair Campbell <acampbell@nomensa.com> wrote:
>>
>> Hi Gregg,
>>
>> One overall comment on the topic: People creating digital productshave todeal 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.
>
> GV: 1000% Agree with that.
>
> But that is a matter of prioritization — not a matter of whether something is accessible or not. That was my concern.
> Determining what is first second etc. has many other factors. Severity, ease, context of use etc. and each will vary from one company or even instance to another.
> Unfortunately severity also varies by user. And here is where I think we need to be careful.
>
> I don’t have a problem with providing some guidance for priority setting. (That is which to do first maybe) But I do with which we can skip. (Do 90% and stop - kind of thing)
>
>> 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.
>
> GV: My concern is that we pick black and white things to be an example - and then it gets applied across the board. We can always find examples that make our point. My concern is the unintended consequences of making decisions based on some examples.
>
> I often hear people talking about ALT text being a barrier but plain language or consistency being a hinderance. Yet for someone with a cognitive, language, and learning disability - the latter may be what is a showstopper for them though it is just a hinderance for us - while not having alt text may be a showstopper or not for another group depending on what the picture was.
>
> As I mentioned lots of times now — I ALSO thought weighing and scoring was the answer — even separating different disability groups into different categories and scoring within each separately — but it always failed when I really did my homework and tried to work it all the way through. There are different groups within each disability group - that are also distinct from each other. And this does not include people with multiple disabilities who further complicate this.
>
> So my comment is — that we can look at this but don’t hang our hopes on it. It always gets more complicated and (at least for me) always ended up having to make priority judgements between disability groups (not just major disability groups - but also different levels or subgroups within disability groups — and the ones with lower abilities usually are the ones that look most likely to get left off)
>
> I DO like the idea of a separate document on "Priority setting when you are starting out — or if flooded with content (like at acquisition or other things identified in the old "approaches to conformance" group).
> But I worry about it when looking at an approach to conformance. I worry that we will spend a LOT of time on it — then get so invested that — when we figure out all the problems as we get into details — we won’t want to back out and will push it through when it shouldn’t be.
>
> So explore it thoroughly up front - YES
> List pros and cons - YES
> Commit to it seriously before we try to explore it on a detailed level first — that is my concern.
>
>>> 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.
>
> GV: ok
>
>>>
>>
>>> 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.
>
> GV: yes - and I am still confused how they all fit together. But watching.
>
>> Those concerns have been discussed, an so far the guidelines & outcomes are tech agnostic and methods are tech specific (or general).
>
> GV: Makes sense. And this was how it was in WCAG 2 as well. So we kept the tech specific in a different (and huge) document so WCAG stayed agnostic and didnt have to be revised each time technology changed.
>
>> 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.
>
> GV: yea— you didnt mention tests in your last comment about agnostic or not. These tend to be even more technology specific - but not always.
>
> Are you thinking of putting the methods and tests in the guidelines - or having them in a companion doc (note) that can be more easily adopted.
>
> PS See the document I sent for ideas on ways to get methods or process into WCAG as testable. I think it can be done but they would be qualitatively different and would have to be handled and tested differently. But might be a path.
>
>>> 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.
>
> GV: yea — this reminds me of the example I cited in the meeting - where I thought advertising was low priority on a web page since it wasn’t the task of the page - or even on a shopping site since it wasn’t the act of buying — until I was told that ads were a key source of information to people with disabilities. That they depended on them to learn about new things. And to learn about sales and other ways to save money. And that they were critical to them — though I would have judged them as lower priority. And some things I thought of as high priority - they didnt care about.
>
> That is my problem. We make priority judgements based on what we think is important.
>
> So I worry.
>
> I ALSO have heard many times that government websites are judged accessible if the disability sections are accessible. In fact the parts where people can get money for children or benefits or submit taxes or any of a number of other topics are in fact more important to them.
> WE would not do that - but a person making an accessible claim might (and HAVE!)
>
>>> 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.
>
> GV: ???? My comment is that anything can be gamed. But we need to spec things that an author can predict which way an external person will judge.
>
> OH I wish this was simpler.
> And I don’t have the answer -
> And I DO know that what we have isnt perfect - and has flaws.
> But I worry that I keep hearing old ideas brought up as if brand new — and being hoped for as the solution (or proposed as the solution) based on a couple examples — but before they have really been thought through and the details examined. THEN - after so much time and hope is invested - no one wants to go back - since that was not perfect.
>
> We will see.
>
> Just throwing in these thoughts — after having traveled a lot of these roads before.
>
> Best
>
>> Kind regards,
>>
>> -Alastair
>>
>> --
>>
>> @alastc / [www.nomensa.com](http://www.nomensa.com/)