Are you Writing Accessible HTML?

Tips to make your website accessible for every user.

--

accessibility

I want you to try something for me.
Imagine that you can’t see the screen, and you can close your eyes if that helps.

So you can’t see the screen & you want to applaud this article by clicking the clap icon

But if you can’t see the screen, you can’t use a mouse. So maybe you’ll be using a keyboard instead. But how do you hover over the Clap icon if you’re just using a keyboard?

The answer is you can’t.

But as web developers, it’s really important for us to take into account that there’s lots of different kinds of users, and not all of them can use a mouse. And that’s what accessibility is all about, making your web usable by everyone.

If this doesn’t motivate you then a law forces you. In some countries, it’s mandatory to provide accessibility.

Different kinds of users with disabilities.

  • Visually impaired users will generally use a screen reader that describes the page using speech.
  • Low vision users will generally use large fonts or something called a screen magnifier.
  • Motor-impaired users, who can’t use a mouse, might use some kind of special keyboard or even a voice control interface to interact with your app.

Let’s focus on solutions for Visually impaired Users in this article.

ChromeVox: It is a screen reader for Chrome. It’s a Chrome extension. You control it using keyboard shortcuts, and it speaks the contents of pages using the Chrome TTS API.

The interesting thing about the DOM is visually impaired users using assistive technology like a screen reader see only the DOM. It doesn’t matter what’s your page looks like. They see only the building blocks of the page. So the DOM is the user’s mental image of the page.

So the way you build your app, the app skeleton (i.e. html), that’s the way these users are going to interact with it.

DOM Best Practices

html5 semantics
  • Create logical sections of the document to help identify interface elements that are related. HTML5 semantics elements like <nav>, <header> and <h1>are useful here.
  • Make sure parts of controls are grouped together in the DOM. For example, the drop-down menu button and the drop-down menu itself.
  • Use CSS for layout instead of tables.

Interactive Controls

Interactive Controls

  • Use native HTML tags instead of generic divs or spans. In other words, no Div Soup! No Span Salad!

Why?

  • Screen readers can’t identify generic div’s or span’s as controls.
  • Generic div’s or span’s aren’t focus-able, so they can’t be activated with the keyboard.

Labeling — Label Your Controls and Images!

  • <label> is perfect for form elements.
<label for="firstname">First name:</label>
<input type="text" id="firstname"/>
  • All images should have the altattribute:

Important images should have descriptive alt text.

<img src=”chart.png” alt=”[description]”>

Decorative images should have blank alt text.

<img src="bullet.gif" alt="">

Manage focus.

  • Keyboard-only users navigate by moving focus through the DOM.
  • So we should proactively place focus with element.focus() to create an efficient workflow.
  • Make custom interactive elements focusable with tabindex:
  • Custom controls should respond to keys like Enter, Space, Arrows, Escape, etc. as appropriate. Pick a native control and mimic it!

Try other screen readers too

References:

--

--