Top 10 Accessibility mistakes and Why?


Nawaz @PayPalInclusive

When should testing take place?

  • Now : Mostly tested before release by QA and accessibility team finds problems post production.
  • Issues found may not be fixed as it may have high design or code changes, also needs Product Management decision.
  • Designer should test before giving mockup and Developer should test before code commit.
  • Then comes QA with tools and technologies.

Focus on Frequently seen errors

  1. Many of the errors occur again and again...
  2. Either teams are not educated or they don't care.

Top 10: Undestand Why those error occur

Here I'm just trying to explain as a developer on what could be the possible reason for error from my experience as programmer and frequently worked with designers.

1. Img element missing an alt attribute

  1. Why? : Wedevelopers put placeholders on a page. Images are updated by content publisher. CMS system may lag alt attribute or alt is not mandatory. Also content publisher never learnt how useful is the alt attribute. Some may understand it to be useful for SEO, but it would be the job of SEO to promote alt text.
  2. How to find: Wave toolbar, Firefox Webdeveloper tool
  3. Solution: Content authors should test their work before publishing. They should be educated on the Alt text decision tree.

2. Anchor element found with no link content and no name and/or ID attribute


	
  1. Why? : Link are done makeup to work like buttons. JavaScript does some fancy things. Developers don't understand how select element, button, submit button link etc work for a non mouse user.
  2. How to find: Keyboard navigation, Touch Navigation or Wave toolbar
  3. Solution: Need to deeply understand user interactions. Elements should work like the way they look.

3. Outline:none


								a { outline: none; }
					
  1. Why? : Cosmetic reasons says the developer or CSS resets.
  2. How to find: Keyboard navigation
  3. Solution: Re-define focus style
    						
    a:focus {
    	outline: 1;
    }
    

4. Poor color contrast

  1. Why? : Designers copy design from other sites and fail to pass it through contrast filter. Color palettes are validated
  2. How to find: Color Contrast Analyser (early stage), Chrome Accessibility Toolbar (late stage)
  3. Solution: Design palettes with good luminousity and contrast for body text and links
Nice article on color contrast [https://viget.com/inspire/color-contrast]

5. Form does not contain a submit button

  1. Why? : Innovation for the sake of innovation. May look nice, but painful for many users.
  2. How to find: Keyboard navigation
  3. Solution: Submit button should exist or use AJAX and make sure the new content is available to PWD.

6. Lang Attribute Missing

  1. Why? : Developer handcode HTML rather than using generators for sake of clear code. Miss it because there are many meta tags as well
  2. How to find: View source
  3. Solution: Go back to basics on meta tags and html attributes.

7. Textarea element does not have a name available to an accessibility API

  1. Why? : Design don't have visible label for textarea (Most). Text next to input is understood as label
  2. How to find: Click on label, Wave
  3. Solution: Go back to basics on html.

8.Events bound to items that are not discoverable via keyboard

  1. Why? : Developers try to mimic desktop application without proper understanding of how the application works with different inputs. Developers code for mouse and QA test with mouse clicks and hovers.
  2. How to find: Keyboard navigation, Touch navigation
  3. Solution: Have clear element and widget guidelines on how they should work for different inputs. Should work like the way they look.

9. Data tables with no headers

  1. Why? : Lack of markup knowledge and how the table caption, headers etc. work for PWD.
  2. How to find: Test with Screen readers
  3. Solution: Clear element and Widget guidelines. Need to undestand the importance of caption, row headers etc.

10. Error Recovery

  1. Why? : Replaced JavaScript alerts with spans and Divs with styles. Developers don't know how those old alerts used to work for non mouse users
  2. Problems: Difficult to find the error field, error field is not focussed. Message have low contrast.
  3. How to find: Keyboard and Screen readers.
  4. Solution: Make them prominent. Message size, colour and location of messages are important. Need to use role of alert.

Other problems

  1. Pile of Documentation for WCAG, Section 508.
  2. More than one solution for Aria and Experts do not agree upon common solution
  3. Giving more than one opinion confuses the developer
  4. ARIA widgets required extra JavaScript, need to include it in estimation
  5. InAccessible Deisgn or Code is not seen as Qualtiy of issue

Quick Check Demo

References:

  1. https://viget.com/inspire/color-contrast
  2. All about outline: none
  3. Writing error messages
  4. Easy Checks - A First Review of Web Accessibility
  5. 10 Accessibility Checks in 10 minutes

Contact

PayPal Accessibility

Follow us on Twitter / @PayPalInclusive