Bug 155399 – AX: Investigation: Determine if document history pushState() and replaceState() should trigger additional AX notifications

• Status: NEW
• Component: Accessibility

[James Craig]

Investigation: Determine if document history pushState() and replaceState() (bug 36152) should trigger additional AX notifications

https://developer.mozilla.org/en-US/docs/Web/API/History_API#The_pushState()_method

For example, if no explicit focus event occured within 500ms of a history push, VoiceOver could navigate to the hashed value, or heurisitically determine whether to navigate to the 1) top of document, 2) main section, or 2) first heading.

[Radar WebKit Bug Importer]

<rdar://problem/25129699>

[James Craig]

By "hashed value" I meant "element matching the @id or @name of the URL hash"

[James Craig]

A few negative case examples from some internal discussion:

"""
AK: Browse to http://www.apple.com/shop/buy-iphone/iphone5s
Select the appropriate options e.g. Space Gray, 16GB, Unlocked.
The URL updates to http://www.apple.com/shop/buy-iphone/iphone5s/16gb-space-gray

It’s appropriate to tell the user that the URL changed (even though this is replaceState) but definitely not appropriate to move their focus.

...
With pushState, we would rarely use a hash in the URL. That’s the fallback old style behaviour, where you need no .history() object. We would instead use a “real” URL that can be shared, bookmarked, and so on - and reacted to server-side (which is great SEO) rather than detecting the hash via JS.
"""

and

"""
CS: While yes, devs should be moving focus correctly, I fear that it would degrade the UX for AT users to have focus jumped for sites that already have poor AX.

Also, I can see having fixed timings causing a lot of issues on slow networks, and just being hard to debug (race conditions). E.g. I might update the URL on user click, but it takes longer to get the new content than ~500ms.
"""

I will close as WORKFORME if there are no objections or strong counterpoints.

[Todd Kloots]

James, 

You raise some good points. Rather than trying to tackle this problem by having the History API trigger AX notifications by default, I wonder if a better solution would be to provide an API enabling developers the ability to trigger the right AX notification via JavaScript. This might be useful in cases where it _is_ appropriate to tell the user that the URL changed and move the virtual navigation to the top of the page. For example: on twitter.com all the navigation within the site is done via pushState. If the user moves from /home to /i/notifications moving the cursor to the top of the page seems appropriate.

Todd