Accessibility in Pattern Libraries

Russ Weakley
Russ WeakleyUX/UI developer at Max Design
Accessibility
in pattern libraries
pages
Moving away from
Does anyone remember a time when
we built websites using table-based
layouts and spacer gifs?
For a long time, people used to
approach complex websites and web
applications as a series of “pages”.
These pages were often designed and
built as complete entities.
This practice began to change in
2006-2007 when people began to
abstract aspects of web pages into
“reusable patterns”.
The earliest patterns, like BluePrint
CSS (released in 2007), focussed on
abstracting the overall layout grids.
More complete systems soon
followed. However, many of these
were just glorified style guides rather
than pattern libraries.
In 2009, Nicole Sullivan introduced
“Object Oriented CSS” and the
concept of abstracting aspects of
the UI became a serious business.
By 2011, there were a wide range of
off-the-shelf pattern libraries, like
Twitter’s Bootstrap.
This concept of “abstracting aspects
of the UI” is an important part of all
style guides and pattern libraries.
We’re going to look at three different
systems and how to include
accessibility as part of the process.
1. Front-end pattern libraries

2. Design style guides

3. UX wireframe/prototype libraries
Now, you may have totally different
names for each of these… or you may
work in a different way… and that’s
ok!
pattern libraries
Front-end
Front-end pattern libraries are a
collection of user interface
components.
These components should take the
form of fully functional HTML/CSS/
JS code snippets.
The code snippets should include all
states, dynamic behaviours and
feedback mechanisms.
Along with the code snippets, there
should be additional information such
as context and usage.
Front-end pattern libraries have a
range of benefits.
In many cases, they make it faster
and easier to build.
If done well, they are much easier to
update and maintain.
And most importantly, they provide a
consistent level of quality.
Lego blocks?
Most complex pattern libraries follow
the “Lego building block” concept.
This means abstracting the UI down
to individual “building blocks” and
then using these blocks to build larger
and more complex components.
In the early days there was often
heated debate as to how to
categorise the UI and what to call
each of the categories.
This “categorisation dilemma” came
to a head in 2013 when Brad Frost
introduced Atomic Design.
Brad came up with a naming
convention that used five categories:
atoms, molecules, organisms,
templates and pages.
People became obsessed with trying
to force their pattern libraries into
these categories rather than seeing
them as a suggested framework.
Let’s keep it simple, and break
everything into elements, modules,
components and screens.
Elements Modules Components Screens
Elements
Elements are standard HTML
elements such as headings,
paragraphs, tables, forms, fieldsets,
labels, inputs and buttons.
They are the basic building blocks of
any pattern library.
These elements are sometimes used
on their own but are more commonly
used to make modules and
components.
Modules
Modules are small sets of elements
that are joined together in reusable
chunks.
For example, an input module could
include a label and an input.
Input label
A basic input module
However, the module should consider
all possible states and options.
Input label
Additional Information
A input module with additional information
Input label
Error message
A input module in error state
Input label
Additional Information
A input module in disabled state
Input label
Additional Information
A input module in focus state
Each module should be defined as
simply as possible so that they are
highly flexible.
In most cases, modules should not
have a specific width or any vertical
spacing. These should be handled
using modifiers and helper classes.
Components
Components are made from a series
of elements and modules that are
added together to build 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.
Accessibility in Pattern Libraries
Elements
Modules
Component
Screens
Screens are where elements,
modules and components are
combined into the final concepts that
are presented to the user.
An example might be a login screen,
which includes the login form,
navigation, header and footer
components.
A screen may also have different
states depending on different factors,
such as the type of user, where they
are in the current process, etc.
A dirty secret
While starting from tiny Lego blocks is
a sound approach, it does not work
for all components or screens.
In some cases, the process needs to
start with components or screens,
and these need to be broken down
into modules.
There are also times when a
component produces unique
modules that will never be used for
anything apart from that component.
In these cases, there is a question as
to whether they should ever become
modules, or stay as part of the
larger component.
There is no “one size fits all” when it
comes to pattern libraries. Embrace
the anomalies and move forward.
The danger of

