WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: [EXTERNAL] Graphical element instead of the role link presence. How should I report it?

for

From: Mark Magennis
Date: Mar 4, 2021 8:41AM

How to complete full manual testing? Well, basically you need a process, a lot of knowledge, and some tools.

In terms of process, you need a checklist of tests to perform and issues to look for. That checklist could simply be the WCAG success criteria, though I don't think they are organised in a way that makes for an easily used auditing checklist.

In terms of tools, there are many that you can use to help identify and analyze issues. The essential ones I think are a keyboard, a screen reader, and the F12 DOM inspector in the browser. You need to use everything with a keyboard. Then you need to use it all with a screen reader, based on an understanding of how screen reader users themselves access web content and how things *should* work for them. More about that below. The accessibility tree inspector, also available through F12, is also very useful. As we've discussed, automatic test tools like aXe, WAVE and a host of powerful commercial applications can be very useful too. Then there are colour contrast analyser tools, window resizers, text spacing bookmarklets, focus indicators, heading and landmark inspectors, etc. All of these can make the detection and analysis job quicker and easier.

But even more than process and tools, the most important thing you need is knowledge. Two types:

1. An understanding of how people with disabilities and using assistive technology access web content and use web functionality and the barriers they face. You can get this by working with them or by running or observing user tests involving them. Unless you know what you're trying to achieve in terms of user experience, you'll never be able to judge whether something is an issue and how serious it is.

2. An understanding of the WCAG success criteria, what fails them, and how they can be passed. Bearing in mind that a lot of accessibility issue, including some of the most serious you will find, are not WCAG violations.

Those two things are essential, but there are two others that are also very important:

3. An understanding of why coding causes these problems to arise and what coding changes would be required to prevent or alleviate them.

4. An understanding of why UX design causes some of these problems to arise and what design changes would be required to prevent or alleviate them.

Without understanding coding and design, you may be able to point out problems but you won't be able to provide much help with solutions. So you've only done half the work and you risk being a reporter whose report gets left on a shelf because nobody knows how to implement its recommendations. Testing has to somehow morph into remediation otherwise nothing changes. That's something you really want to be able to assist with.

Bear in mind, these requirements are not all or nothing. You don't need to be an expert to make a difference. If you have some understanding in all these areas you will still have some impact. Over time you will learn more and more and make more and more impact. You will never know anything near everything there is to know because accessibility is vast, still only partially understood, and changing all the time with technology. I know of one outstanding contributor to this list and to the community in general, who says he does not consider himself an expert. I think he's being overly modest but I can see he has a point.

Mark

-----Original Message-----
From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of Vsevolod Popov
Sent: 04 March 2021 13:50
To: WebAIM Discussion List < <EMAIL REMOVED> >; Steve Green < <EMAIL REMOVED> >
Subject: Re: [WebAIM] [EXTERNAL] Graphical element instead of the role link presence. How should I report it?

Hello,

Thank you for your tip.

As the beginner q/a I find it a little bit easier to start testing with axe or microsoft accessibility insights which uses the same automatic testing tools that axe uses,

because it gives me confidence if I correctly understand problems that are present on the page.

Of course I scan the page with the screen reader before running the utility. But utilities can give a little bit more understanding of the concrete issue.

But I would also like to know how to complete the full manual testing.

Thank you!

04.03.2021 14:25, Steve Green пишет:
> Although it's not strictly relevant to this discussion, I strongly recommend the exact opposite. In most contexts, I advocate conducting a full manual test first, and only then use an automated tool as a safety net.
>
> The rationale, which I have observed in practice, is that the automated tool results adversely affect how people do the manual testing. They miss issues the tool didn't report, perhaps because there is a subliminal voice telling them there's nothing wrong there. They tend to report issues exactly as the tool reported them, even if the tool misdiagnosed them, which is not uncommon. This shouldn't happen, but it does.
>
>
>
> --
> Best regards,
> Vsevolod