Accessibility in Agile Projects

www.planittesting.com
Accessibility in Agile
Projects
Exploring the requirements, roles and
responsibilities of Agile teams for
accessible delivery.

www.planittesting.com © Planit 2
Web accessibility refers to the inclusive practice of removing barriers that prevent interaction with, or
access to websites, by people with disabilities. When sites are correctly designed, developed and
edited, all users have equal access to information and functionality.
What is web accessibility?

Why is accessibility important?
© Planit 3

15% of the world’s population (1 billion people) experience some form of disability.
(World Report on Disability, World Bank/WHO, 2011)
1.1 million people in New Zealand (1 in 4) identified as having a disability.
(2013 Disability Survey, Stats NZ, 2013)
4.3 million Australians (1 in 5) have a disability, inclusive of limitation, restriction or impairment.
(Survey of Disability, Ageing and Carers, Australian Bureau of Statistics, 2015)
13.3 million people in the UK (1 in 5) reported to be living with disability.
(Family Resources Survey 2015/16, Department for Work & Pensions, 2016)
26.8 million people in India reported having a disability.
(Measurement of Disability through Census, National Experiences: India, Office of the Registrar General & Census Commissioner, 2011)
Current global statistics

Reasons for testing
• Digital accessibility enables independence, choice,
convenience and inclusion for people who require
access using technology.
• Potential for litigation and lawsuits if your content is
inaccessible. For many government agencies,
accessibility is a legislative requirement.
• Poorly designed websites and apps can cause great
difficulties for people with disabilities. Creators can
make content accessible by knowing what to do.

Visual: mild or moderate vision impairments in one or both eyes (‘low vision’ or ‘partial
sight’), to substantial loss of vision in both eyes (‘blindness’). Includes reduced sensitivity to
colour (‘colour blindness’).
Auditory: mild or moderate hearing impairment (‘hard of hearing’), to substantial impairment
in one or both ears (‘deafness’).
Cognitive and neurological: disorders of any part of the nervous system, including the
brain and the peripheral nervous system. Impacts ability to learn and understand information.
Physical: limitation of muscular control, involuntary movement, lack of coordination,
paralysis, joint problems, missing limbs (“motor disabilities”).
Speech: includes difficulty producing speech that is recognisable by others or by voice
recognition software.
Diversity of digital users
Source: https://www.w3.org/WAI/intro/people-use-web/diversity

Diversity of digital users (cont.)
• Age-related impairments: includes significant differences in the use of assistive technologies, the level of computer
skills, or in the use of the web in general.
• Multiple disabilities: Some people have combinations of different kinds of disabilities, which may limit their
approaches for interacting with the web. (e.g. someone who is deaf and has low vision might benefit from captions
for audio, but only if these captions have adjustable size and colour.)
• Health conditions: Some people have health conditions that may affect their stamina, dexterity, or concentration.
• Changing abilities: Some people may experience progressive or recurring functional limitations that impact their
use of the web differently at different times.
• Temporary impairments: Some people may be experiencing temporary impairments such as those that may occur
due to an accident, surgery, or medication.
• Situational limitations: Some people may experience constraints due to their surrounding or due to other situational
aspects. For instance, they may be in a loud environment and unable to hear audio, in bright sunlight and unable to
see a screen, or they may not be able to afford some technologies.

Moral/ethical
The ‘right thing to do’
Important to create an
inclusive experience
Corporate
Maximising product
user experience
Larger market =
more $$$
Legal
Legislative
requirements
Lawsuits due to
inaccessibility
Drivers for accessibility

Diverse user experiences
© Planit 9

Examples of assistive technologies
Screen readers
A screen reader is a software application which, rather than presenting web content visually,
converts text into 'synthesised speech' allowing users to hear content.
Windows:
• Microsoft Narrator
• NV Access NVDA
• Freedom Scientific JAWs
OS X:
• Apple VoiceOver for OS X
iOS:
• Apple VoiceOver for iOS
Android:
• Google TalkBack

