Annotating designs for accessibility
•
0 j'aime•228 vues
This presentation was delivered by Claire Webber to the Accessibility Global Collective in March 2023
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à Annotating designs for accessibility
Similaire à Annotating designs for accessibility (20)
Plus de Intopia
Plus de Intopia (20)
Dernier
Dernier (20)
Annotating designs for accessibility
- 1. Annotating Designs for Accessibility Claire Webber Digital Accessibility Consultant
- 4. Shift left
- 5. Cost of re-work Source: NIST
- 7. Benefits of annotations Saves time More eyes Collaboration Put into practise
- 10. Choose what will work for your team! What are you already doing?
- 11. States States for UI component – focus, hover, selected, etc!
- 12. Hover and focus
- 13. Selected
- 15. Colour Information on colour themes and how they should be used.
- 18. Headings Identify what should be a heading and plan your heading hierarchy
- 20. Keyboard Document keyboard patterns and interaction.
- 22. Content order Sometimes we may have special rules for content order.
- 24. Page titles Document the page titles or standards around page title format.
- 27. Page regions Identify and document the regions in your designs.
- 30. Images Identify informative images and provide a text alternative that conveys the meaning or content in your designs.
- 33. Focus order Document any decisions on focus order, or any page level interactions.
- 35. Features Any decisions or features added to support accessibility.
- 37. What now?
- 38. Have a go Start small Lead the way
- 39. Resources • Intopia's Annotation Kit (Figma) • Components.ai (Colour system lab) • Contrast Grid • Accessible Colour Design • Accessibility Toolkit from Jack Nicolai • Accessibility Bluelines by Jeremy Elder • ARIA Authoring Practices Guide
Notes de l'éditeur
- Why use annotations What should I annotate?
- The shift-left model is common across DevOps and agile methodology, which encourages quality to be addressed as early on in the process as possible. When it comes to Accessibility unfortunately the traditional quality modal is still often used, leaving accessibility until late in the process
- Accessibility is everyone's responsibility, and a lot of accessibility defects can be avoided at the design stage or earlier.
- By annotations we are talking about further documentation for the design. Like an architectural blueprint, we want all the information to be clear. If something is missing, how thick the foundations are for example – the house might fall down. We want to create: Consistent documentation Common understanding Easy to understand and act upon
- Save time Bring conversations up front More eyes Build collaboration Increase communication Helps build test cases Clear what is required for accessibility Takes out assumptions Increases accessibility knowledge across organisation Put it into practice – embed accessibility into your way of working
- All of the examples today we will be using our own annotation kit which you can find in the Figma community Our kit has a set of small annotations with a comment template for adding more details off to the side, saving room on your design itself. We also recently update the kit with a dark mode, so it is more flexible for different colour schemes, ensuring your annotations are always highly visible. - There are many other annotation kits also available, so have a play in whatever application you are using
- No matter what you decide, it will be a chore if it does not already fit into your team’s workflow Think about what you currently do and how you document things, and choose a process that will fit within that
- States is a really great place to start when it comes to documenting accessibility. Think about each state of your component and if it will be accessible. This may be something that is documented at the component or design system level, if you have one
- Hover and focus are a great place to start. Make sure you are documenting these states Ensure they are checked over for contrast in particular. We want to make sure our text contrast is maintained in every state and the keyboard focus indicator is very clear with enough contrast. - What backgrounds will the component be used on? Will the hover and focus states be clear in every scenario?
- Selected states are important as well. Similar to the hover and focus, we want to make sure contrast is maintained in every state. Will someone be able to easily tell something is selected? Make sure your selected state has enough contrast and is not relying on a colour change.
- Ensure you cover additional states such as errors. Ensure you have covered error states for relevant components, what happens when something goes wrong and how will your user recover? Ensure these states are accessible Not relying on colour alone Easy to see Where are error text cases covered? Can a user recover from the error? Where are errors displayed? How long are they shown? What happens to focus? Ensure you are also covering combinations of states. Is your component still accessible while two states are active? For example error and keyboard focus. Or perhaps focus and hover, etc.
- Whether you have a design system or a set of brand colours, ensuring your palette can be used in an accessible way is esstenial. Give your team some clear guidance around how colours should be used.
- There are some tools you can use to automate this process, otherwise it can be very manual and time consuming. In these tools, you can input all the colours in your palette and create a guide on which colours can be used together to create strong contrast. These three I found the best components.ai Accessible colour design Contrast grid
- The components colour system lab was my favourite, as you can change the output view to suit you. It is really easy to find accessible combinations for each colour. Decide where the best location to document this information will be. Create a reference point where designers can easily and quickly find accessible colour combinations.
- Another area that is important to think about upfront is headings. Don’t leave your heading hierarchy until development, at the design stage is a great time to plan and document What should be a heading What level each heading should be Designs and content writers are best placed to ensure the heading hierarchy reflects the content itself as you are more familiar with it
- You can use annotations to markup the design with what level each heading should be. No matter how the heading looks, the hierarchy should be considered at the page level, to ensure underlying code reflects the content’s hierarchy For those not familiar, in HTML headings can be a level 1 or H1 through to a H6. Your headings should reflect a hierarchy, similar to a table of contents. Screen reader users rely on headings when navigating, so its important that the underlying heading levels reflect the visual hierarchy of the page. A neat way of checking your hierarchy is to bring the headings out of context beside your design, as shown here on the left, forming a neat little table of contents for your page. This way you can confirm that the heading levels will be set correctly, not skipping and levels and forming a nice little tree.
- Keyboard patterns and interactions is another that may be best documented at the component or design system level.
- We want to make sure any custom components have their keyboard interactions well documented and understood. ARIA Authoring Practises Guide
- At the component/design system level you may occasionally have special rules for content order. This is something which should be more uncommon but sometimes still comes up
- Particularly for components such as cards. In this example there is some content above the heading. <describe> For users who are navigating by headings they may miss this, so we may want the code order and visual order to be slightly different to support this <describe>
- Another area which is really helped by documentation is page titles. If you have a smaller site you may be choosing a page title at the page level. Or for a larger site you may need some standards around page title formats
- The page title is what is displayed in your browser bar. This can be a great wayfinding tools for users to orient themselves, but it can be particular important for screen reader users.
- Some options If you have a design system, have some documentation around page titles Example from NSW Education Include page title information in specifications Add a note/annotation to the design file
- More than just the order of focus – but also focus management Focus management – where is focus going to go, or return to
- Have you added any particular features or made a decision to support accessibility? These are great to annotate or document somewhere clearly. You don’t want something inadvertently removed or changed that was added for accessibility
- Skip links Some other examples might be: A play/pause button A transcript below a video component Alternatives to guestures
- You might be thinking, that was a lot! What do I do now?
- Have a go: Give an annotation kit a try. Try outs of one of the other existing annotation systems The one we showed today we have published in the Figma community Make your own, build on your own existing design system/processes, think about how annotations can be used for more than just accessibility Start small: Don’t be daunted Pick something to start with that is going to have a big impact Lead the way Accessibility is all about momentum