It seems that style guides are meant to serve as good examples of Company-Endorsed HTML Code, CSS Usage, Brand Colors, Logo Usage, etc. Their purpose is also likely to train employees in standardized coding practices to make collaboration easier.
So why would your company want to actively promote inaccessible HTML coding methods that actually reduce customer usability of your website and forms?
The Style Guide is the PERFECT place to promote standards-compliant, accessible code and user-centered design/usability best practices!
In Part 1 of this series I’ll post a few inaccessible code examples from Yelp’s style guide which gave me the idea for this topic.
Examining Style Guides from Web Companies
Stylibrary is a collection of style guides from big web companies like GitHub, Yelp, WordPress, jQuery, and more. Maybe it will be updated with more in the future, I’m sure there are lots of other big company’s style guides out there and I’m sure they have accessibility problems in the code samples.
Yelp recently made their front-end design and development style guide open to the public on their blog, Yelp Product & Engineering Blog: Yelp’s got style (and the guide to back it up). It looked interesting so I checked it out and did my accessibility nerd thing and went straight to examine the code to see if it was actually accessible.
Finding issues like bad color contrast does not surprise me in modern web libraries, e.g. gray on gray text, really light, hard to read gray text, etc. WCAG 2.0 AA color contrast violations are present and can easily be discovered with a contrast analyzing tool like Deque’s FireEyes.
Forms Accessibility Failures Are More Disappointing
Forms are the first place to look and see if a company is following accessibility requirements. Yelp’s text input examples have label elements that are not connected to their inputs using the for/id construct. Their fieldset examples with radio buttons or checkboxes do not have legends to serve as the common label for the set.
Jim Thatcher’s Favlets showing errors on the labels and inputs.
Since there is no connected label VoiceOver reads “edit text Placeholder text”.
Yelp’s Inaccessible Form Labels Code
<input type="text" placeholder="tacos, cheap dinner, Max's">
<span class="help-block">Optional. Yelper name or an email address.</span>
<textarea placeholder="Placeholder text"></textarea>
<input type="text" disabled="disabled" placeholder="Disabled placeholder text">
Yelp’s Form Labels Code Made Accessible
<label for="input1">Label name</label>
<span id="help1" class="help-inline">Optional</span>
<input type="text" id="input1" aria-describedby="help1" placeholder="tacos, cheap dinner, Max's">
<label for="input2">Label name</label>
<span id="help2" class="help-block">Optional. Yelper name or an email address.</span>
<textarea id="input2" aria-describedby="help2" placeholder="Placeholder text"></textarea>
<input type="text" aria-label="Invisible Label Name" disabled="disabled" placeholder="Disabled placeholder text">
In addition to not creating accessible names for a screen reader to speak to a blind user the form labels are also not “clickable”, that is, a mouse user cannot click on the label to put their input cursor into the text field and a mobile user cannot tap on the label to set focus to the input either. This is bad for usability! Our fat fingers need extra space to tap.
Error Messages Not Programmatically Associated
Yelp’s form error messages are not spoken by screen readers in forms mode because the error text is not connected to the input. Instead VoiceOver for OS X is shown reading only “edit text blank”.
Using WAI-ARIA this can be fixed easily like so:
<input type="text" aria-required="true" aria-invalid="true" aria-describedby="error" class="input-error">
<p id="error" class="text-error text-error-inline">Please provide a valid email address</p>
In Part 2 I’m likely going to use GitHub’s style guide for examples because they have TONS of problems with their forms!
Let me know what you think in the comments 🙂