Screen magnification
A screen magnifier is software that interfaces with a computer's graphical output to present
enlarged screen content. It is generally used by people with visual impairment to enlarge
text and content.
Windows:
• Microsoft Magnifier
• Glassbrick Screen Magnifier
• Freedom Scientific MAGic
OS X:
• Apple Magnifier for OS X
iOS:
• Apple Magnifier for iOS
Android:
• Google Magnification
gestures
Web browser zoom:
• IE, Edge, Chrome,
Firefox, Safari

Input devices
Software functions must be accessible using both the keyboard and specific input devices.
Specialised solutions are available, including on-screen software keyboards and alternate
input devices (switches, joysticks, trackballs, sip-n-puff).

Braille display/reader
A refreshable braille display or braille terminal is an electro-mechanical device for displaying
braille characters, usually by means of round-tipped pins raised through holes in a flat
surface.

Guidelines and standards
© Planit 14

W3C Accessibility Guidelines
Web Content Accessibility Guidelines (WCAG) 2.0 & 2.1
Accessibility guidelines for websites, media content & web applications
Authoring Tool Accessibility Guidelines (ATAG) 2.0
Ensures authors and people with disabilities can utilise tools to create accessible content
(Drupal, WordPress, Squarespace, etc.)
User Agent Accessibility Guidelines (UAAG) 1.0
Guides developers to create user agents that make the web more accessible to people with
disabilities (NVDA, Braille reader, JAWs, ChromeVox, etc.)
Accessible Rich Internet Applications (WAI-ARIA)
Allows assistive technologies to interact with dynamic and complex user interface controls
(carousel banners, live update widgets, etc.)

Accessibility & Agile

Everyone has a role to play, and this includes you!
All Agile team members need to play their part to develop accessible and inclusive experiences for
users with diverse requirements.
• Product Owners
• Developers
• Designers
• Content Authors
• Testers
Accessibility responsibilities in Agile

Product Owners
• Accessibility requirements start with you.
• Understand your company’s responsibilities and accessibility
compliance targets.
• Research accessibility guidelines and clearly communicate your
expectations to Agile teams working on an inclusive product.
• Create user stories for diverse personas including users with
accessibility requirements.
• Embed accessibility into your acceptance criteria.
• Make inclusive design part of your showcases for acceptance
before marking stories as done.

Developers
• Use compliant code for scripts, structure, labels, roles and values in line
with W3C guidelines and conformance requirements (e.g. WCAG 2.0/2.1).
• Perform code validation using automated tools (e.g. W3C Markup
Validation Service, WAVE, aChecker, etc). Accessibility errors and
warnings from automated tools should be manually reviewed to remove
false positives.
• Ensure your platform is navigable for non-mouse users. Some people
may require only keyboard controls on desktop, specific gestures on
mobile devices, or an input device as their preferred navigation tool.
• Provide meaningful page titles across your platform. This can
significantly improve navigation and provide context for screen reader
users and people with cognitive disability requirements.

Designers
• Use accessible colour combinations. Users with colour blindness or visual
impairment may experience difficulty reading text or seeing content across your
platform if your style guide is not accessible.
• Avoid reliance on sensory characteristics. Interfaces which rely on single
senses (e.g. sight, sound, speech, etc.) may exclude users with disabilities.
• Do not use colour alone to convey information. Users with visual impairment
may not be able to understand information conveyed by colour changes alone
(e.g. input field errors, single colour buttons, etc).
• Ensure consistent navigation and identification. Links, buttons, menu items
and components with similar functionality should be easily identifiable and usable
for the end user.

Content Authors
• Provide alternative text on images. Non-visual users require
access to visual content, particularly images, on your digital
platform. This is usually implemented via an alternative text
attribute, an ARIA label or long description attribute to help
screen readers interpret non-text content.
• Avoid images of text. Using image files like JPEGs or GIFs
containing text content can make it hard for users to customise
text presentation according to their preferences.
• Use meaningful link names. Link labels like “click here” or
“read more” can create difficulty for users to understand where
the link will take them. It can also cause navigational difficulty
for screen reader and keyboard users.

