E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 7 (In chronological order)

From: Nathan Clark
Date: Wed, Apr 13 2022 7:49AM
Subject: priority accessibility issues
No previous message | Next message →

Dear list,
When doing accessibility audit on a website, what do you all consider
to be low, medium or high priority accessibility bugs?

Thanks.
Sincerely,
Nathan Clark

--
Nathan Clark
QA Automation Analyst Tech team
Accessibility assistant
CPACC
cell: 410-446-7259
email: = EMAIL ADDRESS REMOVED =
101 Village Blvd
Princeton, NJ 08540
SMBE & Minority Owned Business

--

From: glen walker
Date: Wed, Apr 13 2022 8:08AM
Subject: Re: priority accessibility issues
← Previous message | Next message →

I think that might be too broad of a question although some generalities I
follow are:

high - blocker type issues, a user can't accomplish a task
med - non-blocking but still frustrating but a workaround might exist
low - technical wcag failure but might not have too adverse of an effect

A high bug might be an image button that doesn't have alt text or a label
so the user doesn't know what the button does, or an interactive element
that does not allow keyboard selection.
A medium bug might be an inconsistent or missing heading structure.
A low bug might be a color contrast of 4.4:1, just below the minimum.

I have been playing with a format that has high and medium as true WCAG
failures and then using low for UX bugs that don't fail WCAG but still
cause problems for users. For example, a "learn more" link that is
embedded in a paragraph with its context technically passes 2.4.4 but I
recommend making the link text make sense on its own (2.4.9). If there are
multiple links in a row that go to the same destination, I recommend
combining the links or "unlinking" some of the text if it's appropriate.
If there's a character in button label that is decorative but it's still
announced, such as a greater than sign, it doesn't make the button unusable
but sounds a little funny.


On Wed, Apr 13, 2022 at 7:49 AM Nathan Clark < = EMAIL ADDRESS REMOVED = >
wrote:

> Dear list,
> When doing accessibility audit on a website, what do you all consider
> to be low, medium or high priority accessibility bugs?
>
> Thanks.
> Sincerely,
> Nathan Clark
>
> --
> Nathan Clark
> QA Automation Analyst Tech team
> Accessibility assistant
> CPACC
> cell: 410-446-7259
> email: = EMAIL ADDRESS REMOVED =
> 101 Village Blvd
> Princeton, NJ 08540
> SMBE & Minority Owned Business
>
> --
>
>
>
> > > > >

From: Steve Green
Date: Wed, Apr 13 2022 8:10AM
Subject: Re: priority accessibility issues
← Previous message | Next message →

That's a question I get asked a lot, and I refuse to answer it because it is not a useful question. In particular, it is not what the person asking it really wants to know. And it hides a lot of complexity. So the answer is "why do you want to know?"



The person asking it usually wants to know something different, such as:



* In what sequence should we fix the bugs?

* Which bugs can we go live with and which must be fixed first?

* Can we leave some bugs permanently unfixed?



Once I get a sensible question like this, my answer is usually “if you are going to fix some or all of the bugs before going live, do so in the sequence that makes the most efficient use of development and testing resources.” You may choose to fix some low-impact bugs if they are in the same area of code as a high-impact bug you have decided to test.



Prioritisation of post-launch fixes is rather different and there are a lot of factors to consider. For a US website I might recommend prioritising all the issues (including false positives) that automated tools report in order to minimise the likelihood of a spurious legal claim. For each bug, you might want to assess which user group(s) are impacted, how large such groups are, the extent to which they are impacted, the importance of the inaccessible feature or content and whether there are workarounds. Most of that is subjective and some is unknowable. There is no right answer.



The important thing to explain to project managers (since it is usually they who ask the question) is that you can't just say that WCAG success criterion 1.3.1 is higher priority than 1.4.3 because it's level A rather than AA. Taking into account the criteria I mentioned above, some level AA non-conformances might be much more important than some level A ones on a particular website. And you certainly shouldn't generalise across websites.

