The document discusses using AXE for web accessibility testing. It begins with an introduction to web accessibility and common issues like lack of text alternatives and low color contrast. It then summarizes the WCAG guidelines and principles of perceivable, operable, understandable and robust. Various accessibility testing options are listed including AXE, which is an open source tool that can be used as a browser plugin or API for automated testing. It provides details on using the AXE JavaScript API to integrate accessibility tests into existing automation frameworks.
3. ABOUT ME
• Test Automation Consultant, Trainer
• Twitter – @aparna2019
• Linked in - https://www.linkedin.com/in/aparna-a-
gopalakrishnan-8088765a/
• Email - aparna.vadakath@gmail.com
4. AGENDA
• Introduction to Web Accessibility- What and Why?
• Common Accessibility Issues
• The Guidelines (WCAG Overview)
• Web Accessibility Testing Options/Tools
• Onto Axe
6. Difficulty hearing, deafness and hearing impairments.
Visual Blindness, colour blindness, and low-vision
caused by various eye conditions.
Various forms of limited movement caused by injury,
congenital conditions, and tremors.
Conditions that affect the brain - memory, attention, or
ability to interpret
11. • Social Responsibility
• Better Business
• Accessible websites are easier to find by search
engines
• “Accessibility Optimized” websites are easier to
navigate and simple to use
• Accessibility helps everyone
20. WCAG 2 OVERVIEW
(Web Content Accessibility Guidelines)
“The WCAG documents explain how to
make web content more accessible to
people with disabilities.”
21. THE STANDARDS
• WCAG 2.0 - published on 11 December 2008
• WCAG 2.1 - published on 5 June 2018
“Content that conforms to WCAG 2.1 also conforms to WCAG
2.0. (This is often called “backwards compatible”.) A website
that meets WCAG 2.1 should meet the requirements of policies
that reference WCAG 2.0.”
22. THE GUIDELINE
PRINCIPLES
• Perceivable - Alt Text and Captions
• Operable- Keyboard navigation
• Understandable- Link text, error suggestion, etc.
• Robust- Semantics, assistive technologies (screen readers)
24. Web Accessibility Testing
There is no substitute for real user feedback.
You need to include people with disabilities to test.
FACT
25. Accessibility Testing Options,
Tools, etc.
• Tab through the page using keyboard
• Screen readers (JAWS, NVDA, Talk Back, Speak
Screen, etc.)
• Zoom Text
• Browser plug-in(Axe, WAVE)
• APIs for automation (axe, pally, totalValidator,
etc.)
26. On to AXE!!!!
An Open source product from the Deque for accessibility testing
27. Axe
• Browser plug-in (chrome and Firefox)
• APIs for web accessibility automation
• Native apps and hybrid apps for android(Android
App and Axe Android API)
**iOS will be coming soon!
28. Axe As Browser Plug-in
Download and add browser extension to the browser and Analyze
29. Axe As Browser Plug-in
Axe plugin added
Inspect on the page
31. Axe API For Web
Accessibility Automation
➢Open source accessibility rules for automated testing
➢Can be integrated on to existing automation framework
36. Page scanning options
// To run only specific set of rules
AxeBuilder(driver).withTags([‘wcag2a’]);
//To limit analysis to only specified rules
AxeBuilder(driver).withRules(['html-lang', ‘image-alt’]);
//To disable some rules
AxeBuilder(driver).disableRules(‘color-contrast’);
37. Pros
• No false-positive scenarios
• Better rule coverage
• Seamless integration feasibility with test automation
framework
• Easy integration with CI
• Easy to use
• Open Source
Accessibility = Availability?
Accessibility is Usability of the website for disabled or differently abled people.
We are talking about people who are differently abled.
Accessibility is to make sure the user experience
Accessibility is not just following the rules. It’s about usability as well. So we have to involve people with disabilities to test
Perceivable - - about alt text and captions (briefly). Web content easier to read
Operable - Helps to navigate and look for content
Keyboard navigation
Animation and flashes
Form labels
Pause or delay (provide enough time to users to read and use content)
Understandable-
Make content readable, predictable and understandable
-providing link text
-error suggestion
-navigation
Robust-
Make content compatible
It has to be interpreted by a wide variety of user agents, including assistive technologies.
-semantics
Levels
Level A – basic web accessibility check, easiest to implement, low impact on presentation/visually
E.g.: 1.2.2 – captions must be provided for pre-recorded video
Level AA – moderate check – bit more responsible checks!
E.g: 1.2.4Captions (Live) - Level AA
captions must be provided for live videos
Levels
Level AAA – specific user impact and increased complexity to implement
E.g.: 1.2.6Sign Language (Pre-recorded) - Level AAA
Sign language interpretation must be provided for all prerecorded content
**Mostly used checks are A and AA
If we don’t involve people with disabilities while framing the problem, we wont understand how they think. And if we don’t understand how they think, we wont know how to serve their needs in the best way possible.
So here unlike any other test automation - be it functional/non functional/API/compatibility, we may not see a benefit in terms of saving time, because not all the rules are covered through automation. And not only one tool will help to find out all the accessibility issues, So we need to do a manual round of testing using screen readers or other tools to ensure there are no accessibility issues.
What matters is TEST YOUR CODE
Automating web accessibility testing is not a replacement of manual web accessibility testing.
Testing your code
Test your code regularly, using both automated testing and manual testing. These tests will also uncover issues with design and content.
It’s important to do both types of testing - you’ll miss some issues if you only do automated testing.