Addressing accessibility requirements in design briefs

Don’t produce a design document that includes a design implementation recipe without including accessibility details.

Adesign brief is a description of a project and corresponding drawings (comps and wireframes, for example) created by a person or team in consultation with project stakeholders.

• Design briefs outline the deliverables and scope for project implementation and address both function and aesthetics, such as patterns and colors.
• Sometimes design briefs contain additional project logistics like schedule and budget.
• Design briefs usually have some type of stakeholder signoff process.
• If (when?) during implementation it is determined that a change is required, it must be agreed to by all parties and attached to the brief as an appendix. Sometimes these are referred to as “change orders”
• At the end, the design brief is used to evaluate the deliverable because they are incredibly useful as an accountability mechanism.

What level of accessibility detail should I include in a design brief?

The answer to this one is “it depends”.

• Does the stakeholder you are designing for have an accessibility statement? If so, you should definitely include a pointer to that statement in the brief’s accessibility section
• Include the supported platforms matrix. Identify what hardware, operating systems, browsers, and assistive technology should be tested.
• Are the implementors accessibility-novices? If so, the more accessibility detail in the design brief, the better. Tell them things like: page titles, header structure, alt text, expand/collapse announcements, focus order, keyboard indicator color, and specialized announcements for things like “click here” links that require more detail for screen reader users. Point to the accessibility statement as well (if there is one), cite the standard to be used (WCAG 2.1 Level AA for example).
• Are the implementors experienced at building accessible apps / websites? If so, informing them of the accessibility standard to develop to should be sufficient. However, the more details that you provide in the design brief (such as those detailed above), the less back and forth you will have with the developers as they are implementing (or worse, post-implementation when performing acceptance testing)
• A few reminders that the entire experience has to be accessible in the design brief can’t hurt. That means any documentation, training, and help or support associated with the product being designed should also be accessible.

---

It takes a village to build an accessible product. And the “village elder” is design. Every time an inaccessible product is released, it excludes up to 18 % of the potential users, and opens the company up to serious risk of lawsuit. Design briefs that call out “do we make it accessible” question convert the accessibility decision from unconscious to conscious. And no one wants to leave evidence behind for the litigators to find in discovery that a company deliberately made the decision in the earliest stages of the product to make it inaccessible.

If every designer included accessibility details in their design briefs, it would raise the visibility of accessibility as an important design factor that needs to be addressed in implementation. And if every accessibility professional asked “where’s the design brief”, the problem can be tackled from both sides.