Accessibility - the black, the white and 50 shades of grey

Introduction

The Web Content Accessibility Guidelines (WCAG) 2.0 is a stable, referenceable technical standard that is made up of a number of guidelines that help to make web content more accessible to people with disabilities. Salsa is often engaged on projects to design and build websites for government departments where WCAG 2.0 accessibility is a key requirement. In executing such projects, the Salsa team has had number of opportunities to validate our own understandings around accessibility, pick up some new learnings and successfully deliver on client’s expectations. In this write-up, I attempt to retrospectively capture such project moments, some best practices and a few lessons we have learnt along the way that might help similar projects in the future.

Before the build

Everyone acknowledges the importance of accessibility in a public-facing website. However, very few projects have had instances where this requirement is discussed at great length. On most projects, this is more an inferred requirement. Considering the importance of such requirements, I believe it’s absolutely crucial that we discuss these requirements in greater detail during projects.

Defining accessibility requirements

It’s important that all accessibility requirements are thoroughly defined early on in the project. Why do this early? Can’t we review later on during the project to ensure compliance? Best practice is to call out all accessibility requirements at the beginning — irrespective of whether the project is agile or waterfall. This is because there will be cascading effects on design and implementation, and any drastic changes later on will incur unnecessary additional cost. Another factor is the WCAG AA 2.0 standard is not strict and a number of areas are open to interpretation (as we will discuss in the next sections). Deciding on the requirements with the client early on ensures there aren’t issues near project completion.

This, of course, means that all key stakeholders (especially those who sign-off on accessibility requirements) should be involved early. In most projects, before the ‘build’ phase, the Salsa team usually executes a technical review with the client’s compliance teams, to ensure that the approach we take meets their compliance needs. It would seem logical that accessibility requirements should be reviewed at this stage. A further discussion and agreement on how specific accessibility goals are to be met is recommended.

Set the goal posts

The ‘secret’ ingredient for any successful agile project is that requirements/stories are typically authored by the product owner or by a close proxy. This simple detail (the ‘who’) makes a big difference and is very important in determining the outcome of the project. This is directly applicable to accessibility related requirements. It’s important that the client calls out their most important accessibility requirements and that these are documented. It also makes sense to have a joint exercise between Salsa and the client team to classify the requirements and add basic priorities, just like we would for any other functionality.

The expected outcome is a prioritised list of accessibility requirements. Why is this important? The Salsa team regularly uses industry standard tools to help ensure that the websites we build meet the required standards, including accessibility (e.g. accessibility checker). This is a technical quality review process done in every project at Salsa. However, the output of those generic tools is usually a huge laundry list of items, ranging from unimportant feedback to mission-critical ones. At this stage, a prioritised list of requirements will help the project team focus all energy on what’s most important from the client’s perspective and filter out the noise.

Compliance levels

It’s important to understand that accessibility can have multiple levels of compliance. Websites can range from a full WCAG 2.0 compliant website to a full non-compliant website. Most websites fall somewhere in-between, with sufficient level of WCAG 2.0 compliance being met. This ‘balance’ needs to be clearly called out and understood at the start of the project. For example, it would take a lot of effort to create a data-driven website (with infinite numbers, tables and beautiful graphs) and make it fully accessible and comprehensible via, say, screen readers. It could be high value to discuss what the end personality of the website is going to be, and what the primary goals of the website are. Salsa has a well-established process for determining these key inputs using standard practices from across the industry (e.g. Business model canvas).

During the build

Even after thorough discussions before the project, due to the inherent nature of accessibility, there can still be some cases during the project where interpretations differ and pose questions as to whether or not a specific requirement is met. This risk is somewhat mitigated in an agile project, since there is opportunity for continuous feedback and refinement along the way. Below are some specific examples of different interpretations of accessibility we’ve come across. These are potential ‘grey areas’, which require extra detailing.

Screen readers

WCAG guideline (ref):

G117: Using text to convey information that is conveyed by variations in presentation of text

Multiple other

Interpretation: This guideline is to ensure that the text and alternative texts provide the same presentation on screen readers rather than in a "window" or screen on the monitor. Due to inherent differences in the way screen readers handle content, it’s quite hard to ensure similar experiences across screen reader software. Also, since most Salsa websites are responsive, the same experience has to be maintained across screen readers across different resolutions including mobile and desktop. This requirement is heavily dependent on screen reader software itself, however, the basic interpretation is to ensure that screen readers read through content sequentially ‘as presented’ visually (sic) and the implementation meets all other accessibility requirements. This is a very subjective area of discussion and usually poses multiple challenges. This is also a classic example of when compliance levels (above) have to be discussed and agreed upon.

