How should a screen reader read a website?

237 Views Asked by At

I'm doing an accessibility analysis of a site, and for the first time I'm using a screen reader (jaws) to verify that the site is readable. What I don't understand is whether the site is actually good. If I have jaws read the whole page, I noticed that it reads pretty much everything. If, on the other hand, I navigate through the site using the tab, only the focusable elements with the tab are read (buttons, links, etc.), the titles and other writings in that case are not read. This is right? Or is there a need for all text elements to be read via tab as well? Could you recommend a site that explains the accessibility rules for reading a page using a screen reader?

1

There are 1 best solutions below

0
Andy On

That is a great initiative and in the beginning it can be very confusing to use a screen reader. For me, it was the most difficult step to take, but also the most insightful one.

Tab is only being used for interaction with the website, mainly with form elements and links. But there are a ton of other shortcuts that allow navigating headings, landmarks, tables, forms and more.

How to navigate with a screen reader

Just as well-sighted users, screen reader users do not simply read everything. People skim websites, looking for the piece of information they came for.

The vast majority (67.7 %) of screen reader users navigates headings first to find information – very similar to well sighted users. Only 8 % would read through the page first, which mainly are “those with beginner proficiency”.

Screen readers usually allow navigating headings via the h key or number keys for the respective levels, in combination with the modifier key. Once at the right heading, arrow keys allow to continue reading from there.

Titles etc. when using Tab

[…] only the focusable elements with the tab are read (buttons, links, etc.), the titles and other writings in that case are not read. This is right? Or is there a need for all text elements to be read via tab as well?

This is not entirely right. There is a need for some text elements to be read along with a focusable element.

First of all, the element’s accessible name is being read. It usually comes from a <label> element, but also aria-label or aria-labelledby can provide this name.

Then, if the element is inside a group, for example a <fieldset> that group’s accessible name is also being read, once focus enters it.

Screen readers can also be configured to read descriptive text, which can be assigned to a focusable field via aria-description or aria-describedby. This is often done to associate a related hint or error message.

Give it a try with Jaws:

<fieldset>
  <legend>Address</legend>

  <label>
    Street name
    <input type="text" aria-describedby="street-hint">
  </label>

  <p id="street-hint">You can shorten “Street” with St.</p>
</fieldset>

How to evaluate Web Accessibility with JAWS

WebAIM, who conducted the quoted survey, also has a guide for Using JAWS to Evaluate Web Accessibility which explains