Accessibility in pattern librariesAccessibility in

pattern libraries

Moving away from pages

In the past, many people approached complex websites and web

applications as a series of “pages”.

These pages were often designed and built as complete entities.

More recently, in complex websites and applications, the focus has shifted from full page layouts to

re-usable components.

A re-usable component could be a layout grid structure, a button, an

input, a drop-down, a menu, a heading, a table, or even a pullquote.

So, what are pattern

libraries?

Pattern libraries are a collection of user interface components that can

be used multiple times across a website or web application.

On large websites and complex applications, pattern libraries have a

range of benefits.

In many cases they make it faster and easier to build.

If done well, they provide a shared vocabulary across all teams.

And most importantly, they provide a consistent level of quality.

Lego blocks?

Most complex pattern libraries follow the “lego building block” concept.

This means that they start with individual “lego building blocks” and then use these block to build

larger and more complex components.

Complex pattern libraries are often broken down into categories such as

elements, modules and components.

Elements Modules Components

Elements

Elements are standard HTML elements such as headings, labels,

inputs, buttons, etc.

They are the basic lego building blocks of the pattern library.

Most of these elements are rarely used on their own - they are used to make modules and components.

Modules

Modules are small sets of elements that are joined together in re-usable

chunks.

For example, an input module could include a label, an input, a hint text, a possible error message and then all of

the possible states including focus, hover, and disabled.

Static Input

Disabled Input

This field cannot be filled in

Error Message

Additional Information

Additional Information

Invalid Input

Focussed Input

Invalid user data

Value

Additional Information

Inputs

Placeholder

Static Input

Additional Information

Value

Disabled Input This field cannot be filled in

Error Message

Additional Information

Invalid Input

Focussed Input

Invalid user data

Additional Information

Inputs - Side-By-Side

Placeholder

Input module

Components

Components are modules that are added together to build larger, more

comprehensive concepts.

An example might be a signup form that includes various form control modules, a button module and a potential success/error module.

Elements

Modules

Component

Final screens

Screens are where modules and components are combined into the final concepts that are presented to

the user.

An example might be a login screen, which not only has the login form

component, but also the navigation component, header component and

footer component.

A screen may also have different states depending on a number of

different factors, such as the type of user, where they are in the current

process etc.

Generally, screens are not part of a pattern library. The pattern library is used to help create these screens.

Different types of pattern libraries

Pattern libraries can and should be used during all phases of the design

and development process.

There are three distinctly different types of pattern library:

UX/UI pattern libraries Design style guides

Front end pattern libraries

UX/UI pattern libraries

UX/UI pattern libraries often include comprehensive documentation

that:

1. Define all elements, modules and components.

2. Define the various states for all elements, modules, components (i.e. hover, focus, active states, logged-in

or logged out etc).

3. Define key dynamic behaviours (i.e. animations, transitions, fly-outs,

drop-downs etc).

4. Define feedback and notification mechanisms (i.e. success messages,

error messages etc).

5. Define additional information associated with modules (i.e. hints,

tips etc).

These pattern libraries normally take the form of detailed wireframes and/or prototypes along with additional

documentation.

They help to communicate to internal teams and stakeholders how a

website or app should be built.

Design style guides

During the design phase, the emphasis is less about defining re-usable modules and more about

defining a consistent “look and feel” across every aspect of the website or

application.

For this reason, they are more often style guides rather than pattern

libraries.

Design style guides should address:

1. How core branding will be implemented across the website or

app.

2. The overall “look and feel”.

3. How typefaces and font-size will be used.

4. How colour schemes will be used.

Front end pattern libraries

Front-end pattern libraries should produce fully functional HTML/CSS/JS examples of all elements, modules

and components.

These examples should include all states, dynamic behaviours and

feedback mechanisms.

These elements and modules can then be used as needed to rapidly build complex components and the

final screens.

The danger of copy/paste pattern

libraries

One danger with front-end pattern libraries is where modules and components are presented as

examples that have to be copied and pasted by developers.

The problem is that they can easily be applied incorrectly.

Pattern libraries should be built so that modules and components are

referenced directly from the pattern library in some way.

This means that they can be updated automatically without leaving legacy

versions across an application.

More importantly, they cannot be applied incorrectly.

What about existing pattern

libraries?

There is a wide range of pre-existing UX and front-end pattern libraries

available today.

