You’ve got your unit tests. Your end-to-end flows. Maybe even 100% code coverage. But bugs still slip through.

That’s because full code coverage doesn’t guarantee full test coverage. Visual glitches, browser inconsistencies, and content drift often escape traditional automation — and they’re exactly the kinds of issues your users notice first.

In The Coverage Overlook, the kickoff session of our Testing Your Way: Code & No-Code Journeys webinar series, we explored five critical coverage gaps most teams miss — and how to close them with AI-powered visual testing and no-code tools.

1. Visual and Layout Bugs

Code-based assertions won’t catch when an element shifts, disappears, or overlaps. That’s where Visual AI steps in.

By analyzing the rendered UI — not just the DOM — Visual AI identifies layout issues, missing images, overlapping text, and subtle visual defects with a single line of code (or none at all).

“Visual AI can instantly catch layout shifts, missing elements, and new text that coded assertions would miss — all without the maintenance burden of custom locators.”
— Tim Hinds, Applitools

2. Cross-Browser and Device Inconsistencies

Most test suites default to Chrome. But real users span dozens of devices and browsers.

Visual AI tools like Applitools Eyes can validate your app across multiple browsers and screen sizes in parallel — using a single test run. No custom scripting required.

3. Dynamic Content Variations

Personalized content, A/B tests, and location-based content are tough to verify with scripted tests alone.

Visual AI combined with flexible match algorithms can confirm layout structure while ignoring safe visual differences — helping your team catch what matters, without writing exceptions for every variant.

4. Lower-Priority Flows and Pages

Teams tend to focus their test coverage on critical flows — like checkout or login — and leave lower-traffic pages untested.

No-code tools like Applitools Autonomous make it easy to cover the rest. A built-in crawler can scan your site and establish visual baselines across dozens (or hundreds) of pages — all without writing a single test script.

5. Accessibility Gaps

Code coverage can’t catch color contrast failures, missing labels, or overlapping elements that make your UI inaccessible.

Visual AI can. And with upcoming enforcement of the European Accessibility Act, now is the time to start catching these issues early.

Watch the Full Session On-Demand: Code & No-Code Journeys: The Coverage Overlook

Closing the Gap

Code coverage still has value — but modern teams are shifting toward user-centered test coverage.

As shared in the session, teams like Eversana are combining code-based, no-code, and visual testing strategies to expand coverage, accelerate feedback, and reduce risk. With this blended approach, they’ve achieved:

• 65% reduction in regression testing time
• 750+ hours saved per month
• 90% test stability
• A unified testing culture across manual testers, developers, and QA

What’s Next in the Series?

The journey continues with The Maintenance Shortcut, where we explore how teams are reducing flaky tests, eliminating brittle locators, and cutting test maintenance with Visual AI and Autonomous.

The post Think You Have Full Test Coverage? Here Are 5 Gaps Most Teams Miss appeared first on AI-Powered End-to-End Testing | Applitools.

Cypress vs. Playwright: The Rematch

One of our most popular series is Let the Code Speak, where we compare testing frameworks in real examples. In our rematch of Let the Code Speak: Cypress vs. Playwright, Andrew Knight and Filip Hric dive deeper to how Cypress and Playwright work in practical projects. Quality Engineer Beth Marshall moderates this battle of testing frameworks while Andy and Filip explore comparisons of their respective testing frameworks in the areas of developer experience, finding selectors, reporting, and more.

Automating Testing in a Component Library

Visual testing components allows teams to find bugs earlier, across a variety of browsers and viewports, by testing reused components in isolation. Software Engineering Manager David Lindley and Senior Software Engineer Ben Hudson joined us last year to detail how Vodafone introduced Applitools into its workflow to automate visual component testing. They also share the challenges and improvements they saw when automating their component testing.

When to Shift Left, Move to Centre, and Go Right in Testing

Quality isn’t limited to the end of the development process, so testing should be kept in mind long before your app is built. Quality Advocate Millan Kaul offers actionable strategies and answers to questions about how to approach testing during different development phases and when you should or shouldn’t automate. Millan also shares real examples of how to do performance and security testing.

You, Me, and Accessibility: Empathy and Human-Centered Design Thinking

Inclusive design makes it easier for your customers with your varying needs and devices are able to use your product. Accessibility Advocate and Crema Test Engineer Erin Hess talks about the principles of accessible design, how empathy empowers teams and end users, and how to make accessibility more approachable to teams that are newer to it. This webinar is helpful all team members, whether you’re a designer, developer, tester, product owner, or customer advocate.

Erin also shared a recap along with the audience poll results in a follow-up blog post.

Future of Testing October 2022

Our October Future of Testing event was full of experts from SenseIT, Studylog, Meta, This Dot, EVERSANA, EVERFI, LAB Group, and our own speakers from Applitools. We covered test automation topics across ROI measurement, accessibility, testing at scale, and more. Andrew Knight, Director of Test Automation University, concludes the event with eight testing convictions inspired by Ukiyo-e Japanese woodblock prints. Check out the full Future of Testing October 2022 event library for all of the sessions.

Skills and Strategies for New Test Managers

Being a good Test Manager is about more than just choosing the right tools for your team. EasyJet Test Manager Laveena Ramchandani shares what she has learned in her experience on how to succeed in QA leadership. Some of Laveena’s strategies include how to create a culture that values feedback and communication. This webinar is great for anyone looking to become a Test Manager or for anyone who has newly started the role.

