Accessibility in pattern libraries
•
2 likes•1,652 views
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.
Report
Share
Accessibility in pattern libraries
- 1. Accessibility in pattern libraries Accessibility in pattern libraries
- 3. In the past, many people approached complex websites and web applications as a series of “pages”.
- 4. These pages were often designed and built as complete entities.
- 5. More recently, in complex websites and applications, the focus has shifted from full page layouts to re-usable components.
- 6. 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.
- 8. Pattern libraries are a collection of user interface components that can be used multiple times across a website or web application.
- 9. On large websites and complex applications, pattern libraries have a range of benefits.
- 10. In many cases they make it faster and easier to build.
- 11. If done well, they provide a shared vocabulary across all teams.
- 12. And most importantly, they provide a consistent level of quality.
- 13. Lego blocks?
- 14. Most complex pattern libraries follow the “lego building block” concept.
- 15. This means that they start with individual “lego building blocks” and then use these block to build larger and more complex components.
- 16. Complex pattern libraries are often broken down into categories such as elements, modules and components.
- 18. Elements
- 19. Elements are standard HTML elements such as headings, labels, inputs, buttons, etc.
- 20. They are the basic lego building blocks of the pattern library.
- 21. Most of these elements are rarely used on their own - they are used to make modules and components.
- 22. Modules
- 23. Modules are small sets of elements that are joined together in re-usable chunks.
- 24. 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.
- 25. Static Input Disabled Input This field cannot be filled in Error Message Additional Information Additional Information Invalid Input Focussed Input Invalid user data Value Additional Information Inputs Placeholder Static Input Additional Information Value 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 Placeholder Input module
- 26. Components
- 27. Components are modules that are added together to build larger, more comprehensive concepts.
- 28. An example might be a signup form that includes various form control modules, a button module and a potential success/error module.
- 29. Elements
- 30. Modules
- 31. Component
- 32. Final screens
- 33. Screens are where modules and components are combined into the final concepts that are presented to the user.
- 34. 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.
- 35. 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.
- 36. Generally, screens are not part of a pattern library. The pattern library is used to help create these screens.
- 38. Pattern libraries can and should be used during all phases of the design and development process.
- 39. There are three distinctly different types of pattern library: UX/UI pattern libraries Design style guides Front end pattern libraries
- 41. UX/UI pattern libraries often include comprehensive documentation that:
- 42. 1. Define all elements, modules and components.
- 43. 2. Define the various states for all elements, modules, components (i.e. hover, focus, active states, logged-in or logged out etc).
- 44. 3. Define key dynamic behaviours (i.e. animations, transitions, fly-outs, drop-downs etc).
- 45. 4. Define feedback and notification mechanisms (i.e. success messages, error messages etc).
- 46. 5. Define additional information associated with modules (i.e. hints, tips etc).
- 47. These pattern libraries normally take the form of detailed wireframes and/ or prototypes along with additional documentation.
- 48. They help to communicate to internal teams and stakeholders how a website or app should be built.
- 50. 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 application.
- 51. For this reason, they are more often style guides rather than pattern libraries.
- 52. Design style guides should address:
- 53. 1. How core branding will be implemented across the website or app.
- 54. 2. The overall “look and feel”.
- 55. 3. How typefaces and font-size will be used.
- 56. 4. How colour schemes will be used.
- 58. Front-end pattern libraries should produce fully functional HTML/CSS/ JS examples of all elements, modules and components.
- 59. These examples should include all states, dynamic behaviours and feedback mechanisms.
- 60. These elements and modules can then be used as needed to rapidly build complex components and the final screens.
- 61. The danger of copy/ paste pattern libraries
- 62. 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.
- 63. The problem is that they can easily be applied incorrectly.
- 64. Pattern libraries should be built so that modules and components are referenced directly from the pattern library in some way.
- 65. This means that they can be updated automatically without leaving legacy versions across an application.
- 66. More importantly, they cannot be applied incorrectly.
- 68. There is a wide range of pre-existing UX and front-end pattern libraries available today.
- 69. Some of these pattern libraries have a simple purpose - such as predefined sets of UI modules in wireframe form, or front-end grid systems.
- 70. Others, especially in the front-end, are full “frameworks” that offer a wide range of fully functional elements, modules and components.
- 71. There are some great benefits to using a pre-existing framework.
- 72. They are often ready to use and are therefore quick to implement.
- 73. They are also often useful for rapid prototyping during the UX/UI phase.
- 74. However, there can be some downsides as well.
- 75. The pre-build modules and components may not suit your project which means they have to be heavily modified.
- 76. They often produce a generic look, mainly because people are not experienced enough to know how to customise them.
- 77. You are also relying on someone else for code quality.
- 78. This is especially true for accessibility within pre-existing frameworks.
- 79. Do you want to rely on others to make sure all of your modules and components are accessible?
- 81. Many people focus on addressing accessibility during the front-end phase only.
- 82. However, accessibility can be addressed to some degree during the UX/UI and design phases as well.
- 83. UX/UI pattern libraries should describe solutions to some aspects of accessibility such as states, behaviours, proximity, notifications, error messages etc.
- 84. Good UX/UI pattern libraries even help to describe how keystrokes should allow users to “travel” through complex components.
- 85. These descriptions should help front-end teams when building the final modules and components.
- 86. 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.
- 87. These requirements can then be applied into the front-end modules and components.
- 88. So, the UX/UI and design phases provide recommendations and requirements.
- 89. And these recommendations and requirements can then be put into action during the front-end phase.
- 91. In the old days, accessibility reviews were often tacked on at the end of major site or application builds. Often just before launch.
- 92. Full site build with accessibility review just before launch UX Design Build Launch Review
- 93. Even worse, in some circumstances, reviews were carried out after launch - only when someone made a complaint.
- 94. Full site build with accessibility review after launch UX Design Build Launch Review
- 95. Of course, that sort of thing never happens today… does it?
- 96. With complex applications and websites, there has been a shift away from a single massive build cycle.
- 97. Instead, complex applications and websites are often rolled out in a series of feature releases.
- 98. Feature Feature Feature Feature Rolling feature releases over time
- 99. A feature is a stand-alone section of a web application. A new feature may require anything from a single screen to multiple screens.
- 100. For example, in a banking web application, a new feature could allow customers to add additional bank accounts to the system.
- 101. Because features are released individually, accessibility reviews can be conducted on an individual feature rather than an entire application or site.
- 102. A single feature build process with accessibility review before launch UX Test Build Test Launch Review
- 103. And, if accessibility is considered during all phases of feature development, the accessibility review should be even less painful.
- 104. A single feature build process with accessibility integrated throughout all phases A A Review UX Test Build Test Launch
- 105. However, with the use of pattern libraries, accessibility can be “baked in” even earlier in the process.
- 106. In many cases, an initial pattern library is built before any features are ready.
- 107. These initial pattern libraries often include elements and modules but no components.
- 108. Accessibility should be “baked into” each of these modules. And, they need to be carefully reviewed before proceeding.
- 109. What does this mean? Well, it means following basic accessibility guidelines…
- 110. Making sure all modules use semantic and well-formed markup.
- 111. Using alt attributes on images.
- 112. Making sure for and id attributes are used correctly for labels and inputs.
- 113. Making sure th, thead, tbody are used appropriately in tables.
- 114. Using additional aria roles, labels and descriptions where appropriate.
- 115. If modules are built correctly, they provides a solid foundation for all future components.
- 116. The process is often similar to a feature release, except the outcome is the initial pattern library rather than a feature.
- 117. Pattern library build with accessibility integrated throughout all phases A A Review UX Design Build Ready
- 118. As new features move into production, new components are built and added into the pattern library.
- 119. Some people make the mistake of assuming that these components will automatically be accessible because they use the tested modules as a base.
- 120. However, components often present their own accessibility issues.
- 121. For this reason, new components should also be tested and reviewed before launch, as part of the feature release.
- 122. A single feature build process with accessibility integrated throughout all phases A A Review UX Test Build Test Launch
- 123. Bottom line
- 124. For large websites and complex apps, pattern libraries are critical.
- 125. UX/UI pattern libraries and design style guides should include accessibility as part of the process.
- 126. For front-end pattern libraries, make sure to bake accessibility into all core modules and test carefully.
- 127. Make sure to test all components and screens as they are released with features.
- 128. And, avoid building pattern libraries that rely on developers having to copy/paste code samples.
- 129. These steps will save a world of pain in the future.
- 130. Russ Weakley Max Design Site: maxdesign.com.au Twitter: twitter.com/russmaxdesign Slideshare: slideshare.net/maxdesign Linkedin: linkedin.com/in/russweakley