Re: Notes re a roadmap to reaching consensus

Hi All

I read over the Issue severity presentation with interest. I have a few
initial thoughts, while confessing that my current circumstances (my wife
has advanced ALS) have absended me from joining the full conversation. I
offer these thoughts as a few considerations, without taking a firm
position on the context issue.

It seems there are attempts to identify likely situations where an issue
will be (1) Critical - 3 pts (2) Medium - 2 pts (3) minor - 1 pt. and
create a testing framework that will account for that and it would impact
the conformance score.

I appreciate that we are looking at a simple delegation to one of 3
categories to try to reduce the burden on evaluators and other
stakeholders, which would be harder if the categories were more granular.
Here are a few things I've noticed in evaluations I've done that perhaps
other evaluators can speak to.

Every accessibility company I've encountered offers a priority schema. If
it is a manual evaluation, it tends to work pretty well. For
automation I've seen very mixed results. I recently worked with a high
profile airline application that was evaluated with a leading automated
checker. The tool marked icons without alt text as critical because they
were images that had no alt text but in this context the images had
redundant text beside them. And so we had to spin a bunch of cycles
changing the priority level on them so we could get really important issues
handled first. So my two points here are that

(a) It was a lot easier to change the priority level on these because it
was generated by a tool. But let's just say it was defined in WCAG as high
priority, it would be set in stone as a high priority item. And it might
get priority over some of the "medium" issues that the tool picked out that
I thought were more important to users
(b) It might be easier for stakeholders closer to the content to provide
priorities then for us (WCAG) to provide them from our 10,000 foot view
because they are closer to the content and the contexts

I'm not sure if this is helpful to the discussion, but I offer it from my
encountering these types of issues in the trenches.

Cheers,
David MacDonald



*Can**Adapt* *Solutions Inc.*
Mobile:  613.806.9005

LinkedIn
<http://www.linkedin.com/in/davidmacdonald100>

twitter.com/davidmacd

GitHub <https://github.com/DavidMacDonald>

www.Can-Adapt.com <http://www.can-adapt.com/>



*  Adapting the web to all users*
*            Including those with disabilities*

If you are not the intended recipient, please review our privacy policy
<http://www.davidmacd.com/disclaimer.html>


On Fri, Oct 7, 2022 at 2:42 PM Todd Libby <toddlibby@protonmail.com> wrote:

> Rachael,
>
> Thank you and I understand the need to keep conversations here. I
> apologize for my earlier email, my intent was not malicious.
>
> I'll look into filtering out some of the items I don't need to be a part
> of. 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 11:11 AM, Bradley-Montgomery, Rachael <
> rmontgomery@loc.gov> wrote:
>
> Hello Todd,
>
>
>
> This email list is for discussion and we need to encourage asynchronous
> conversations like this in order to move forward. Over time, I expect the
> pace will increase rather than decrease. As Andrew mentioned, its been
> rather light lately compared to other times.
>
>
>
> That said, we also know that not everyone can follow the email threads and
> so we try to bring back final summaries/decisions to the group outside of
> email.
>
>
>
> I have my email set up to filter it out the various W3C group emails out
> of my main inbox so I can review them later. There are instructions on how
> to do this for various clients at
> https://www.w3.org/2006/tools/wiki/EmailClientForMailingListFiltering
>
>
>
> Another option would be to change the email address associated with your
> account so it is not coming to a regular email address.  If you need help
> with any of these please let me know.
>
>
>
> Kind regards,
>
>
>
> Rachael
>
>
>
> *From: *Todd Libby <toddlibby@protonmail.com>
> *Date: *Friday, October 7, 2022 at 1:43 PM
> *To: *Gregg Vanderheiden RTF <gregg@raisingthefloor.org>
> *Cc: *Alastair Campbell <acampbell@nomensa.com>, WCAG <w3c-wai-gl@w3.org>
> *Subject: *Re: Notes re a roadmap to reaching consensus
> *Resent-From: *WCAG <w3c-wai-gl@w3.org>
> *Resent-Date: *Friday, October 7, 2022 at 1:43 PM
>
>
>
>
>
>
>
> 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 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.
>
>
>
>  *   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
>
>
>
>
>
>
>