Ensuring a Reliable Digital Experience This Black Friday

With so much data and so many combinations of state, digital shopping experiences can be challenging to test. Senior Director of Product Marketing Dan Giordano talks about how to test your eCommerce application to prioritize coverage on the most important parts of your application. He also shares some common shopper personas to help you start putting together your own user scenarios. The live demo shows how AI-powered automated visual testing can help retail businesses in the areas of visual regression testing, accessibility testing, and multi-baseline testing for A/B experiments.

Dan gave a recap and went a little deeper into eCommerce testing in a follow-up blog post.

Cypress, Playwright, Selenium, or WebdriverIO? Let the Engineers Speak!

Our popular Let the Code Speak webinar series focused primarily on differences in syntax and features, but it doesn’t really cover how these frameworks hold up in the long term. In our new Let the Engineers Speak webinar, we spoke with a panel of engineers from Mercari US, YOOBIC, Hilton, Q2, and Domino’s about how they use Cypress, Playwright, Selenium, and WebdriverIO in their day-to-day operations. Andrew Knight moderated as our panelists discussed what challenges they faced and if they ever switched from one framework to another. The webinar gives a great view into the factors that go into deciding what tool is right for the project.

Read the Let the Engineers Speak recap blog series

Let the Engineers Speak! Part 5: Audience Q&A

Articles — 01.11.2023

Let the Engineers Speak! Part 4: Changing Frameworks

Articles — 01.05.2023

Let the Engineers Speak! Part 3: Favorite Test Integrations

Articles — 12.28.2022

Let the Engineers Speak! Part 2: The Biggest Challenges

Articles — 12.22.2022

The post Test Automation Video Winter Roundup: September – December 2022 appeared first on AI-Powered End-to-End Testing | Applitools.

Test Automation University (also called “TAU”) is one of the best online platforms for learning testing and automation skills. TAU offers dozens of courses from the world’s leading instructors, and everything is available for free. The platform is proudly powered by Applitools. As of November 2022, nearly 140,000 students have signed up! TAU has become an invaluable part of the testing community at large. Personally, I know many software teams who use TAU courses as part of their internal onboarding and mentorship programs.

So, which TAU courses are currently the most popular? In this list, we’ll count down the top 10 most popular courses, ranked by the total number of course completions over the past year. Let’s go!

#10: Selenium WebDriver with Java

Starting off the list at #10 is Selenium WebDriver with Java by none other than Angie Jones. Even with the rise of alternatives like Cypress and Playwright, Selenium WebDriver continues to be one of the most popular tools for browser automation, and Java continues to be one of its most popular programming languages. Selenium WebDriver with Java could almost be considered the “default” choice for Web UI test automation.

In this course, Angie digs deep into the WebDriver API, teaching everything from the basics to advanced techniques. It’s a great course for building a firm foundation in automation with Selenium WebDriver.

#9: Python Programming

#9 on our list is one of our programming courses: Python Programming by Jess Ingrassellino. Python is hot right now. On whatever ranking, index, or article you find these days for the “most popular programming languages,” Python is right at the top of the list – often vying for the top spot with JavaScript. Python is also quite a popular language for test automation, with excellent frameworks like pytest, libraries like requests, and bindings for browser automation tools like Selenium WebDriver and Playwright.

In this course, Dr. Jess teaches programming in Python. This isn’t a test automation course – it’s a coding course that anyone could take. She covers both structured programming and object-oriented principles from the ground up. After two hours, you’ll be ready to start coding your own projects!

#8: API Test Automation with Postman

The #8 spot belongs to API Test Automation with Postman by Beth Marshall. In recent years, Postman has become the go-to tool for building and testing APIs. You could almost think of it as an IDE for APIs. Many test teams use Postman to automate their API test suites.

Beth walks through everything you need to know about automating API tests with Postman in this course. She covers basic features, mocks, monitors, workspaces, and more. Definitely take this course if you want to take your API testing skills to the next level!

#7: Introduction to Cypress

Lucky #7 is Introduction to Cypress by Gil Tayar. Cypress is one of the most popular web testing frameworks these days, even rivaling Selenium WebDriver. With its concise syntax, rich debugging features, and JavaScript-native approach, it’s become the darling end-to-end test framework for frontend developers.

It’s no surprise that Gil’s Cypress course would be in the top ten. In this course, Gil teaches how to set up and run tests in Cypress from scratch. He covers both the Cypress app and the CLI, and he even covers how to do visual testing with Cypress.

#6: Exploring Service APIs through Test Automation

The sixth most popular TAU course is Exploring Service APIs through Test Automation by Amber Race. API testing is just as important as UI testing, and this course is a great way to start learning what it’s all about. In fact, this is a great course to take before API Test Automation with Postman.

This course was actually the second course we launched on TAU. It’s almost as old as TAU itself! In it, Amber shows how to explore APIs first and then test them using the POISED strategy.

#5: IntelliJ for Test Automation Engineers

Coming in at #5 is IntelliJ for Test Automation Engineers by Corina Pip. Java is one of the most popular languages for test automation, and IntelliJ is arguably the best and most popular Java IDE on the market today. Whether you build frontend apps, backend services, or test automation, you need proper development tools to get the job done.

Corina is a Java pro. In this course, she teaches how to maximize the value you get out of IntelliJ – and specifically for test automation. She walks through all those complicated menus and options you may have ignored otherwise to help you become a highly efficient engineer.

