Select Page

Category Selected: Accessibility Testing

12 results Found


People also read

API Testing

Postman API Automation Testing Tutorial

Automation Testing

Top 10 AI Automation Testing Tools

Automation Testing

Talk to our Experts

Amazing clients who
trust us


poloatto
ABB
polaris
ooredo
stryker
mobility
The Definitive Mobile App Accessibility Testing Checklist for Android & iOS

The Definitive Mobile App Accessibility Testing Checklist for Android & iOS

As mobile phones are the most commonly used gadget in the global space, it is highly important to ensure that it is accessible to everyone. According to a CDC estimate, one in four adult Americans has some form of disability. In today’s modern age where smartphones and mobile apps are an essential part of daily life for many, mobile app accessibility testing has definitely become the need of the hour. As a leading accessibility testing company, we have years of experience in testing both Android & iOS apps for their accessibility. With that experience, we have created this definitive Mobile App Accessibility Testing Checklist that will ensure your mobile apps are accessible.

Mobile App Accessibility Testing Checklist

There are so many aspects of a mobile application that has to be tested to ensure it is accessible to people with disabilities. At its core, we can use the POUR principle to check if the mobile app and its features are

  • Perceivable: Check if information and user interface elements are presented in a way that users can perceive them with ease.
  • Operable: Make sure the mobile app’s navigation is used so that it enables easy user interaction.
  • Understandable: Ensure that the information and user interface functionality is understandable.
  • Robust: Test if the mobile app’s features & functionalities are robust so that they can be reliably interpreted by a wide range of user agents, including users using assistive technology such as screen readers.

But the problem with such a mobile app accessibility testing checklist is that it does not cover the intricate actions that have to be done to ensure your mobile app is accessible. That is why we have created a categorized mobile app accessibility testing checklist that will provide you with definitive actions you’ll need to do in an organized manner.

Categorized Mobile App Accessibility Testing Checklist

Mobile App Accessibility Testing Checklist

By keeping POUR at the core, we have created this categorized mobile app accessibility testing checklist to make it easy for you to understand and navigate through our blog.

  • User Interaction
  • Navigation
  • Notifications
  • Form Labels & Validation
  • Toggle Button
  • Tables & Accordion
  • Text & Color Contrast
  • Images
  • Audio & Video
  • Animation & Motion

1. User Interaction

Accidental touches in any mobile app can be annoying to any user. But what could be just annoying to regular users can have serious impacts when used by people with disabilities. Such issues can worsen the user experience for all users in general. One such way to improve the user experience is by following this Mobile App Accessibility Testing Checklist that will ensure users have no issues with user interaction.

  • Check if the click or touch target size is large enough for the user to touch their intended target without any difficulties. Also, make sure that the touch targets do not overlap.
  • Even if there are any compact touch targets, ensure they are not placed adjacent to each other to avoid accidental touches.
  • If multiple active elements have the same target, make sure those elements are grouped into a one-touch target.
  • Ensure that the application doesn’t rely on kinetic motion (detected by the accelerometer) alone for inputs.
  • Verify if the motion-sensitive features can be disabled by the users.
  • Make sure the mobile application is not completely or too dependent on voice control or on gestures as it could limit usability in some cases.
  • Check if the autocomplete suggestions are announced to the users when they appear and also validate if they are operable.

2. Navigation

Now that we have looked at the user interaction, let’s cover the navigational aspects in our Mobile App Accessibility Testing Checklist as it is a very common issue faced by many.

  • Ensure that the mobile app screens have meaningful titles and tabs that convey their role, their current state, and their order in the total number of tabs to the screen reader.
  • Verify if the buttons accurately convey to users their accessible name, role, value, and state through the respective screen reader.
  • Check if a button or an active image used as a button conveys their correct trait or role.
  • Make sure the role and purpose of a hyperlink are clearly specified in the anchor text as generic texts like ‘Click Here’ will confuse a user using TalkBack/VoiceOver.
  • Check if the progress bars convey their visible name, role, and current value to TalkBack/ VoiceOver users with a descriptive and unique accessibility label.
  • Verify if the slider controls and switch controls have a visible label that is programmatically associated using the accessibility label property.
  • Verify if the button that opens the menu has a clear and descriptive title or must have an accessibility label that accurately conveys its purpose.
  • Test if users using screenreaders are able to dismiss the menu and when they do so; check if the focus returns to the triggering button correctly.

3. Notifications

The most important function of a mobile app notification is to grab the attention of the device user. But how can we make these notifications accessible for people with various disabilities? We can ensure these notifications are designed with actual mechanisms including visual, auditory, and vibration cues. Here are the checkpoints you’ll have to follow to achieve that.

  • Test whether the dynamic content changes are notified to Talkback/ VoiceOver users through spoken accessibility announcements or focus management.
  • Ensure that the user login session doesn’t timeout without providing any accessible timeout warning or a session extension method.
  • Verify whether all alerts include a title and a description and that are announced through Talkback/VoiceOver or if they grab the user’s attention.
  • Validate if the Modal dialogs capture the focus of the screen reader and trap the keyboard. Make sure the presented dialogs are given focus until dismissed by the user.

Notification Checklist in Mobile App Accessibility Testing

4. Form Labels & Validation

Form labels and Validation are especially important in making a mobile app accessible as it ensures the users are able to easily provide their input when needed. They are generally read by a screen reader and the form fields also receive focus whenever it requires user inputs. So next up in our mobile app accessibility testing checklist, we’ll be covering what aspects you’ll have to check to ensure disabled users can use their assistive technologies to full effect.

Form Labels and Validations

  • Ensure that the native date picker controls which are exclusive to android are used over plain text inputs or custom date picker controls.
  • Test if controls using UIPickerView which is exclusive to iOS are programmatically connected with their visible label.
  • If there are any inputs that require a star rating or any rating in general, ensure they have accessible names that be conveyed to the end user.
  • Ensure that the label text is visible to the end-users at all times and they are programmatically associated with their corresponding control elements.
  • Check whether the groups of related inputs convey their group legend text to the TalkBack/VoiceOver users.
  • Validate if the radio buttons convey their individual label, group legend, and checked state to the end-users.
  • Check if the Select dropdown controls have an associated visible text label.
  • Ensure that the users receive effective, understandable, and properly labeled text-based notifications for form validation signals and errors.

5. Text & Color Contrast

Sometimes the text color, contrast, and size can make it hard for people with visual impairments to read. So in our mobile app accessibility testing checklist, we’ve listed all the major points you’ll need to cover in this regard.

  • Test if sections of content whose language is different from the mobile app’s default language are programmatically identified and marked in a way that allows assistive technology to find them.
  • If any information is conveyed through color or a change in color, ensure it is accompanied by a programmatically-discernible text alternative.
  • Check if the contrast ratio for small text is at least 4.5 to 1 with the background and if the contrast ratio of large text is at least 3 to 1 with the background.
  • When text or images are used to replace color to convey information, make sure it correctly conveys the same information.

6. Toggle Button

Understanding the state of toggle buttons can be very tricky for people with disabilities. Since toggle buttons are commonly used in numerous mobile apps you’ll have to follow the below-mentioned actions.

  • Ensure the state of the toggle button is conveyed to the end user.
  • Make sure that the toggle button conveys an accessible name with programmatically associated and visible labels that convey their state.
  • Check if the image toggle buttons have descriptive and accurate alternative text provided in the accessibility label.

7. Tables & Accordion

Though we may not see many tables and accordions, few mobile apps might actually use them or different forms of them in a feature. Without the right tests, understanding tables can truly become a huge challenge, especially when using assistive technologies such as screen readers. So let’s look at the checkpoints you’ll need in our mobile app accessibility testing checklist.

  • Test if the screen reader is able to read the accessible names of the accordion components.
  • Make sure the screen reader announces if the component is in the expanded or collapsed state.
  • Check if the data in the tables are in a logical reading order and if the screen reader is announcing the correct row and column header text to the users.
  • Verify if the sorted state of a sortable table column header is conveyed to the users.

8. Images

