Blog

The Definitive Mobile App Accessibility Testing Checklist for Android & iOS

by Anika Chakraborty | Nov 3, 2022 | Accessibility Testing, Blog | 0 comments

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

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.

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.

• 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

by Arthur Williams | Sep 15, 2022 | Accessibility Testing, Blog | 0 comments

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

• No-Down-event
• Up-event abort or undo
• Up reversal

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).

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?

by Anika Chakraborty | Jun 16, 2022 | Accessibility Testing, Blog | 0 comments

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 Test Color Contrast for Accessibility using CCA?

by Chris Adams | May 25, 2022 | Accessibility Testing, Blog | 0 comments

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?

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.

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.

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.

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:

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:

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.