#4: Java Programming

Our list is winding down! At #4, we have Java Programming by Angie Jones. For the third time, a Java-based course appears on this list. That’s no surprise, as we’ve said before that Java remains a dominant programming language for test automation.

Like the Python Programming course at spot #9, Angie’s course is a programming course: it teaches the fundamentals of the Java language. Angie covers everything from “Hello World” to exceptions, polymorphism, and the Collections Framework. Clocking in at just under six hours, this is also one of the most comprehensive courses in the TAU catalog. Angie is also an official Java Champion, so you know this course is top-notch.

#3: Introduction to JavaScript

It’s time for the top three! The bronze medal goes to Introduction to JavaScript by Mark Thompson. JavaScript is the language of the Web, so it should be no surprise that it is also a top language for test automation. Popular test frameworks like Cypress, Playwright, and Jest all use JavaScript.

This is the third programming course TAU offers, and also the top one in this ranking! In this course, Mark provides a very accessible onramp to start programming in JavaScript. He covers the rock-solid basics: variables, conditionals, loops, functions, and classes. These concepts apply to all other programming languages, too, so it’s a great course for anyone who is new to coding.

#2: Web Element Locator Strategies

I’m partial to the course in second place – Web Element Locator Strategies by me, Andrew Knight! This was the first course I developed for TAU, long before I ever joined Applitools.

In whatever test framework or language you use for UI-based test automation, you need to use locators to find elements on the page. Locators can use IDs, CSS selectors, or XPaths to uniquely identify elements. This course teaches all the tips and tricks to write locators for any page, including the tricky stuff!

#1: Setting a Foundation for Successful Test Automation

It should come as no surprise that the #1 course on TAU in terms of course completions is Setting a Foundation for Successful Test Automation by Angie Jones. This course was the very first course published to TAU, and it is the first course in almost all the Learning Paths.

Before starting any test automation project, you must set clear goals with a robust strategy that meets your business objectives. Testing strategies must be comprehensive – they include culture, tooling, scaling, and longevity. While test tools and frameworks will come and go, common-sense planning will always be needed. Angie’s course is a timeless classic for teams striving for success with test automation.

What can we learn from these trends?

What other courses are popular?

The post The Top 10 Test Automation University Courses appeared first on AI-Powered End-to-End Testing | Applitools.

Learn how to get started with web accessibility testing with this list of the best paid, free and open source accessibility testing tools.

If you visit the Web Accessibility Evaluation Tools List, there are a whopping 167 tools to choose from! As someone who is just starting in the world of accessibility, how do you decide which tools to choose?

There are of course various factors to consider when choosing an accessibility tool, but in this blog post, I’ll share a few tools that I have found really useful when it comes to accessibility testing. If you tuned in to my talk on Shifting Accessibility Testing to the Left (or read my blog post), you would know that I like to group the accessibility testing tools in different areas. These areas are:

• Tools requiring human assistance
• Semi automated tools in the form of browser extensions
• Automated tools

Accessibility Testing Tools Requiring Human Assistance

Even though there’s a growing number of automated tools out there, accessibility testing still requires human assistance to make sure that the experience we are testing closely matches the one our users will have. The following tools are my go-to when it comes to manually testing for accessibility.

Keyboards

The first tool is my very own keyboard. Making sure that your website is keyboard friendly and compatible already makes it more accessible than many other websites.

To get started with keyboard compatibility testing, you need to know basic keystrokes such as TAB, Enter, Arrow keys (← ↑ → ↓), just to name a few, to make sure that you can still interact with the website as if you are using a mouse.

When it comes to testing with a keyboard, this can surface accessibility considerations such as:

• Are your elements focusable when the user tabs through it?
• Do you have a skip to the main content link which is only visible when tabbed through with a keyboard?
• When presented with a modal or a pop-up, can the users exit the modal and interact with what they were presented before?

Screen Readers

Using a screen reader can be overwhelming for people who don’t use it but screen readers are a must when it comes to testing for accessibility. Depending on the operating system that you are using, there is an available screen reader software for you to use such as VoiceOver, JAWS, NVDA and TalkBack. Spend some time familiarizing yourself on how to use a screen reader to make sure that your websites are accessible for these users.

Zoom/Magnification

Users who have low vision need to have a way to easily perceive, navigate and interact with the content that is presented to them. By using the zoom or magnification too that’s built into browsers, you can zoom in up to 200% (or more) and verify if the elements are displayed nicely and are still interactable.

Semi-Automated Accessibility Testing Tools in the Form of Browser Extensions

Browser extensions are a quick way to help you surface any accessibility issues that your websites might have. Most of the browser extensions are provided to you for free with additional features unlocked if you purchase their commercial version. The common thing with the extensions below is they all provide an easy way to check violations. All of the extensions, apart from ColorBlindly, also provide an easy to digest output so you can share with your teams a list of accessibility issues.

Axe DevTools and WAVE

Axe DevTools and WAVE are two extensions that you can install and integrate easily in your browser of choice. These accessibility extensions scan a specific web page and report any accessibility violations that it finds. These are great tools to get started with accessibility, especially if you are a beginner. They provide useful information such as the description of the accessibility violation, its impact, how to fix it and elements that are impacted.

Google Lighthouse