copy/paste
Front-end pattern libraries should
allow modules and components to
be referenced directly from the
pattern library in some way.
The system should not allow
developers to copy and paste code
snippets from the library.
Code snippets that have been copied
and pasted have to be manually
updated.
More importantly, copying and
pasting code snippets allows
developers to misuse or abuse the
code.
Remember, every time you allow a
developer to copy and paste code
snippets from a front-end pattern
library, a puppy dies!
Design
style guides
A design style guide provides a
framework for consistent visual
practices.
Design style guides should address
(amongst other things):
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.
UX
wireframe/prototype
libraries
UX wireframe/prototype libraries often
take the form of detailed wireframes
and/or prototypes.
These types of libraries should:
1. Define all elements, modules and
components.
2. Working with Visual Designers,
define the various states for all
elements, modules, components (i.e.
hover, focus, active states, logged-in
or logged out).
3. Working with Visual Designers,
define key dynamic behaviours (i.e.
animations, transitions, fly-outs and
drop-downs).
4. Define feedback and notification
mechanisms (i.e. success messages
and error messages).
5. Define additional information
associated with modules (i.e. hints
and tips).
On a higher level, these libraries
should also define the overall
information architecture, the flow from
screen to screen, the various user
states and much more.
These libraries help to communicate
how the screens, components and
modules fit together into the overall
UI, and how users will engage with
the product.
Adding
accessibility
Many people focus on addressing
accessibility during the front-end
phase only.
However, accessibility must be
considered during the UX and design
phases as well.
UX wireframe/
prototype
libraries
UX wireframe/prototype libraries
should include accessibility
considerations such as:
Define a clear and consistent
navigation methodology.
Define clearly identifiable error
messages and error states.
Make sure that additional information
is associated in close proximity to
the relevant element.
Make sure that animations enhance
rather than detract from user
experience.
Attempt to reduce cognitive load for
complex UI components.

This is especially important if target audiences
include technology-challenged or cognitive-
impaired audiences.
Try to limit choices to allow for easier
decision making.

Again, this is critical for

cognitive-impaired users.
Describe how keystroke-only
interactions should “travel” through
complex components.

This is vitally important for

keyboard-only users.
Of course, these are just the tip of
the iceberg.
I’ve worked with UX teams who
assume that a lot of these
decisions will be resolved during the
front-end development phase.
However, it is better to resolve and
document these issues as early as
possible in the development process
- ideally during the UX phase.
Design style
guides
Design style guides should also
include accessibility
considerations, although the list is
much shorter:
Choose colour schemes that meet
colour contrast guidelines.

This is important for a range of visually-impaired
user groups.
Avoid using colour-alone to define
any critical information - especially
around error messages.
Define the use of icons and make
sure that they improve the user
experience rather than adding
confusion.

For some cognitive-impaired groups, icons can
become critical.
Define font-sizes, line-height and
vertical spacing that helps users
rather than making them work harder.
Baked-in?
In the old days, accessibility reviews
were often added just before the
launch of the website or web
application.
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
Feature releases
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 or sprint 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/Design 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
Adding
accessibility even
earlier?
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.
Making sure modules are keyboard-
friendly.
Making sure focus is intuitive and
visible across all aspects of modules.
Using additional aria roles, labels and
descriptions where appropriate.
If modules are built correctly, they
provide 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 Test Build Test Launch
As features move into production,
new modules and components are
built and added into the pattern
library.
Some teams 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/Design Test Build Test Launch
Final
thoughts?
For large websites and complex apps,
UX component libraries, Design style
guides and Front-end pattern libraries
are critical.
Accessibility should be an integral
part of all of these systems.
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 added.
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
1 of 151

More Related Content

Similar to Accessibility in Pattern Libraries(20)