Steve Green
Managing Director
Test Partners Ltd




-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Nathan Clark
Sent: 13 April 2022 14:49
To: = EMAIL ADDRESS REMOVED =
Subject: [WebAIM] priority accessibility issues



Dear list,

When doing accessibility audit on a website, what do you all consider to be low, medium or high priority accessibility bugs?



Thanks.

Sincerely,

Nathan Clark



--

Nathan Clark

QA Automation Analyst Tech team

Accessibility assistant

CPACC

cell: 410-446-7259

email: = EMAIL ADDRESS REMOVED = <mailto: = EMAIL ADDRESS REMOVED = >

101 Village Blvd

Princeton, NJ 08540

SMBE & Minority Owned Business



--

From: Mark Magennis
Date: Wed, Apr 13 2022 8:43AM
Subject: Re: priority accessibility issues
← Previous message | Next message →

Steve makes an interesting basic point that it's not all about the accessibility impact on the user.

In my company, we log bugs in Jira and Jira requires a priority - Critical, High, Medium, or Low. The Accessibility Office which either logs the bugs or triages them uses a schema pretty much like what Glen outlined, based on user impact, although we don't take into account whether or not they are WCAG failures.

But then ... bugs go into development sprints and it is the Product Owner (or feature owner) or the Scrum Master (Agile process) who decides what goes into a sprint, i.e. what gets fixed first. This takes into account some of what Steve mentioned, including development effort, current development focus, customer interest (some bugs were initially reported by customers so get to the front of the queue), as well as our accessibility priority and, sometimes, whether it is a WCAG failure or not and will therefore affect our VPAT (I know it's not the correct term so please don't point it out). Ultimately, everyone gets to input their two cents worth and the Product Owner is the final arbiter, although in practice it's very often the Accessibility Office that has the biggest say, which is great because we always go for max user impact.

As an aside, the most impactful bugs are very frequently not WCAG failures!

Mark

-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Steve Green
Sent: 13 April 2022 15:10
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: [EXTERNAL] Re: [WebAIM] priority accessibility issues

That's a question I get asked a lot, and I refuse to answer it because it is not a useful question. In particular, it is not what the person asking it really wants to know. And it hides a lot of complexity. So the answer is "why do you want to know?"



The person asking it usually wants to know something different, such as:



* In what sequence should we fix the bugs?

* Which bugs can we go live with and which must be fixed first?

* Can we leave some bugs permanently unfixed?



Once I get a sensible question like this, my answer is usually “if you are going to fix some or all of the bugs before going live, do so in the sequence that makes the most efficient use of development and testing resources.” You may choose to fix some low-impact bugs if they are in the same area of code as a high-impact bug you have decided to test.



Prioritisation of post-launch fixes is rather different and there are a lot of factors to consider. For a US website I might recommend prioritising all the issues (including false positives) that automated tools report in order to minimise the likelihood of a spurious legal claim. For each bug, you might want to assess which user group(s) are impacted, how large such groups are, the extent to which they are impacted, the importance of the inaccessible feature or content and whether there are workarounds. Most of that is subjective and some is unknowable. There is no right answer.



The important thing to explain to project managers (since it is usually they who ask the question) is that you can't just say that WCAG success criterion 1.3.1 is higher priority than 1.4.3 because it's level A rather than AA. Taking into account the criteria I mentioned above, some level AA non-conformances might be much more important than some level A ones on a particular website. And you certainly shouldn't generalise across websites.

Steve Green
Managing Director
Test Partners Ltd




-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Nathan Clark
Sent: 13 April 2022 14:49
To: = EMAIL ADDRESS REMOVED =
Subject: [WebAIM] priority accessibility issues



Dear list,

When doing accessibility audit on a website, what do you all consider to be low, medium or high priority accessibility bugs?



Thanks.

Sincerely,

Nathan Clark



--

Nathan Clark

QA Automation Analyst Tech team

Accessibility assistant

CPACC

cell: 410-446-7259