Google Lighthouse, which is already built into Google Chrome’s developer tools, provides an easy way to perform accessibility audits. It can also measure web performance apart from accessibility and can provide recommendations on how to fix the issues caught. Don’t get too fixated though with the Lighthouse accessibility scores as this is not a complete indication that your website is accessible.

ColorBlindly

ColorBlindly is an easy to use Chrome extension that can simulate different types of color blindness with just one click. This extension can help you verify if the color schemes of your website are accessible from a wide range of color blindness.

Automated Accessibility Testing Tools

Now, in order to shift accessibility testing as early as possible, apart from having early conversations with your team, leveraging automation is key so that you can focus on areas where accessibility testing is needed the most. What’s common with these tools is that you can easily integrate them as part of your continuous integration pipelines and it can provide a safety net so your team can be confident in making changes or introducing new features.

Axe CLI

Command line lovers, this tool is for you! Axe CLI is a command line tool which provides a way to perform accessibility audits straight from your command line. This is particularly useful if you want to quickly scan various pages from your command line.

The scan can be configurable in the sense that you can disable certain accessibility rules, include or exclude certain elements and modify the accessibility report. 

If you’re looking for a quick tool that you can easily integrate as part of your pipelines, give Axe CLI a try.

Cypress and cypress-axe

Good news for Cypress users! Did you know that you can easily integrate accessibility tests just by installing a plugin called cypress-axe? Cypress-axe uses the axe-core library and lets you audit pages or components straight from your Cypress tests. I have discussed this in more detail in my course Test Automation for Accessibility so if you’re interested to find out how the plugin works, check out this course from Test Automation University.

Similarly, if you’re using other testing frameworks, you’re also in luck because axe-core can be integrated with other frameworks or testing libraries. Whether you are using Playwright, WebdriverIO, Selenium or others, axe-core has a library for you which can be found here: projects that use axe-core.

Applitools Contrast Advisor

Did you know that Applitools also supports accessibility testing? If you’re already using Applitools for visual testing, then you can also try their Contrast Advisor tool which can detect contrast violations using artificial intelligence. With Contrast Advisor, it can easily integrate into your existing workflow and pipelines already so no additional coding setup is needed. You can also validate the contrast of images and native applications easily with this tool.

Wrap Up

The tools above are by no means a complete list, but should help you get started when it comes to accessibility testing. Regardless of what tools you choose, you should have the same goal and that is to catch as many accessibility issues as possible before giving it to your real users. 

By using a combination of these tools as early as possible, along with other accessibility testing strategies, you can ensure that your user experience is inclusive. The above tools should not be a replacement for accessibility testing with real users but should complement it instead.

How Can I Help?

Accessibility doesn’t start and end with tools. It requires a change of culture and wider buy-ins to make sure that everyone is on the same page. If you or anyone from your team requires specific consultation help with regards to accessibility, I’m happy to have an introductory chat to help you nurture accessibility within your team. You can contact me via Twitter @mcruzdrake or via my personal blog at mariedrake.com.

The post Top 10 Accessibility Testing Tools for Websites appeared first on AI-Powered End-to-End Testing | Applitools.

15% of the world’s population live with a form of disability. That’s equivalent to about one billion people. As we now live in a digital era where everything can be accessed online, we need to make sure that the features we provide are accessible to everyone, including those with disabilities. Accessibility testing is definitely not something new – it’s something that we’ve been trying to do for many years now. Yet until now, the number of inaccessible websites that we encounter are still very high.

The Accessibility Problem

Speaking with different individuals, it seems that there’s still a lack of buy-in from various teams to prioritise designing, developing and testing for accessibility. We’ve all heard about the infamous Domino’s accessibility case. There are regulations out there that state that organisations must have a responsibility to make sure that their products are accessible by people with disabilities. However, based on WebAIM’s accessibility research called the WebAIM Million, where they analysed the homepages of the top one million websites every year, they stated that “Users with disabilities would expect to encounter detectable errors on 1 in every 17 home page elements with which they engage.” From their research, they approximately found 51 million distinct accessibility errors. While the results for 2021 are slightly better than previous years, a significant chunk of work still needs to be done to make sure that the web is accessible for everyone.

There are a lot of available tools out there that can help us with accessibility testing. Giridhar Rajkumar has previously blogged what are some of the accessibility testing tools we can use to help us with testing (Accessibility Testing: Everything You Need To Know). However, the statistics above show that there’s still a lot of work to be done. In this blog post, I’ll explain why designing for inclusivity wins, why we need to talk about accessibility a lot, what we can do to create a culture of inclusivity and how to shift accessibility testing to the left.

Designing for Inclusivity

When we design for inclusivity, everyone wins. Let’s look at an image below to explain this concept.

Basically what we have here is we have a baseball game and a fence separating the people watching it and to also stop people running to the baseball field. Not everyone can see through the fence unless you are tall enough. This represents inequality. To remedy this, on the first image, we can give everyone a box to stand on even if they don’t need a box to emphasise equality. Some people will be able to watch along just fine but others won’t.

The second image shows that some people who are not tall enough can ask for additional boxes so they can watch the game. However, this is bad equity because someone needs to be there to hand out boxes physically which can be seen as an extra business overhead.

In order to not increase business overhead, we can just make the fence see through like in the last image. It still keeps people from stepping into the baseball field and at the same time, everyone can watch the game without anyone handing them boxes. Everyone wins if you think about being inclusive. Rather than seeing this as a cost overhead, it’s now become a revenue generator because everyone, whether you’re tall or small, in a wheelchair or not, can enjoy the game.  

