Depending on your industry, location, and other factors, your company may need to audit for compliance with certain accessibility standards or identify specific product requirements that will be audited for. In addition to the existing international and state standards, there may be many other specific requirements for users with different disabilities, such as limited hearing or color sensitivity.

A subset of screens or pages may be selected for accessibility auditing if your software is very complex. For example, an administrator page with a limited number of internal users may not meet all accessibility criteria. On the other hand, the public product page must always meet all the requirements of the selected guidelines and regulatory standards.

Once you have determined the requirements and regulations that apply to your product and the pages that need to be tested, you must create an accessibility checklist. The accessibility checklist should cover all five major categories of disability: visual, speech, auditory, motor, and cognitive.

Accessibility Tools & Techniques

There is manual and automated accessibility testing. Automated testing is done with a variety of accessibility testing tools that verify application accessibility. These tools vary from platform to platform and should be chosen carefully depending on the needs of the application, budget, and other factors. Manual availability testing is done by people who use the application and check it for defects. At GREY CLOUD SERVICES – FZCO , we have also involved people with disabilities in accessibility testing to test the software because they have the best perspective.

• Manual testing/human testing – Manual execution of a predetermined checklist.
• Testing with assistive technologies – Testing with assistive software, including speech recognition software, screen reading software, screen magnification software, and special keyboards – JAWS, NVDA, ZoomText, and Dragon NaturallySpeaking.
• Web accessibility assessment tool testing – tests performed with automation tools to check CSS, HTML code, and other components.
• Accessibility testing with people with disabilities – Tests performed by a visually impaired QA who performs the entire workflow as an end user of the system and reports on defects.
• Accessibility testing on mobile devices

Accessibility testing helps make mobile apps usable by people of all abilities or disabilities. It ensures that everyone is treated equally. When considering mobile users, don’t limit yourself to blind users.

Other factors need to be considered as well:

• Partial vision (especially when using a small screen)

color blindness

• Dyslexia and other cognitive problems that can affect the readability of the site
• Arthritis and other finger joint motor problems

We use a variety of tools to perform accessibility testing related to visual defects. The actual user testing is done by a person with a disability using assistive technology, after which we analyze the barriers they encounter. Our goal is to improve the user experience and ensure that people with different types of disabilities can use our software. Some of the tools we use include:

Accessibility Scanner

Accessibility Scanner is a tool that offers improvements to app accessibility. Suggestions include: enhancing small touch objects, increasing contrast, and providing content  to make it easier for people with disabilities to use your app.

Screen readers

Screen readers are programs that allow blind and visually impaired people to read computer screen content using voice synthesis or Braille. A screen reader is an interface between the user, the operating system, and its applications.

Gestures

Another approach to mobile accessibility testing is the use of gestures. In our testing, we combine this tool with a screen reader. There are three types of gestures based on user needs: one-finger gestures, two-finger gestures, and three-finger gestures. The main navigations are:

1-Finger Gestures:

• Tap the screen to select items
• Press twice to activate items
• Select the previous or next item by swiping left or right.
• Swipe up or down to navigate and select a rotor option.

2-Finger Gestures:

• Swipe up to read the highlighted area
• Swipe down to read the selected item
• Swipe back and forth to close pop-up windows
• Highlight or deselect.
• Rotate to open the web rotor and select rotor items.

3-Finger Gestures:

• Swipe left or right to move to another screen.
• Swipe up or down to scroll the screen.

Screen Magnifiers

Both Android and iOS include screen magnifiers in their accessibility options. An on-screen magnifier works by magnifying either the entire screen or parts of it. For example, this tool can enlarge form fields, allowing the disabled user to fill them out more easily. Some screen magnifiers can magnify text, icons, and other graphics up to 64 times. They can also magnify and enhance mouse and text cursors to make them easier to see and track, and even sharpen edges, increase contrast, and change colors to make everything easier to see.

Special Keyboards

Using different keyboards, we can test whether the user with motor disabilities can reach all the elements on the screen; focus the item; navigate through different pages and sections, modals, pop-ups, forms and panels; or go directly to the main content. Essentially, it is used to look for problems with missing keyboard indicators and non-focused or non-functioning keyboard controls.

Audit Report: Documenting the Recommendations

The audit report is an important part of accessibility testing. It describes how the website/mobile application meets the required standards. Based on the assessment, it can be determined whether or not the website/mobile application meets or fails to meet the guidelines of the required level.

The World Wide Web Consortium (W3C) requires that the report generated at the end of the audit has the following format:

