How to Improve Your Accessibility Testing (For Beginners) Webinar Q & A

Posted on:

In Tuesday’s webinar, SSB BART Group’s Senior Accessibility Consultant Owen Edwards and Accessibility Analyst James Thompson outlined a checklist-based approach to accessibility testing, and examined what details need to be included on setup and testing to ensure consistent, reliable results.

This post contains their responses to audience questions posed during and after the presentation.

Missed the webinar? No problem! You can access the webinar recording, slides, and CART transcript here: How to Improve Your Accessibility Testing (For Beginners) Webinar Resources.

Webinar Q & A

Q: How do you adjust your testing methods when reviewing Responsive Web Design websites?

// After the initial web test, we again go through the page in the supported sizes to ensure that resizing and modifications to the elements work properly using Firefox’s responsive design tool (Ctrl-Shift-M). Ensure that you go through the responsive view using only the keyboard to more closely mimic screen reader operation.

Q: How will you avoid the keyboard traps in JavaScript?

// Be very careful when creating event handlers for Tab and Shift-Tab and anytime you programmatically move focus. Be sure to test using keyboard-only operation, Tab and Shift-Tab from top to bottom and vice versa.

Q: Is changing order of elements via Flexbox (CSS) a violation of reading order? Is there any potential confusion users might encounter as a result of use of Flexbox? For example, changing the direction/order.

// Yes, reordering content in the CSS but not in the DOM is a violation of reading order.

Q: I have heard it’s difficult to work with Google Sites webpages because of the limited ability we have with them.  Our entire websites for the district is entirely Google Sites.  Do you have any information you would be able to send me to help me with making sure we pass the accessibility if we are audited? 

// The presentation describes techniques for testing an existing page which is framework independent. As far as developing a site, each environment will have its own capabilities and challenges when fixing accessibility issues. The specifics of fixing accessibility issues found in different frameworks is the subject of other webinars.

Q: Should the screen reader navigation access a larger set of UI components, a smaller set, or the exact same set as keyboard navigation without the screen reader?

// The goal accessibility is to provide an equivalent experience regardless of the technology used. So Ideally everything a mouse user has access to, a keyboard-only user will also have access to with and without a screen reader.

Screen readers have a much larger set of keyboard key mappings for accessing, finding and interacting with UI components. Keyboard-only navigation without a screen reader only uses a small subset by default. (e.g. Tab, Shift-Tab, Enter, Spacebar, and Ctrl-C all work the same whether one uses a screen reader or not, but the keys to jump to headings, lists and form fields do not work without a screen reader.)

Q: I’ve seen that NVDA and JAWS read pages differently, how do you resolve these problems?

// As long as the technology accurately conveys the page’s content, how the Assistive Technology (AT) does so is the company’s prerogative. There are features that JAWS implements that can fix or work-around a page’s shortcomings that NVDA doesn’t do. That said, if the page is coded properly and the AT is incorrectly conveying content we recommend filing a bug with the AT’s manufacturer.

Q: How does a screen reader work with popups?

// If the pop-up’s HTML and JavaScript is coded properly then the screen reader user will be able to open on activation, navigate through, and close the pop-up when leaving it. A web based dialog should behave like a native system dialog.

Q: Do you also test with NVDA? Why or why not?

// Yes, some client’s products do not run in IE and NVDA works better on Firefox than JAWS does. Also, JAWS does a lot to correct for bad code while NVDA does not; which makes problems in the code more apparent.

Q: How do we tackle background images?

// If they are informative or actionable, convert them to inline images with an appropriate description in the alt attribute. If they are decorative, leave them as invisible to AT.

Q: If you are blind and using JAWS as a tester is there a way to find out what the hexadecimal is of the text or background of a page?

// When using JAWS, Ins+5 will tell you the color and if you hit it twice quickly it will tell you the hex values. Or you can use NUM PAD 5 three times quickly.

Q: So how do we deal with different color schemes by the browser? 

// If you define a specific text color you must also define a background color with sufficient contrast in the CSS of the site.

Q: What do you do in scenarios where ARIA may not be supported by the AT/browser? What’s the strategy?

// We have a best practice that explains that when using ARIA, developers must also code a fallback for when ARIA is not supported. As ARIA becomes more ubiquitous we see fewer and fewer cases where this is a concern.

Q: Aren’t the orange and red indicators themselves a violation of the rule that you should not rely exclusively on color to signify things?

// In addition to turning the text red, the tool does add text when it finds an error in the ARIA.

Q: Can you recommend some testing tools and which browser to use on a mac for testing?

// When testing for 508 I use the tools required for Trusted Testers. (i.e. WAT on a PC in IE, etc.), Level Access’ Access Assistant toolbar for Chrome and Firefox and can run on Mac or PC.

Q: Is AMP available for desktop install? Does it check web applications as well?

// AMP is a cloud-based platform and Access Assistant is the testing interface to AMP which runs in the browser. We do not currently offer a product for testing operating systems.

Q: What’s the recommended order here: manual test first, then auto check?  Or the opposite?  Depends?

// If you are just starting out, we recommend running through all the manual test first and then checking your results against the automatics. If you run the automatics first it is easy to get overwhelmed. If you have been doing this a while the manual list is more of a reminder than a checklist to follow.

Q: When a screen reader starts reading a web page, what should be the expected ideal navigation?

// Screen reader users should be able to experience an equivalent navigation of the main content and the ability to skip past repetitive navigation structures.

Q: Whenever a pop-up is opened, what is the expectation of screen reader, whether it should read automatically the contents of the pop-up or it should just saw the pop up has so many links and buttons?

// There are no requirements in WCAG 2.0 nor Section 508 describing this behavior. The implementation is up to the developer but the behavior needs to be consistent across the site and internal policies should be consulted. In general equivalent facilitation means that the user knows that a pop-up has opened and can easily read its content.

Q: Can we talk about audit report formats? Are there examples I can review? My audio kept cutting in and out, so I’m not sure if this was covered. 

// WCAG conformance statements, Section 508 Voluntary Product Accessibility Templates (VPAT), and EU compliance documents have well defined formats which can be found online. Level Access has its own proprietary format which we use to communicate intermediate and more detailed results along with the AMP platform which allows multiple views of the detailed audit results.

Q: I test for a website we designed that has a left side hamburger menu. It is hidden until I click on it to display the menu. If I test in keyboard only how is that menu displayed? I tab 15 times before I see the selection moving on to other items outside the hamburger menu.

// Ideally, the hamburger menu’s items should only be available to keyboard-only users once the menu has been activated. Only visually available content should be accessible to keyboard-only users. It sounds like keyboard focus is moving through the menu items while they are visually hidden which means that the links have not been hidden programmatically.

« More Blog Posts

Put yourself on the path to complete accessibility!

Just fill out the form below and we’ll contact you to set up your free consultation with an expert specializing in your industry.

If you need more immediate assistance, please send an email to info@ssbbartgroup.com or call (800) 889-9659. We look forward to helping you!