Talking About Accessibility

So why is it that so many teams still think accessibility is a nice to have feature rather than having it embedded right from the beginning? I think the answer is we don’t talk about accessibility a lot. It’s not because our teams can’t code accessible websites, but because there is a missed education around the importance of accessibility which then leads to no consideration at all for accessibility. By educating our teams the benefits of having accessible products, we can get them to understand why we need to include it in the first place. 

We need to educate our teams that accessible products are easier to use and it increases user satisfaction. The more users a business can reach, the better it is for the business since it will have financial benefits. Accessibility is also linked to higher SEO ranking and better quality code. It avoids lawsuits and legal complications and encourages independence amongst all our users.

Creating A Culture Of Inclusivity

There’s all kinds of areas where we can bring value and make things more accessible but it starts from creating a culture first of inclusivity. This book that I read by Regine Gilbert called Inclusive Design for a Digital World, which I highly recommend to everyone, explains how it takes a whole village to make accessible products. It’s not only up to us, it’s up to everyone. 

Accessibility tools are here to help us and it can provide value but if there is no change in mindset and culture, then shifting accessibility testing to the left will be difficult since you’ll get resistance from the business to prioritise it. 

Shifting Accessibility Testing to the Left

In order to shift accessibility testing to the left, we need to make sure that accessibility is part of every stage of the development lifecycle and even as far left as possible from the planning stages. Rather than reacting to it right at the end, proactively discuss it as early as possible and get buy-in right from the start. Get your project managers involved and your leadership team onboarded so they know that it’s a priority and educate them that if it’s left out right at the end, it can be time consuming to fix the accessibility issues and exponentially expensive. 

Shifting accessibility is not just about automation. It’s also about having these conversations earlier on the cycle and trying to influence everyone in your team and the business so that everyone is on the same page.

Apart from early conversations and using automation to catch basic accessibility issues, the following are some of the example activities that you can do to shift left:

• Sit with your UX and Design team and test the design mock-ups. Verify if the general layout is clear and the colours use high contrast.
• Participate in planning sessions and contribute what scenarios need to be taken into consideration. This is where adopting different personas can help.
• Plan ahead on how it should be used by keyboards and screen readers and share that knowledge to your team.
• Participate in code reviews if you can. Semantic tags have built-in accessibility features so make sure that these are used appropriately.
• Try pair testing to catch more accessibility issues earlier on. 
• Integrate automated tests as part of your continuous integration pipelines so you can provide faster feedback to your team.

When accessibility is embedded right from the start, user experience will improve and be simplified and barriers for people with disabilities will be removed.

More Resources

Accessibility can be overwhelming, there are tons of resources out there with lots of information. The Web Content Accessibility Guidelines contain a lot of valuable information but it can be daunting to absorb all that information especially if this is your first time. 

So, what can you do? Start talking to your teams about accessibility! Find your allies and get that buy-in from the business by explaining the benefits. Remember that it needs a shift in culture and mindset. Once you have that support, if your website is live already, it’s a good idea to first see how accessible it is. Have an accessibility audit performed so you can see where the issues are. Start with a single page and acknowledge that it will take time. You won’t solve all the issues at once but that is ok. Every small accessibility fix that you and your team introduce will make it better for someone out there.

If you want to know more about testing for accessibility, check out this free course from Test Automation University – Test Automation for Accessibility.

The post Shifting Accessibility Testing to the Left appeared first on AI-Powered End-to-End Testing | Applitools.

Note: Today’s guest post author, Giridhar Rajkumar, holds many roles: speaker, author, founder, and instructor. He founded Tips for Test Automation, LearnDevTestOps, and The Tester’s Hub. He serves as a Cypress.io ambassador. Giridhar has 10+ years of experience as a test automation consultant at Wipro Limited. 

We all are living in a Digital Era where the smartphones and web applications dominate everything we do in day-to-day activities some way or the other. The time we spend daily interacting with our phones or laptops is huge these days.

We need to understand the fact that not all people would be able to use today’s mobile or web applications in the same way. There are people with various disabilities which makes the usage of some applications not accessible to them.

An application should always be built keeping in mind about all types of end-users. Considering the statistics released by the WorldBank – 

“One billion people or 15% of the world population undergo some sort of disability.”

So, as an organisation, it is our foremost duty to consider accessibility testing a priority before we release any applications to our end users.

In this article, we will see a few types of common disabilities, how to perform accessibility testing and some of the commonly used tools in the market to perform various types of accessibility testing.

Types of disabilities

There are multiple types of disabilities people will face at some point in time in their life. Here are some common disabilities:

1. Physical Disability 
2. Cognitive Disability 
3. Eyesight / Vision Disability 
4. Hearing Disability
5. Temporary Disability

Physical Disability is a kind of a disability where people may have challenges with speaking, rely on motorised equipment and cannot access physical devices like a keyboard or mouse to interact with the applications.

Cognitive Disability is the type in which people have poor memory and have difficulties in understanding and expressing their thoughts to the other person.

Eyesight disability is one of the most ¹ disabilities and again, according to the World Health Organisation, around 2.2 million people globally have visual impairments or blindness.

Hearing Disability is the inability to hear. This can be partial or complete deafness.