Testers
• Study the accessibility guidelines. It’s essential for testers to
understand W3C guidelines like WCAG 2.0/2.1 across Level A, AA
and AAA success criteria.
• Understand accessibility issues from an end user’s perspective.
Knowing how to spot defects is just the beginning. Learning how
inaccessibility impacts the experience of people with disabilities is an
entirely different skillset which can be mastered.
• Be part of the team from day one. Testers and consultants should
be available from project start to guide Agile developers, designers
and content authors on inclusive best practices.
• Testers with lived disability experience should be involved in the
QA process.

Embedding accessibility requirements into Agile ceremonies are important to empower the team, share
knowledge and drive successful development.
• Sprint Planning
• Daily Stand-up
• Iteration Review
• Retrospective
Agile ceremonies
Source: https://www.atlassian.com/agile/scrum/ceremonies

Sprint Planning
• Effective sprint planning sets the entire team up for success.
• The product owner can provide a prioritised product backlog
highlighting accessibility issues and expected conformance
requirements.
• Development teams can discuss accessibility issues, how to
meet guidelines and collectively estimate the remediation
effort as a group.
• The sprint forecast outlining how much work the team can
complete should also include the accessibility effort. This
information feeds into the sprint backlog.

Daily Stand-up
• The tone of your daily stand-up meeting should be light and fun, but
also informative.
• Take accountability for what you have completed, what you will be
working on and what may be blocking accessibility progress.
• Use your stand-up time to raise accessibility compliance questions
and concerns with the team. Significant issues can be discussed in
detail with specific team members outside the stand-up.
• The team should have an up-to-date understanding of the project’s
accessibility status. Use your stand-up time to briefly discuss
development fixes, design updates, content changes which may
impact the project’s accessibility conformance level.

Iteration Review
• Iteration review is a time to showcase the work of the team.
• The team should celebrate inclusive design accomplishments
within the iteration, highlight accessibility achievements and
receive immediate feedback from project stakeholders.
• Work should be fully demonstrable, compliant with
accessibility guidelines (e.g. WCAG 2.0/2.1) and meet the
team's quality standard to be considered complete and ready
to showcase.
• Accessibility testing is essential to ensure the project’s quality
and conformance benchmarks have been met prior to
showcasing results.

Retrospective
• Retrospectives help the team understand what worked well
and what could have been improved upon during Agile
delivery.
• Use the retrospective to share learning experiences around
inclusive development and design practices, as well as
accessibility implementation and conformance target status.
• Continuous improvement should be a key goal of the
retrospective. Streamlining accessible delivery practices for all
team members is important.
• Outstanding accessibility issues should be highlighted during
the retrospective. These can feed into improvements in future
releases and form the basis of an accessibility statement.

Content examples
© Planit 29

Level A
1.1.1 – Non-text content
Provide text alternatives for non-text content
Why is this important?
Information conveyed through images needs a text alternative. This ensures non-visual users can understand
image content (photos, icons, data charts, infographics, etc.) using a screen reader.
How to test?
• Descriptive alternative text should be applied to images which contain information.
• Decorative pictures should have an empty alt attribute (e.g. alt=“”).
An alternative text attribute should be provided within the
‘image’ element in HTML markup:
<img
src="https://cdn.pixabay.com/photo/2016/08/06/22/07/bee-
1575236_1280.jpg" alt=“Two bees on the edge of a
sunflower petal" height="474" width="711">

Level A
1.2.2 – Captions (Pre-recorded)
Provide captions for videos with audio

Level A
1.2.3 – Audio Description or Media Alternative (Pre-recorded)
Video with audio has a second alternative

Level A
1.3.3 – Sensory Characteristics
Use more than one sense for instructions
Components which refer to shape, size, visual location, orientation, or sound may prevent users with
disabilities from interacting with them.
Click the star on the right to continue
How to test?
• Check that content is not only identifiable by shape (e.g. “press the circle to continue”).
• Make sure content is not only identifiable by location (e.g. “use the link near the top of the page”).
• Ensure that content is not only identifiable by a graphical symbol (e.g. tick to confirm shopping cart items).
• Check that sound cues are not only way to interact with content.