Thanks to fast internet speeds on mobile data, almost every mobile app today uses images. So images are the next focus area in our mobile app accessibility testing checklist where we tell you how you can use alt text correctly.

  • Test if images that convey valuable information have an accessibility label or appropriate alternative text that describes the image or presents the same information as the image.
  • But if there are any decorative or redundant images in the mobile app, make sure that such images don’t have any alternative text equivalents as they should be hidden from the screen readers.
  • Make sure images of text are not used as they should not be used if the same output can be achieved using real text. Logos with the company name are examples of when images can replace text.
  • Test if the image button controls have a proper content description.
  • If your mobile app uses custom emojis, check if they have appropriate alternative text.

9. Audio & Video

Few mobile apps might use audio & videos or few apps might be used exclusively to stream video or audio over the internet or playback the files in the internal storage system. So based on the use case, make sure to follow the specified actions to ensure they are accessible.

  • Test if all the pre-recorded multimedia content (Videos & Audio) and narration events that contain dialog and/or narration must be accompanied by synchronized captions.
  • Likewise, check if videos have audio descriptions or separate audio-described versions for users who have vision disabilities.
  • Make sure all prerecorded videos and audio used in the mobile app have text transcripts.
  • Verify if the SeekBar sliders have TextView labels.
  • If the mobile app uses any sound effect used to convey the success or failure of a process, make sure there are alternative ways to convey the same information.

10. Animations and Motion

Every mobile application will have a certain number of animations and motions to make it visually appealing to its users. But these can also be a challenge for users with seizures as sudden & continuous flashes of light might be a trigger. Here are some of the ways you can achieve your goal.

  • If there is a Carousel of multimedia content, check if there is a way to stop the Carousel’s movement.
  • Validate if the users are able to disable any non-essential motion-sensitive visual effects.
  • Make sure that the content doesn’t flash more than three times a second and that it doesn’t violate the general flash thresholds as it could affect people with seizures.
  • Ensure that the progress spinners or other similar loading effects have proper alternative text to ensure the information is conveyed.
  • Likewise, test if they immediately receive focus so that the screen reader can announce their accessible name to the users.

Conclusion

We hope this Mobile App accessibility testing checklist walked you through the key components, such as general objectives, necessary testing procedures, suggested testing, and unique considerations to build a mobile app with all the necessary accessibility features. Apart from enabling the mobile app to be accessible to people with disabilities, such type of testing will also enhance the overall user experience of regular users.

Another aspect that makes it a win-win situation is that you can steer clear of any legal trouble by ensuring your mobile app is accessible. Based on the location you operate your mobile app or website, there are legal grounds for people to sue you if the products are inaccessible. Over the years we have delivered top-notch accessibility testing services for testing websites, e-learning platforms, mobile apps, and so on for our customers who have truly benefited from creating accessible products and services.

Understanding Success Criterion 2.5.2 Pointer Cancellation

Understanding Success Criterion 2.5.2 Pointer Cancellation

Wrong clicks and incorrect touches can be annoying to any user. But what could be just annoying to regular users can have serious impacts when used by people with disabilities as such issues could render the product unusable. That is why WCAG introduced the Success Criterion 2.5.2 for Pointer Cancellation in WCAG 2.1. Understanding Success Criterion 2.5.2 Pointer Cancellation is very important as it has to be fulfilled to achieve Level A compliance. So in this blog, we will be exploring the different conditions that have to be satisfied and get to know the exceptions by using examples. But before that, let’s take a deeper look at why Pointer Cancellation is very important for people with disabilities.

UNDERSTANDING SUCCESS CRITERION 2.5.2 POINTER CANCELLATION

The 2.5.2 Pointer Cancellation success criterion belongs to the 2.5 guidelines of WCAG 2.1 that deals with input modalities for making it easier for people with disabilities to use more input methods other than the keyboard. Visually challenged people might use a braille keyboard and be unable to use a mouse or touch input devices. But people with other disabilities such as hearing loss or even color blindness will be able to use a mouse or provide touch inputs as well. But the primary focus of the 2.5.2 Pointer Cancellation success criterion is to help people with motor-based impairments and cognitive disabilities as they are prone to making more mistakes.

Pointer Cancellation can be compared to the undo button that is present in most applications. For example, if we accidentally delete all the selected text in Microsoft Word or Google Docs, we would just hit the undo button and fix the issue. But it is not that simple when it comes to using the web as people might be taking an important online test or making a purchase and so on. So WCAG has given 3 options for us to choose from as the 2.5.2 Pointer Cancellation success criteria will be satisfied even if one of the 3 conditions is met.

The 3 Conditions in 2.5.2 Pointer Cancellation

Before we move forward in our effort to understand the 2.5.2 Pointer Cancellation success criterion, we’ll have to know what Up and Down events are. If we were to take the mouse as an example, the down event is the process of pressing the button down, and the up event is the process of releasing the pressed button. The same applies to touch-enabled devices as well where touching a part of the screen is the down-event and releasing your hand is the up-event.

For example, let’s say there is a button to mute the audio output. You can observe in the illustration that the audio will not be muted when the button is pressed down (Down-Event) and that the functionality will be carried out when the button is released (Up-Event).

Comparing Down Event and Up Event - 2.5.2 Pointer Cancellation

No-Down-event

One of the best ways to achieve pointer cancellation is by ensuring that the function is not carried out with the down-event completion alone. So if you are holding the mouse button down, the action should be completed only when you let it go (When the up-event happens). By doing so, there will be an option to abort or even reverse the click when the up-event happens.

The Exception

But there are a few exceptions when it comes to the 2.5.2 Pointer Cancellation success criterion as not all functionalities can be developed in a way that prevents a no-down-event. Let’s take an example of a piano application where a key press or touch input will mimic the action of the keys of a piano getting pressed. Such a scenario can be an exception as there might be a need for two or more keys to be pressed simultaneously to produce a particular sound. In addition to that, the duration of the key press will also determine how long the sound will be actively produced.

Up-event abort or Undo

So if ensuring that the down press does not affect functionality until the key is released, the next step would be to define a target area around the click. By doing so, we can enable users to move out of the target area if they have clicked incorrectly and then perform the up-event to either abort the operation or undo it.

Example

The drag and drop feature is a very great example as there will be a target area from where the file is being dragged to where it is being dropped and if at all the user has dragged the wrong file, then they can just undo their action by dropping the item outside the target area. Even if it is not a drag-and-drop feature, the users must be able to just move away from the target area before performing the up-event to abort the down-event.

Up Reversal

This is also similar to the up-event abort or undo function we have seen thus far in terms of the 2.5.2 Pointer Cancellation success criterion. But it serves a different purpose instead of aborting or undoing an action. It can be used for functions that use press and hold actions. So it will only hold the effect of a down-event until the up-event is performed.

Example:

Activating or viewing a pop-up is a great example of a press-and-hold action. If a user clicks on a pop-up or a pop-up video the down-event will ensure that the pop-up stays open or active until the up-event is performed. It will revert back to the state it was in before the down-event.

A Quick Tip

Even if we follow such conditions, users are prone to make mistakes by performing both the down and up events quickly unaware that they have made a mistake. So if you are working on pages that don’t support the back button such as payment gateways, online examination submissions, and so on, it is always better to use a confirmation pop-up.

Example:

If we take an online examination itself as an example, the submit button shouldn’t work on a single click as an incorrect click might end the exam for the participants abruptly. So a pop-up that confirms if the user is ready to submit their answers and end the examination should be mandatory to ensure incorrect outcomes.

Conclusion

We hope you have clearly understood Success Criterion 2.5.2 Pointer Cancellation by now and will be able to implement your gained knowledge while testing a product. As one of the leading accessibility testing services providers in the industry, we are experts when it comes to testing in accordance with WCAG’s success criteria. We will continue to share more informative content and recommend you subscribe to our newsletter to keep yourself updated on software testing.

How to receive a $5000 Tax Credit for your Website’s Accessibility?

How to receive a $5000 Tax Credit for your Website’s Accessibility?

If you have made some significant investments in your business and haven’t already begun working on your website accessibility, these tax breaks may just be what you need right now. We all would be aware of the tax credits that help us with the costs incurred towards aiding accessibility like hiring a sign language interpreter for an event or a wheelchair ramp, etc. Likewise, there is a tax credit in the United States for having an accessible website as well. So in this blog, we will be seeing how you can avail the website accessibility tax credit and discuss the various additional advantages you can benefit from by having an accessible website. Apart from the many advantages, creating a barrier-free digital experience without any website accessibility challenges for all the people with disabilities is a much-appreciated initiative.