Temporary Disability can occur due to environmental conditions, illness or accidents and mostly a temporary situation.

How to perform Accessibility Testing?

Now that we know the common disabilities, it’s time for us to know how we can leverage the testing strategies for accessibility. But before that, we need to know a few artifacts that are considered industry standards.

Web Accessibility Initiative (WAI) of the World Wide Web Consortium (W3C) has issued a set of guidelines known as ‘The Web Content Accessibility Guidelines (WCAG)’ which organisations must strictly follow to make the application accessible to people with disabilities. The different phases of SDLC should follow these set of guidelines as part of their Non-Functional Testing process.

These guidelines can be found here.

For each and every guideline, there are testable success criteria, which are at three levels:

• A (lowest)
• AA (mid-range)
• AAA (highest)

These levels may vary from different organisations and in different situations. Conformance at higher levels indicates conformance at lower levels. For example, by conforming to AA, a Web page meets both the A and AA conformance levels. Level A sets a minimum level of accessibility and does not achieve broad accessibility for many situations. For this reason, UC recommends AA conformance for all Web-based information.

Many organisations practically do accessibility testing by recruiting real-time testers in their own abilities to validate whether their product meets the correct user experience.

Having said that, let’s now see how we can perform accessibility testing for the types of disabilities we read about earlier.

Physical Disability

1. Check whether there is voice recognition software and test its consistency

2. For people with a speech disability, check whether the physical keyboard is efficient to use

3. People with a motor disability should have an option to find human help in case of emergencies

4. Test the application with a specialised mouse for people who have limitations in muscular control

5. Make sure the timeouts are configured accordingly as the user consumes more time for situations like entering the values in the form etc.

Cognitive Disability

1. Check whether the controls are clear for the users to use

2. Easily understandable menus so that the user can select what they need

3. Maximum usage of images and graphs instead of texts which make understanding the context difficult

4. Test whether the user can complete a task without unnecessary distractions like alerts, advertisements, etc.

5. Validate whether there is an option to find human help

Eyesight / Vision Disability

1. Test whether the application provides keyboard shortcuts for all the operations used by a mouse

2. Text to audio converters

3. Magnifiers in place for fewer vision abilities

4. Fonts used are satisfying the rules of W3C Accessibility Checker

5. Color blindness filters

Hearing Disability

1. Test whether the application alerts the users with vibration even when that feature is turned off (mobile apps)

2. Providing manuals in sign language for better understanding the application

3. Flash alerts in mobile phones like led lights flashing during incoming calls

4. Audio to text converters in place

Temporary Disability

This type of disability is spontaneous and can happen anytime in one’s life. This can include a foreign person using an ATM in a region where the language could be a barrier. In this case, we need to see if there is an option in the ATM system to use a common language, commonly English to control.

There might be a situation where a person can have a broken arm or undergo surgery on one eye. So we need to ensure whether the application we develop can be adapted by the user during those situations without giving stress to the users.

Though we are in a digital era, not all disabilities are identified and addressed. So in reality, unfortunately not all types of disabilities are considered while an application is built and released.

Tools to perform Accessibility Testing

With all the guidelines defined according to W3C standards, one or more tools can be used to validate the required success criteria of the application. Accessibility testing can be achieved either manually or automated. There are several open-source and commercial tools in the market to test the application for accessibility compliance. 

Following are some of the tools that can be used.

Screen Magnification

People with limited vision may not be able to read the content with the normal font size. Such people need to zoom in on the content to read it.

Magnifier App in Windows and Zoom option in macOS are excellent tools. 

Color Contrast Analyser

Color Contrast Analyser (CCA) helps to keep sufficient contrast between foreground and background colors by providing appropriate test results.

Applitools Accessibility Testing

Applitools uses AI powered computer vision (Visual AI) to help identify potential contrast violations. If the measured contrast ratio in text or images is less than the minimum defined by WCAG then a contrast accessibility failure is flagged for that element. It can be used for both web, mobile web, and native mobile applications.

Users can toggle between WCAG 2.0 or 2.1 as well as AA or AAA to be advised on how well their website or application complies. 

This product can be enabled within your existing automation framework with a simple line of code, or easily configured to automatically scan your site or application without writing a single line of code.

Contact Applitools to schedule an early-preview demo today.

Screen Readers

Screen readers are the tools used for narrating the content of a page. A screen reader can narrate everything for the user like the texts on the website, links, checkboxes, radio buttons, images, etc.

Here are some famous screen readers for browsers and mobile devices:

• IE and Chrome: JAWS (Job Access With Speech)
• Firefox: NVDA (Non-Visual Desktop Access)
• Safari: Voice Over 
• iPhone: Voice Over
• Android: Talkback 

Speech Recognition Tools

Speech recognition tools are used to interact with the application by dictating text or commands to it. It can be used to dictate text, control buttons, links, open an application and other controls. Windows Speech Recognition, Apple Dictation and Dragon are some common Speech Recognition tools.

Axe Browser Plugin

Axe is a browser plugin for Chrome and Firefox web browsers. It scans the web page to find for WCAG 2 (Web Content Accessibility Guidelines 2) and Section 508 (Standards defined for Federal Agencies) accessibility and reports the violations. The axe-Chrome extension utilizes the axe open-source JavaScript library developed by Deque Systems.

WorldSpace Attest from Deque