Some of these pattern libraries have a simple purpose - such as predefined sets of UI modules in wireframe form,

or front-end grid systems.

Others, especially in the front-end, are full “frameworks” that offer a wide range of fully functional elements,

modules and components.

There are some great benefits to using a pre-existing framework.

They are often ready to use and are therefore quick to implement.

They are also often useful for rapid prototyping during the UX/UI phase.

However, there can be some downsides as well.

The pre-build modules and components may not suit your

project which means they have to be heavily modified.

They often produce a generic look, mainly because people are not

experienced enough to know how to customise them.

You are also relying on someone else for code quality.

This is especially true for accessibility within pre-existing

frameworks.

Do you want to rely on others to make sure all of your modules and components are accessible?

Accessibility in all phases

Many people focus on addressing accessibility during the front-end

phase only.

However, accessibility can be addressed to some degree during the

UX/UI and design phases as well.

UX/UI pattern libraries should describe solutions to some aspects

of accessibility such as states, behaviours, proximity, notifications,

error messages etc.

Good UX/UI pattern libraries even help to describe how keystrokes

should allow users to “travel” through complex components.

These descriptions should help front-end teams when building the

final modules and components.

Design style guides should address a range of design-related

accessibility concerns such as: colour contrast, use of proximity, use

of iconography and font-size.

These requirements can then be applied into the front-end modules

and components.

So, the UX/UI and design phases provide recommendations and

requirements.

And these recommendations and requirements can then be put into action during the front-end phase.

Baking in accessibility?

In the old days, accessibility reviews were often tacked on at the end of major site or application builds.

Often just before launch.

Full site build with accessibility review just before launch

UX Design Build Launch

Review

Even worse, in some circumstances, reviews were carried out after launch

- only when someone made a complaint.

Full site build with accessibility review after launch

UX Design Build Launch

Review

Of course, that sort of thing never happens today… does it?

With complex applications and websites, there has been a shift away from a single massive build cycle.

Instead, complex applications and websites are often rolled out in a

series of feature releases.

Feature Feature Feature Feature

Rolling feature releases over time

A feature is a stand-alone section of a web application. A new feature may require anything from a single

screen to multiple screens.

For example, in a banking web application, a new feature could allow

customers to add additional bank accounts to the system.

Because features are released individually, accessibility reviews can

be conducted on an individual feature rather than an entire

application or site.

A single feature build process with accessibility review before launch

UX Test Build Test Launch

Review

And, if accessibility is considered during all phases of feature

development, the accessibility review should be even less painful.

A single feature build process with accessibility integrated throughout all phases

A A Review

UX Test Build Test Launch

However, with the use of pattern libraries, accessibility can be “baked

in” even earlier in the process.

In many cases, an initial pattern library is built before any features are

ready.

These initial pattern libraries often include elements and modules but no

components.

Accessibility should be “baked into” each of these modules. And, they need to be carefully reviewed before

proceeding.

What does this mean? Well, it means following basic

accessibility guidelines…

Making sure all modules use semantic and well-formed markup.

Using alt attributes on images.

Making sure for and id attributes are used correctly for labels and inputs.

Making sure th, thead, tbody are used appropriately in tables.

Using additional aria roles, labels and descriptions where appropriate.

If modules are built correctly, they provides a solid foundation for all

future components.

The process is often similar to a feature release, except the outcome is the initial pattern library rather than

a feature.

Pattern library build with accessibility integrated throughout all phases

A A Review

UX Design Build Ready

As new features move into production, new components are built and added into the pattern library.

Some people make the mistake of assuming that these components will

automatically be accessible because they use the tested modules

as a base.

However, components often present their own accessibility issues.

For this reason, new components should also be tested and reviewed before launch, as part of the feature

release.

A single feature build process with accessibility integrated throughout all phases

A A Review

UX Test Build Test Launch

Bottom line

For large websites and complex apps, pattern libraries are critical.

UX/UI pattern libraries and design style guides should include

accessibility as part of the process.

For front-end pattern libraries, make sure to bake accessibility into all core modules and test carefully.

Make sure to test all components and screens as they are released

with features.

And, avoid building pattern libraries that rely on developers having to

copy/paste code samples.

These steps will save a world of pain in the future.

Russ Weakley Max Design

Site: maxdesign.com.au Twitter: twitter.com/russmaxdesign Slideshare: slideshare.net/maxdesign Linkedin: linkedin.com/in/russweakley