E-mail List Archives
Thread: Graphical element instead of the role link presence. How should I report it?
Number of posts in this thread: 12 (In chronological order)
From:
Date: Wed, Mar 03 2021 8:52AM
Subject: Graphical element instead of the role link presence. How should I report it?
No previous message | Next message →
Hello everyone,
There is a webpage that I need to provide an accessibility testing for. It was given to me as the practice.
The issue is that there is practically no html markup on a webpage, if I press ctrl+u and review the code the only thing I find is the connection process of java scripts in body of the document.
So I cannot review the code and report it as it would be more correctly.
The issue is that the element that logically should be stated as the element as the link role is presented as the graphical element with the alt text "Ceotech logo". When pressed, it returns back to the home page.
Here's how I have written a report.
Please feel free to correct me if I am wrong, because I have no idea how to tell it correctly in this case.
The graphical logo instead of the link role element is presented.
The element which is ment to be a home forwarding link is stated as an image that should be replaced with the element with name "home" and role link.
It will allow a screen reader user to interact with this element as needed.
Now it is not clear if it is an image or a link.
Expected result: An html element with the name "Home" and the link role should be presented.
Actual result: An aria-control element. The image element doesn't have a link role and has the wrong name which is confusing when using a screen reader.
Standards and guidelines:https://www.w3.org/TR/WCAG21/#non-text-content
https://www.w3.org/TR/WCAG21/#name-role-value
See also:https://www.w3.org/WAI/WCAG21/Understanding/name-role-value.html
https://dequeuniversity.com/rules/axe/4.1/image-alt?application=AxeFirefox
Reproduced on: Windows 10 (64 bit)
NVDA 2020.4.
Firefox 85.0.
P.s.:
There are no elements with the link role at all. All links are presented as divs or graphical elements.
The url is:
https://ceotech.ca
Thank you in advance!
Best regards,
Vsevolod
= EMAIL ADDRESS REMOVED =
My telegram channel (russian only):
http://t.me/vsevapopov2
The channel chat:
http://t.me/vsevapopovclub
From: Mark Magennis
Date: Wed, Mar 03 2021 9:45AM
Subject: Re: [EXTERNAL] Graphical element instead of the role link presence. Howshould I report it?
← Previous message | Next message →
Wow!
That site is really terrible from an accessibility point of view. The logo Home page link is really the least of the problems.
The biggest problem is that the site as a whole is completely inaccessible using the keyboard because you cannot Tab to any of the interactive elements.
It's slightly better using a screen reader because at least you can arrow through it, read most of the content, and activate many of the menu items.
I would suggest you mention these two points and then arrow though it with a screen reader yourself to find other issues you can point out in your report, such as:
1. Some content, including navigation menu items, is skipped.
2. Navigation menus don't behave correctly (e.g. you can't close them without selecting an option)
3. Some headings are not marked up and heading levels aren't correct.
4. Information is contained in images without text alternatives.
5. Some non-informational images have unnecessary and meaningless text alternatives.
6. Etc.
You can look at a lot of the HTML code in the Inspector - right click on any element and select Inspect from the menu.
Good luck,
Mark
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of ???????? ?????
Sent: 03 March 2021 15:53
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: [EXTERNAL] [WebAIM] Graphical element instead of the role link presence. How should I report it?
Hello everyone,
There is a webpage that I need to provide an accessibility testing for. It was given to me as the practice.
The issue is that there is practically no html markup on a webpage, if I press ctrl+u and review the code the only thing I find is the connection process of java scripts in body of the document.
So I cannot review the code and report it as it would be more correctly.
The issue is that the element that logically should be stated as the element as the link role is presented as the graphical element with the alt text "Ceotech logo". When pressed, it returns back to the home page.
Here's how I have written a report.
Please feel free to correct me if I am wrong, because I have no idea how to tell it correctly in this case.
The graphical logo instead of the link role element is presented.
The element which is ment to be a home forwarding link is stated as an image that should be replaced with the element with name "home" and role link.
It will allow a screen reader user to interact with this element as needed.
Now it is not clear if it is an image or a link.
Expected result: An html element with the name "Home" and the link role should be presented.
Actual result: An aria-control element. The image element doesn't have a link role and has the wrong name which is confusing when using a screen reader.
Standards and guidelines:https://www.w3.org/TR/WCAG21/#non-text-content
https://www.w3.org/TR/WCAG21/#name-role-value
See also:https://www.w3.org/WAI/WCAG21/Understanding/name-role-value.html
https://dequeuniversity.com/rules/axe/4.1/image-alt?application=AxeFirefox
Reproduced on: Windows 10 (64 bit)
NVDA 2020.4.
Firefox 85.0.
P.s.:
There are no elements with the link role at all. All links are presented as divs or graphical elements.
The url is:
https://ceotech.ca
Thank you in advance!
Best regards,
Vsevolod
= EMAIL ADDRESS REMOVED =
My telegram channel (russian only):
http://t.me/vsevapopov2
The channel chat:
http://t.me/vsevapopovclub
From: glen walker
Date: Wed, Mar 03 2021 9:49AM
Subject: Re: Graphical element instead of the role link presence. How should I report it?
← Previous message | Next message →
Being given a website to "practice" might also be a way for your employer
to evaluate your skills, and if we help you in that respect, it would skew
the results. But you were also being honest about the purpose of reviewing
the page (which, perhaps you shouldn't have been ð). You could have said
you were reviewing the page and left out that it was for practice.
So before we dive in too deep, use the browser's code inspector tool (f12)
instead of "view source" (ctrl+u) so that you can see the html that was
generated by the javascript. You'll see that the "link" is just an <img>
with a click handler. You're on the right track with your solution.
As far as the alt text, that's subjective. I, personally. wouldn't use
"logo" in the alt text but it's not quite a failure. Does it indicate it
takes you to the home page? Not really, but having an image/link as the
first thing on the page is generally understood to be a "home" link. So if
I were writing the report about fixing the image/link (which *does* have to
be fixed), I would also note my preference about the alt text but it would
be a side note.
On Wed, Mar 3, 2021 at 8:52 AM ÐÑеволод Ðопов < = EMAIL ADDRESS REMOVED = > wrote:
> Hello everyone,
> There is a webpage that I need to provide an accessibility testing for. It
> was given to me as the practice.
> The issue is that there is practically no html markup on a webpage, if I
> press ctrl+u and review the code the only thing I find is the connection
> process of java scripts in body of the document.
> So I cannot review the code and report it as it would be more correctly.
> The issue is that the element that logically should be stated as the
> element as the link role is presented as the graphical element with the alt
> text "Ceotech logo". When pressed, it returns back to the home page.
> Here's how I have written a report.
> Please feel free to correct me if I am wrong, because I have no idea how
> to tell it correctly in this case.
> The graphical logo instead of the link role element is presented.
> The element which is ment to be a home forwarding link is stated as an
> image that should be replaced with the element with name "home" and role
> link.
> It will allow a screen reader user to interact with this element as needed.
> Now it is not clear if it is an image or a link.
> Expected result: An html element with the name "Home" and the link role
> should be presented.
> Actual result: An aria-control element. The image element doesn't have a
> link role and has the wrong name which is confusing when using a screen
> reader.
> Standards and guidelines:https://www.w3.org/TR/WCAG21/#non-text-content
> https://www.w3.org/TR/WCAG21/#name-role-value
> See also:https://www.w3.org/WAI/WCAG21/Understanding/name-role-value.html
> https://dequeuniversity.com/rules/axe/4.1/image-alt?application=AxeFirefox
> Reproduced on: Windows 10 (64 bit)
> NVDA 2020.4.
> Firefox 85.0.
> P.s.:
> There are no elements with the link role at all. All links are presented
> as divs or graphical elements.
> The url is:
> https://ceotech.ca
> Thank you in advance!
> Best regards,
> Vsevolod
> = EMAIL ADDRESS REMOVED =
> My telegram channel (russian only):
> http://t.me/vsevapopov2
> The channel chat:
> http://t.me/vsevapopovclub
> > > > >
From: Vsevolod Popov
Date: Wed, Mar 03 2021 11:45AM
Subject: Re: [EXTERNAL] Graphical element instead of the role link presence. How should I report it?
← Previous message | Next message →
Hello Mark,
Thank you for your answer!
Yes, the first thing that I reported was the inability to navigate using
the keyboard with tab key and also I reported about the menu which
doesn't have link elements and only has the div elements.
Thank you for your tips,
I will surely use them when doing my next reports!
Thank you again!
03.03.2021 19:45, Mark Magennis пиÑеÑ:
> Wow!
>
> That site is really terrible from an accessibility point of view. The logo Home page link is really the least of the problems.
>
> The biggest problem is that the site as a whole is completely inaccessible using the keyboard because you cannot Tab to any of the interactive elements.
>
> It's slightly better using a screen reader because at least you can arrow through it, read most of the content, and activate many of the menu items.
>
> I would suggest you mention these two points and then arrow though it with a screen reader yourself to find other issues you can point out in your report, such as:
>
> 1. Some content, including navigation menu items, is skipped.
> 2. Navigation menus don't behave correctly (e.g. you can't close them without selecting an option)
> 3. Some headings are not marked up and heading levels aren't correct.
> 4. Information is contained in images without text alternatives.
> 5. Some non-informational images have unnecessary and meaningless text alternatives.
> 6. Etc.
>
> You can look at a lot of the HTML code in the Inspector - right click on any element and select Inspect from the menu.
>
> Good luck,
> Mark
>
>
> --
> Best regards,
> Vsevolod
From: Vsevolod Popov
Date: Wed, Mar 03 2021 11:53AM
Subject: Re: Graphical element instead of the role link presence. How should I report it?
← Previous message | Next message →
Hello,
Thank you for your tip :).
So, the question is:
What is the difference between the code view that opens with ctrl+u and
inspecting the page by pressing ctrl+shift+i?
Why aren't objects displayed in the code when they are displayed in DOM?
I thought that if the object is displayed in the DOM it will be also
repeeted in the code.
Or how does it work?
What is the huge difference between these two?
Do I understand correctly that if the element is displayed from java
script there will be the source to java script in the code and the java
script elements themselves will be in the DOM?
I am sorry if my questions can be strange, I am beginner in
accessibility testing, so I decided that it's better to ask and make
sure that I get it right.
Thank you in advance!
03.03.2021 19:49, glen walker пиÑеÑ:
> Being given a website to "practice" might also be a way for your employer
> to evaluate your skills, and if we help you in that respect, it would skew
> the results. But you were also being honest about the purpose of reviewing
> the page (which, perhaps you shouldn't have been ð). You could have said
> you were reviewing the page and left out that it was for practice.
>
> So before we dive in too deep, use the browser's code inspector tool (f12)
> instead of "view source" (ctrl+u) so that you can see the html that was
> generated by the javascript. You'll see that the "link" is just an <img>
> with a click handler. You're on the right track with your solution.
>
> As far as the alt text, that's subjective. I, personally. wouldn't use
> "logo" in the alt text but it's not quite a failure. Does it indicate it
> takes you to the home page? Not really, but having an image/link as the
> first thing on the page is generally understood to be a "home" link. So if
> I were writing the report about fixing the image/link (which *does* have to
> be fixed), I would also note my preference about the alt text but it would
> be a side note.
>
>
>
> --
> Best regards,
> Vsevolod
From: Swift, Daniel P.
Date: Wed, Mar 03 2021 12:34PM
Subject: Re: Graphical element instead of the role link presence. How should I report it?
← Previous message | Next message →
Control+U shows the document as it comes from the server (web page after any server-side processing). Inspecting it shows DOM changes to the page as it renders which includes any modifications through client-side scripting.
Daniel Swift, MBA
Senior Web Specialist
University Communications and Marketing
West Chester University
610.738.0589
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Vsevolod Popov
Sent: Wednesday, March 3, 2021 1:54 PM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >; glen walker < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Graphical element instead of the role link presence. How should I report it?
Hello,
Thank you for your tip :).
So, the question is:
What is the difference between the code view that opens with ctrl+u and
inspecting the page by pressing ctrl+shift+i?
Why aren't objects displayed in the code when they are displayed in DOM?
I thought that if the object is displayed in the DOM it will be also
repeeted in the code.
Or how does it work?
What is the huge difference between these two?
Do I understand correctly that if the element is displayed from java
script there will be the source to java script in the code and the java
script elements themselves will be in the DOM?
I am sorry if my questions can be strange, I am beginner in
accessibility testing, so I decided that it's better to ask and make
sure that I get it right.
Thank you in advance!
03.03.2021 19:49, glen walker пиÑеÑ:
> Being given a website to "practice" might also be a way for your employer
> to evaluate your skills, and if we help you in that respect, it would skew
> the results. But you were also being honest about the purpose of reviewing
> the page (which, perhaps you shouldn't have been ð). You could have said
> you were reviewing the page and left out that it was for practice.
>
> So before we dive in too deep, use the browser's code inspector tool (f12)
> instead of "view source" (ctrl+u) so that you can see the html that was
> generated by the javascript. You'll see that the "link" is just an <img>
> with a click handler. You're on the right track with your solution.
>
> As far as the alt text, that's subjective. I, personally. wouldn't use
> "logo" in the alt text but it's not quite a failure. Does it indicate it
> takes you to the home page? Not really, but having an image/link as the
> first thing on the page is generally understood to be a "home" link. So if
> I were writing the report about fixing the image/link (which *does* have to
> be fixed), I would also note my preference about the alt text but it would
> be a side note.
>
>
>
> --
> Best regards,
> Vsevolod
From: Mark Magennis
Date: Thu, Mar 04 2021 4:12AM
Subject: Re: [EXTERNAL] Graphical element instead of the role link presence. How should I report it?
← Previous message | Next message →
You're welcome Vsevolod.
I should add, I think it is always useful to begin any review by running an automated accessibility testing tool on the page. It will catch quite a few issues (somewhere around a quarter of them in my experience) and flag some suspected issues. I use aXe from Deque. You can download it for free and run it from the F12 inspector in the browser. It is simple to use and produces very clear results. It shows you the things that it knows are errors and points you to some other things that it suspects may be errors that you can check manually. It's a great start. It also links to further information and explanations which can be very useful in developing your knowledge of accessibility.
Mark
-----Original Message-----
From: Vsevolod Popov < = EMAIL ADDRESS REMOVED = >
Sent: 03 March 2021 18:45
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >; Mark Magennis < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] [EXTERNAL] Graphical element instead of the role link presence. How should I report it?
Hello Mark,
Thank you for your answer!
Yes, the first thing that I reported was the inability to navigate using the keyboard with tab key and also I reported about the menu which doesn't have link elements and only has the div elements.
Thank you for your tips,
I will surely use them when doing my next reports!
Thank you again!
03.03.2021 19:45, Mark Magennis пиÑеÑ:
> Wow!
>
> That site is really terrible from an accessibility point of view. The logo Home page link is really the least of the problems.
>
> The biggest problem is that the site as a whole is completely inaccessible using the keyboard because you cannot Tab to any of the interactive elements.
>
> It's slightly better using a screen reader because at least you can arrow through it, read most of the content, and activate many of the menu items.
>
> I would suggest you mention these two points and then arrow though it with a screen reader yourself to find other issues you can point out in your report, such as:
>
> 1. Some content, including navigation menu items, is skipped.
> 2. Navigation menus don't behave correctly (e.g. you can't close them
> without selecting an option) 3. Some headings are not marked up and heading levels aren't correct.
> 4. Information is contained in images without text alternatives.
> 5. Some non-informational images have unnecessary and meaningless text alternatives.
> 6. Etc.
>
> You can look at a lot of the HTML code in the Inspector - right click on any element and select Inspect from the menu.
>
> Good luck,
> Mark
>
>
> --
> Best regards,
> Vsevolod
From: Steve Green
Date: Thu, Mar 04 2021 4:25AM
Subject: Re: [EXTERNAL] Graphical element instead of the role link presence. How should I report it?
← Previous message | Next message →
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.
Steve Green
Managing Director
Test Partners Ltd
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Mark Magennis
Sent: 04 March 2021 11:13
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] [EXTERNAL] Graphical element instead of the role link presence. How should I report it?
You're welcome Vsevolod.
I should add, I think it is always useful to begin any review by running an automated accessibility testing tool on the page. It will catch quite a few issues (somewhere around a quarter of them in my experience) and flag some suspected issues. I use aXe from Deque. You can download it for free and run it from the F12 inspector in the browser. It is simple to use and produces very clear results. It shows you the things that it knows are errors and points you to some other things that it suspects may be errors that you can check manually. It's a great start. It also links to further information and explanations which can be very useful in developing your knowledge of accessibility.
Mark
-----Original Message-----
From: Vsevolod Popov < = EMAIL ADDRESS REMOVED = >
Sent: 03 March 2021 18:45
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >; Mark Magennis < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] [EXTERNAL] Graphical element instead of the role link presence. How should I report it?
Hello Mark,
Thank you for your answer!
Yes, the first thing that I reported was the inability to navigate using the keyboard with tab key and also I reported about the menu which doesn't have link elements and only has the div elements.
Thank you for your tips,
I will surely use them when doing my next reports!
Thank you again!
03.03.2021 19:45, Mark Magennis пиÑеÑ:
> Wow!
>
> That site is really terrible from an accessibility point of view. The logo Home page link is really the least of the problems.
>
> The biggest problem is that the site as a whole is completely inaccessible using the keyboard because you cannot Tab to any of the interactive elements.
>
> It's slightly better using a screen reader because at least you can arrow through it, read most of the content, and activate many of the menu items.
>
> I would suggest you mention these two points and then arrow though it with a screen reader yourself to find other issues you can point out in your report, such as:
>
> 1. Some content, including navigation menu items, is skipped.
> 2. Navigation menus don't behave correctly (e.g. you can't close them
> without selecting an option) 3. Some headings are not marked up and heading levels aren't correct.
> 4. Information is contained in images without text alternatives.
> 5. Some non-informational images have unnecessary and meaningless text alternatives.
> 6. Etc.
>
> You can look at a lot of the HTML code in the Inspector - right click on any element and select Inspect from the menu.
>
> Good luck,
> Mark
>
>
> --
> Best regards,
> Vsevolod
From: Catherine Roy
Date: Thu, Mar 04 2021 4:51AM
Subject: Re: [EXTERNAL] Graphical element instead of the role link presence. How should I report it?
← Previous message | Next message →
+1
--
Catherine Roy
www.catherine-roy.net
> On Mar 4, 2021, at 6:25 AM, Steve Green < = EMAIL ADDRESS REMOVED = > wrote:
>
> 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.
>
> Steve Green
> Managing Director
> Test Partners Ltd
>
>
> -----Original Message-----
> From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Mark Magennis
> Sent: 04 March 2021 11:13
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Subject: Re: [WebAIM] [EXTERNAL] Graphical element instead of the role link presence. How should I report it?
>
> You're welcome Vsevolod.
>
> I should add, I think it is always useful to begin any review by running an automated accessibility testing tool on the page. It will catch quite a few issues (somewhere around a quarter of them in my experience) and flag some suspected issues. I use aXe from Deque. You can download it for free and run it from the F12 inspector in the browser. It is simple to use and produces very clear results. It shows you the things that it knows are errors and points you to some other things that it suspects may be errors that you can check manually. It's a great start. It also links to further information and explanations which can be very useful in developing your knowledge of accessibility.
>
> Mark
>
> -----Original Message-----
> From: Vsevolod Popov < = EMAIL ADDRESS REMOVED = >
> Sent: 03 March 2021 18:45
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >; Mark Magennis < = EMAIL ADDRESS REMOVED = >
> Subject: Re: [WebAIM] [EXTERNAL] Graphical element instead of the role link presence. How should I report it?
>
> Hello Mark,
>
> Thank you for your answer!
>
> Yes, the first thing that I reported was the inability to navigate using the keyboard with tab key and also I reported about the menu which doesn't have link elements and only has the div elements.
>
> Thank you for your tips,
>
> I will surely use them when doing my next reports!
>
> Thank you again!
>
> 03.03.2021 19:45, Mark Magennis пиÑеÑ:
>> Wow!
>>
>> That site is really terrible from an accessibility point of view. The logo Home page link is really the least of the problems.
>>
>> The biggest problem is that the site as a whole is completely inaccessible using the keyboard because you cannot Tab to any of the interactive elements.
>>
>> It's slightly better using a screen reader because at least you can arrow through it, read most of the content, and activate many of the menu items.
>>
>> I would suggest you mention these two points and then arrow though it with a screen reader yourself to find other issues you can point out in your report, such as:
>>
>> 1. Some content, including navigation menu items, is skipped.
>> 2. Navigation menus don't behave correctly (e.g. you can't close them
>> without selecting an option) 3. Some headings are not marked up and heading levels aren't correct.
>> 4. Information is contained in images without text alternatives.
>> 5. Some non-informational images have unnecessary and meaningless text alternatives.
>> 6. Etc.
>>
>> You can look at a lot of the HTML code in the Inspector - right click on any element and select Inspect from the menu.
>>
>> Good luck,
>> Mark
>>
>>
>> --
>> Best regards,
>> Vsevolod
> > > > > > >
From: Mark Magennis
Date: Thu, Mar 04 2021 5:33AM
Subject: Re: [EXTERNAL] Graphical element instead of the role link presence. How should I report it?
← Previous message | Next message →
Thanks for injecting this Steve. I think it's very useful to discuss approaches to testing and it does seem relevant to this discussion.
Despite having said the polar opposite, I understand your point and yes, if starting with an automated tool does negatively affect the quality of a subsequent manual testing then that is a problem. I haven't observed this in practice but that may be because I haven't sufficiently studied it closely enough.
However, for most of those in my company who do accessibility testing, I think starting with aXe has a lot of benefits. All members of the development teams - UX, Engineering, and QA - are expected to cover accessibility, but in practice this is only to the extent that they are able. We use automated testing as the minimum and expect/hope some degree of manual testing will follow on from there and that's where we run into limitations. Engineers don't have time to do much testing but we ask them to at least run aXe and fix Violations before handing over to QA. We also ask them to try the functionality with the keyboard only and check what the screen reader reads, though I know a lot of them don't do that. Even if they do, we run into the problem where they don't really understand how it *should* work with the keyboard and what a screen reader *should* read, so their manual testing is not always effective. QA are expected to do much more in depth testing, as is normal in their role, and hopefully develop accessibility knowledge over time. We still recommend they start with aXe, if only to check that there aren't any Violations that Engineers should already have found and fixed. But with manual testing, QA run into the same problems as Engineers - not having sufficient understanding of how something should work for it to be considered accessible. They have a process and a lot of supports (defined testing process, a11y user acceptance criteria, learning resources, etc.), but they often still have insufficient time to learn and put their learning into practice. If they were able to use all of the resources and do the full manual QA check to a high degree of expertise, then there would be little need for them to use an automated tool. But in practice, some QA Engineers are entirely new to accessibility, most have very little time to devote to a11y QA (let's face it, the overhead is enormous), some squads or product owners are just not sufficiently bought into it to allocate the time, and some QA staff just don't get it or don't have the level of interest for it to spark their curiosity and wish to learn more. Very few have ever sat down with real users with disabilities or observed user testing for example, so their understanding of what we are trying to achieve is often very limited. We do use offshore QA who have a lot more a11y experience and they can follow the process much deeper, but they are still limited in their understanding. The specialists in the Accessibility Office are the ultimate testing and knowledge resource but we are painfully few and very stretched.
Given this, we find that getting the dev teams to at least use the automated tool and think about what it is telling them is a very good start and often as far as we will get. But it does give a good platform for training/mentoring discussions. The Accessibility Office runs regular a11y workshops for UX, Engineering, and QA and the teams often come with questions around "aXe is saying this but I don't fully understand it". I find that's a really good start for conversations that will help to upskill them.
The Accessibility Office can do a complete manual audit without needing automated tools, but as you say it's useful as a check to see if anything was missed. However, I personally always start by running aXe and seeing what it says. I don't really know why I start with this. I didn't used to but I've grown to like it. Maybe it just feels like it gets me going easily. I don't feel it affects the manual testing I do and yes, it does misdiagnose a fair amount but I can understand that. So for specialists maybe it doesn't matter but for people strapped for time or with little knowledge then I feel it can be useful to start with automated tools.
I think I'll pay more attention in future to looking to see whether it might hamper subsequent manual testing though because I can see your point.
Best,
Mark
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Steve Green
Sent: 04 March 2021 11:25
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] [EXTERNAL] Graphical element instead of the role link presence. How should I report it?
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.
Steve Green
Managing Director
Test Partners Ltd
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Mark Magennis
Sent: 04 March 2021 11:13
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] [EXTERNAL] Graphical element instead of the role link presence. How should I report it?
You're welcome Vsevolod.
I should add, I think it is always useful to begin any review by running an automated accessibility testing tool on the page. It will catch quite a few issues (somewhere around a quarter of them in my experience) and flag some suspected issues. I use aXe from Deque. You can download it for free and run it from the F12 inspector in the browser. It is simple to use and produces very clear results. It shows you the things that it knows are errors and points you to some other things that it suspects may be errors that you can check manually. It's a great start. It also links to further information and explanations which can be very useful in developing your knowledge of accessibility.
Mark
-----Original Message-----
From: Vsevolod Popov < = EMAIL ADDRESS REMOVED = >
Sent: 03 March 2021 18:45
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >; Mark Magennis < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] [EXTERNAL] Graphical element instead of the role link presence. How should I report it?
Hello Mark,
Thank you for your answer!
Yes, the first thing that I reported was the inability to navigate using the keyboard with tab key and also I reported about the menu which doesn't have link elements and only has the div elements.
Thank you for your tips,
I will surely use them when doing my next reports!
Thank you again!
03.03.2021 19:45, Mark Magennis пиÑеÑ:
> Wow!
>
> That site is really terrible from an accessibility point of view. The logo Home page link is really the least of the problems.
>
> The biggest problem is that the site as a whole is completely inaccessible using the keyboard because you cannot Tab to any of the interactive elements.
>
> It's slightly better using a screen reader because at least you can arrow through it, read most of the content, and activate many of the menu items.
>
> I would suggest you mention these two points and then arrow though it with a screen reader yourself to find other issues you can point out in your report, such as:
>
> 1. Some content, including navigation menu items, is skipped.
> 2. Navigation menus don't behave correctly (e.g. you can't close them
> without selecting an option) 3. Some headings are not marked up and heading levels aren't correct.
> 4. Information is contained in images without text alternatives.
> 5. Some non-informational images have unnecessary and meaningless text alternatives.
> 6. Etc.
>
> You can look at a lot of the HTML code in the Inspector - right click on any element and select Inspect from the menu.
>
> Good luck,
> Mark
>
>
> --
> Best regards,
> Vsevolod
From: Vsevolod Popov
Date: Thu, Mar 04 2021 6:50AM
Subject: Re: [EXTERNAL] Graphical element instead of the role link presence. How should I report it?
← Previous message | Next message →
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
From: Mark Magennis
Date: Thu, Mar 04 2021 8:41AM
Subject: Re: [EXTERNAL] Graphical element instead of the role link presence. How should I report it?
← Previous message | No next message
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 ADDRESS REMOVED = > On Behalf Of Vsevolod Popov
Sent: 04 March 2021 13:50
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >; Steve Green < = EMAIL ADDRESS 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