The Worldspace Attest is a toolkit used by developers while they code. It supports the shift-left approach to identify the accessibility issues (as per the guidelines defined by WCAG, Section 508, etc.,) much earlier in an automated fashion. This has the feature to integrate with the existing test automation framework which will check for the compliance issues while the functional tests run.  It currently supports all major browsers like IE, Chrome, Safari, Firefox. It has extensive support for both iOS and Android devices as well.

It’s Everyone’s Right!

As per the United Nations Convention on the Rights of Persons with Disabilities (UN CRPD), access to information and communications, including web & mobile applications, is defined as a basic human right and applications must comply to Accessibility Standards.

Performing accessibility testing will help us make our applications friendly to those with disabilities, thus offering them equal rights to the digital world. 

Remember, everyone will become disabled in some way, sometime, in our lives as part of nature’s cycle.

References:

• https://www.worldbank.org/en/topic/disability
• https://www.w3.org/WAI/standards-guidelines/wcag/
• https://www.who.int/news-room/fact-sheets/detail/blindness-and-visual-impairment
• https://app14743.cloudwayssites.com/docs/api/eyes-sdk/classes-gen/class_configuration/method-configuration-setaccessibilityvalidation-selenium-java.html
• Slideshare by Manoj Kumar

For More Information

• Upskill and Create New Tests Much Faster – The Impact of Visual AI
• How To Remove Blind Spots With Visual Testing
• A/B Testing: Validating Multiple Variations
• How To Ace High-Performance Test for CI/CD

The post Accessibility Testing: Everything you need to know appeared first on AI-Powered End-to-End Testing | Applitools.

As front end developers, our job is to present visual information that looks good and gives users cues to help them understand content quickly. Even a static, text-only web page is more than a collection of words. The page has a title that appears at the top. The title may be bold or in a large font size. In the body of the text, words are grouped into sentences that end with periods, and related sentences are grouped into paragraphs. Certain words in a sentence may be emphasized with bolding, underlining, or italics. These examples barely scratch the surface of the many, minute details of visual web page design.

These components may seem basic and unimportant, but for many people, accessing and reading text on a web page is difficult. For example, individuals with visual impairments often struggle to read the text. When we think of visual impairment, most of us automatically picture a person who is blind, but there are many other types of visual impairment to consider, including color blindness, low vision, sight problems caused by degenerative disorders, etc. The range of disabilities and handicaps our users may have extends far beyond the visual category to include hearing, cognitive, motor, and other types of issues. Therefore, making sure your website or application is accessible rises to the utmost importance. 

Since front end developers handle the visual presentation and functionality of web pages and applications, we need to be aware of and address the accessibility issues that exist for those who have disabilities and handicaps. While we all have a moral imperative to do our best to make websites and applications accessible, front end developers in many countries also have a legal obligation to do so.

This post will define what accessibility means and will discuss what kinds of issues front end developers need to be conscious of in terms of providing accessibility. We’ll also review some of the available methods, tools, and resources to address these issues.

What Is Web Accessibility and Why Do You Need to Be Involved?

The World Wide Web was created for the purpose of sharing research amongst atomic physicists at CERN. As the web grew, the World Wide Web Consortium (WC3) was created to govern it. The WC3’s mission states that the web was created to enable human communication to benefit all people, no matter where they live or what physical and/or mental abilities they may have.

Web accessibility ensures that people with physical and non-physical disabilities have equal access to the web. It helps people with impaired auditory, cognitive, neurological, physical, speech, or visual functions perceive, understand, navigate, interact with, and contribute to the internet. To help web developers and designers make their pages and applications accessible, the WC3 launched the Web Accessibility Initiative (WAI), which provides guidelines for making the web available to people with disabilities. Providing accessibility also helps other groups, such as users of mobile technologies, older people, people who have temporary disabilities (e.g., someone who is recovering from an injury caused by a physical accident), and people in certain locations and countries with limited bandwidth.

Beyond our basic obligation to help our fellow human beings, there are also practical reasons for providing equal accessibility. No matter what type of organization we work for, be it commercial, non-profit, governmental, etc., we need to accommodate all users and customers. If we understand what our users need and provide methods to meet those needs, any person, no matter their physical or other limitations, can buy our products and use our services.

As the reach of the internet spreads to individuals with limited income and to less developed countries, we risk losing huge numbers of potential customers if we don’t make our products accessible to them. According to the World Health Organization (WHO), one out of seven people of the world’s population is disabled or handicapped in some capacity. So, if we fail to meet this population’s needs, we’re missing out on approximately one billion potential consumers.

In some countries, front end developers are also legally required to provide accessibility. Many governments around the world have adopted the WC3’s Web Content Accessibility Guidelines (WCAG) 2.0. WCAG 2.0 provides guidelines for implementing solutions, but it isn’t tied to any specific technologies. The UN and local initiatives have also used WCAG 2.0 as the basis for their accessibility legislation. Countries that currently have laws governing web accessibility include Australia, Brazil, Israel, the United Kingdom, the United States, and the member states of the European Union.

How to Provide Web Accessibility

Since we have a limited amount of space in this post, we’ll concentrate on vision and cognitive impairments for our specific examples of how to provide web accessibility.

One of the simplest ways to accommodate these users is to provide good page semantics. Semantics are the elements and structure of a page that give it meaning to a human reader. A page’s semantics are created by applying the correct HTML elements in the right sequence (e.g., using page headings H1 and H2 in the correct order). You can also differentiate between different types of content by using bulleted and numbered lists. Page semantics matter because assisted reading technologies, such as screen readers, use them to process the page and read it aloud to people with visual impairments.

