Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Accessibility in Pattern Libraries

502 views

Published on

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.

Published in: Education
  • Be the first to comment

  • Be the first to like this

Accessibility in Pattern Libraries

  1. 1. Accessibility in pattern libraries
  2. 2. pages Moving away from
  3. 3. Does anyone remember a time when we built websites using table-based layouts and spacer gifs?
  4. 4. For a long time, people used to approach complex websites and web applications as a series of “pages”.
  5. 5. These pages were often designed and built as complete entities.
  6. 6. This practice began to change in 2006-2007 when people began to abstract aspects of web pages into “reusable patterns”.
  7. 7. The earliest patterns, like BluePrint CSS (released in 2007), focussed on abstracting the overall layout grids.
  8. 8. More complete systems soon followed. However, many of these were just glorified style guides rather than pattern libraries.
  9. 9. In 2009, Nicole Sullivan introduced “Object Oriented CSS” and the concept of abstracting aspects of the UI became a serious business.
  10. 10. By 2011, there were a wide range of off-the-shelf pattern libraries, like Twitter’s Bootstrap.
  11. 11. This concept of “abstracting aspects of the UI” is an important part of all style guides and pattern libraries.
  12. 12. We’re going to look at three different systems and how to include accessibility as part of the process.
  13. 13. 1. Front-end pattern libraries 2. Design style guides 3. UX wireframe/prototype libraries
  14. 14. Now, you may have totally different names for each of these… or you may work in a different way… and that’s ok!
  15. 15. pattern libraries Front-end
  16. 16. Front-end pattern libraries are a collection of user interface components.
  17. 17. These components should take the form of fully functional HTML/CSS/ JS code snippets.
  18. 18. The code snippets should include all states, dynamic behaviours and feedback mechanisms.
  19. 19. Along with the code snippets, there should be additional information such as context and usage.
  20. 20. Front-end pattern libraries have a range of benefits.
  21. 21. In many cases, they make it faster and easier to build.
  22. 22. If done well, they are much easier to update and maintain.
  23. 23. And most importantly, they provide a consistent level of quality.
  24. 24. Lego blocks?
  25. 25. Most complex pattern libraries follow the “Lego building block” concept.
  26. 26. This means abstracting the UI down to individual “building blocks” and then using these blocks to build larger and more complex components.
  27. 27. In the early days there was often heated debate as to how to categorise the UI and what to call each of the categories.
  28. 28. This “categorisation dilemma” came to a head in 2013 when Brad Frost introduced Atomic Design.
  29. 29. Brad came up with a naming convention that used five categories: atoms, molecules, organisms, templates and pages.
  30. 30. People became obsessed with trying to force their pattern libraries into these categories rather than seeing them as a suggested framework.
  31. 31. Let’s keep it simple, and break everything into elements, modules, components and screens.
  32. 32. Elements Modules Components Screens
  33. 33. Elements
  34. 34. Elements are standard HTML elements such as headings, paragraphs, tables, forms, fieldsets, labels, inputs and buttons.
  35. 35. They are the basic building blocks of any pattern library.
  36. 36. These elements are sometimes used on their own but are more commonly used to make modules and components.
  37. 37. Modules
  38. 38. Modules are small sets of elements that are joined together in reusable chunks.
  39. 39. For example, an input module could include a label and an input.
  40. 40. Input label A basic input module
  41. 41. However, the module should consider all possible states and options.
  42. 42. Input label Additional Information A input module with additional information
  43. 43. Input label Error message A input module in error state
  44. 44. Input label Additional Information A input module in disabled state
  45. 45. Input label Additional Information A input module in focus state
  46. 46. Each module should be defined as simply as possible so that they are highly flexible.
  47. 47. In most cases, modules should not have a specific width or any vertical spacing. These should be handled using modifiers and helper classes.
  48. 48. Components
  49. 49. Components are made from a series of elements and modules that are added together to build more comprehensive concepts.
  50. 50. An example might be a signup form that includes various form control modules, a button module and a potential success/error module.
  51. 51. Elements
  52. 52. Modules
  53. 53. Component
  54. 54. Screens
  55. 55. Screens are where elements, modules and components are combined into the final concepts that are presented to the user.
  56. 56. An example might be a login screen, which includes the login form, navigation, header and footer components.
  57. 57. 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.
  58. 58. A dirty secret
  59. 59. While starting from tiny Lego blocks is a sound approach, it does not work for all components or screens.
  60. 60. In some cases, the process needs to start with components or screens, and these need to be broken down into modules.
  61. 61. There are also times when a component produces unique modules that will never be used for anything apart from that component.
  62. 62. In these cases, there is a question as to whether they should ever become modules, or stay as part of the larger component.
  63. 63. There is no “one size fits all” when it comes to pattern libraries. Embrace the anomalies and move forward.
  64. 64. The danger of
 copy/paste
  65. 65. Front-end pattern libraries should allow modules and components to be referenced directly from the pattern library in some way.
  66. 66. The system should not allow developers to copy and paste code snippets from the library.
  67. 67. Code snippets that have been copied and pasted have to be manually updated.
  68. 68. More importantly, copying and pasting code snippets allows developers to misuse or abuse the code.
  69. 69. Remember, every time you allow a developer to copy and paste code snippets from a front-end pattern library, a puppy dies!
  70. 70. Design style guides
  71. 71. A design style guide provides a framework for consistent visual practices.
  72. 72. Design style guides should address (amongst other things):
  73. 73. 1. How core branding will be implemented across the website or app.
  74. 74. 2. The overall “look and feel”.
  75. 75. 3. How typefaces and font-size will be used.
  76. 76. 4. How colour schemes will be used.
  77. 77. UX wireframe/prototype libraries
  78. 78. UX wireframe/prototype libraries often take the form of detailed wireframes and/or prototypes.
  79. 79. These types of libraries should:
  80. 80. 1. Define all elements, modules and components.
  81. 81. 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).
  82. 82. 3. Working with Visual Designers, define key dynamic behaviours (i.e. animations, transitions, fly-outs and drop-downs).
  83. 83. 4. Define feedback and notification mechanisms (i.e. success messages and error messages).
  84. 84. 5. Define additional information associated with modules (i.e. hints and tips).
  85. 85. 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.
  86. 86. 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.
  87. 87. Adding accessibility
  88. 88. Many people focus on addressing accessibility during the front-end phase only.
  89. 89. However, accessibility must be considered during the UX and design phases as well.
  90. 90. UX wireframe/ prototype libraries
  91. 91. UX wireframe/prototype libraries should include accessibility considerations such as:
  92. 92. Define a clear and consistent navigation methodology.
  93. 93. Define clearly identifiable error messages and error states.
  94. 94. Make sure that additional information is associated in close proximity to the relevant element.
  95. 95. Make sure that animations enhance rather than detract from user experience.
  96. 96. Attempt to reduce cognitive load for complex UI components. This is especially important if target audiences include technology-challenged or cognitive- impaired audiences.
  97. 97. Try to limit choices to allow for easier decision making. Again, this is critical for
 cognitive-impaired users.
  98. 98. Describe how keystroke-only interactions should “travel” through complex components. This is vitally important for keyboard-only users.
  99. 99. Of course, these are just the tip of the iceberg.
  100. 100. I’ve worked with UX teams who assume that a lot of these decisions will be resolved during the front-end development phase.
  101. 101. However, it is better to resolve and document these issues as early as possible in the development process - ideally during the UX phase.
  102. 102. Design style guides
  103. 103. Design style guides should also include accessibility considerations, although the list is much shorter:
  104. 104. Choose colour schemes that meet colour contrast guidelines. This is important for a range of visually-impaired user groups.
  105. 105. Avoid using colour-alone to define any critical information - especially around error messages.
  106. 106. 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.
  107. 107. Define font-sizes, line-height and vertical spacing that helps users rather than making them work harder.
  108. 108. Baked-in?
  109. 109. In the old days, accessibility reviews were often added just before the launch of the website or web application.
  110. 110. Full site build with accessibility review just before launch UX Design Build Launch Review
  111. 111. Even worse, in some circumstances, reviews were carried out after launch - only when someone made a complaint.
  112. 112. Full site build with accessibility review after launch UX Design Build Launch Review
  113. 113. Feature releases
  114. 114. With complex applications and websites, there has been a shift away from a single massive build cycle.
  115. 115. Instead, complex applications and websites are often rolled out in a series of feature or sprint releases.
  116. 116. Feature Feature Feature Feature Rolling feature releases over time
  117. 117. A feature is a stand-alone section of a web application. A new feature may require anything from a single screen to multiple screens.
  118. 118. For example, in a banking web application, a new feature could allow customers to add additional bank accounts to the system.
  119. 119. Because features are released individually, accessibility reviews can be conducted on an individual feature rather than an entire application or site.
  120. 120. A single feature build process with accessibility review before launch UX/Design Test Build Test Launch Review
  121. 121. And, if accessibility is considered during all phases of feature development, the accessibility review should be even less painful.
  122. 122. A single feature build process with accessibility integrated throughout all phases A A Review UX Test Build Test Launch
  123. 123. Adding accessibility even earlier?
  124. 124. However, with the use of pattern libraries, accessibility can be “baked in” even earlier in the process.
  125. 125. In many cases, an initial pattern library is built before any features are ready.
  126. 126. These initial pattern libraries often include elements and modules but no components.
  127. 127. Accessibility should be “baked into” each of these modules. And, they need to be carefully reviewed before proceeding.
  128. 128. What does this mean? Well, it means following basic accessibility guidelines.
  129. 129. Making sure all modules use semantic and well-formed markup.
  130. 130. Using alt attributes on images.
  131. 131. Making sure for and id attributes are used correctly for labels and inputs.
  132. 132. Making sure th, thead, tbody are used appropriately in tables.
  133. 133. Making sure modules are keyboard- friendly.
  134. 134. Making sure focus is intuitive and visible across all aspects of modules.
  135. 135. Using additional aria roles, labels and descriptions where appropriate.
  136. 136. If modules are built correctly, they provide a solid foundation for all future components.
  137. 137. The process is often similar to a feature release, except the outcome is the initial pattern library rather than a feature.
  138. 138. Pattern library build with accessibility integrated throughout all phases A A Review UX/Design Test Build Test Launch
  139. 139. As features move into production, new modules and components are built and added into the pattern library.
  140. 140. Some teams make the mistake of assuming that these components will automatically be accessible because they use the tested modules as a base.
  141. 141. However, components often present their own accessibility issues.
  142. 142. For this reason, new components should also be tested and reviewed before launch, as part of the feature release.
  143. 143. A single feature build process with accessibility integrated throughout all phases A A Review UX/Design Test Build Test Launch
  144. 144. Final thoughts?
  145. 145. For large websites and complex apps, UX component libraries, Design style guides and Front-end pattern libraries are critical.
  146. 146. Accessibility should be an integral part of all of these systems.
  147. 147. For front-end pattern libraries, make sure to bake accessibility into all core modules and test carefully.
  148. 148. Make sure to test all components and screens as they are added.
  149. 149. These steps will save a world of pain in the future.
  150. 150. Russ Weakley Max Design Site: maxdesign.com.au Twitter: twitter.com/russmaxdesign Slideshare: slideshare.net/maxdesign Linkedin: linkedin.com/in/russweakley

×