Website Accessibility Tax Credit

According to an article cited by Forbes, 71% of website users with disabilities will leave the site immediately if the site is not accessible and search for one that is more user-friendly. The major issue here is that it will shoot the bounce rate up and harm your organic rankings. So even after doing all the hard work to reach a valid user, you will miss out on reaping the benefits. So, it is very clear that having an accessible website has lots of benefits and one of them is the tax credit.

The website accessibility tax credit is primarily intended to encourage businesses to make their websites accessible by compensating the costs incurred in doing so. Under the IRS Code Section 44, Disabled Access Credit, companies who make changes to make their business accessible to people with disabilities are eligible for a $5,000 tax credit. Since your website is also seen as a part of your business, having an accessible website will make you eligible for the web accessibility tax credit.

How to Apply for the Website Accessibility Tax Credit

  • To be eligible for the website accessibility tax credit, your company must have annual revenues of less than $1 million and have less than 30 full-time workers.
  • If eligible, the businesses may apply for the tax credit via the IRS 8826 form.
  • A tax of 50% is eligible for businesses whose list of eligible expenditures exceeds $250 but does not exceed $10,250 for a taxable year.

Note: These website accessibility tax credits are different from the tax deductions. They will be applied after the tax is determined, and the credit will be removed directly from the tax owed.

Additional Benefits of Website Accessibility

While website accessibility is a vital aim for encouraging more people to utilize the internet, it also has a direct influence on a company’s digital success. So let’s explore the additional benefits apart from the website accessibility tax credit that an accessible website can offer.

Enhanced Usability

The purpose of accessibility is to ensure access to information for individuals with disabilities and enable them to use the web services like everyone. But it also increases the usability of your website for all users and makes it easier for mobile phone users & old age users to view your content. Since the number of mobile phone users on the internet is on the rise, this is a key benefit that you shouldn’t miss out on. Although it is not possible to design a website that’s accessible to all, a few common modifications can go a long way in reaching a wider audience.

SEO Booster

Accessibility enablers like a proper heading structure, alt text, closed captions, and video transcripts are also effective SEO boosters that can help in the organic reach and ranking of your website and its content. Apart from that, the decrease in bounce rate that we discussed earlier will also improve the SEO health of your website.

Building a Positive PR

Positive PR can go a long way in helping boost your visibility. The value of your brand is impacted by the values and beliefs you stand for. Since web accessibility is universally agreed upon to be a necessity, projecting your brand’s efforts in ensuring that the disabled people’s right to information is fulfilled will definitely be a boom.

Higher Quality Code

Developing a site that is accessible is comparatively easier than making a site accessible due to various reasons. So if you are creating a website with the intent of making it accessible, you will observe that the code is cleaner and of higher quality. So the end result will be the reduction of bugs, better performance, and overall better usability.

But what if your Website isn’t Accessible?

Apart from helping a business attain digital visibility, success, and the website accessibility tax credit, accessible websites also protect it from legal issues. The number of website accessibility lawsuits is rapidly increasing with high-profile companies such as Netflix and Dominos facing such litigations. The rise of awareness with regards to website accessibility could be a major contributor to such litigations. So companies looking to stay away from any kind of discrimination accusations and legal actions should seek to incorporate online accessibility standards such as the Web Content Accessibility Guidelines (WCAG). They can also receive a Letter of Reasonable Accessibility attesting to the fact that their website has been audited and reasonable modifications have been made to help the individuals with disabilities.

Website Accessibility Challenges

Though you can perform basic checks from your end, it is always recommended to hand it over to the experts by approaching a web accessibility testing company as there are numerous challenges. It will also not be enough to make your site comply with the WCAG conformance levels and help you stay safe from legal actions. Even the smallest of accessibility issues can become obstacles that make it difficult or even impossible for impaired users to access, navigate, or interact with your website’s content. So here’s a list of the most common web accessibility challenges one can face.

  • The size and nature of the website are factors as it will be hard to implement accessibility in large and dynamic websites.
  • The scope for automation in accessibility testing is very minimal and so it would require a lot of manual effort.
  • The testers performing the accessibility testing should be well-versed with all the WCAG standards to be effective.
  • Performing accessibility testing is also very different from the other types of software testing because of the guidelines we have to adhere to. So there is a lack of good accessibility testers who can look past the guidelines and test with the user experience of the people with disabilities in mind.
  • Not all disabilities are covered under WCAG or have the required aids to overcome the limitations.
  • Despite the presence of WCAG, there are different accessibility laws around the world and you would have to comply with those as well.

Conclusion

The most obvious benefit of having an accessible website is that it helps people with disabilities enjoy the digital experience just like everyone else. But web accessibility doesn’t limit itself to just that, it also serves as a source for the $5,000 website accessibility tax credit, improves the SEO, enhances the overall usability, and so on. If you’re worried about how you’ll be able to attain the required compliance on your own, you could always reach out to an established web accessibility testing services provider such as us to attain the required accessibility compliance without having to burn a hole in your pocket. Our team of experienced accessibility testers here at Codoid is ready to help. We are passionate about making your website as accessible as possible to all users!

How to do Accessibility Testing? A Complete Guide

How to do Accessibility Testing? A Complete Guide

As of 2022, the internet has a whopping 4.95 billion users on a global level (i.e) 62.5% of the entire global population is on the internet. There are various reasons for us to believe that the internet is one of the best innovations of this century as it has reshaped the course of our lives by providing us with access to information at our fingertips. But the question to be asked here is if this access is universal to all of us. Truth be told, no. There are about 1 Billion people with at least one form of disability. Web accessibility is the way to ensure that the basic right to information is fulfilled for the 1 billion people, and accessibility testing is the key to ensuring it.

Accessibility testing is definitely very different from regular testing types. Its unique nature might even instill fear in various testers to even try to learn about accessibility testing. Being a leading web-accessibility testing service provider, we have years of experience in this domain. Our dedicated team of testers has mastered the accessibility testing process to not only comply with the various guidelines but to also ensure access and a great user experience for people with disabilities. So in this blog, we will be extensively covering the concepts you will need to know to perform accessibility testing, how web accessibility is measured, the various steps involved in accessibility testing, and much more. Before we head to all that, let’s first clear the air from any and all misconceptions by debunking the myths surrounding accessibility testing.

Accessibility Laws Around the World