Grey areas:

• Different screen reader software (JAWS, VoiceOver, etc.) has different behaviours. It’s a good idea to define a baseline at the start of the project.

• Any accordions have added complexity on screen readers.

• Interactive elements (e.g. links, buttons, etc.) are ‘preferred’ by screen readers as opposed to flat text content. This affects screen reading sequence and should be a consideration during design.

Moving/scrolling content

WCAG guideline (ref):

G4: Allowing the content to be paused and restarted from where it was paused.

G75: Providing a mechanism to postpone any updating of content

G76: Providing a mechanism to request an update of the content instead of updating automatically

G186: Using a control in the Web page that stops moving, blinking, or auto-updating content

Interpretation: Unless explicit implementation requirements are laid out, this set of guidelines should seem straightforward. The intent of these guidelines are to ensure that users with disabilities are given adequate time to interact with Web content whenever possible. W3C says: “People with disabilities such as blindness, low vision, dexterity impairments, and cognitive limitations may require more time to read content or to perform functions such as filling out on-line forms.” In the absence of any other irregular implementation, this requirement is met if a user is given the ability to: (a) pause any moving content, e.g. on sliders; and (b) resume from where paused.

Grey areas:

• Duration of ‘pause’.

• Animation when scrolling: fade vs slide vs other → each have their own merits and demerits.

• Poor internet connections may cause issues such as flickering, image overlays, etc.

• Cross-browser behaviours, especially Internet Explorer.

Error validations

WCAG guideline (ref):

G83: Providing text descriptions to identify required fields that were not completed

G84: Providing a text description when the user provides information that is not in the list of allowed values

G85: Providing a text description when user input falls outside the required format or values

Interpretation: These are standard requirements and are applicable for almost all websites that have form entry fields. These guidelines are to ensure that users are notified when there are user errors on form fields. If the following cases are handled, then it sufficiently addresses these guidelines. Notify users if: (a) mandatory fields have not been completed; (b) user fills in unallowed values; and (c) incorrect format input.

Grey areas:

• Multiple forms on the same page causes issues → consideration for design.

• In-line form field errors vs page errors → page errors may cause issues if there is a large amount of content between the page errors and the actual form fields.

• Screen reader issues → handling of error messages by some screen readers is not as mature as others.

Expert reviews

Below is some consolidated feedback from the rest of the team based on experiences working on projects with WCAG 2.0 accessibility requirements.

Design team

Due to our past rich experiences designing WCAG 2.0 accessible websites, we inherently get typography and colour schemes right. All fonts, colours and contrast ratios etc. are checked for AA compliance before they’re used in Salsa designs. Colour palettes are usually chosen with WCAG 2.0 accessibility in mind.

Instead of multiple assumptions about content presentation, it’s usually good practice if all designed pages are viewed with specific live content. Ability to apply designs to live content will help tease out some simple items (such as font size conventions) that may otherwise go unnoticed. Also, in a sizeable project, close consultation with the core decision group within the client organisation is usually quite helpful. As a precursor, workshops should be focused on clear decision-making rather than consensus and a one-solution-fits-all culture.

Front-end team

By virtue of multiple government projects with similar requirements, the Salsa team has developed detailed WCAG 2.0 checklists outlining focus areas during front-end UI development. Salsa has a good knowledge base to build on and extrapolate such learnings for any project. Certain guidelines (such as provisioning for keyboard-based navigations) are included pre-emptively by default on any website build we undertake.

There are usually some challenges posed by semantic structures vs aspirational design. It’s good practice to conduct a technical review of the designs before implementation begins. For example, Drupal output heading levels and typical WYSIWYG editors have some degree of overlap making front-end implementation tricky. In these cases, content has to be set up carefully, otherwise screen reader functionality may not be optimal. It’s also good practice to have detailed markup guides per page with clear definitions including heading styles, hovers, buttons states, etc.

Conclusion

In conclusion, the difference between building a site and building an WCAG 2.0 accessible site is more than just estimating for any fixes that may need to be done afterwards. It’s an end-to-end process that starts from knowing the right requirements early, reviewing/collaborating regularly on designs, and continuous, timely feedback on implementation. Good luck on your next project!