accessibility in pattern libraries

Click here to load reader

Post on 23-Jan-2018




0 download

Embed Size (px)


  • 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


  • 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


  • 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


    Additional Information



    Static Input

    Additional Information


    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


    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


  • 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


  • 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

    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


  • 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

    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


  • 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


  • 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

View more