W3C home > Mailing lists > Public > public-silver@w3.org > July 2019

Re: Thinking about points

From: David MacDonald <david100@sympatico.ca>
Date: Thu, 11 Jul 2019 14:03:54 -0400
Message-ID: <CAAdDpDZtzue-d_qV052A2gP3ELbJAWjTF65w0JGaqj1z8V4snA@mail.gmail.com>
To: Léonie Watson <tink@tink.uk>
Cc: Silver Task Force <public-silver@w3.org>
 Here's what I remember about trying to overcome bias from way back.

WCAG 1.0 had the concept of Priority 1, 2, 3 and the concern in WCAG 2.0
was that WCAG 1 assigned *priorities* to checkpoints that were addressing a
specific need of a certain group. And therefore we were introducing bias
against certain needs by using the word "priority 1, 2, 3".

We **tried** to address in 2.0 that by assigning a generic name of "Level
(A, AA, AAA) to Success Criteria (which was loosely based on "checkpoints"
in WCAG 1.0). We hoped the letters A, AA, AAA wouldn't assign priority and
importance like the hierarchical numbers 1, 2, 3.

In my opinion WCAG 1 and 2 emphasised solutions for blindness because (1)
Screen reader AT was fairly mature (2) with blindness we knew, in a general
way, what to do and there was research. We knew that our recommendations
would help blind people and we knew they were doable across technologies,
languages and a variety of types and sizes of web sites.

We've been trying to overcome bias for a long time and it's hard to do. I'm
not saying we shouldn't continue to try, but I expect that whatever we do
in Silver, the next generation will see its inherent bias. Hopefully we can
however, improve with each version.

David MacDonald

*Can**Adapt* *Solutions Inc.*

Tel:  613-806-9005



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

On Thu, Jul 11, 2019 at 12:29 PM Léonie Watson <tink@tink.uk> wrote:

> Everyone,
> I've talked with JF more about his proposed points system, in particular
> about the part that worried me most on the call on Tuesday.
> I'm going to try and share my thoughts with you. I make no claims about
> any of this being final, concrete, or even entirely thought through, and
> if I'm repeating anyone's ideas without realising - I'm sorry, and thank
> you.
> I was worried about the idea of prioritising requirements based on user
> impact, because it will put people from one group into competition with
> people from another.
> Let's take two possible user needs/requirements:
> Requirement 1:
> "I want to be able to use headings to understand the hierarchy of content."
> Requirement 2:
> "I want to be able to understand the audio content of video."
> I'm not suggesting these should be actual requirements, I'm just making
> them up for the purposes of this email.
> If we say that requirement 1 is orientated towards blind people, it
> isn't critical, and assign it 10pts; then say requirement 2 is
> orientated towards Deaf people, it is critical, and assign it 20pts; it
> puts blind people and Deaf people into competition with each other, when
> it comes to the way authors choose to collect points.
> This doesn't seem like a good thing, and as it turns out I don't think
> it was what John was proposing.
> We then began walking through some ideas, one step at a time, and we
> started with the premise that all requirements are worth the same points
> to start with. Let's go with 10pts for want of anything else.
> Note: I know this idea isn't knew!
> We then thought about how to start differentiating between requirements,
> without making it a competition between different groups of people.
> We decided to identify how many user groups benefit from the requirement
> being met. Requirement 1 arguably benefits blind people, people with low
> vision, and people with cognitive disabilities; requirement 2 benefits
> Deaf people and people with cognitive disabilities.
> So requirement 1 is multiplied by 3 (making it worth 30pts), and
> requirement 2 is multiplied by 2 (making it worth 20pts).
> Note: the multiplier is based on the number of user groups that are
> benefited, not the number of users, and this was a really important
> distinction for me as JF and I talked. If we make it about numbers of
> users, we re-introduce the competition between users problem, and as
> previously noted that seems like a bad idea.
> We then considered how many requirements were likely to benefit only one
> user group. This is a question worth considering in more depth, but the
> example that came to mind as JF and I talked was this:
> Requirement 3:
> "I want to be able to disable flashing content before it begins."
> This requirement benefits one user group - anyone who will be exposed to
> the risk of seizing when they see the content flash.
> Using the model so far, requirement 3 would be worth 10pts because it
> benefits only one user group. That completely fails to recognise how
> critical this requirement is to people in that group though.
> So we then thought about having different levels of criticality for each
> user group. Let's say:
> 1. Useful
> 2. Needed
> 3. Critical
> We could bikeshed on the names, so again, I'm just making them up for
> the purposes of this email. Don't get too hung up on them just yet.
> Requirement 1 is:
> * Needed by blind people. That's a multiplier of 3 (1 for the user
> group, and 2 because it's "needed" by that user group).
> * Useful to low vision people. That's a multiplier of 2 (1 for the user
> group, and 1 because it's "useful" to that group).
> * useful too people with cognitive disabilities. That's a multiplier of
> 2 (1 for the user group, and 1 because it's "useful" to that group).
> Requirement 1 therefore has a total multiplier of 7 (if you add up all
> of the above), making it worth 70pts.
> This still doesn't quite work as intended though, because requirement 3
> would be worth 40pts compared to requirement 1 at 70pts.
> Requirement 3 is critical to people with Photo-Sensitive Epilepsy. This
> means it has a multiplier of 4 (1 for the user group, and 3 because it's
> "critical" to that group).
> There are different ways we might solve this, and I'm really winging it
> at this point, but stick with me.
> We could use a different points system for the criticality levels.
> 1. Useful
> 10. Needed.
> 150. Critical.
> Maths is not my strong suit, so I'm sure many of you will take one look
> at this and shoot it down, but hopefully you get the idea.
> We could add another criticality level, perhaps "Life-saving", that
> would only be used rarely, perhaps even only for this requirement.
> Note: as I write this email, I realise that requirement 3 also benefits
> people with cognitive disabilities who find moving/flashing content a
> distraction.
> Perhaps it would be useful to look more closely at the following things:
> * How might we identify the different user groups?
> * How many requirements are beneficial to 1 user group, 2 user groups, 3
> user groups, and so on.
> That information might help us figure out the maths with a bit more
> certainty, even if we only use a small sample of requirements initially.
> That's as far as we got. As I said at the start, I make no claims as to
> the usefulness of any of it!
> Léonie.
> --
> @LeonieWatson Carpe diem
Received on Thursday, 11 July 2019 18:04:39 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:31:46 UTC