Sandwich

Copenhagen

Odense

Denmark.

Berlin

Hamburg

Düsseldorf

Germany.

Paris

France.

Dnipro

Mykolaiv

Ukraine.

Chisinau

Moldova.

Sofia

Bulgaria.

Hanoi

Vietnam.

Boise

USA.

Romania.

Austria.

Home

About

Work

Services

Insights

Contact

English

Dansk

Français

Deutsch

English UK

Stories of inaccessible sites can be disheartening. So many people are out there, working on making accessibility the norm,  and it can still feel like organisations are not “getting it”. It’s easy to get frustrated with teams or stakeholders for not putting it first, but that’s not really fair either. There are as many reasons as to why this isn’t ingrained into a given culture as there are individuals working on fixing the issues. This isn't a matter of blame - people typically want to do the right thing. I really believe that. I believe that it’s more about a lack of empowerment or perspective than it is not wanting to take responsibility. The good news is that those are two areas we’re going to touch on together. 
<h4>Accessibility in Perspective</h4>
The first step to approaching accessibility is to assume positive intent. Organisations are made up of amazing people; many of whom are disabled too. There are great people who find themselves trying to juggle budgets, timelines, stakeholder expectations, and more. And when cuts have to come, sometimes important features get put into a backlog and left there. In the current professional climate, accessibility is often seen as a feature. It’s not that people don’t want to be inclusive; it's that accessibility is seen as additional - an extra feature - not an essential part of how sites are built.
The key to having an accessible and inclusive future is to bake these into our definition of “done”. That inaccessible deliverables are not any more complete than a non-responsive one would be. This shift may not happen overnight, but even to move forward gradually, more teams are going to need to accept this “simple” approach to understanding what it is for a website to be complete.
An unfortunate side effect of this gradual shift is that it leaves room for “quick fix” solutions such as Overlays (a product or service that applies a piece of code to a website and promises a more accessible user experience). Overlays can promise to add a script and make all the accessibility issues disappear. Truth is, Overlays are ableist in nature. They typically only address a limited number of challenges, and in doing so, they often interfere with the tools that disabled users use every day.
The disabled community is not looking for a quick fix or a hero to jump in with a solution for them. If your car cannot pass a broken stretch of road, do you want a tow truck to drag you over it in an awful way, maybe breaking your car in the process, or do you want them to fix the road? And wouldn't that new road make a better driving experience for all who travel it? It's the same with users who travel your website; if we build it correctly all users benefit. 
This is where a lot of managers stop and say, “Ok great. But how am I supposed to do that?” 
<h4>Accessibility-Minded Management Practices</h4>

The definition of "done"
Though most talked about in agile practises, in all web development we identify what “done” looks like from the business perspective. This may be what we think the final product may look like from a department or vendor, or, in agile practises, it may be the deliverable from a given sprint. No matter how your team breaks down the work to define “done”, it’s time to make accessible deliverables a requirement at every stage; from strategy to design to development.

Let’s make it simple; if 20-25% of users cannot use your website, it’s not done. I don’t care if it’s a hosting issue, a browser issue, a device issue, or an accessibility issue, it is basic management that if you could be missing nearly a quarter of your site visitors that your site is not meeting its KPIs and isn’t “done”.
<h4>Strategic Planning</h4>
Projects typically begin with looking at your strategic materials. Regardless if you’re starting from scratch or just updating what you have, you have the opportunity to be inclusive at this stage. 
Personas: Knowing that your target audience is already disabled, it makes sense to include disabilities into your personas. I’m not suggesting a “disabled persona” but rather, incorporating disabilities in as you would any other inclusive property. I hope your personas already represent identifications such as multiple races, gender identities (including non-binary), ages, and income levels in a respectful way. You cannot be inclusive without the disabled community; add them in too before you consider this deliverable "done". 
Content: Webpages have only seconds to grab a user's attention and to get them engaged with your content. Using clear and consistent language from the beginning will help set the tone for all other content and will help users who experience cognitive differences such as ADHD, ASD, or maybe are even just distracted. Build this practise into your identification of “done” for all of these deliverables from the start. 
Timeline &amp; Estimates: Any manager knows that the nemesis of any project is scope creep. This adds strain and anxiety around each deliverable. Eliminate the perception of scope creep by accounting for accessibility in all of your timelines and estimates. We all know that good work takes time, and we account for that; just build the time your team needs to build successful and accessible experiences into your timelines from the start. 
Roadmap: With accessibility built into your timeline already and included in your definition of “done” at each step - your roadmap should now inherently account for building an accessible experience. Other areas to consider that may take time would be accessibility testing with native users or time that the legal department may need to review an accessibility statement. 
<h4>Questions to Ask the Project Team</h4>
Unsure if you’re headed in the right direction? Here are questions to ask your team to help keep accessibility in scope. 
Strategy
<ul>
<li>Do your personas have inclusive representation?</li>
<li>Are there specific target demographics which would benefit from AAA consideration?</li>
<li>Does the navigation use clear and concise terminology? </li>
<li>Will you be doing user testing with people who are disabled? </li>
<li>Have you planned for an Accessibility Statement?</li>
</ul>
Design
<ul>
<li>Are common brand colour combinations visually accessible?</li>
<li>Do provided designs have target size, line spacing, etc. considered?</li>
<li>Have you included room for captioning, pause buttons, and links to transcripts in the designs?</li>
<li>If you are planning on animations, will they require a low-motion option?</li>
</ul>
 
