Accessible Web Design
•
1 j'aime•1,873 vues
Describes why web accessibility should be considered right from the design phase.
Recommandé
Contenu connexe
En vedette
En vedette (20)
Dernier
Dernier (20)
Accessible Web Design
- 1. Accessible Design Ramya Sethuraman, Jan 2013
- 2. Accessibility issues in the design phase?
- 3. Color
- 5. Font size
- 8. Fly-outs & hovers (contd.)
- 9. Fly-outs & hovers (contd.)
- 11. Focus indicators
- 12. Keyboard navigation in design
- 14. Links
- 15. Links (contd.)
- 16. Headings
- 17. This is just a sample of what can be done towards accessibility in the design phase. For a quick glace at accessible design, take a look at webaim: http://webaim.org/resources/designers/
Notes de l'éditeur
- Does it make sense to do an accessibility evaluation in the design phase?
- To a color blind person, the sign in form on the left looks like the one on the right. In this case, color is not the only indication of the error, so this form is accessible.
- In this screen shot from linkedIn, the placeholder text “Search” and the white background color do not have sufficient color contrast. People with low vision will have difficulties reading this text.
- I took this screen shot after increasing text size only just once on Safari. While this may be solvable by using relative font sizes or not specifying a size at all, another design alternative is to not clutter the screen with so much information that even just doubling the font size results in overlap.
- The Kayal website handles font increases much better (here I have zoomed text twice on Safari).
- This is a nice accessibility issue to catch in the design phase – keyboard accessibility. Ensure that menus that popup on hover can also be activated using just the keyboard. The menu shown above can also be navigated using just the keyboard.
- Amazon’s fly-out menu is completely inaccessible by the keyboard (they have a different version of this website which they say is accessible).
- The ‘Shared with’ privacy icon in Facebook has a hover menu that also pops up when it gets keyboard focus.
- This is an interesting use case. How do you convey to screen readers that the ‘Place Order’ section is highlighted? One way to do it is to use the <mark> element in html5 (not yet supported by screen readers). But, in this case, the whole section is an image. We could give an alt text of “Place Order” to the image but then the rest of the information in the image is lost. If the whole section were coded as tabs, the problem would be easy to solve because the active tab would have aria-selected as true. Another issue (which is not relevant to this screen shot) is when the ‘Place Order’ text alone is in red to indicate that it is active. That problem can be easily solved for color blind users by giving the active link a border or making it bold. There is the less elegant option of giving instructions for screen reader users in text within the link and placing the text off-screen.
- If you are planning to remove the default dotted focus outline, provide a focus indicator that is accessible such as a border that is bold. I prefer the dotted indicator to the blue indicator in the picture because the blue focus indicator is not accessible to color blind users.
- It would be neat if we can indicate keyboard navigation in the design document. For eg: for the menu above, we can indicate in the design document: ‘Tab to place focus on settings icon. Arrow up/down through menu items. Esc to close menu and place focus back on the icon.
- Another useful enhancement to a design document is to add wai-aria information to it. For eg, we could add information to this screen shot: role=“dialog”, aria-labelledby pointing to the id of the heading ‘Create New Event’, focus should go to the first focusable element in the dialog, esc to close dialog.
- Make links look like links. This is not to say that all links have to be underlined but visually, it should be obvious to the user that they are links. In this screen shot above, it is not clear at a first glance that all the text below the image are links. The good thing about this design is that an underline shows up once you hover over the links. Unfortunately this feature is not available to keyboard only users. There is no focus outline anywhere on the page.
- The links on the ibm able page are more obvious because of their location. I don’t think it is feasible anymore to ask that links be underlined by default because it has become the design norm to not underline links but any other way that we can indicate that a link is actually a link and not static text, it will be helpful. Something to keep in mind in the design phase.
- Headings are really important for accessibility since screen reader users usually jump through headings to get a sense of what is on the page. The Google home page makes good use of headings: the arrows indicate headings.