Haymarket Media Dev Extra

Development: Coding For Accessibility

As a developer, it’s your responsibility to follow conventions coding ( HTML in particular) to the best of your ability. As we move into complex web architecture structures and out-of-the-box code-generated systems, your HTML markup may fall short of being in the programmatic flow. This can make it difficult for Accessible tools, such as screen readers to follow effectively. By adhering to strict-ish ( let’s be realistic here) web standards can help keep us closer to your goal of conforming to the Web Accessibility standards.

Below are a few tips we should keep in mind.

Accessibility in HTML/clean coding

  • Writing HTML with accessibility in mind provides the users with an efficient way to navigate and interact with your site
  • Try to make the HTML code as semantic as possible — semantic HTML refers to correct HTML elements for their correct purpose as much as possible
  • Semantics and accessibility go hand in hand

Accessible forms ( always a challenge )

  • Forms are used for many interactions on the web
  • When referring to accessibility forms what is generally discussed is the accessibility of the form to people who use screen readers or keyboards
  • They should be clear and intuitive and organized in a logical manner — including instructions, cues, required form fields, field formatting requirements, and so on
  • Form elements might also be required so it is important to include them
  • Forms must be able to be completed using only the keyboard because there are a few things that can make the forms totally unusable with the keyboard — the most common is JavaScript — JavaScript can manipulate form data, set focus, change form elements, or submit forms
  • Make sure to test website forms for keyboard accessibility
  • Text labels should generally describe the function of each form control — labels are usually positioned above or to the left of the controls, but the checkboxes and radio buttons are normally to the right of the control
  • Users with disabilities cannot make the distinction to visually associate a text label with its corresponding form control
  • This is where the <label> element is used to associate a text label to a form control which allows a screen reader to read the associated label text when the user navigates to the form control

Label challenges

  • To continue to check that your forms are completed correctly to make the form user friendly and accessible it’s important to associate form controls with a text label by using the label element
  • When testing, the form controls, labels, and functionality must be understandable and usable
  • If there are certain controls that must be completed or selected, the instructions should  typically be located adjacent to and within the label of the required form control
  • Labels should be adequately descriptive as well as being visually apparent
  • Whenever it is not desired to have labels appear visually within the form (this is common when using complex forms within tables when table headers identify the function or purpose of multiple form controls within a specific row or column) — screen readers may not identify the purpose of the form control so instead of invoking the client-side validation: <form action=”submit.php” onsubmit=”return validateform()”>

Images

We tend to underestimate the value of images in a programmatic flow, which can create confusion with Accessibility. To keep it sane remember to always use ALT text on images. For SVG include the [role=”” ] attribute to aide screen readers.

Related links:

Alert challenges

  • Instead of using the JAvaScript ‘alert’ function, we can use WAI-ARIA widget for notifications 
  • role=”alert” is used for important messages that should be read by a screen reader as soon as they appear — ARIA alerts can be useful when implemented correctly
  • role=”button” when this is being properly used, it can tell a screen reader that an element functions just as a button does — so for example, if a link is given role=”button”, JAWS will tell the user to activate the button with Spacebar (links, however, can only be activated with Enter)

Other interaction channels – preloaders and spinners

  • Preloaders, also known as loaders, are what you see on the screen while the rest of the webpage’s content is finishing loading — this provides important interface elements that will let the users know that the website hasn’t crashed, just that it is taking some time to load
  • Recently, preloaders have been simplified, as complex loaders have been known to slow down the page’s loading process even further
  • A spinner should have the Aria  role=”status” and contain assistive text that explains what is currently happening 

Accessibility podcasts

  • For users who are blind, visual podcast content is inaccessible, so if there is content-rich information in the video without any audio describing it, the information becomes inaccessible
  • In order to fix this, podcast providers should provide an audio description of the information that is provided only in the video
  • For users who are deaf or hard of hearing, all audio podcast content is inaccessible  — so all video podcasts should include accompanying captions or a transcription of the audio content (captions should be playing in sync with the podcast)
  • Other ways to make podcasts more accessible include providing transcripts. After this, the focus should be put on the website and media player
  • Transcripts are the easiest to implement from a technical perspective — for the website and media layer, there is more to do on the website building end

Here are a few links to round up the topics:

Previous Topic: Design Next Topic: Experience