Page semantics are also important for helping individuals with cognitive disorders. For example, people who have dyslexia can see words and pictures, but they have difficulty extracting meaning from the raw, visual input because of difficulties with processing contextual information like letters and word order.

There are a variety of ways to make information accessible for users with disabilities and handicaps. To help people with low vision and dyslexia, you can use a high-contrast color palette. You can achieve this contrast by using a dark color like black as the background color and a bright color like white or yellow for the foreground text.

Front End Development and Accessibility

As front end developers, we have the power to make equal accessibility a reality. There are a number of tools you can use to build and test web accessibility. We discuss some of the best tools below.

ARIA

The Angular, React, and Vue frameworks all provide support for the Accessible Rich Internet Applications (ARIA) toolkit. 

ARIA is a WIA platform that standardizes how developers can build web-accessible applications and present content for people with disabilities. It provides the required functionality for assistive technologies (e.g., means to control input devices for people with limited/impaired motor functions and screen readers for people who have visual impairments).

ARIA can be used as an indicator of the state of a web component to a screen reader or an input device. In a web application, components indicate their current state visually. If the state of the component changes, the object’s presentation changes. For example, a checkbox indicates the values are true by displaying a checkmark, and false by leaving the box blank. To support assistive technologies, additional semantic information is required so that the component’s state can be presented to the user.

To provide this information, you can add the ARIA-checked label to the component. If the page is read by a screen reader, it will use a label to inform the user if the box is checked or not. If the page is being used by a person with limited mobility, component state changes can be indicated via haptic feedback.

Ally.js

While ARIA can help you identify components and provide state information to users, it doesn’t have any built-in support for navigating web pages. In this context, navigating a page refers to two things: moving between page components and indicating the order in which they should be used. For example, if a website requires a user to change their password, it will ask them to type a password into one text box, retype it into a second text box, and then press the submit button. After each step is completed, visual cues in the application tell the user what to do next and where to place the required input. For a user who is unable to use conventional input devices, it’s difficult to enter the information in the correct location and navigate to the next component in the correct order.

Ally.js is a library that enables users with restricted mobility and limited vision to navigate web pages. It does this by providing an accessibility tree that shows the structure of the page and indicates any objects and components that have semantic significance. The accessibility tree defines a web page’s Sequential Navigation Focus Order, which is a list that determines the sequence in which components are accessed via an input device.

Test Automation

There are many available tools for testing web accessibility, but testing often involves boring and repetitive tasks. So, there are many tools and frameworks for automating functional, regression, and visual testing. Testing accessibility can be done by using the same methods and tools. The best tool for the job is the aXe platform, which is an open-source project that provides assertions for accessibility testing and integrates with a large range of testing and CI systems.

Conclusion: Committing to Making the Web Accessible to All

We all agree that everybody, no matter what mental or physical restrictions they may have, should have equal access to the web. There are clear moral, economic, and legal reasons to make the web accessible, and there are also guidelines, techniques, and technologies available that can help front end developers actually make it happen.

With the many tools we have at our disposal, creating accessible web pages and applications has never been easier. Accessibility support is baked into the major platforms via ARIA for front end developers. If you need extra functionality that isn’t provided by your framework of choice, you can use ally.js. You can even do automated testing with the aXe platform to test your applications for web accessibility. With empathy, understanding, and the proper tools, front end developers have the power and the responsibility to make the web accessible to all.

To learn more about Applitools’ visual UI testing and application visual management (AVM) solutions, check out the tutorials on the Applitools website. To get started with Applitools, request a demo, or sign up for a free Applitools account.

The post Making Your Website/Application Accessible: a Guide for Front End Developers appeared first on AI-Powered End-to-End Testing | Applitools.

Automating accessibility testing is not only about making it easier for those with disabilities to access your site and app, but also optimizing your overall automated testing efforts, in order to support speedy product delivery without sacrificing software quality.

Watch this webinar to learn how to effectively automate accessibility testing, including: industry standards, challenges, available tools, and see – step by step – how to write a proper automated test. 

Leading companies are currently moving into Continuous Delivery and DevOps model, aiming to speed up their release cycle with a variety of tools and processes that support Continuous Integration. To match this need for speed, a fast feedback mechanism – “Automated Testing” – is used to validate the build.

But functionally testing an app is not enough, as it ignores end users with disabilities. Today. app developers and test engineers must validate the accessibility of the app to ensure it can be accessed by everyone – and that includes people with disabilities, which account for a large percentage of the population

Listen to Test Automation and Selenium expert Manoj Kumar in this in-depth session, where he covers the essentials of Accessibility Testing, including:

• What is Accessibility testing
• The Accessibility standards
• Different tools available to automate Accessibility testing
• How to automate Accessibility testing, and what resources are needed
• How to implement an effective Accessibility strategy within your organizations

Manoj’s slide-deck can be found below:

And you can watch the full recording here:

To read more about Applitools’ visual UI testing and Application Visual Management (AVM) solutions, check out the resources section on the Applitools website. To get started with Applitools, request a demo or sign up for a free Applitools account.

The post Automating Accessibility Tests: Web is for Everyone appeared first on AI-Powered End-to-End Testing | Applitools.