Executive Summary – A brief overview of the website’s compliance with the accessibility criteria; indicate whether the website meets, fails to meet, or comes close to meeting the requirements.

Scope of review – Indicate the name of the site or application and its purpose, the base URL of the site, the URLs included in the review, the URLs excluded from the review, the exact date of the review, and the natural language used.

Reviewers – Include the names of everyone who reviewed the site, or the name of the organization.

Review process – Identify the target users and set the overall scope. Determine the level for which the review will be conducted, such as WCAG 2.1 level A, AA, or AAA. List the assessment and validation tools used and their versions. Also, include a description of the manual checks used (usability testing of accessibility features).

Results and Recommended Actions – a summary of the review results, detailed results, and points for improvement. Here you should provide information on whether the site/mobile app meets the criteria, what needs to be fixed urgently, and what can be fixed later. Also, based on the guidelines, you should provide details with links to the success criteria, methods for all non-compliant items, and recommendations for fixing the above items.

References – Provide a list of references that have been used for references.

Accessibility Testing Performed by People with a Disability

GREY CLOUD SERVICES – FZCO involves users with disabilities in accessibility testing because they can provide the necessary perspective on the problems they encounter most often. Even non-technical testers can quickly point out problems that experienced quality assurance professionals might miss if they don’t have an understanding of the issues faced by people with disabilities.

At GREY CLOUD SERVICES – FZCO , we have unified our processes to ensure that both QA and non-technical testers have the same understanding of what availability testing is and how it is done. We provided them with theoretical and practical knowledge of how we test, track defects, and create reports for our customers.

Our colleagues with disabilities demonstrated how they navigate through various Web sites while observing the process, which helped us incorporate new methods into our testing. We used two approaches: first, the visually impaired person tested a site they were unfamiliar with, and then tested a site about which they had detailed information (pages and items on them).

Each method provided different benefits.

When testing unfamiliar sites, one can quickly see how user-friendly it is and whether the test taker can complete any task without prompting, relying only on the screen reader. With this approach, many missed problems, inaccuracies in the page structure, and improper navigation can be identified. We also ask test-takers to “think out loud” and describe what they are doing during the task. This might go something like, “I’m trying to navigate to the Careers link using the keyboard, but the order of the tabs seems wrong.” The researcher will observe and ask questions to see if the interface meets their expectations and where they are having difficulty. They might ask, “You mentioned that the tab order seems wrong; what did you expect?” The benefits of this approach include getting the opinions of real people with disabilities, getting fresh opinions, getting the opinions of non-technical people (if you’re recruiting specifically for this), and getting an unbiased opinion.

On the other hand, when testing a Web site, knowing what it should contain, you may find that some parts of the system are simply inaccessible to people with visual impairments, and others are difficult to navigate. In addition to discovering the many hidden accessibility defects, a blind tester can provide clearer suggestions for improvement and clearer explanations of why certain problems are preventing customers from using your site or application.

This two-way learning process allows QA professionals to gain a much deeper understanding of accessibility testing by learning new techniques that we now incorporate into our training sessions. In addition, our colleagues with disabilities have greatly improved their testing skills by learning QA’s defect tracking and reporting procedures.

Training Non-Technical Testers: How to Report Defects?

The first challenge for anyone who is not a QA is understanding the processes and methods used for testing and reporting defects. This may require several training sessions that provide both theoretical and hands-on training to new test takers with disabilities.

One of the challenges we faced was to teach our colleagues exactly how to report defects found – not just describing them in plain text, but following a certain structure with clear and concise explanations of the problem and how to fix it. In addition, it is important for all testers to make suggestions for improvement and describe exactly what impact the bugs had on their user experience.

Our initial training project had so many accessibility issues that our colleagues with visual impairments could not access much of the system. This led to the idea of creating a document describing the content of each page so they could better understand the platform. When using Excel or Google Sheets for defect tracking, we also recommend documenting keyboard shortcuts for testers to make these documents easier to navigate.

Adding these unique viewpoints has been invaluable to our testing team. Without them, we wouldn’t have the understanding and skills needed to conduct thorough accessibility testing and improve our products for all users.

Conclusion

Accessibility testing is crucial for companies because not only does it make their sites accessible to more users, but it can also have some legal implications if not done correctly. For example, a person with a disability can sue a company if its site does not provide equal access and use of its features. In recent years, there has been an increase in the number of such lawsuits over website accessibility. A lawsuit of this nature can result in reputational damage and financial loss to the company, regardless of the outcome.