Skip to main content
Posted in

Accessibility Testing

Prioritising Accessibility issues

August 10, 2018 Srinivasu Chakravarthula 1 comment Accessibility Testing, Web Accessibility ,

I was recently asked by a friend if there are any standard rules to set priority for accessibility issues for a website and that triggered me write-in this piece. 

In general, for an accessibility tester and when we read failure statements, everything sounds important, but it’s essential to prioritize issues since not all of the issues could be addressed one go; It’s fair for product managers to prioritise the effort. 

Why is it important to prioritise?

If we do not prioritise at the time of testing, we will be either asked to do it at a later stage or product team has to work on prioritising. If product team prioritise without consultation of accessibility team, chances are more for misinterpretation of what is important and what’s not from accessibility prospective. Prioritising is important because developers may not be able to address all of the issues at one go. 

How to set priority?

To begin with, leverage of “Levels” defined in Web Content Accessibility Guidelines 2.1 since they are set as Level A (minimum), Level AA (should be achieved) and Level AAA (maximum level of compliance). This could be first consideration. 

Next consideration should be importance of the feature. This needs to be decided in consultation with business owners. Let’s if issues falls under WCAG’s Level AA but feature is very important and/or frequently used, then it should be flagged as high priority. If an issue falls under WCAG’s Level A but doesn’t really bother user’s usability, then it’s priority can be set to moderate. 

Another consideration should be effort needed to fix. Specially when accessibility practice is new in the organisation, it would be worth to have developers fix easy things first; that gives them an opportunity to taste the benefits of writing accessible code and provide them enough time to understand ways to write accessible code. Getting started with easy things will provide developers a sense of encouragement.  

In conclusion, it’s essential to prioritise Accessibility issues and should be in-line with business priorities. 

Tips for developers: Get your website teted for accessibility – Part 2 – Operable

May 9, 2017 Srinivasu Chakravarthula Leave a Comment Accessibility Testing, Accessibility Tips , , ,

This is Part 2 of 4 parts on how a developer should get their website or application tested for accessibility. Objective of this series is to provide easy method of accessibility testing to developers so that they can test as they code. This is how we would achive accessibility right at the development and design stage. These tips would not only be helpful to developers but also to interaction designers who decides interaction of elements and those who develop prototypes. This Part 2 is related to Operable section of Web Content Accessibility Guidelines 2.1.

Question: How to test for keyboard accessibility?
Answer: Load the page. Press CTRL + Home (Windows), this will take focus to the top of the page. Then use tab key to move from one element to another. Use enter or space key to activate an element. One should be able to activity every element including menus, modals, buttons etc.,

Question: When I was browsing a page with keyboard, focus does not move from an element, focus just gets stuck; is there a problem with my keyboard?
Answer: Probably not, this is called keyboard trap and needs to be avoided. When a component recieves keyboard focus, there should be mechanism to move away keyboard focus from same component.

Question: What to consider when there is a time limit for a page?
Answer: Check if there is an option to turn-off timing, adjust as per user’s requirement or extend the time limit. There could exceptions such as activity at real-time, esential time limit such as a test and time limit of 20 hours and more.

Question: What to look for elements that moves, blinks or scroll?
Answer: There should be a mechanism to pause, stop or hide. If content is being updated automatically, there should be a mechanism to pause or set how periodical that an update should happen.

Question: What is bypass blocks and how do we test?
Answer: Bypass blocks is a mechanism to enable keyboard users to skip representative set of blocks such as navigation and jump quickly to main content. This can be achieved by providing “Skip to main content” link at the top, using appropriate heading structure and/or using ARIA land marks.

Question: How to test page titles?
Answer: Look at top bar of browser window and see if page title does exist and is appropriate. For example Page title should be page name along with the company / domain name. It should not be just company name only on all the pages.

Question: What all needs to be considered as Focus order issues?
Answer: Ensure that the tab order is logical, if an element opens a modal, focus focus must be set to modal and must not move out until user closes the modal, When modal is closed, focus should be returned to the triggered element.

Question: Testing for link purpose
Answer: Ensure that all links have meaningful and spell out the context to the users. Avoid links like “Read more”, “Click here” etc., Using automated tools would be effective to test this requirement.

Question: What are the multiple ways required for a website?
Answer: A search functionality or a site map. There should be more than one way to reach a specific page on the website.

Question: How to test for focus visible?
Answer: When you tab through the page, every element should receive an indicator and you should be able to see where the keyboard focus is. It can be either custom focus indicator or browser’s default focus indicator.

Tip for Developers: Get your website tested for accessibility -Part 1 Perceivable

April 10, 2017 Srinivasu Chakravarthula Leave a Comment Accessibility Testing, Web Accessibility ,

Quite often, I receive emails from non-profit organizations asking if I can help them with accessibility testing for their newly built website. I also see most of them do not get built accessibility in mind though many of them are for organizations who offer services to people with disabilities. This post illustrate a few tips that developers can use while building a website. While we intend to see many developers have knowledge on accessibility, it’s absolutely fine to start with a willingness to build an accessible product. This post illustrates advice in the form of question and answer in reference to Web Content Accessibility Guidelines (WCAG) 2.1. This will be series of four articles to cover Perceivable, Operable, Understandable and Robust.