S. No COUNTRY / REGION LAW NAME YEAR OF IMPLEMENTATION SCOPE WCAG VERSION
1 AUSTRALIA Disability Discrimination Act 1992 1992 Public Sector, Private Sector WCAG 2.0
2 CANADA Canadian Human Rights Act 1985 Public Sector, Private Sector WCAG 2.0
3 CHINA Law On The Protection Of Persons With Disabilities 1990 2008 Public Sector, Private Sector None
4 DENMARK Agreement On The Use Of Open Standards For Software In The Public Sector, October 2007 (Danish) 2007 Public Sector WCAG 2.0
5 EUROPEAN Web And Mobile Accessibility Directive 2016 Public Sector WCAG 2.0
6 FINLAND Act On Electronic Services And Communication In The Public Sector 2003 Government None
7 FRANCE ” Law N° 2005-102 Of February 11, 2005 For Equal Rights And Opportunities, Participation And Citizenship Of People With Disabilities (French)” 2005 Public Sector None
8 GERMANY Act On Equal Opportunities For Persons With Disabilities (Disability Equality Act – BGG) (German 2002 Public Sector, Private Sector None
9 HONG KONG(HKSAR) Guidelines On Dissemination Of Information Through Government Websites 1999 Government WCAG 2.0
10 INDIA Rights Of Persons With Disabilities Act, 2016 (RPD) 2016 Public Sector, Private Sector None
11 IRELAND The Disability Act, 2005 2005 Public Sector WCAG 2.0
12 ISRAEL Equal Rights Of Persons With Disabilities Act, As Amended 1998 Public Sector, Private Sector WCAG 2.0
13 ITALY Law 9 January 2004, N. 4 “Provisions To Facilitate The Access Of Disabled People To IT Tools” (Stanca Law) (Italian) 2004 Public Sector, Government WCAG 2.0
14 JAPAN Basic Act On The Formation Of An Advanced Information And Telecommunications Network Society 2000 Public Sector, Private Sector None
15 NETHERLANDS Procurement Act 2012 (Dutch) 2016 Government WCAG 2.0
16 NORWAY “Regulations On Universal Design Of Information And Communication Technology (ICT) Solutions (Norwegian)” 2013 Public Sector, Private Sector WCAG 2.0
17 REPUBLIC OF KOREA Act On Prohibition Of Discrimination Against Persons With Disabilities And Remedy For Rights, Etc. (Korean) 2008 Public Sector, Private Sector WCAG 2.0
18 SWEDEN Discrimination Act (2008:567) 2008 Public Sector, Private Sector None
19 SWITERZLAND Federal Law On The Elimination Of Inequalities Affecting People With Disabilities (French) 2002 Public Sector, Private Sector WCAG 2.0
20 TAIWAN Website Accessibility Guidelines Version 2.0 (Chinese (Zhōngwén), Chinese, Chinese) 2017 Public Sector WCAG 2.0
21 UNITED KINGDOM Equality Act 2010 2010 Public Sector, Private Sector WCAG 2.0
22 UNITED STATES Section 508 Of The US Rehabilitation Act Of 1973, As Amended 1998 Government WCAG 2.0

Accessibility Metrics: How is Web Accessibility Measured?

Though there are different laws that are followed around the world, a majority of them are based on WCAG (Web Content Accessibility Guidelines). W3C (World Wide Web Consortium) developed WCAG and published it for the first time in 1999 in an effort to ensure accessibility on the internet. When it comes to accessibility metrics, web accessibility can be measured using three conformance levels, namely Level A, Level AA, and Level AAA. These 3 WCAG Compliance Levels have numerous success criteria that ensure accessibility to people with various disabilities.

Understanding the 3 WCAG Compliance Levels:

WCAG has developed these compliance levels with 4 primary guiding principles in mind. These 4 aspects are commonly referred to with the acronym POUR.

  • Perceivable
  • Operable
  • Understandable
  • Robust

The perceivable, operable, and understandable principles are pretty self-explanatory as every user should be able to perceive the content, operate or navigate through it, and understand it as well. Robust is focused on ensuring that they can do all the 3 in various devices to decrease numerous limitations. WCAG was first introduced in 1999 and has been going through constant upgrades by adding success criteria to meet the various accessibility needs. The most recent version of WCAG is WCAG 2.1 which was officially released in June 2018.

The 3 WCAG compliance levels are built around these guiding principles. Each level of compliance is built around the previous level. To put it in simple terms, If you have to attain level AAA compliance, you should satisfy all the success criteria from the AA compliance level. Likewise, if you wish to comply with AA level compliance, you should have satisfied all the success criteria of level A. So level A compliance is the most basic of the 3 available WCAG compliance levels. Since there are also no partial WCAG compliance levels, even if your website doesn’t satisfy one of the required success criteria, it will be termed non-compliant.

Level A Compliance: Minimum Level

Level A is the most basic level of accessibility that every website should aim to comply with. It solves the primal problem of people with disabilities finding your website unusable. Since each compliance level is built around its preceding levels, level A compliance lays the foundation for everything. Now let’s take a look at the 30 success criteria at this level.

Level A Compliance Minimum Level

If you are very new to accessibility, you may not be able to comprehend everything mentioned in the list. But this level of compliance ensures that people with visual impairments will be able to use screen readers effectively with the help of proper page structure and media alternatives such as alt-text for images, subtitles for videos, and so on. But it definitely doesn’t solve all the problems. So let’s see what level AA compliance has to offer.

Level AA Compliance: Acceptable Level

If level A is the bare basics, then Level AA is the Acceptance level of compliance a website can look to achieve to enhance the user experience for disabled people. In addition to the 30 success criteria that have to be met in level A compliance, an additional 20 success criteria also have to be satisfied. Of the 50 total success criteria at level AA, let’s take a look at the success criteria exclusive to this level in a categorized way.

Level AA Compliance Acceptable Level

We can see the additional focus on notable aspects like color contrast levels, well-defined roles and labels in form labels, status messages, and so on.

Level AAA Compliance: Optimal Level

Level AAA is the highest level of accessibility compliance that has an additional 28 success criteria that have to be satisfied. So the grand total of success criteria to be met for this level of compliance is 78 as of writing this blog. It is also the most difficult level of compliance to attain. Though achieving this level of compliance is hard, it has to be done if you are looking to build a specialist site for accessibility. Here is a list of the 28 success criteria that are exclusive to level AAA.

Level AAA Compliance Optimal Level

The level of difficulty in each of these success criteria is definitely high. For example, if you have a pre-recorded audio or video on your site, it definitely has to have sign language support. Since live videos are very uncommon on websites, the amount of work needed to achieve this is high. There are also focus areas such as mentioning the expanded form of abbreviations, providing context-sensitive help, and so on.

Which Disabilities Are Supported by WCAG?

Though there are numerous types of disabilities, not all disabilities are covered under the Web Content Accessibility Guidelines. Though there are new guidelines being added over time, as of now WCAG supports visual impairments, auditory disabilities, cognitive disabilities, and motor disabilities. The support is provided due to assistive technologies such as

  • Screenreaders
  • Braille Displays
  • Text-to-speech systems
  • Magnifiers
  • Talking Devices
  • Captioning

ARIA

Out of these assistive technologies, screen readers are the most used and so understanding what ARIA is and how it is used is an integral part of accessibility testing.

What is ARIA?

ARIA expanded as Accessible Rich Internet Applications, is a set of attributes that can be added to the HTML for developing more accessible web content applications. It is a W3C specification that fills in the gaps and makes up for the accessibility voids in regular HTML. It can be used to

  • Help Screen readers and other assistive technologies perform better by improving the accessibility of interactive web elements.
  • Enhances the Page Structure by defining helpful landmarks.
  • Improves keyboard accessibility & interactivity.

Now let’s find out how ARIA improves accessibility by taking a look at the most commonly used ARIA attributes with the help of an example.

The most commonly used aria attributes:-

  • 1. aria-checked.
  • 2. Aria-disabled.
  • 3. aria-expanded.
  • 4. aria-haspopup.
  • 5. Aria-hidden
  • 6. Aria-labelledby
  • 7. Aria-describedby
ARIA Attribute Example: Aria-checked

The aria-checked attribute can be used to denote the current state of checkboxes and radio buttons. So it will be able to indicate whether an element is checked or unchecked by using true and false statements. You can use JavaScript to ensure that the ARIA’s state changes when it is checked or unchecked.

ARIA Attribute Example, Aria Checked - Accessibility Testing

  • aria-checked=”true” indicates the element is checked.
  • aria-checked=”false” indicates the element is in an unchecked state.
  • aria-checked=”mixed” indicates partial check for elements that have tri-states

As the name of all the other commonly used attributes suggests, they can be used to indicate if a list is expanded, if there is a pop-up, and so on.

Web-Accessibility Testing Tutorial

Accessibility testing is very much different from the regular types of software testing and might seem daunting to many. As seen in the ‘How Accessibility is Measured’ section, there are 3 different WCAG compliance levels. So we will now be focusing on the various success criteria from the A-level compliance. To make it even easier for you to perform these tests, we have broken down the entire accessibility testing process based on the different web elements and content types we will generally add to a website. Once we have covered all that, we will then explore how to ensure general accessibility.

Page Title

The page title is one of the most basic properties of a web page that helps us differentiate the numerous webpages that appear in the search results on Google or when multiple webpages are opened in a browser. We will easily be able to see and identify the difference. But if you’re using a screen reader, it will not read out the domain name. And if the Page Titles are similar, it’ll become hard for the user to know the difference. So make sure to test if the titles clearly convey what the webpage is about.

Best Practice:
<html>
<head>
<title>How to do accessibility testing</title>
</head>
</html>
Bad Practice:
<html>
<head>...</head>
 <body>...</body>
</html>
Places to Check:
  • Browser Tab.
  • Search Engine results page.
  • Bookmarks.
  • Title of other pages within the same website. (Eg. Blog Articles)

Structure check

Now that we have seen how the title can impact a disabled person’s usability, let’s shift to the structure of the webpage. A complicated structure can confuse even a regular end-user. So using a well-planned and clean structure will make it easier for regular users to scan through and read your content while making it accessible for people with cognitive and visual disabilities.

Checklist:
  • 1. Check if the page has a defined header and footer.
  • 2. Validate the main landmark and the complementary landmarks by navigating to specific sections.
  • 3. Test the flow of the Heading structure.
  • 4. If there are numbered lists, bullet lists, or tables, check if they are read properly by the screenreader.
  • 5. Test if the bypass blocks work using a screen reader.
  • 6. Check if the webpage is coded with human-readable language that can be programmatically determined by assistive technologies.
  • 7. Check if the basic structural elements like sections, paragraphs, quotes(blackquotes), etc. have been defined properly.
  • 8. Check for hyperlinks on the page and ensure that the anchor text is descriptive enough to convey the change of context to the user.

Headings

Headings in a webpage are very crucial as it outlines the main content of the page and helps convey which parts are important. So if your webpage has more than 1 Heading 1, doesn’t have any headings, or doesn’t follow a proper hierarchy, it will definitely cause confusion. That is why the heading structure flow is recommended to go from H1 to H6 even though it is not mandatory.

Best Practice:
*Heading level 1<h1>
    *Heading level 2<h2>
        *Heading level3<h3>
           *Heading level4<h4>
              *Heading level5<h5>
                 *Heading level6<h6>
        *Heading level3<h3>
           *Heading level4<h4>
              *Heading level5<h5>
                 *Heading level6<h6>
    *Heading level 2<h2>
       *Heading level3<h3>
          *Heading level4<h4>
Bad Practice:
   *Heading level 1<h1>
      *Heading level 2<h2>
         *Heading level3<h3>
            *Heading level 1<h1>
               *Heading level 4<h4>
                  *Heading level5<h5>

Tables

Tables are used to present the data in an organized way and in logical order. The table should have a table header, the table header should be marked up with ‘th’. And the data inside the cells should be marked up with ‘td’. If there are any highly complex tables, check if the scope header and id have been provided.

Good Practice:
<table>
 <tr>
  <th>Types of Disabilities</th>
  <th>Description</th>
</tr>
<tr>
<td>Vision</td>
<td>People who have low vision, complete blindness and partial blindness</td>
</tr>
</table>
Bad Practice:
<table>
 <tr>
<td>Vision</td>
<td>People who have low vision, complete blindness and partial blindness</td>
</tr>
</table>
Checklist:
  • Verify if all the column or row data are read out along with the respective column or row headers.
  • Ensure that the number of total rows and columns are properly readout.
  • Check if the row and column numbers are correctly readout when the focus shifts to them.

Lists

Typing out over-long paragraphs and not using lists in pages can greatly reduce the readability for even regular users. The right usage of lists can make it very easy for people with visual impairments using screen readers or for even people suffering from disabilities like Dyslexia. But if the proper HTML coding isn’t used in the lists, screen readers might just read all the words together like a sentence and confuse the user. Since there are 3 types of lists (Unordered list, Ordered list, and Descriptive list), we have shown what the proper code structure will look like.

Good Practice
<ul>
 <li>Apple</li>
 <li>Orange</li>
</ul>
<ol>
‘ <li>Vision</li>
 <li>Speech</li>
</ol>
<dl>
 <dt>Disabilities</dt>
 <dd>Vision</dd>
 <dd>Speech</dd>
</dl>

Forms, labels, and error

Other common components seen in various websites are text boxes, buttons, dropdowns, and so on. Since the user should be able to interact with these web elements, it is important for them to have accessible names and proper ARIA labels for the screen reader to read them properly.

Checklist:
  • 1. Check if proper attributes are used for all required fields as the screen reader should be able to announce to the user that it is a required field.
  • 2. If there are any radio buttons, check if they are grouped together.
  • 3. Check if all elements should receive focus when navigating using the tab key.
  • 4. If there are any errors in an input field, check if the error is mentioned and read out by the screen reader.
  • 5. Check if all the dropdown options have aria attributes like “aria-expanded” and “aria-collapsed”.
  • 6. Verify that the pop-up content has an ARIA attribute as “aria-haspopup”.
  • 7. Check if all buttons have proper ARIA labels that help the user understand their usage.
  • 8. Verify that the aria attributes for alert contents are implemented correctly.

Multimedia Content

Multimedia content such as images, audio, and videos will not be accessible to people with various disabilities. But there are steps developers can take to make them accessible to all by

  • Adding alt text or long descriptions to images.
  • Adding Closed Captions, transcripts, and audio descriptions for videos and audios.

Images – Alt text

Alt-text is nothing but the alternative text that explains the purpose or content of images, charts, and flowcharts for the people who will not be able to see them. So when an image is bought to focus, the screen reader will be able to read out the provided alternative text. If it is a very complex visual that requires more than 140 characters, then we could opt to use long descriptions over alt text.

<div>
<img style=”” src=”” alt=”” width=””> 
</div>

The job doesn’t end by checking if the alt text is present or not, we should ensure that the alt text fulfills its purpose by carrying out the checks from the below checklist.

Checklist
  • 1. Check if the alt text is descriptive enough to convey the intent or info from the image.
  • 2. Be clear when using terms prone to misconception like ‘Apple’. Users might get confused if we are talking about the company named Apple or the fruit named Apple.
  • 3. Make sure the alt text is not used as a holder of keywords for the various SEO needs.
  • 4. Text alternatives are not needed for decorative images as they will not affect the user in understanding the main content of the page. For example, consider a tick mark near the text that says “Checkpoint”. Here it is not mandatory to mention the tick mark.

Videos & Audios

Things get a little more complicated when other multimedia contents such as videos and audio have to be added. We would have to verify if these multimedia contents are supported by closed captions, audio descriptions, or transcripts. Let’s take a look at each of these assistive technologies.

Closed captions & Transcripts

A visually impaired person will be able to understand the context of videos with dialogues or conversations. But what if a person with a hearing disability watches the same video? Though there are auto-generated captions, they are not that reliable. That is why it is important to include closed captions or transcripts for all the videos/audio you add. Though transcripts are not mandatory, they will be effective when used for podcasts, interviews, or conversations. So a person with hearing impairment can read the transcript if they wish to.

Checklist:
  • 1. Check if the closed captions are in sync with the video.
  • 2. Validate if the subtitles have been mapped word-by-word.
  • 3. Make sure the closed captions are visible within the player.
  • 4. If it is a conversational video, make sure the name of the speaker is also mentioned.
  • 5. Check if all the numeric values are mentioned properly.
  • 6. Make sure the closed captions mention important background audio elements such as applause, silence, background score, footsteps, and so on.

Audio Description

But what if the video doesn’t have any or much dialogues or conversations? What if the visuals are a key to understanding the video? Then employing subtitles alone will never be enough. That is where audio descriptions come into play as they will describe all the actions that are happening in the visual and help users understand it clearly.

Checklist
  • 1. Ensure the description makes it possible for visually impaired users to create a clear mental image in their minds.
  • 2. Make sure the audio description covers every action, activity, silence, animation, expression, facial expression, and so on.
  • 3. The paused screen when the audio description is playing should be clearly visible and no text, image, or element should be blurred or misaligned.
  • 4. Check if all the on-screen text is available correctly in the audio description.
  • 5. Validate if all the activities and on-screen elements are in sync with the Audio description.
  • 6. The screen should be paused at the same instance which is being described in the audio description.

Animations, Moving and blinking Contents

Animations, scroll effects, and such dynamic content are being widely used on various websites. As debunked earlier, accessibility guidelines don’t prevent us from doing so. Rather, it just guides us in implementing it in the right and usable way.

Checklist
  • 1. Ensure all animations that are over 5 seconds in length have the provision to play, pause, or stop them.
  • 2. If there are any blinking or flashing contents, ensure that it doesn’t flash more than 3 times in one second as it might affect people prone to seizures.

Color Contrast

A general rule to keep in mind when developing or adding such content is to ensure there is proper color contrast between the background color and foreground elements such as text, buttons, graphs, and so on. Be it a table, image, video, form, or any content type we have seen, a lack of proper color usage can make it hard for even regular users to view the content without any difficulty. So it is needless to say that people with low vision or color blindness will find it impossible to access the content. The preferred color of the background is white and the foreground is black.

Now that we have covered all the aspects of adding different types and categories of content, let’s progress to the usage aspects that you must know when it comes to accessibility testing.

Keyboard Control & Interaction

People with visual impairments and motor disabilities will not be able to use a mouse in the same way a regular user can. So using braille keyboards or regular will be the only option they have. The most important key on the keyboard will be the ‘Tab’ key as it will help navigate to all the interactive web elements. You can use the ‘Shift+Tab’ keys combination to move in the backward direction.

  • Test if all the web elements receive focus when you hit the tab key. Also, check if the focus shifts from that element when the tab key is pressed again.
  • The element in focus will be highlighted with a gray outline. So, test if it is visible as it will be helpful for people with motor disabilities.
  • Ensure that the focus order is from left to right or right to left based on the language in use.
  • For web elements such as drop-down lists, ensure that all the options are read out by the screen reader when navigating using the arrow keys.
  • If there is any video or a carousel, the user must be able to control (Pause/Play/Volume Control) it using the keyboard actions alone.
  • Likewise, if there are any auto-play functionalities, check if the playback stops in 3 seconds or provides an option to control the playback.
  • If an interactive element does not receive the tab focus, then the element should be coded with “tab index=0”.

Input Modalities

To make it easier for the users to access the web page with different input options such as the touchscreen on mobiles, and tablets without using the keyboard. While thinking about checking the web page without keyboard keys, we can use pointer cancellation, pointer gestures, and motion actuation.

Zooming

Since there are various types of visual impairments, people with low vision might be able to access the content on the webpage without the use of a screen reader. So we have to zoom in and view the page at 200 and 400% zoom levels and check for

  • Text Overlaps
  • Truncating issues
Other Checks

From all the points we have discussed above, it is obvious that any instructions or key elements that are crucial for understanding and operating the content should not rely only on sensory characteristics. For example, if there is a form to be completed, then the completion of the form shouldn’t be denoted with a bell sound alone as people who have hearing impairments will not be able to access it. Likewise, showing just a visual or color change to denote completion will also not be accessible to all.

If there are any defined time limits, make sure that people with disabilities will be able to use them correctly. So if we take a session expiration as an example.

  • Check if the user is able to turn off or adjust the time limit before it starts.
  • The adjusting limit should be at least 10 times more than the default setting.
  • Make sure there are accessible warning messages before expiration and that there is at least a 20-second time gap for the user to extend the session with a simple action such as typing the space key.
  • It is important to keep in mind that there are exceptions for expirations such as an online test as the ability to extend the provided time limit would invalidate the existence of a time limit. Likewise, these criteria can be exempted if the time limit is more than 20 hours or if a real-time event such as an auction is being conducted.

Most common Accessibility issues

So what kind of issues can you expect when following the above-mentioned checklist? Here’s a list of the most common accessibility issues that will give you a heads up about the various issues you will encounter when performing accessibility testing. Please note that this is not a comprehensive list and that you have to keep your eyes open for any unexpected accessibility issues that might come your way.

  • 1. Heading level issues
  • 2. Incorrect implementation of list tags
  • 3. Missing alt-text for images
  • 4. Incorrect focus order
  • 5. Missing tab focus for interactive web elements
  • 6. Poor Color Contrast
  • 7. Incorrect reading order
  • 8. Missing ARIA labels
  • 9. State not announced.
  • 10. Improper table implementation
  • 11. Inability to access the contents using keyboard keys
  • 12. Content is not visible at 400 % and 200% zoom levels
  • 13. Screen reader not notifying alert messages
  • 14. Screen reader not reading the dropdown list
  • 15. Lack of expanded and collapsed state implementation
  • 16. Missing closed captions, audio descriptions, or video transcripts for videos

Challenges of Accessibility Testing

There is no task without any challenges and Accessibility Testing also does come with its own share of challenges.

Dynamic Websites

Dynamic websites tend to have 100 or 1000’s changes every minute or every hour. So implementing web accessibility for dynamic content inside such web pages is considered to be very hard due to the presence of third-party content like ads and other such factors.

Large Websites

Though it would be easier to work with static content in comparison, it would still be a mammoth challenge if it has to be implemented for over 1000 pages in retrospect. So the next major challenge in implementing accessibility is the scale of the website as the more the number of pages, the higher the variety of content that will be available.

Limited Automation Scope

The scope for automating web accessibility tests is very low as even if we write scripts to detect the images with or without alt-text, it only solves half the problem. What if the alt-text is present but not descriptive enough or relevant to that image? We would once again need a manual tester to validate it. Lack of conformance verification is what makes scaling web accessibility tests with automation a challenge.

Test Artifacts over the User Experience

The focus of WCAG and its success criteria are primarily on technical artifacts and not on the user’s journey and goals. To put it in simple terms, their guidelines are only focused on the webpage as seen earlier, and not on the user experience. The clear gap between accessibility and the user experience can be bridged if the accessibility testing team focused on the user experience while performing testing. And that is why we ensure to train our accessibility testers to test by keeping the user experience in mind.

Web Accessibility Testing Tools

Since disabled people use various assistive technologies, as a tester you should know how to use those technologies too. That’s just the first step, as you should also use the assistive technology in a way that a real person with disabilities will use it. Putting yourself in their perspective is the key to maximizing the scope of usage. There are dedicated screen readers that come with built-in various devices and platforms. Though there will be various similarities when it comes to the usage of these screen readers, you should know how to use them individually.

Inbuilt List of Screen Readers
  • Narrator for Windows
  • ORCA for Linux
  • Voiceover for macOS and iOS
  • Talkback for Android
  • ChromeVox for Chromebooks
Other Popular Screen Readers
  • JAWS for Windows (Commercial)
  • NVDA for Windows (Free)

Apart from these assistive technologies, we also employ a set of tools to ease the accessibility testing process. While no tool will work without human validation, it is still handy to have such options to speed up the evaluation process. In order to speed things up, even more, we also use various browser extensions and bookmarklets such as,

  • Wave
  • Color Contrast Analyzer
  • arc & axe

Conclusion

So that pretty much sums everything up you will need to know to get started with accessibility testing. We hope you found our guide easier to understand when compared to the other conventional options as we have broken down the checks based on the different web elements as they are more tangible. Make sure to subscribe to our newsletter as we will be posting such highly useful content on a weekly basis. Have any doubts? Ask them in the comments section and we will try our best to answer them.

How to Test Color Contrast for Accessibility using CCA?

How to Test Color Contrast for Accessibility using CCA?

According to a survey by WebAIM, low contrast text is the most widely seen bug with regard to accessibility as it is present in 86.3% of the top one million home pages on the web. So despite the different preferences of the users when it comes to font color, the focus should always be on the legibility of the text. Color Contrast Analysis goes beyond the text color as proper contrast levels have to be maintained even in visual elements like graphs, infographics, and interactive elements such as links, buttons, and so on. But how will you determine if the contrast levels used are in line with the standards set by WCAG? We simply can’t take a look at it and come to a conclusion on our own. That is where Color Contrast Analyser comes into play.

So in this blog, we will be explaining to you how to use a Color Contrast Analyser for your testing with a few sample scenarios as well. Even though the process itself is very simple, the effectiveness of using a color contrast analyzing tool comes with the maximum coverage we can attain. So we will also be seeing a general checklist and a few common challenges that you will be facing during your testing.

Why should we use a Colour Contrast Analyzer for Accessibility Testing?

Why should we use a Colour Contrast Analyzer for Accessibility Testing

People with visual impairments such as color blindness and low vision find it difficult to identify the difference between certain color combinations like Red-Green, Red-Black, Blue-Yellow, and so on. As a result, if online sites contain text with such color combinations, or if there is a lot of content with small font size on a non-white backdrop, it becomes hard for anyone with visual impairments to see and understand it. So color contrast analyser is an easy-to-use, yet effective tool that will let you know if your choice of color combinations will pass the visibility test.

How to test Color Contrast for Accessibility?

Though there are numerous color contrast analyzing tools available, we always opt to use the Color Contrast Analyser provided by TPGi as it is widely used for accessibility testing by testers. You can download both the Windows and macOS versions by visiting the TPGi website.

So once you have installed the Color Contrast Analyser by following the mentioned steps, you will be able to check if the contrast levels fulfill the success criteria defined by WCAG. We all know that accessibility is measured by the level of compliance (A, AA, & AAA). So the level of color contrast ratio comes under the AA & AAA compliance levels. The specific success criteria that can be used to find out if the text is accessible for sighted people is WCAG 1.4.3. The contrast ratio should be greater than 4.5:1 in order to pass this success criterion from WCAG 2.1. Likewise, for non-text content, the success criteria to comply with is 1.4.11 and the contrast ratio should be higher than 3:1 to pass.

Now that we know what the goal is, the first step would be to check the size of the font and get an idea of whether it will be considered small or large text. If the text size is 18 points (24 pixels), it will be considered large text. And if the text size is 14 points (18 pixels) it will be considered small text. The reason is that there are distinct success criteria for both small and large text.

S. No Type of Content WCAG Success Criteria Required Contrast Level for Level AA Required Contrast Level for Level AAA
1 Text Content WCAG 1.4.3 4.5:1 (Small Text) 3.1(Large Text) 7:1(Small Text) 4.5:1(Large Text)
2 Image Of Text WCAG 1.4.5 4.5:1
3 Non-Text Content (Link, Graph, Buttons, And So On) WCAG 1.4.11 3:1

You can easily use the Color Contrast Analyzer by following the below-mentioned steps

  • Click on the Color Picker option in CCA.
  • Place the picker correctly on the background of the text and click to pick the color.
  • Look for the darkest part of the text and pick the color using the tool.
  • You can even input the hex codes of the colors you wish to check if you do not want to use the eyedropper tool.

How to Use Color Contrast Analyser

If the contrast levels between the background and text are okay, we will see a green color tick mark in the contrast tool. If not, it will show a red color X mark. The same process can be repeated for all other content such as images of text, links, buttons, radio buttons, and so on.

How to check color contrast on a mobile app?

Since there aren’t any mobile applications that can do the same tasks as the Color Contrast Analyser, you can use the color palette of your app to check the color contrast levels. But if you do not have access to the mobile app’s color palette, one easy alternative is to just take screenshots of the various screens you want to test and transfer them to your computer to test it using CCA. But if your app is large in scale, you might want to use a simulator to get your testing done.

Whichever method you opt to use, you have to keep a few things in mind when it comes to testing color contrast for mobile apps. Though we do not turn on high contrast mode in computers, dark mode & high contrast settings are important as both Android and iOS have recently introduced system-wide “Dark Mode” functionality. So you have to make sure to test the color contrast levels in both the dark and light modes.

It is also tough to judge the text size with just the appearance on mobile devices as they have a broad range of DPI and screen sizes. So make sure you do not presume the text is huge unless you know for sure that it is 18+ pt or 14+ pt bold (24px or 19px bold for online).

Checklist

  • Make sure to test web elements by shifting focus to them, hovering over them, and so on to see if the desired visual indicators such as outline/border creation, or color/background changes.
  • Check if the outline or border width is at least 2 px.
  • Make sure no meaning is conveyed only by color if there are additional formatting options such as bold, italics, or underline.
  • If texts are there in an image, ensure that the font size is at least 16 px to maintain legibility.
  • Ensure that pie charts have a gap between each portion to make it possible for people with color blindness to see and understand it clearly. Based on the level of compliance, you can even add labels with arrows to ensure there is no type of miscommunication.
  • Since logos and decorative images are exempt from color contrast analysis, you need not waste time worrying about them.
  • If there are any outlines behind a text, to make up for the change in the opacity of the text or the luminance of the background, the color of the outline should only be considered as the background color.
  • Make sure the ‘High Contrast’ or Night modes are turned off when performing these tests on your computer.
  • If any drop-down or flyout vanishes whenever the CCA comes into focus, make sure to take a screenshot of the flyout and then test it using the CCA.

Color Contrast Analyser Checklist 1

Color Contrast Analyser Checklist 2

Sample Scenarios

We have used a random website in the below scenarios for our explanation purposes. We will be a success scenario and a failure scenario as it will help you get a clear picture of using a Color Contrast Analyser.

Scenario 1:

Scenario 1 to check color contrast on a mobile app

In this scenario, the regular text has failed at the AA level and the large text has failed at the AAA level of the compliance. It is also evident that it has passed only in the non-text contrast testing. As a result, the image will be very hard for visually impaired viewers to view.

Scenario 2:

Scenario 2 to check color contrast on a mobile app

Since it is black text on a white background, all the conditions have been satisfied in the color contrast analyzing text.

Conclusion

Though color contrast analysis is a very simple process, the ability to yourself in the shoes of a visually impaired person is the key to attaining the best results. Thanks to our years of experience in providing accessibility testing services to numerous clients, we have a well-trained accessibility testing team that has delivered the best results with maximum coverage. And that knowledge is what has helped us convey such informative content. So make sure to subscribe to our newsletter to stay tuned with Codoid.

A VoiceOver Quick Reference Guide with Keyboard Shortcuts & Gestures

A VoiceOver Quick Reference Guide with Keyboard Shortcuts & Gestures

Apple is one of the biggest technology companies in the world with over 1.8 billion active devices as of 2022. VoiceOver is an in-built screen reader that was first introduced by Apple in 2009. It is now available on all their devices like Macs, iPhones, iPads, and so on. So as an accessibility tester, knowing to use VoiceOver for testing is mandatory. Being a leading web accessibility testing services provider, we have written this VoiceOver Quick Reference Guide that will help you in using VoiceOver for your accessibility testing. So we will be covering the various VoiceOver shortcut keys you’ll need to know when it comes to Macs and the various VoiceOver gestures when it comes to iPhones & iPads.

How to Get VoiceOver Started?

So let’s start this VoiceOver Quick Reference Guide by seeing how to start VoiceOver across all the devices. On a Mac, you can start VoiceOver by either using the shortcut keys (Command + F5) or by Settings -> General Section -> Accessibility Menu -> VoiceOver.

If you are using an iPad or iPhone that is supported by Siri, then you could also boot it up using Siri. You can also triple press the side button or the home button to start VoiceOver, or turn it on by Settings -> Accessibility -> VoiceOver.

Rotor

One unique feature in VoiceOver is the rotor, which can be described as a wheel of commands that is dependent on the context. So the user can choose what settings or navigation options that have to appear in the rotor. The rotor is highly customizable as the user can assign different navigation options such as headings, window spots, links, and so on as shown.

Rotor Functionality Menu in VoiceOver

You can define the settings you want to display in the rotor by navigating to Settings -> General -> Accessibility -> Voiceover -> Utility -> Web -> Web Rotor.

When it comes to devices such as iPads and iPhones, you can also turn Rotor on by swiping two fingers on the touchscreen like how you would dial with a rotating dial pad. And you will get a similar functionality where you can define the navigation options you need and use them by performing the appropriate gestures.

Accessibility Testing Using VoiceOver

Screen readers are accessibility testing tools that are primarily assistive technologies used by people with disabilities to access the content. So knowing the basic VoiceOver keyboard shortcuts to operate it is a must. In addition to that, there are a few checkpoints that every accessibility tester should validate to ensure that the content is accessible. So in this VoiceOver Quick Reference Guide, we have categorized the VoiceOver keyboard shortcuts with reference to those checkpoints.

  • Content Navigation
  • Reading Content
  • Interactive Element Navigation
  • Table Navigation

VoiceOver Keyboard Shortcuts for macOS:

iMacs and Macbooks are the Apple devices where VoiceOver can be controlled using various keyboard shortcuts. Since devices like iPads and iPhones have a touch screen for the input, they will be using touch gestures to control VoiceOver. We will be covering those gestures later on the blog once we have seen the keyboard shortcuts.

Functional :
S. No Actions Commands
1 Start Or Stop VoiceOver Command + F5
2 VoiceOver Activation Keys (Or VO Keys) Control + Option (Referenced As VO)
3 Lock (Or Unlock) VO Keys Control + Option + ;
4 Open Rotor Control + Option + U
5 Choose Speech Setting Options Such As Speaking Rate, Voice, Pitch, Etc. Control + Option + Command + Right Arrow / Left Arrow
6 Modify The Chosen Speech Setting Control + Option + Command + Up Arrow / Down Arrow
7 Toggle Screen Curtain On/Off Control + Option+ Shift +F11
Content Navigation
S. No Actions Commands
1 Go To The Top Of The Page (IMacs) Control + Option + Home
2 Go To The Top Of The Page (Macbooks) Control + Option + Fn + Left Arrow
3 Navigate To The Bottom Of The Page (IMacs) Control + Option+ End
4 Navigate To The Bottom Of The Page (Macbooks) Control + Option + Fn + Right Arrow
5 Go To The Next Heading Control + Option + Command + H
6 Go To The Next Table Control + Option + Command + T
7 Go To The First Item On Page Control + Option + A
8 Scroll (Vertically Or Horizontally) Shift Key + Scroll
9 Go To Previous (Heading, Table, Etc.) Control + Option + Shift + Command + (H, T, Etc.)
Reading Content:
S. No Actions Commands
1 Start Reading Control + Option+ A
2 Stop Reading Control
3 Start Reading Continuously From This Point On Control + Option + Down Arrow
4 Read The Entire Page Control + Option + Up Arrow / Down Arrow
5 Read The Next Line, Word, Character Control + Option + Right Arrow
6 Read The Previous Line, Word, Character Control + Option + Left Arrow
7 Repeat The Last Spoken Phrase Control + Option + Z
8 Read The Selected Paragraph Control + Option + P
9 Read The Selected Sentence Control + Option + S
10 Read The Selected Word Control + Option + W
11 Spell The Selected Word Alphabetically Control + Option + W + W
12 Spell The Selected Word Phonetically Control + Option + Shift + Command + (H, T, Etc.)
13 Read From Top To Current Location Control + Option +B
Interactive Elements Navigation:

If you are unsure of what interactive elements are, they are what the name suggests. They are web elements that a user can interact with or elements that respond to inputs from the user.

S. No Actions Commands
1 Go To The Next/Previous Focusable Item (Link, Button, Input, Etc.) Tab / Shift + Tab
2 Next Link Control + Option + Command + L
3 Next Visited Link Control + Option + Command + V
4 Next Form Element Control + Option+ Command + J
5 Next List Control + Option + Command + X
6 Next Graphic Control + Option+ Command + G
7 Activate A Link Or Form Control Control + Option Enter (Or) Space Bar
8 Interact With (Go Into/Out Of) Objects (Like Iframes, Menus, Application Regions, Etc.) Control + Option + Shift + Down Arrow / Up Arrow
Table Navigation:
S. No Actions Commands
1 Next Table Control + Option + Command + T
2 Read Column Header Control + Option + C
3 Read Row From VO Cursor Location To End Of Row Control + Option + R
4 Read Column From VO Cursor Location To The Bottom Of Column Control + Option + R + C
5 Move Up Or Down In A Column Up Arrow Or Down Arrow
6 Move To The Left Or Right In A Row Left Arrow Or Right Arrow

iOS VoiceOver gestures

Apart from the way VoiceOver is controlled on these touch-enabled devices, it does provide a very uniform experience across the Apple ecosystem. So let’s take a look at the various gestures in the same categorized view as before.

  • Functional
  • Content Navigation
  • Reading Content
  • Interactive Element Navigation
  • Text Editing
  • Table Navigation

Apart from the gestures that you will be seeing in this VoiceOver Quick Reference Guide, you will also have the option to enable typing feedback for VoiceOver to read out the words or characters that have been typed by Settings -> General -> VoiceOver -> Typing Feedback. Since VoiceOver changes the way gestures work on an iPad or iPhone, make sure to disable them in the Settings.

Functional:
S. No Action Command
1 Start Or Stop VoiceOver (When It Is Enabled) Triple-Press Home Button Or Side Button (IPhone X +)
2 Gesture Help 4-Finger Double-Tap
3 Split Tap Quick-Activation Select And Hold With One Finger, Tap With Another
4 Double-Press Button Triple-Tap
5 Next/Previous App 4-Finger Swipe Right/Left
6 Drag Mode Tap Twice And Hold
7 Toggle Screen Curtain On/Off Three-Finger Triple-Tap
8 Item Chooser: Two-Finger Triple-Tap
9 Choose Speech Setting Options Such As Speaking Rate, Voice, Pitch, Etc. VO + Command + Right/Left Arrow Key
10 Modify The Chosen Speech Setting VO + Command+ Up/Down Arrow Key
11 Open Rotor Rotate Two Fingers
Content Navigation
S. No Action Gesture
1 Go To The Top Of The Page Two-Finger Swipe Up
2 Navigate To The Bottom Of The Page Two-Finger Double-Tap One-Finger Tap
3 Go To The Next Heading Set Headings On Rotor And Swipe Down
4 Go To The Next Table Rotor, Swipe Down
5 Go To Previous (Heading, Table, Etc.) Swipe Up
6 Go Back, Close A Popup, Or Cancel The Last One. Two-Finger Scrub
7 Go To The First Item On The Page 4-Finger Tap On The Upper/Lower Half Of The Screen
8 Scroll (Vertically Or Horizontally) 3-Finger Swipe Up, Down, Left, Or Right
9 Go Back To One Link, List, Table, Landmark, Heading, Etc. Swipe Up
Reading Text:
S. No Action Command
1 Start/Stop Reading Two-Finger Tap
2 Start Reading Continuously From This Point On Two-Finger Swipe Down
3 Read The Entire Page Two-Finger Swipe Up
4 Read Next Line, Word, Character Rotor, Swipe Down
5 Read The Previous Line, Word, Character Rotor, Swipe Up
6 Read The Selected Paragraph Swipe Down – Two Fingers
7 Read The Selected Sentence Swipe Down – Two Fingers
8 Read The Selected Word Read The Selected Word
9 Read From Top To Current Location VO + B
10 Toggle Speech On/Off Three-Finger Double-Tap
Interactive Elements Navigation:
S. No Action Command
1 Go To The Next/Previous Focusable Item (Link, Button, Input, Etc.) Swipe Right
2 Next Link Rotor, Swipe Down
3 Next Visited Link VO + Command +V
4 Next Form Or Button Element VO + Command + J
5 Select And Deselect Checkboxes, Radio Buttons Double-Tap
6 Next Checkbox. Combo Box, Radio Button Rotor (Same Item Or Form Controls), Swipe Down
7 Open Combo Box Double-Tap
8 Hear Combo Box Options: Drag Finger Through The List/td>
9 Activate The Link Or Button Double-Tap
10 Next List Rotor, Swipe Down
11 Next Graphic Rotor, Swipe Right
12 Interact With (Go Into/Out Of) Objects (Like Iframes, Menus, Application Regions, Etc.) VO + Shift + Down/Up Arrow
Text Editing:
S. No Actions Gestures
1 Select/Deselect Text Pinch Out/In
2 Copy The Last Spoken Text To The Clipboard Three-Finger Quadruple-Tap
3 Change Case Three-Finger Swipe Up/Down*
4 Insert Space Two-Finger Swipe Right*
5 Backspace Two-Finger Swipe Left*
Table:
S. No Actions Command
1 Next Table Rotor, Swipe Down
2 Move Up In A Column Swipe Up
3 Move Down In A Column Swipe Down
4 Move To The Left In A Row Swipe Left
5 Move To The Right In A Row Swipe Right

Advantages of VoiceOver:

  • The layout and gestures of VoiceOver are universal across all devices making the shift from one device to another seamless.
  • The curtain mode enables users to turn off the screen when the screen reader is being used to enable a more private user experience.
  • Users will also be able to change the speech rate if they wish to speed things up.
  • Numerous voice options with different accent options such as UK, Ireland, Australia, and South Africa.
  • Users can also determine what information has to be read by the screen reader such as punctuation, emojis, hyperlinks, and so on.

Disadvantages of VoiceOver

  • VoiceOver will not read any content from Microsoft Office for Mac.
  • Likewise, it will also not read any content from Adobe Acrobat.

Conclusion:

So as stated earlier, knowing how to use VoiceOver across all Apple devices is very crucial for an accessibility tester. The categorized tables can serve as an effective VoiceOver keyboard shortcuts guide for macOS or as a VoiceOver gestures cheat sheet for iOS. So we hope this VoiceOver Quick Reference Guide improves your accessibility testing skills. Make sure to subscribe to our newsletter to stay up to date with such informative content.