In the old days, many developers looked at complex websites and web applications as a series of individual pages. These days, it’s all about abstracting these pages down to re-usable elements, modules and components which are then documented, designed and built as comprehensive pattern libraries. Pattern libraries can be used as an integral part of the UX, design and front-end development phases. But where should accessibility be included in these different types of pattern libraries? Come on a journey as we explore the pain and glory of baking accessibility into UX, design and front-end pattern libraries.
82. 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).
83. 3. Working with Visual Designers,
define key dynamic behaviours (i.e.
animations, transitions, fly-outs and
drop-downs).
84. 4. Define feedback and notification
mechanisms (i.e. success messages
and error messages).
85. 5. Define additional information
associated with modules (i.e. hints
and tips).
86. 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.
87. 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.
95. Make sure that additional information
is associated in close proximity to
the relevant element.
96. Make sure that animations enhance
rather than detract from user
experience.
97. Attempt to reduce cognitive load for
complex UI components.
This is especially important if target audiences
include technology-challenged or cognitive-
impaired audiences.
98. Try to limit choices to allow for easier
decision making.
Again, this is critical for
cognitive-impaired users.
107. 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.
118. A feature is a stand-alone section of
a web application. A new feature
may require anything from a single
screen to multiple screens.
119. For example, in a banking web
application, a new feature could allow
customers to add additional bank
accounts to the system.
120. Because features are released
individually, accessibility reviews can
be conducted on an individual
feature rather than an entire
application or site.
121. A single feature build process with
accessibility review before launch
UX/Design Test Build Test Launch
Review
122. And, if accessibility is considered
during all phases of feature
development, the accessibility review
should be even less painful.
123. A single feature build process with accessibility
integrated throughout all phases
A A Review
UX Test Build Test Launch