Focus placement on state change in Single Page Applications

110 views
Skip to first unread message

Mark Williams

unread,
Nov 3, 2014, 6:15:03 AM11/3/14
to free...@googlegroups.com

I wonder whether anyone could steer me in the right direction please.

We are building a large single page application where all content is dynamically generated. When the user activates a link we automatically move focus to the area where the incoming content has displayed (A link that opens a form for instance). 

From our testing sighted users prefer to have focus in the first field of a form. However, as I understand it, for screen readers the containing element should be focussed allowing full context for the new content.

I would prefer not to have a preference switch between sighted or screen reader users if I can possibly help it. Your thoughts would be greatly appreciated.

Mark

Octavian Rasnita

unread,
Nov 3, 2014, 8:03:18 AM11/3/14
to free...@googlegroups.com
Hi Mark,
 
Most important, from the perspective of blind users, a single-page site is the worst idea because most probably that page will contain a lot of JS code and it will consume many resources, the screen reader may look to be frozen some periods.
 
From the perspective of every user that may want to add a bookmark to a certain page from that site, or for those who may want to send a link to a certain page from that site to somebody else by email it is also a bad idea.
 
Yes, you are right about context, but sometimes by placing the cursor in a form field may offer enough context. It depends what kind of form it is.
For example, if the form field has a label like "Login name:", it is obvious that that form is a login form.
If it is a more specialized form and the sighted users may also not understand it if they would see only the first field without other explanatory notes, then yes, it wouldn't be a good idea to skip the context in which that form appears.
 
--Octavian
--
You received this message because you are subscribed to the Google Groups "Free ARIA Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to free-aria+...@googlegroups.com.
To post to this group, send email to free...@googlegroups.com.
Visit this group at http://groups.google.com/group/free-aria.
For more options, visit https://groups.google.com/d/optout.

Mark Williams

unread,
Nov 3, 2014, 6:16:35 PM11/3/14
to free...@googlegroups.com
Thanks Octavian. Excuse my ignorance in advance as I ask more questions!

Just to respond to your comments first, deep linking and bookmarking is supported, so its not as bad a situation as it may be. It isn't obvious from our fields what the context is, so it sounds like giving a broader context is better, and allow sighted users to set a preference to go to the first field.

A question on your other comment. How does the screen reader/browser normally signify loading a new page?
We are hoping to announce when the application is in a loading state using aria-role status to mitigate the times where it may 'seem' frozen, but I'd like as native an experience as possible.

Mark

Octavian Rasnita

unread,
Nov 4, 2014, 1:41:23 AM11/4/14
to free...@googlegroups.com
Hi Mark,
 
The main problem I found in the pages that use a lot of Javascript code is not only that they don't announce when something new appeared on the page using AJAX, because that thing can be solved by using ARIA. But the main problem is that those pages really froze the screen reader because it uses too much resources and the screen reader must also needs to do its calculations in order to understand those pages.
 
And as I reported a few days ago, a good example is youtube.com.
I guess that for you the page might appear to load instantly, but for me and for other users of Windows 7 and 8.1 that use IE 9 or 11 the computer is frozen after we type youtube.com in browser and press enter.
 
So not only the page looks frozen or the browser, but the whole computer. In that period we can't even hear what's the time if we press the key combination for that. And this is because Javascript is doing too much.
 
Native experience is not possible with Javascript. For sighted  users that prefer using a mouse instead of keyboard, yes, native experience is possible.
The sighted acccountants for example, that need to use the keyboard very much, usually don't prefer to use a web interface, even if it looks visually like a native interface.
One of the main reasons why, is that Javascript is not as fast as C/C++ so the interfaces created with it are not as responsive as the native interfaces created with C++, and for keyboard users the responsiveness is very important. For JAWS users it is even more important because for offering a better accessibility in interfaces that don't offer a very good accessibility interface, it needs to do more calculations, so it also delays, plus that it also consume even more resources.
 
The blind computer users can see a difference even between a native interface like offered by standard Win32 widgets/MFC and by interfaces like SWING or Windows Forms.
 
If the Javascript code is well done and the page doesn't appear to be frozen, the single-page app is OK if it doesn't have other problems.
 
Another problem of single-page sites is that usually we can't press Alt+Left Arrow to go to the previous page upt to the first page we started.
And if you say that the site will support bookmarking, it means that it is probably either using HTML 5, which is not compatible with all the browsers which are used today, or it uses the #fragment in the URL, which implies even more Javascript processing just for opening the wanted page, and of course, it would not work if somebody will want to see that page by using curl.
 
Another problem of single-page apps is that they usually don't allow opening more windows and they consider this a bad practice, even though I don't know why, because opening a page in a new window by clicking Shift+Enter is very useful for the blind. We can open that new page, read it and after we finished it we can close the window and we will return to the previous page/window and the focus will be on the link that opened that new page and we can continue to navigate from that point forward, without needing to lose the time to find that link and continue from there.
Well, I know why they consider it a bad practice... because this can break the complicated session state which is usually needed for those apps.
 
If all of these can be solved, then using single-page web apps is very OK:
- The page should be loading very fast, and after the page has finished loading and the screen reader starts to read the page, no other AJAX code should continue to update the page with new data and make the page hard to use in that period;
- It should allow using the "back" and "forward" buttons of the browser;
- It should allow opening new pages in a new window if the user wants that;
- It should not force the ARIA application mode to on when it is not the case to use it, because it can decrease the accessibility.
 
HTH.
 
--Octavian
----- Original Message -----
--
Reply all
Reply to author
Forward
0 new messages