Question 45153 in Html Question posted in
Some basic documentation can be found here.

How to set text to be accessible on a webpage – Html

When a user clicks tab on my page, it travels to all the links and buttons. Simply anything that is interactive. This works fine.

But how will a person that has accessibility limitations know there is a text on the page and to get it read out or to tab to it.

What’s the norm here. Cause I tried the same on well known sites like stackoverflow and bbc.co.uk. They are doing the same where tabbing only works on links and buttons. It ignores text.

What about text. I tried using arrow keys which does nothing. If I press down it scrolls the page.

I get that the person could highlight the text and then get it read out to them with a screen reader. But that is assuming they are able to highlight in the first place.

What’s the expected behaviour. How do we deal with text to get read out.

Imagine a page in following format. At present tab skips all text and only highlights the links and buttons. How do we handle text for accessibility. How do we set it up for keyboard access or have I pictured this wrong and text should indeed be ignored.

<!DOCTYPE html>
<html>
<body>
    <h1>Heading 1</h1>
    <p>This is some sample text.</p>
    <h2>Heading 2</h2>
    <p>This is some more sample text.</p>
    <h3>Heading 3</h3>
    <p>Here's even more sample text.</p>
    <!-- All the above ignored by screen reader unless you highlight with a mouse, arrow key does nothing even on sites like bbc.co.uk -->
    <button>Button 1</button>
    <a href="#">Link 1</a>
    <button>Button 2</button>
    <a href="#">Link 2</a>
</body>
</html>

P.S: If it matters, using mac with built in screen reader. Also tried on Windows with NVDA, same outcome.

Tags:

2

Answers


  1. 0

    You don’t need to do anything additional to allow for reading your website (except for providing a proper semantic structure of your document, which you did).

    Desktop screen readers distinguish between reading and interaction. The latter is done via the Tab keys.

    As you mentioned, arrow keys are usually used for reading, but only together with a modifier key.

    According to WebAIM’s guide on Using VoiceOver to Evaluate Web Accessibility, you can use

    VO+a to start reading

    VO + → to read next item

    The modifier key for VoiceOver, here referred to as VO can be customised. By default, it’s Control + Option. So you’d press Control + Option + a to start reading.

    Login or Signup to reply.
  2. 0

    You are essentially asking how to use a screen reader. @andy already spoke about VoiceOver so I’ll comment on NVDA since you said "Also tried on Windows with NVDA, same outcome."

    Using the tab key is just one way to navigate a webpage. Anyone can use tab regardless of whether a screen reader is running or not.

    But with a screen reader such as NVDA (or JAWS) on a PC, you have a ton of shortcut keys for navigating. When NVDA is running, the down arrow will navigate to the next DOM elements (*) so you can access all the text on the page.

    (*) It’s not really the next DOM element but the next element in the accessibility tree, which is like a subset of the DOM. From the "Accessible Name and Description Computation 1.1" document, the "Introduction" section says:

    User agents acquire information from the DOM and create a parallel structure called the accessibility tree, made up of accessible objects. An accessible object provides information about its role, states, and properties.

    And the "accessibility tree" is defined as:

    Tree of accessible objects that represents the structure of the user interface (UI). Each node in the accessibility tree represents an element in the UI as exposed through the accessibility API; for example, a push button, a check box, or container.

    Also, the down arrow might not navigate to the next DOM element if you are in "forms mode". You have two modes you can run a screen reader in: "Forms mode" and "Browse mode". (The actual term for the mode might be different for different screen readers but conceptually they’re "forms" and "browse"). The two modes automatically switch between the two by default (unless you change your screen reader settings).

    In "browse mode", the down arrow key moves to the next DOM element. Browse mode also allows lots of other keyboard shortcuts such as the H key to navigate to the next heading (<h1>, <h2>, etc), the T key to navigate to the next table (<table>), the L key to navigate to the next list (<ul>, <ol>, <dl>), etc. NVDA and JAWS have similar keyboard shortcuts but occasionally the shortcut letter might be different.

    If you tab to a form element such as an <input>, NVDA and JAWS will automatically switch from "browse mode" to "forms mode". In browse mode, all keyboard events are interpreted by the screen reader first but in forms mode, the keyboard events are sent to the browser. This lets you type the letter "H" or "T" or "L" into the <input> without the screen reader trying to navigate to the next heading, table, or list (respectively). So when you’re in "forms mode", the down arrow will not move to the next DOM element.

    That might be what you were experiencing when you said the down arrow key was not working with NVDA.

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search