Question: Do you have images or any other non-text content?
Answer: When you have images, identify if they are informative images decorative images. If informative images, provide an alternate text. For decorative images, provide empty alt text i.e. alt=””; alt attribute must be present in any form of image; if not provided, path of the image gets exposed to assistive technologies such as screen reader, shown on text only browsers (or when images are turned off in the browser), shown to search engines.

Question: Do you have audio-only conent on the website?
Answer: Provide synchronized captions or text transcript

Do you have video only content?
Answer: Provide audio-description

Do you have a live audio / video event happening?
Answer: Ensure there is voice over when only visual actions are happening and captions are provided for audio. This will aid visually impaired users to know what’s visual actions are happening and hearing impaired users to know what the conversation is happening. If there is only music being played, show captions as “Music being played” and if possible what instrument is being played and some illustration.

Question: How my content should be structured and organized?
Answer: Ensure content is structured in a logical order, Headings are marked up appropriately using Hx values e.g. h1, h2 etc., Do not just decorate content as a heading, mark-up list items as ordered or unordered list, ensure all form fields do have associated labels using “for” and “id” attributes, radio buttons and check boxes have associated with their group label.

Question: My user tells me that my content is not read in right sequence, what could be wrong?
Answer: When content is presented in a sequence that is different than usual, it’s essential to ensure sequence of content is meaningful programmatically.

Question: Can I color code the information?
Answer: Yes, color can be used to convey information but color must not be the only form of presenting information. Example, accept is marked as “green” button and decline is marked as “red button”, same labels i.e. accept / decline must be provided as a text in addition to color code.

Question: Can I play audio or music automatically on my web page?
Answer: It’s a not a good practice to play audio automatically on a web page; reason being it would disrupt users with screen readers and people who do not expect an audio on loading of a web page. However, if audio has to played automatically and length is more than 3 seconds, controls must be provided to pause or stop the audio.

Question: How can I check for contrast of colors?
Answer: Simple way is to use Color Contrast Analyzer tools. See the list on Accessibility Testing tools section of Our Resources page

Question: How to meet resize text requirement?
Answer: User browser’s default zoom option (mostly CTRL and +) and zoom up to 200%

Question: Can I use images of text?
Answer: Where possible, it’s advisable to use text to convey the information rather than embedding onto an image.

Question: What’s graphics contrast?
Answer: It’s a new Success Criterion – 1.4.12 Graphics Contrast of WCAG 2.1. If information is conveyed only in the form of graphic e.g. charts etc., it must have minimum contrast ratio of 4.5:1.

Accessibility Automation Testing Tool by PayPal

January 9, 2016 Srinivasu Chakravarthula Leave a Comment Accessibility Testing, Web Accessibility , , , ,

Overview

It’s often true that a quality tester or anyone for that matter would look for robust features and possibly have all features at one place. When it comes to identifying automated tool to check for accessibility of a web interface, some of the questions that would come up with are:

  1. Does this tool be able to test as per standards?
  2. Does this tool be able to cover all segments like use of colors, forms, headings, tables etc.,?
  3. Does this tool be able to generate a report?
  4. Can I be able to export results for my own purpose?

One such tools that was recently open sourced by PayPal is Automated Accessibility Testing Tool [External link].

What is AATT?

AATT tests web applications regarding conformance to the Web Content Accessibility Guidelines (WCAG) 2.0. Find a list of the WCAG 2.0 rules checked on the HTML CodeSniffer WCAG Standard Summary page. AATT provides an accessibility API and custom web application for HTML CodeSniffer. Using the AATT web application, you can configure test server configurations inside the firewall, and test individual pages.

AATT includes HTMLCodeSniffer with Express and PhantomJS, which runs on Node.

For example, it can be used to test Java web applications using SeLion automation test frameworks.

For node applications, it can be integrated into NemoJS testing framework to run accessibility testing during automated unit testing.

Features of AATT

  1. There are two tabs in the interface; one is to test by providing a website address and second is to test by writing code into its editor
  2. Tester can choose if to see screenshots or not to see them. Good part is that it shows the screenshot of the element that has a problem
  3. Tester can configure to display errors, warnings and notices
  4. By clicking on “Test Page” button, an alert is displayed as loading and as the process gets completed, results are displayed in a table format that includes:
    1. Error level – this displays whether one is error, warning or notice
    2. Second column displays name of Principal hyperlinking to its documentation on ‘s documentation
    3. Then displays the description of error / warning / notice
    4. Next column displays the code snippet of the element; this would be very useful for developers to identify where the actual problem is
    5. Second last column displays link to technique from WCAG documentation to resolve the problem
    6. And the last column displays “Screenshot (if selected above)
  5. In the results table, first two columns (error type and Principal) are sortable
  6. Ability to export results as CSV file
  7. If web pages are beyond the firewall and require authentication, one can use “Login” feature and provide Web page address, user name and password so that tool will create a cookie and process the testing

Refer to AATT documentation for instructions for download and setup.

Happy testing!