How it should be doneĪll interactive elements should expose their roles to screen readers and other assistive technologies, ideally by using native HTML elements such as elements for links, and. If none of these exist, I would have to revert to the old tried and trusted method of asking a colleague to check whether the element was interactive. Failing that, I’ll check whether the element or one of its close neighbors has an attached click event. If not, I can always inspect the markup using Chrome’s or Firefox’s developer-tools panel, where I can traverse the DOM and look out for visually hidden or controls, class="checkbox/radiobutton" attributes, or elements close to the element at hand that contain hidden content that might be exposed if the control was clicked. If more information appears, or if I’m suddenly able to submit a form, then happy days! So I activate the JAWS cursor, move it to the control and use JAWS to fire a click event on it. “Learn More” and “Full description” are labels that I assume must be disclosure widgets that would reveal extra information if I could just activate them, while “I am over 18” and “I agree to the terms and conditions” are most likely checkboxes that need to be checked before I can submit a form. The text labels assigned to these controls often give the game away. But the surrounding content and the class name provide some hints as to what the element is supposed to be. This looks like a button, but it’s not keyboard focusable. We are experiencing high volumes of orders at the current time so wait times may be a bit longer. So they’re easy for a screen reader user to miss. Since they aren’t native interactive elements, they usually aren’t part of the tab order, and they don’t show up in JAWS’ forms list or links list. Their function is usually to request details or confirmation from the user or to reveal extra information.
So what are the most serious blockers for blind testers, and are there ways to work around them? Below are just some of the issues I encounter that uniquely affect me as a blind tester.ĭuring testing, I frequently come across controls that look like links, buttons, checkboxes, and the like that don’t expose themselves as such to JAWS. Accessibility testing wasn’t a complicated affair (and to be fair, the same old issues still present themselves to this day).įast forward to the days of custom widgets and frameworks, shadow DOM components, multiple ways to render images, and exponentially more complex testing scenarios.
The most common accessibility issues were images with missing or inadequate alternative text, form fields without labels, and text that looked like headings but wasn’t marked up as such. In the first formal accessibility test that I carried out, I used Internet Explorer 3.0 and the JAWS 3.0 screen reader. The landscape has changed beyond recognition since I began. I’m a blind accessibility engineer at TPGi, and I’ve been carrying out accessibility audits and tests in one form or another for almost 25 years. Even auditing content that’s reasonably accessible has its challenges when you can’t see the screen to compare your understanding of the content with what’s visibly presented to the user. In the worst-case scenario, when content is completely inaccessible, a totally blind auditor may not be able to process enough of what’s on the page to carry out any meaningful testing. But depending on the site or app under audit, full-time screen-reader users might not automatically be in a better position to spot issues. Also, you tend to do certain tasks faster than an ad-hoc screen-reader user or tester would. When testing a website or mobile application’s accessibility, some might say that someone who routinely uses a screen reader would be best placed to eke out issues, right? While it’s true that if you use a screen reader for everything you do on your computer, all the time, you naturally become an expert user over time, and you can find issues that may otherwise fly under the radar.
0 kommentar(er)