Uxpin web ui design patterns 2014Uxpin web ui design patterns 2014
Uxpin web ui design patterns 2014
MoodLabs11.7K views
Web UI Design Patterns 2014Web UI Design Patterns 2014
Web UI Design Patterns 2014
Lewis Lin 🦊5.4K views
Building complex sites with JoomlaBuilding complex sites with Joomla
Building complex sites with Joomla
Paul Delbar1.6K views
Moodle reportMoodle report
Moodle report
Nabeel Mahmood396 views
Professional ui for a website designProfessional ui for a website design
Professional ui for a website design
Ravi Bhadauria11.3K views
Single sourcing to the maxSingle sourcing to the max
Single sourcing to the max
Neil Perlin516 views
Design systems - Razvan RosuDesign systems - Razvan Rosu
Design systems - Razvan Rosu
Razvan Rosu191 views
UI Design TrendsUI Design Trends
UI Design Trends
Karthikeyan Dhanasekaran CUA552 views
RWD - BootstrapRWD - Bootstrap
RWD - Bootstrap
Jasvinder Singh1.6K views
Thinking in ComponentsThinking in Components
Thinking in Components
FITC540 views
Molajo - J and Beyond 2011Molajo - J and Beyond 2011
Molajo - J and Beyond 2011
Molajo436 views
Mobile ui design patternsMobile ui design patterns
Mobile ui design patterns
KevinHao14151 views

More from Russ Weakley(20)

Accessible chat windowsAccessible chat windows
Accessible chat windows
Russ Weakley200 views
Accessible names & descriptionsAccessible names & descriptions
Accessible names & descriptions
Russ Weakley16 views
A deep dive into accessible namesA deep dive into accessible names
A deep dive into accessible names
Russ Weakley23 views
Accessible states in Design SystemsAccessible states in Design Systems
Accessible states in Design Systems
Russ Weakley1.3K views
Accessible Inline errors messagesAccessible Inline errors messages
Accessible Inline errors messages
Russ Weakley1.7K views
Accessible Form Hints and ErrorsAccessible Form Hints and Errors
Accessible Form Hints and Errors
Russ Weakley1.8K views
What is accessibility?What is accessibility?
What is accessibility?
Russ Weakley5.3K views
Building an accessible auto-completeBuilding an accessible auto-complete
Building an accessible auto-complete
Russ Weakley9.9K views
Creating Acessible floating labelsCreating Acessible floating labels
Creating Acessible floating labels
Russ Weakley2.8K views
Deep Dive into Line-HeightDeep Dive into Line-Height
Deep Dive into Line-Height
Russ Weakley3.8K views

Recently uploaded(20)

2022 CAPE Merit List 2023 2022 CAPE Merit List 2023
2022 CAPE Merit List 2023
Caribbean Examinations Council3K views
Scope of Biochemistry.pptxScope of Biochemistry.pptx
Scope of Biochemistry.pptx
shoba shoba110 views
Material del tarjetero LEES Travesías.docxMaterial del tarjetero LEES Travesías.docx
Material del tarjetero LEES Travesías.docx
Norberto Millán Muñoz57 views
Classification of crude drugs.pptxClassification of crude drugs.pptx
Classification of crude drugs.pptx
GayatriPatra1449 views
Education and Diversity.pptxEducation and Diversity.pptx
Education and Diversity.pptx
DrHafizKosar56 views
SIMPLE PRESENT TENSE_new.pptxSIMPLE PRESENT TENSE_new.pptx
SIMPLE PRESENT TENSE_new.pptx
nisrinamadani2146 views
Lecture: Open InnovationLecture: Open Innovation
Lecture: Open Innovation
Michal Hron82 views
NS3 Unit 2 Life processes of animals.pptxNS3 Unit 2 Life processes of animals.pptx
NS3 Unit 2 Life processes of animals.pptx
manuelaromero201389 views
discussion post.pdfdiscussion post.pdf
discussion post.pdf
jessemercerail70 views
ICS3211_lecture 08_2023.pdfICS3211_lecture 08_2023.pdf
ICS3211_lecture 08_2023.pdf
Vanessa Camilleri68 views
ACTIVITY BOOK key water sports.pptxACTIVITY BOOK key water sports.pptx
ACTIVITY BOOK key water sports.pptx
Mar Caston Palacio132 views
Psychology KS5Psychology KS5
Psychology KS5
WestHatch53 views
Industry4wrd.pptxIndustry4wrd.pptx
Industry4wrd.pptx
BC Chew153 views
231112 (WR) v1  ChatGPT OEB 2023.pdf231112 (WR) v1  ChatGPT OEB 2023.pdf
231112 (WR) v1 ChatGPT OEB 2023.pdf
WilfredRubens.com100 views

Accessibility in Pattern Libraries