Design at Scale 2021- Accessibility at Scale (Sheri Byrne-Haber)
—> I gave a talk last year at DesignOps 2020 on Accessible Design Systems, and these Design Systems a factor in accessibility program that works at scale
—> But who am I and why should we listen to me?
-
I have a multidisciplinary background in law, business, tech
-
I spent 17 years in disability/accessibility space
-
I founded the McDonald’s and VMware accessibility programs
-
I cofounded the Disability@VMware employee resource group
-
I have a daughter who is disabled
—> I’ll assume no one knows anything about accessibility so we will go through the basics
—> I’ll discuss how accessibility becomes complicated at enterprise-level, and defeating the enemies of accessibility at scale
—> Accessibility is about visible disabilities. Examples of this include:
-
Stephen Hawking
-
Marley Matlin (ASL)
-
Stevie Wonnder
—> It’s also about invisible disabilities. Examples include:
-
Selena Gomez, who has lupus
-
Millie Bobbie Brown, who is deaf in one ear
-
Little Wayne, Elton John, and Prince , who all have epilepsy
-
Mark Zuckerberg, who has color-blindness
—> Accessibility involves making things work for all the people discussed
—> But who needs accessibility? Well you do, or you will
—> Disability can be permanent, temporary, or situational, and is present in up to 30% of audiences
—> Example of different variations of the same disability of being unable to use an arm
-
Permanent, i.e. limb difference, or not having an arm
-
Temporary, your arm being in a sling
-
Situational, Holding something and your arm is disabled
—> People with disabilities can do anything, as long the assistive tech works
—> So how does the tech work? Well, you got the end user and assistive tech ( which can be hardware, software, devices worn, internet of things) to connect them to an online destination
—> User interacts with technology to destination, and vice versa
-
So long as there is support for assistive technology, you will be golden with WCAG standards
—> But what is WCAG?
—> WCAG is a set of standards from the World Wide Web consortium that have come out in past fifteen years
-
Version 2.2. out in September 2021
-
Version 3.0 coming out in 2023
—> AAA is strictest, but not mandated,
-
Regulatory agencies have settled on AA, and a person can’t sell software to the public sector unless it is 2.0 AA compliant
—> Newer standard with 2.1 AA
—> Every country with accessibility standard uses WCAG as source to define what counts as accessibility
-
If you are doing work that involves accessibility, know what standard you are testing to
—> Example guidelines include
-
Captions (Deaf)
-
Color (Red/Green or pale contrast)
-
Magnification (Responsiveness as people zoom into product)
-
Language Settings and Dyslexia Needs
-
Alternative to visuals
-
Links
—> These are all common categories that are in WCAG guidelines
—> The first thing is automated code inspection, which is fast and can be done without humans on repetitive basis
-
30% of requirements can be inspected via automated code
—> Machine Learning review (data and patterns) to look at accessibility data and patterns
—> Humans who interact and test the assistive technology, who can give thumbs up/down on technology
-
50%-66% still needs to be reviewed by humans
-
This is where scale gets complicated
—> Get something accessible is straightforward (it just involves sufficient application of money and people)
-
Keeping it requires process change across large swathes of the org. If you don’t make the process changes, you will revert back to inaccessibility in 9-12 months
-
This is actually the most complicated thing to do, and talking about hundreds of software releases per day in integration pipeline
—> Where are the trouble points?
-
Accessibility at scale puts you into VUCA, an environment that is volatile, uncertain, complex, and ambiguous
-
These are not good things in the world of product development
—> When complexity and uncertainty get higher outcome predictability goes down
-
Less knowledge visibility occurs as well
—> To stay out of VUCA, use the DevOps infinite loop to reduce volatility
-
The loop involves the step of Plan, Build, Code, Test
-
Get accessibility that can be automated, as quickly as possible
-
Minimize and prevent defects through automated testing. This is the next best option to preventing defects from occurring in the first place
—> Next, reduce uncertainty by using established software development principles
-
Design, implement, test, maintain, analyze
—> Look at issues customers report, and target high priority issues that are reported, to allow disabled users to use product
—> Sign of success is getting customer reported bugs
-
Shows that people with disability are using the product, if people can get far enough to report a bug, (80% of internet world is typically unusable for people who are disabled)
—> This is useful especially with large organizations, which want to be compliant across multiple company products
-
That can be fixed through style guides
—> These efforts all reduces ambiguity
—> Accessibility is historically small
-
Typically 1-2 people in an acesssability role
-
But there is only so much that can be done on smaller end and need people talking about accessibility in the company at large
-
Employees with disabilities can help catalyze that conversation
—> Employees with disabilities will keep talking about accessibility even when the team is not in the room
-
W need to make sure you are recruiting people with disabilities, have accessible application process, and get disabled people through background checks and onboarding paper work
-
Everything must be independently usable and accessible
-
Also need to maker sure retention programs consider accessibility
—> Accessibility takes the entire organization to produce accessible products that doesn’t be come inaccessible when things start to scale up
—> Accessibility needs to be part of every product conversation
-
If not integrated, trying to jam in accessibility. Results noticeable to customers
So what makes accessibility happen in an enterprise?
—> Executive Support: Their support trickles down to the company
—> Centralized Resources: Experts who can be drawn upon
—> Champions Program: Building local expertise when centralized resources are not available
—> Accessibility Goals/OKRs: Are people rewarded for building accessible products?
—> What adds accessibility into the enterprise conversation?
-
Hire more employees
-
Listen to their lived experience
-
Include disability in all equity and inclusion discussions
—> Events need to be accessible, and need to work in an accessible manner
-
Everything you buy, use, build, need to be accessible from the very beginning
-
Sets-up situation where disability must constantly ask for accommodations to get basic access to company resources and events
—> Treat defects as bugs that need to be treated as any other products
—> But what to do with people who resist accessibility at scale? There are a few key archetypes to watch out for
—> For people hate change, since accessibility guarantees change:
- You need to find what appeals to them
—> For people demand a business case, say:
- Accessibility is a cvil rights issues, as 18% of users have some sort of disability
—> People only want to work on features, versus tech debt, which accessibility falls under
-
Create incentives and OKRs to minimize this
—> For people who trivialize accessibility
-
Make sure surveys are accessible
-
Do user research with people with disabilities
—> For excluders who feel they don’t need to accommodate people with disabilities
-
It’s a logical fallacy in that most people with disabilities don’t bother complaining or raising issues
-
If you build accessibility, people will come
—> For those who view accessibility as checking a box
-
Build accessibility organically into the org
-
Don’t rely on overlays, as they are superficial
—> This is what accessibility at scale requires
—> Thank you for listening!
—> For more info, see resources I have from my Medium blog, connect with me on LInkedIn, and my free e-book on accessibility