0

Intro:
I'm coding a single-page app. It's a sort of e-book reader and I want to optimize screen reader experience.

For general performance reasons (load times, HTTP requests) all of the functional components of the app are always present in the DOM, visibility managed by CSS. Only the actual content is dynamically loaded.

That means there's a lot of stuff present that is not needed all the time, e.g. the login/register pages.
Sighted users won't know, but screen reader users could be annoyed.

There's also things that I figure shouldn't matter to screen reader users, like a bunch of visual options (font size, colors...).


What I intend:
I want to hide certain sections by applying aria-hidden="true".
I want to dynamically apply that to elements which are not currently functional, like the register page for a logged in user.
Also, I want to generally hide certain "presentational" sections, like visual options.


Questions:
Is that good practice?
Are there drawbacks?
Is it necessary?
Are there other/better ways of telling sr users that elements are of no use to them?

and, last no least,
Are there good ways of directing the attention of sr users to certain elements?

-
p.s. I have already structured the DOM sensibly, like

<body>
    <main role="main"></main>
    <nav role="navigation">
        <button>Next Page</button>
        <button>Previous Page</button>
        ...
    </nav>
    <menu role="menu">
        <ul>
            <li><button role="menuitem">Important Task</button></li>
            ...
            <li><button role="menuitem">Least Worthy Task</button></li>
        </ul>
    </menu>
    <div class="options">
        ...
    </div>

to make sure that the controls should be tab-focused in descending order of use frequency.

Volker E.
  • 5,911
  • 11
  • 47
  • 64
Gorad
  • 3
  • 1
  • 3
  • 1
    Not sure if you know that content hidden in CSS with `display: none` and `visibility: hidden` is hidden to screen readers too? Is it the case in your project? – FelipeAls Dec 01 '13 at 14:13
  • Ah. I did know that, but I didn't consider that it applies here. Weird of me. – Gorad Dec 07 '13 at 09:41

3 Answers3

2

Take a look at the following link. It lists ways to hide content from screen reader users as well as what combinations of screen reader and browsers behave properly. http://www.html5accessibility.com/tests/hidden2013.html

Jared
  • 39,513
  • 29
  • 110
  • 145
1

I assume that the act of changing page would remove/hide the current content and unhide the new page? In which case it sounds like you are taking a good approach from a showing/hiding point of view.

I did a quick gist / cheat sheet recently of current best practice for: hidden from all, hidden from screen readers, or shown only to screen readers: https://gist.github.com/alastc/7706437

For items which are currently not active but disabled, it might be inconsistent (and therefore confusing) to hide them? Perhaps use the disabled/aria-disabled attribute instead.

As the content and next/previous are first in the order, having several disabled controls after those should be fine. NB: When reading screenreaders have a 'browse' order that follows the DOM and is not affected by tabindex. You're order looks good, so don't try and over-ride it with tabindex.

Also, please pay attention to keyboard focus. I.e. when you select 'next', does the keyboard focus move to the top of the next page? I wrote an answer about the keyboard focus aspect for single-page apps.

Also, as you have multiple nav elements it would be helpful to label them, then they could be announced as "Page, navigation" and "Options, menu" (for example).

Community
  • 1
  • 1
AlastairC
  • 3,277
  • 21
  • 15
0

Your approach will work however you are over thinking things.

Any content hidden in CSS with display: none or visibility: hidden is also hidden to screen readers