A real world strategy for building accessible products

Outlined in this post is a flexible and actionable strategy for accessibility governance across product teams – suitable for start-ups to multi-billion dollar enterprises.

Once your organisation decides to embrace accessible design and development, you’ve only just fought the first part of the battle. The next challenge it to get this thinking disseminated through to Product Managers, UX Architects, Visual/Interaction Designers, Developers and QA members.

Without a clear structure and battle plan, teams can easily flounder as priorities change and accessibility requirements get deprioritised or even sidelined. So how do you make sure your digital products become and remain truly accessible?

The key here is to weave appreciation for accessible thinking into your organisation, at all levels, and make it the norm and not the exception.

A pragmatic accessibility strategy

This strategy applies for both small/medium firms to large enterprises. The aim is to infuse accessible thinking across the organisation, so thinking is decentralised and not limited to fixing issues raised by external audits. The key principles,

  1. Build it into organisational roles
  2. Draw up guidelines for your organisation
  3. Enforce standards
  4. Fix key journeys
  5. Set goals and timelines

1 – Roles & responsibilities

Ultimately in most cases the guardians of accessibility on your digital products are the developers writing the actual UI code. Unless you have accessibility user experience specialists outlining an exact accessible experience along with the overall UX – you will rely on the developers to make some calls on how users utilising assistive technology will navigate components like a carousel, or dialog box.

The first port of call is to highlight some responsibilities, and a series of supporting roles – so individual developers don’t feel burdened to make it all work on their own. The following hierarchy can be effective,

  • Developer – the accessibility guardians, they write the bulk of the code, so will need to ensure that all the development meets your guidelines.
  • Team Accessibility Champion – each development team can have a lead accessibility champion who actively champions good accessibility practices amongst the team, and acts as the resident team consultant. Ideally these individuals should volunteer for the role, as it’s a proactive responsibility to undertake.
  • Accessibility Evangelists – a small number of these individuals with relatively acute accessibility knowledge would help to set accessibility guidelines and strategy across the entire organisation.

a11y_org

Finally adopt a comms method, such as a dedicated Slack channel, whereby all of these individuals can freely and easily discuss ideas, queries, swap notes and ensure strategies are aligned together.

Secondly schedule regular (fortnightly) face-to-face meetings to discuss on-going developments and strategies, as well as hosting triage sessions to help diagnose complex implementation challenges.

External audits are still important and it’s useful to have independent external accessibility audits performed 1-2 times a year, to ensure your products remain accessible, and any techniques and approaches employed continue to remain best practice.

In smaller organisations these activities would most likely occur within a single team, and the communication channels should already be very fluid.

2 – Guidelines

The W3C 2.0 Guidelines are big, and great for reference, but they can be interpreted in many ways to create numerous solutions that meet the criteria. It would be up to the Evangelists to create accessibility guidelines which outline best practice and how “we” as an organisation make the site accessible and meet the WCAG guidelines. Here it would be useful to tie it together with a component library which  gives code snippets and examples to show how to solve common problems, such as modal dialogs, carousels, sliders, etc.

The key here is to make the guidelines a truly useful time saver and invaluable resource, if the developers can lift and apply the code snippets with ease they’re more likely to use it and then keep it up to date.


Tip for creating guidelines

Don’t reinvent the wheel! Look at existing guidelines, and use them as a starting point BBC Mobile, eBay MIND and such publish their guidelines for public consumption – they’re a great starting point and can be a good way to  get a running start at tackling a fairly hefty piece of work.

Make sure your guidelines follow the overarching principles of WCAG, and once the Evangelists build the guideline skeleton structure, the Accessibility Champions can then work collectively adding code snippets and components to help fill out the resource as a whole. This approach helps to maintain the guidelines in a more distributed nature, spread knowledge across teams and help cross-check the recommended solutions.


Testing and assistive-tech support matrix

It’s also important here to identify the assistive technology you want to use as a baseline for testing – this includes browser/screen-reader combinations, along with particular mobile hardware. This way the development and QA teams clearly know what they need to be testing against.

3 – Enforce standards

This is an attitudinal shift at the QA and management level, as well as one for developers, this means you don’t ship product until it passes the organisation’s mandated accessibility guidelines, and if it is in exceptional circumstances shipped it becomes a high priority to be patched/fixed immediately post-release.

“You’d never ship a product with significant browser bugs that impede the customer experience, yet in many organisations it’s deemed acceptable to ship with huge accessibility bugs, release after release.”

This does mean QA need to be trained in understanding core accessibility issues, so they can validate that the experience isn’t compromised – similarly to how they would do cross-browser user acceptance testing.

A useful addition to manual testing is to use automated accessibility testing, and making it an integral part of the build cycle. Remember this won’t check the quality of your accessible solutions, but they can help maintain your existing ones don’t break; and basic mistakes and poor practice don’t weave themselves back into the codebase.

Accessibility isn’t a single user story

Accessibility should never be added as a single user story in your task management system, this is akin to adding a story which says it must work in Chrome or Safari. Meeting the accessibility guidelines needs to be an implicit requirement, alongside browser compatibility. The only exception to this rule is when you’re bug fixing or fixing inacessible user journeys.

If you can pull together clear user stories that explicitly outline the user experience for a screen reader user or a switch user for example, this would be an excellent high watermark to achieve, but it’s unlikely you’ll have the expertise at hand from the beginning to achieve that from the outset.

4 – Fix key journeys

It’s relatively easy to mandate that all new features will be accessible from this point onwards, this is a good start as it means eventually everything will become accessible. Eventually however could mean months or years away, especially if common components like the header or overall page structure are inherently broken and inaccessible – it can take a very long time to organically make the site experience accessible.

At this stage it makes sense to look at the tech debt that needs to be resolved to deliver an accessible experience over key journeys such as search, reading an article or placing an order.

These would get added to your task management system as individual accessibility issues (this is the exception I referred to earlier), meaning you would be able to fix journeys and make your product accessible sooner. Remember at this initial stage because it’s not a redesign it doesn’t need to be the optimal experience, this can be dealt with at a later date during the redevelopment of key areas.

5 – Set timelines and dates

With all the good intentions and guidelines, unless you mobilise with some hard dates and get buy-in from the powers that be, you’ll never really kick off the accessibility initiative you set out to do.

This is where you need to set dates, so the key journeys meet the accessible requirements as per the organisation’s accessibility guidelines. This means making tough proposals to stakeholders stating by the end of the quarter the key product functions will be accessible and meet WCAG 2.0 AA.

New development

When you kick off new development, the accessibility leads and the developers need to get early exposure to the key concepts so they can ratify the accessibility issues and give them time to envisage ways to solve the problems that may arise from a particualr desired UX, or feedback and tell the UX/Design team to rethink their approach.

Once you get all the pieces in place I’d expect to see a development process as shown in the following diagram…

accessibility_governance_v1-00

By building in clear checkpoints into the product development pipeline it should become a lot easier to ensure everything that gets built has accessibility considerations at the core of the product and not an afterthought.

Maintaining the momentum

It’s not easy making organisational changes, and maintaining the momentum of initiatives like this, it can be a tough path and keeping teams excited can be a challenge.

I would always remind the team of the human element and the benefits you bring to all users; this could be done by showing videos of users using assistive technology, demonstrating great accessible product experiences made by other organisations, through to bringing users in for some user testing.

If you are running user testing it’s important that all the team members get some real exposure to this, as it’s a great opportunity to truly humanise the technology we work with. It’s moments like this that can change their perspective and make them true advocates, like yourself.