accessibility in pattern libraries

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