What’s happening:
A team has communicated they’re not responsible for the accessibility of their product or certain aspects of it.
Examples
- A team states the issues are contained in features produced outside their team
- The issue originates in the design system and/or component library
- Issues are authored in a content management system (CMS) by a different team
- A 3rd party vendor plugin is causing the issue
How to help
Sometimes coaching is more than helping individual contributors remediate code or redesign a feature.
This is where some collaboration with stakeholders is required.
Find key stakeholders
Commonly, the people who need to talk to each other the most are the very people who talk to each other the least.
Take the time to discover who understands the complete picture of the issue you’re trying to solve.
Don’t be surprised if the a product owner doesn’t know how to contact the right people to remediate an issue.
You may need to spend a significant amount of time communicating in person until you find the right contacts who can coordinate a response.
Study and help adjust processes
Take the time to get to know a team, their product and their process for delivering software.
Be able demo why something is a problem
Being able to show the issues for someone using a feature is much more powerful than a spreadsheet report.
Product owner misconceptions
Be prepared to refer to assessments, remediation policy and accessibility targets set by leadership.
Product owners, depending on their level of technical experience, may have a variety of viewpoints about accessibility, and there is plenty of opportunity for them to see it as out of their scope.
Acceptance criteria aren’t necessary
They should be adding acceptance criteria to features and stories including accessibility, then verifying those criteria are met before closing the story.
The component library is accessible, so they don’t have to worry about anything
While an individual component can be completely accessible, they can be used in completely inaccessible configurations.
A helpful analogy is building a wall with bricks. Individually bricks are quite strong, but they can be arranged in fragile and very weak ways.
The design review means the product is accessible
A common belief is accessibility is solely about color contrast and text size, completely discounting assistive technology.
When a PO does not have a technical background, there is often a lack of understanding how the code affects the UX for people using assistive technology.
3rd party misconceptions
They’re not responsible for ADA compliance
If the contractual arrangement calls for the deliverables to be ADA compliant, but the vendor isn’t delivering on that agreement, this is a good time to engage the vendor relationship manager and possibly legal counsel to make the requirements clear.
They’re not responsible for testing
It’s possible the 3rd party believes another entity is responsible for testing.
Designer misconceptions
Designers may know about color contrast and alt text, but know very little about keyboard and screenreader experiences.
Accessibility is handled by the developers
Because accessibility is not seen as part of UX, it is assumed it is a technical issue for developers to sort out.
The UI design system is accessible, so I don’t have to worry about it.
While an individual design component can be completely accessible, they can be used in completely inaccessible patterns or with difficult to understand language.
Developer misconceptions
The developer thinks because they’re using the component library they don’t have to worry
While an individual UI component can be completely accessible, they can be arranged in patterns that are completely inaccessible.
A helpful analogy is building a wall with bricks. Individually bricks are quite strong, but they can be arranged in a way that is fragile and very weak.
It’s QA’s job to catch accessibility issues
Waiting for QA to deliver results in waterfall fashion is the antithesis of agile methodology.
If acceptance criteria are set by the PO, it’s the developer’s responsibility to demonstrate those criteria are met.
By the time a QA tester produces a report, the work becomes remediation which is time consuming and expensive.