When building my projects at Flatiron School, some things I always liked to keep at the forefront were ease of use and accessibility. I wanted to make the apps I built to be accessible to a wide audience, which initially meant to me: keeping them simple - no muss, no fuss. Now that I’m at the end of my curriculum, I am thinking about how I can continue to grow as a programmer and how to implement better accessibility features in my projects. I wondered about how ADA Policy is applied to the internet, and what the technical guidelines are, so I did some research on web accessibility.
WEB ACCESSIBILITY
As technology expands and evolves, the web becomes an increasingly essential place for activities such as learning, communicating, and otherwise accessing resources. Web accessibility means making content accessible to those with disabilities that include, but are not limited to, auditory, cognitive, neurological, physical, and visual impairments. However, accessibility is not always at the forefront of web development, and guidelines for creating accessible content are not always clear, uniformly applied, or enforced. The WebAIM Project run by the Center for Persons with Disabilities at Utah State tested the top 1 million websites and found that 97.4% of home pages had WCAG 2 failures.
WHAT IS WCAG 2?
The Web Content Accessibility Guidelines are technical guidelines established by the W3C for making Web content more accessible. It is modeled on four basic principles — web content should be POUR: Perceivable, Operable, Understandable, and Robust. This is a set of internationally applicable guidelines, however, it is not a legally binding document, and compliance cannot be enforced. In the United States, Section 508 of the Rehabilitation Act of 1973 dictates web accessibility to ensure equitable web access for people with disabilities. It models standards in accordance with various web accessibility guidelines, including those provided by WCAG. Section 508 is legally enforceable, but only Federally. It does not directly apply to private businesses or state and local governments.
SMALL CHANGES, MEANINGFUL IMPACTS
Here are some small changes that can be made now to make content more accessible:
1. Alternative text
Alternative text can provide a description of content for users who rely on screen readers, or for content that cannot be loaded. Alt text can be used in code like so:
<img src="cat.jpg" alt="a black cat sitting by a window, looking out">
2. Form Controls, Colors, and Error Handling
Forms should have adequate labeling (for left to right languages, label should be to the left of input field) and the form should not rely on color for error handling (ex: green for no error, red for error), as this does not help those with colorblindness. Required fields and errors should be clearly displayed (ex: asterisks, or the word 'required' to denote required fields). W3C also suggests displaying any errors before, not after, the form. Additionally, forms should make use of appropriate labels and tags for attributes, such as 'label', 'for', and 'id'
Example:
<label for="notes">Notes:</label>
<input type="text" id="notes" name="notes">
3. ARIA Landmarks
Much like the above examples, ARIA landmarks can provide insight to the structure of a site for users who rely on assistive technologies. ARIA landmarks denote what the "role" of an element is, and are commonly used for things like forms, navigation, and search. Using ARIA landmarks can look like this:
<div id="nav" role="navigation">Navigation Links Here</div>
This is a short list of quick things that can make a user's experience with web content easier, but by no means covers even close to the full scope of accessibility guidelines for the web. The links below are to policies, and technical tools such as 508 accessibility testing.
SOME RESOURCES
Policies and Guidelines:
Technical:
Top comments (0)