This document discusses how organizational silos negatively impact accessibility and provides recommendations for breaking down silos. It identifies common silos along discipline lines like development, design, QA, etc. and explains how each silo's isolated work harms accessibility. The document then recommends establishing governance, a collaborative culture, integrated standards and processes, training, and continuous improvement to break down silos. It provides action items each group can take to improve accessibility through cross-functional collaboration.
8. Developers
โข How does being siloed affect accessibility?
โข Only visual designs provided
โข 3rd party dependencies
โข Insufficient training
โข Accessibility is considered a technical challenge
9. User Experience and Design
How does being siloed affect accessibility?
โข Development challenges not identified
โข Inconsistent design decisions between products
โข User experience research not shared
โข Teams isolated from the end results
10. QA
How does being siloed affect accessibility?
โข UX not shared with QA
โข Accessibility standards not mandated
โข 3rd party dependencies
โข Test techniques not shared
โข Lack of understanding of severity
โข Lack of training in using assistive technologies
11. Product Managers
How does being siloed affect accessibility?
โข Not aware of design or development challenges
โข Accessibility challenges not shared
โข Accessibility standards not mandated
โข Customer feedback not shared
12. Business Managers
How does being siloed affect accessibility?
โข Inefficient feedback loops
โข Unclear governance structure
โข Procurement of inaccessible software
โข Signing off on ideas before being tested for feasibility
13. Accessibility Specialists
How does being siloed affect accessibility?
โข Becomes the person responsible for accessibility
โข Lack of influence
โข Lack of support
14. Accessibility Consultants
How does being siloed affect accessibility?
โข Focus on remediation
โข Focus on a product rather than process
โข Lack of organisational understanding
โข Lack of transfer of skills
19. Governance
How do we address the silos?
โข Establish a company wide sponsor
โข Define responsibility
โข Resourcing
20. Culture
How do we address the silos?
โข Culture must come from the top
โข Encourage communication and collaboration
โข Empowerment to challenge decisions
โข Empowerment to take the necessary time
21. Standards
How do we address the silos?
โข Beyond WCAG
โข Beyond compliance
โข Adapted
โข Integrated into process
22. Documentation
How do we address the silos?
โข Documentation should be living
โข Appropriate format
โข Integrated
โข Accessible design patterns / libraries
โข Visual design language
โข Text alternative libraries
โข Manual and automated tests
โข User research repository
โข Annotated UX
23. Training
How do we address the silos?
โข Training program not a one off workshop
โข Convenient
โข Provides a reference, allows for refreshing knowledge
โข All new starters receive training
โข Encouraged beyond basic training
โข Role based training available to all
24. Continuous improvement
How do we address the silos?
โข Usability studies - regular and revisited
โข Share metrics, statistics, customer feedback
โข Keep documentation and training up to date
27. Developers
Discuss the next design you receive with itโs designer; indicate where you think
there may be problems, or where there is missing documentation or information.
28. User Experience and Design
Collaborate with developers when designing and document the accessibility
features and requirements of your next design
29. QA
Ask what accessibility / user experience tests are required for the next product you
are testing.
30. Product Managers
Make sure your team has the right training and resources; let company
management know what you need.
32. Accessibility Specialists
Get accessibility written in to your objectives or job description so that you are
empowered to spend time on accessibility and share your knowledge.
33. Accessibility Consultants
Spend time to understand the organisation you work with and donโt be afraid to
recommend they don't do an audit but do something else.
Started to think of silos in terms of disciplines because itโs what weโve experienced
The above also happens to be a common order of assumed responsibility (or blame)
Also , mirrors how accessibility has evolved (used to be a developer issue, designers became aware later (as design evolved from print to web/app)
In the context of this presentation we define specialist and consultant as follows:
Specialist - embedded in design / development / management
Consultant - outsider, often brought in at the end or for remediation rather than planning
We considered two sides of silos:
How it affects you
How it affects the process
Too often visual designs are thrown over the wall to developers without enough accessibility information
Accessibility is a user design issue so needs to be led by design in the form of interaction design that includes keyboard and AT users
For example, lacking focus styles or basic information on keyboard interaction
Itโs rare for a modern website or app to be built from scratch without 3rd party dependencies, which can come from inside or outside of the organisation. It may not be possible to make a site made from mandated dependencies accessible
Itโs unfair to expect developers who have had no exposure to accessibility to make the right decisions, but this is often the case. Accessibility had to compete with 101 other requirements.
Lastly, it has been, and sadly often still is, common for developers to be the people responsibility, regardless of the decisions made outside of their control, for example, inaccessible designs or inaccessible components
Designers lacking awareness of when implementations are not technically possible or, are technically possible but a terrible user experience e.g. custom components rather than standard components such as the dial on the BBC Radio app, anything to do with hover.
Not sharing design decisions leads to inconsistency (an underlying principle of accessible UX), not possible for dev teams to be consistent if design teams are inconsistent.
Reports are not added to a central knowledge base, findings are not shared in a bitesize easy to digest manner.
Designs are handed over with no accessibility annotation, design is more than just visual design.
Once a design team has worked on a site, app, or feature they are often moved on to new projects and do not see the final results for many months and may not be aware of them going live. Similar to the dev issue but more severe. May not even be aware that the design didnโt work.
You canโt easily test for accessibility (or any other user experience aspects) without knowing what the UX should be, for example testing that focus is set to the right element when a button is activated. No collaboration between design and QA. In theory annotated UX > User Stories > Acceptance Tests, in practice its User Stories > Acceptance Tests
Often, no accessibility standard (such as WCAG 2.0 AA) is specified as a requirement, so it doesnโt get prioritised for testing (testing is a risk / reward process - only test what is required to be tested)
As with developers, the use to third party dependencies can cause a problem. They can produce false positives, or raise issues that are beyond the ability of the product to fix
Testing needs to be done in a consistent manner to lead to the same result, and this should apply across all of a companyโs sites and applications. Writing tests to prevent regressions after fixing bugs is also common, and that is an opportunity to test other sites to make sure they donโt suffer from the same problem that is often missed.
Minor issues can be flagged as critical, and critical issues as minor and then ignored. If you donโt fully understand why you are testing for something it is difficult to understand the effect a problem will have on a user, and to then prioritise it accordingly.
QA canโt test with AT such as screen readers if they donโt know how to use them
Directly responsible for a product (such as a site or app)
Often when designers or developers face challenges there is an attitude of fixing things themselves rather than communicate the potential problems. This may seem like a good thing to some product managers, but it hides problems and means that the right decisions canโt be made, or the right resources in terms of training, testing, etc. donโt get allocated.
Sometimes products can exist in isolation, with not much communication between them. This leads to different solutions for the same problems, wasted resources, fails to show where effort needs to be concentrated to solve big problems because you never find out a problem applies to more than one problem areas
Unless a business mandates a certain level of accessibility quality, for example meeting WCAG 2.0 AA, product managers have no way to measure how their product performs. Similarly a product manager must communicate their expectations to their team.
Finally, in large organsiations it is surprisingly easy for product managers to be isolated from customer feedback. Without feedback a product manager is missing a valuable way of identifying problems and therefore make improvements.
Business Manager does not directly manage a product, but might have product managers reporting to them, or may involved in business matters rather than product creation, but whose decisions still have an influence over products.
Business managers are often unaware of accessibility requirements or the state of accessibility within a company. If they arenโt getting feedback from product teams they canโt make decisions around training or resourcing.
Without management setting clear expectations there is no requirement or mandate for product managers to ensure that their teams have appropriate training or meet a particular standard of accessibility. Business Managers canโt assume that everyone knows the right thing to do, or that they are doing it.
Governance - is not provided by the BMs so no knows what their responsibility or who does what.
Business managers need to ensure that the procurement process for the entire business includes accessibility. Without this, anything that depends on inaccessible third party products or services will also be inaccessible.
A sign off process that is top down and doesnโt include designers and developers will often lead to ideas that cannot be designed or implemented in an inaccessible way. Sometimes dependencies such as advertising campaigns can be signed off before product teams have even had any input!
Specialist does not have an accessibility job title, but has taken it upon themselves to improve the accessibility of the projects they are directly involved in and sometimes related projects.
The problem with being seen as the โaccessibility personโ on a team is there is a risk that the responsibility for accessibility will be seen as theirs. If something goes wrong then they are in the firing line, and this is never fair.
Specialists often front-line designers or developers and donโt have the ability to influence policy, such as mandating particular standards are met, and arenโt able to allocate funding for things like training or usability testing
Additionally, accessibility can have a bad reputation, and it is easy for these specialists to be seen as the enemy, always pushing for accessibility in planning meetings, even if their fighting against the tide.
A consultant has accessibility in the job title. It is what they are paid to do. / Outsourced responsibility / Anecdote: iPlayer web (later on mention SMP as the good but NOT here)
Too little too late
Works on remediation more than planning, design, execution, and training
Focus on a product rather than process
Works on remediation more than planning, design, execution, and training
Consultants are hired to audit products, not fix processes
Focus on specific product, not a range of products on a shared platform
Does not embed responsibility with the organisation
Lack of organisational understanding
Lack of knowledge of business requirements, priorities, process, available resources, level of knowledge, culture. Also user experience expectations, documentation, written requirements.
Lack of transfer of skills
One off engagement
Benefits donโt exist beyond the current team or timeframe
Tunnel vision (too focused)
We defined silos in terms of disciplines, and that separates everyone out, so we want to look at how we can bring people together for a better outcome. The solution is to change to a process that is based on integrated accessibility.
Having accessibility that is integrated into the way things are done every day, rather than being a special task, can dramatically included the quality of your product from an accessibility standpoint.
There are 6 areas that we believe are important to move from silos to an integrated accessibility approach.
What it isnโt:
A set of documents, how toโs and guidelines.
A separate set of processes and activities. Itโs integrated into existing processes and in many cases augments processes or highlights where a process is weak or doesnโt exists.
It takes time. Itโs OK to start small and build it out.
Letโs people know what they are responsible for, how to achieve this and measure success
It represents an organisational change rather than just fixing processes
Have to adapt to new circumstances and not treat it as a checklist
It takes time, and thatโs OK; you donโt have to start big, you can start small e.g.:
might be a conversation between devs and designers
might be focus on a single product to pilot new processes (refine, repeat, refine)
Start with training - I was embedded in a couple of products as a con at BBC. Ian was a dev of a different single product we worked formally on training and standards initially.
Accessibility fails without governance
Accessibility is the responsibility of someone with the ability to make decisions and changes across an entire organisation
Not just a โHead of Accessibilityโ but a higher being e.g. CFO at BBC
Why? This person needs to be able to make change, they donโt have to ask or influence anyone higher up.
Layers of responsibility Product Owners, not Accessibility Team
E.g. Head of UX may be doing a fab job at implementing accessibility in UX teams but won't have that impact across dev teams for example.
Resourcing: canโt give people responsibility unless they have the appropriate skills and resources
Unless everyone in an organisation cares about accessibility, accessibility will suffer. If the CEO or CFO why should anyone else? And without good top down management support resources wonโt get allocated where they need to be for training, usability testing, and other things important for the best possible outcome.
Silos exist because of poor communication. Provide the tools to enable communication, which could be as simple a Slack channel, or a well managed Knowledge Base.
Everyone in an organisation needs to feel empowered to question decisions. No more โsign-offโ from the top so that design and implementation decisions are taken away from those best suited to make them. If thereโs a problem, people need to be confident that they can say so.
Finally, everyone needs to feel empowered to take the time necessary to get things right. Perfect is the enemy of good as the aphorism goes, but releasing something that you know is broken damages a culture of accessibility, both inside and outside your organisation, telling everyone that an accessible product is of secondary importance.
Are we relying on the Web Content Accessibility Guidelines to be the saviour of our products?
Beyond wcag -
Standards do not guarantee accessibility (or usability), but they provide a common foundation that can be use to ensure at least a baseline of accessibility
Write bespoke standards or ways of meeting standards that are the best for your organisation and customers
Living - Adapt and iterate standards as customer needs, technical improvements, and design styles change
Formats - MAG anecdote
How do we address the silos?
Not a one off activity, must be ongoing and update to meet changes in technology, design, standards, etc.
Online when suitable, onsite workshops when necessary
All new starters receive training
Starter training available to all
Training for specific disciplines, but other disciplines encouraged to attend For example, developers can access design training
Time provided
Training to suit peopleโs needs
Face to face
Online
Webinars
Sprint 0 tasks: minimum training before starting a project
Product owners responsible for establishing training needs for the team
Mandatory and monitored
Usability studies shouldnโt be a one off, never to be repeated after a site or app is live. Learning more about an existing product can help you plan improvements in to a new product from the very start
Share metrics amongst teams, youโll often find that an improvement to one site will apply to another.
Usability studies / share metrics - used to provide continuous feedback, and to drive continuous improvements
Bad documentation or training is often worse than no documentation or training. Keep it up to date, and keep it relevant to your organisation, and your requirements