Development
<ul>
<li>Are there third-party forms which are embedded with inaccessible script?</li>
<li>Are modules and plugins inherently accessible? If not, have you accounted for ample time to address that before QA?</li>
<li>Will the DOM and the visuals match? Many screen-reader users also take in content visually and a mismatch can cause confusion. </li>
<li>Is there time in QA for accessibility testing? Is there time and budget to test with native users of assistive technologies? </li>
</ul>
<h4>Accessible Communication Practises</h4>
Accessible practises don’t only benefit end users. As a leader in your organisation (regardless of your title), you can help promote building accessibility into your organisational culture. Here are a few ways you can do just that!
Captions/Transcripts: your team may benefit from turning on captions and transcripts, both in the moment and later when reviewing the material covered. Here are two auto-captioning/transcription options for you. They’re not perfect but they’re a good first step into building a more accessible culture. 
<ul>
<li>Zoom captions: if you cannot turn on auto-captions and transcripts yourself - talk to your admin. </li>
<li>Google Slides captions: in my opinion these have a remarkable level of accuracy as compared to other engines. Just pop them up when you go into presentation mode. </li>
</ul>
Content: Your teams need to comprehend what you need from them too! Following a few best practises will help you be more effective and efficient. 
<ul>
<li>Avoid unexplained lingo: every industry has its own vocabulary but look out for new terms or acronyms and make sure to explain them before trying to incorporate them into your conversation. </li>
<li>Bold your Slack links: for whatever reason, the widely-used messaging programme “Slack” does not have its links underlined - only identifying links with a slight change in colour. Help your team out by bolding any links you post. </li>
</ul>
Be Human: When in the thick of a project with looming needs and deadlines, it’s easy to want to push through all of it quickly and get back to work. It’s important to stop and make sure your team is feeling ‘whole’ before trying to get through the project’s tasks. 
<ul>
<li>Give space for those who need more time: some of your deepest thinkers will not talk much in a fast-paced call and when you don’t take the time to allow them to process, the entire team misses out on valuable insights and creative problem solving. Make space for team members to formulate their thoughts by either allowing space at the end of a call or sending notes ahead of time to allow team members who may need more time to prepare. </li>
<li>Don’t require cameras on (though don’t be afraid to encourage it): I love cameras on as I want to read faces and emotions but I also know that this just doesn't work for everyone. For any number of reasons, they are distracted or just not comfortable being on screen. While you should feel free to privately reach out to a team member and invite them to be on camera if they are comfortable, it should not be a requirement. </li>
<li>Ask about stressors and outside influences: your team is made up of people with big, full lives and those lives impact them - no matter how professional they are. I always joke that “humans are messy” because we all have so much going on in our minds outside of any given project. Don’t be afraid to create a safe space for people to just be themselves - even when it's messy. In my experience, the best way to accomplish this is to share something about yourself but take your time - build trusting relationships and feel it out from there. </li>
</ul>
<h4>Setting the Tone for Success</h4>
Inclusion, as a part of an organisation's culture, comes from a place of education, practise, and empathy and cannot be forced. Targeting those who cannot see how to operationalise it, even if well-intended, sometimes just builds more barriers. We need to make it easier for accessibility to be brought into the standard operational procedures. By slowly building it into what you’re doing, people will become aware. By explaining why the choices you are making are of value, you’ll create a deeper understanding for the group as a whole. Learn how to <a href="https://ffwagency.com/learning/blog/flip-narrative-accessibility">flip the narrative on accessibility</a> or <a href="https://ffwagency.com/learning/blog/why-it-makes-sense-and-cents-incorporate-accessibility-best-practices">why accessibility makes sense (and cents)</a> for your organisation for more ways to approach accessibility from the business perspective. You’re empowered to be the leader who just does it, who educates and promotes a more empathetic team and that is the heart of inclusion practises.

Accessibility in Action

15 November 2021