email: = EMAIL ADDRESS REMOVED = <mailto: = EMAIL ADDRESS REMOVED = >

101 Village Blvd

Princeton, NJ 08540

SMBE & Minority Owned Business



--

From: Lars Ballieu Christensen
Date: Wed, Apr 13 2022 8:46AM
Subject: Re: priority accessibility issues
← Previous message | Next message →

I believe there is broad consensus that the A and AA WCAG success criteria - as a total - defines best practice for accessibility compliance. Unless you are talking about WCAG AAA criteria, this is likely not a discussion you will want to have as it would have you prioritise certain user groups over others.

We are frequently asked by clients to prioritise accessibility issues, for example based on the number of users affected by the issues. If that were to be used as the benchmark, our clients would never give priority to matters relating to being blind simply because blindness is a fairly rare disability affecting relative few people (relative to other groups). One of the great things about WCAG is that it helps to make accessibility an objective measure rather than something based on perceived requirements and prejudice: clients need only relate to the WCAG success criteria and not specific user needs..

Within the European Union, WCAG AA compliance is mandated by law (although more or less without consequences); I usually reverse the question by telling clients that it is ethically problematic and tell them that they would probably never raise the question of prioritizing parts of the legal requirements if the subject matter was GDPR.

Venligst/Kind regards

Lars
----
Lars Ballieu Christensen
RÃ¥dgiver/Adviser, Ph.D., M.Sc., Sensus ApS
Specialister i tilgængelighed/Accessibility Consultants
Tel: +45 48 22 10 03 – Mobil: +45 40 32 68 23 - Skype: Ballieu
Mail: = EMAIL ADDRESS REMOVED = – Web: https://www.sensus.dk

Vi arbejder for et tilgængeligt og rummeligt informationssamfund
Working for an accessible and inclusive information society



On 13/04/2022, 15.49, "WebAIM-Forum on behalf of Nathan Clark" < = EMAIL ADDRESS REMOVED = on behalf of = EMAIL ADDRESS REMOVED = > wrote:

Dear list,
When doing accessibility audit on a website, what do you all consider
to be low, medium or high priority accessibility bugs?

Thanks.
Sincerely,
Nathan Clark

--
Nathan Clark
QA Automation Analyst Tech team
Accessibility assistant
CPACC
cell: 410-446-7259
email: = EMAIL ADDRESS REMOVED =
101 Village Blvd
Princeton, NJ 08540
SMBE & Minority Owned Business

--

From: glen walker
Date: Wed, Apr 13 2022 9:52AM
Subject: Re: priority accessibility issues
← Previous message | Next message →

I like Lars' analogy to asking what parts of GDPR should we prioritize and
implement. I've never heard that question asked :-)

On a similar vein, occasionally if a client asks which accessibility issues
should they fix, I ask them which features would they like to exclude from
certain users? It's kind of a rhetorical question and usually starts an
interesting conversation.

From: L Snider
Date: Wed, Apr 13 2022 11:00AM
Subject: Re: priority accessibility issues
← Previous message | No next message

I find that one hard sometimes, because a major barrier for someone who is
deaf-blind using a screen reader can be majorly different than one for
someone with a neurological disability. I try to do priority (access is
impossible or there are severe barriers) and secondary priority (access is
still possible, but there are moderate to low barriers). There is no exacts
in my view as humans have different needs

On Wed, Apr 13, 2022 at 10:49 AM Nathan Clark < = EMAIL ADDRESS REMOVED = >
wrote:

> Dear list,
> When doing accessibility audit on a website, what do you all consider
> to be low, medium or high priority accessibility bugs?
>
> Thanks.
> Sincerely,
> Nathan Clark
>
> --
> Nathan Clark
> QA Automation Analyst Tech team
> Accessibility assistant
> CPACC
> cell: 410-446-7259
> email: = EMAIL ADDRESS REMOVED =
> 101 Village Blvd
> Princeton, NJ 08540
> SMBE & Minority Owned Business
>
> --
>
>
>
> > > > >