accessibility in pattern libraries
Click here to load reader
Post on 23-Jan-2018
Embed Size (px)
Accessibility in pattern librariesAccessibility in
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
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
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.
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 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 are small sets of elements that are joined together in re-usable
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.
This field cannot be filled in
Invalid user data
Disabled Input This field cannot be filled in
Invalid user data
Inputs - Side-By-Side
Components are modules that are added together to build larger, more
An example might be a signup form that includes various form control modules, a button module and a potential success/error module.
Screens are where modules and components are combined into the final concepts that are presented to
An example might be a login screen, which not only has the login form
component, but also the navigation component, header component and
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
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
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,
4. Define feedback and notification mechanisms (i.e. success messages,
error messages etc).
5. Define additional information associated with modules (i.e. hints,
These pattern libraries normally take the form of detailed wireframes and/or prototypes along with additional
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
For this reason, they are more often style guides rather than pattern
Design style guides should address:
1. How core branding will be implemented across the website or
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
These examples should include all states, dynamic behaviours and
These elements and modules can then be used as needed to rapidly build complex components and the
The danger of copy/paste pattern
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
There is a wide range of pre-existing UX and front-end pattern libraries
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
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
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
So, the UX/UI and design phases provide recommendations and
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
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