Level A
1.4.1 – Use of Colour
Don’t use presentation that relies solely on colour
Information presented using colour differences may not be seen by users with visual disabilities (e.g. partial
blindness, full blindness or colour blindness).
Press the purple circle to continue
How to test?
• Make sure that changes using colour are also available using text.
• Check that additional visual cues are available when colour is used to convey information.
• Ensure that required fields or errors in forms are not only communicated using colour.
Resource: Colour blind awareness - Colour blindness simulator

Level A
2.2.1 – Timing Adjustable
Time limits have user controls
Users should be able to complete tasks within a comfortable timeframe. Some users may require additional
time due to disability, limitation or use of assistive technology.
How to test?
Only one of the points below is required to pass this criterion:
• Are you able to turn off the timeout?
• Can the time limit be extended 20 seconds before timeout using a simple action (e.g. spacebar key)?
• Can the time limit be adjusted to 10 times its default amount?
• Is timing linked to a live event (i.e. auction)? If so, no mechanism to extend the time limit is possible.
• Is the time limit essential to completing an activity? If so, it is exempt.
• Is the time limit longer than 20 hours?

Landmark accessibility litigation
Bruce Lindsay Maguire v. Sydney Organising
Committee for the Olympic Games (SOCOG) (2000):
• Blind web user Bruce Maguire filed a case against SOCOG due to the
Sydney Olympic Games website being inaccessible (no alternative
text on images, lack of access to event results and missing image maps).
• The Human Rights and Equal Opportunities Commission (HREOC) ruled
in favour of Maguire, ordering SOCOG to compensate him $20,000 for
unlawful discrimination and fix the website.
• The Australian Government adopted the W3C guidelines for all
agency websites from 1 December 2000.
Source: https://www.w3.org/WAI/bcase/socog-case-study

• Digital products must be inclusive and compliant with applicable W3C accessibility guidelines
such as WCAG 2.0/2.1 and ATAG 2.0 to avoid brand damage and legal repercussions.
• Implementing accessibility the right way is essential to maximising user experience and creating
an inclusive product or platform.
• Accessibility is a specialised field requiring comprehensive expertise around legislation, industry
standards, technologies, tools and best practices. This process can be learned, understood and
integrated into an existing Agile workflow through expert consultancy and guidance.
Challenges to overcome

Automated
Accessibility Tools
Manual Test
Scripts
Inspection of
Code
Consultancy and
Guidance
© Planit 40
How to do it
Heuristic Tests
Accessibility
Statement
Assistive
Technology
Accessibility
Audit Report

1. WCAG 2.0 accessibility audit, analysis & report
• Comprehensive accessibility testing of your digital platforms, products or services.
• Report document outlining WCAG 2.0/2.1 accessibility compliance (Level A, AA or AAA).
• W3C resources for your Agile team to fix accessibility issues.
• Explanation of how accessibility issues affect users and clear screenshots for development teams to identify and address problems.
2. Accessibility evaluation & workshop
• Consultancy and overview of WCAG 2.0/2.1 success criteria with Agile teams to upskill and integrate accessibility practices into
their existing workflow.
• An evaluation walkthrough with an expert, providing you with a first-hand understanding of accessibility in your projects and clear
benchmark of where you need to be.
3. Statement of accessibility
• Public-facing document outlining your accessibility status
• Outlines steps taken to implement fixes, communication of outstanding accessibility issues to your users and a clear statement
of your commitment to achieving WCAG 2.0/2.1 compliance.
Accessibility resources

Contact us
Adrian Redden
Accessibility Test Lead
+61 2 9464 0600
aredden@planittesting.com
AU: 1300 992 967
NZ: 0800 752 648
I N : +91 40 6635 9555
UK: +44 203 457 5020

Accessibility in Agile Projects

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Accessibility in Agile Projects

Similar a Accessibility in Agile Projects (20)

Último

Último (20)

Accessibility in Agile Projects