6

Requirement: on each page change the screen reader must read the entire page content.

We use firefox+NVDA to do our testing, and since angular doesnt "change pages" we have tried the following to make it read the entire page when changing states:

aria-live="assertive"

This for the most part read the changes in text in our site,but it only reads what its being added, in our case we have a table being filled with ng-repeat and it reads the information being added but without any context (it doesnt say what row or column is being read)

Another issue was forms, when being filled by angular, the screen reader will read it before they were populated by angular, this was solved with a $timeout but still when aria-live reads the changes it would skip some parts, and if we added aria-atomic to force read, we had some selects with multiple options, and those were read (all of them, we have more than a hundred options). which is not how screen readers read, they only read the first ten options or the ones visible when you click on them.

Remember that without any aria-live or aria-atomic, when you change states in angular the user is not notified of any changes.

after almost giving up we decided that maybe our focus was wrong, we needed to make each state its own page so we used the following:

function ForceNVDARead() {
    $(window).on('hashchange', function () {
        location.reload();
    });
}

This for every change in the URL will force a reload. This works GREAT, everything was being read correctly, we almost thought this solved everything. Except this causes double requests from the client to our server.

Is there any way to make NVDA read the contents of an angular state like a regular page load, without having to force the reload of the page?

Please dont say use aria-roles only or something like that that doesnt work for this and we already have them, we need the application to read everything when changing states.

ANY help is appreciated, we are about to give up, and restart the project without angular as we are not able to achieve our accessibility requirement.

luisluix
  • 547
  • 5
  • 17
  • where on the page did you add `aria-live="assertive"`? was it on the entire body itself? on the table? – haxxxton Nov 20 '14 at 01:59
  • could you try a combination of live, atomic and relevant on the entire body? ie. `aria-live="polite" aria-atomic="true" aria-relevant="additions removals"`. an alternative might be to 'toggle' the presence of the aria values on the respective elements using angulars `$stateChangeStart` and `$stateChangeSuccess` events. (unfortunately, i have no way of testing these suggestions currently) – haxxxton Nov 20 '14 at 02:04
  • we already try a lot of them actually, nothing was working. the problem is mostly with forms, when you wanna edit something, since it fills fields, some fields dont change, so we cant manually put aria-live on each field, because then not all of them are changing / read. – luisluix Nov 20 '14 at 03:03

1 Answers1

9

Requirement: on each page change the screen reader must read the entire page content.

This is fundamentally not a requirement from an accessibility point of view, it is the equivalent of making someone looking at the screen to read everything one line at a time, or use readquick, it is not natural usage.

Screenreader accessibility is acheivable when using Angular, but we need to reset some assumptions:

  • When you have page updates, the key is to manage the focus, and move to the new content. That allows people to read in their own way, not the way you have been assuming they have to read.
  • ARIA live is intended for small updates elsewhere on the page (away from the keyboard focus), not the whole content, it is not the answer here, I would drop it completely.
  • If people are reading forms before they have loaded, that might be a side effect of trying to force the reading with ARIA-live. If not, then trying using focus-management to place focus at the top of the form when it has loaded.
  • It is probably worth reading a tutorial on NVDA usage, or talking to a 'native' user. I can say from experience you are not using it in the way end users do, so get to understand better what 'normal' interactions are like.

If you drop the use of ARIA-live and go with focus management you'll probably solve most of the issues, but there may well be more questions later from a different point of view.

Community
  • 1
  • 1
AlastairC
  • 3,277
  • 21
  • 15
  • based on the number of views this question has had, a lot of people like myself probably have the same requirements, I find that quite interesting. – luisluix Jul 25 '19 at 21:07