WebAIM - Web Accessibility In Mind

E-mail List Archives

Thread: Turbolinks / pushState

for

Number of posts in this thread: 4 (In chronological order)

From: Chris Pearce
Date: Fri, May 31 2013 10:11PM
Subject: Turbolinks / pushState
No previous message | Next message →

Hi,

The website I'm working on will use Rails Turbolinks:
https://github.com/rails/turbolinks/. Which basically uses HTML5
pushState. So what this means is there's no page refresh just 1 state
between all pages, only the HTML body is being updated. This speeds
up the website but I'm worried about accessibility esp. how screen reader
users go with this setup. Only modern browsers support pushState with non-supporting
browsers falling back to normal behaviour i.e. page refreshes.

Be great to get some feedback from anyone who's used this and whether its accessible.
I can't test with NVDA yet as it hasn't been setup.

Cheers,
Chris


Sent from my iPhone

From: Steve Green
Date: Sat, Jun 01 2013 8:18AM
Subject: Re: Turbolinks / pushState
← Previous message | Next message →

It would be interesting to see an example of such a site, but all I have found is http://diveintohtml5.info/examples/history/fer.html, in which only a small part of the page is replaced using pushState, which I expect is what it was intended for.

It works ok with JAWS, but the absence of a page reload will undoubtedly leave some users wondering what is happening. In that sense it's no different from any other dynamic content such as hide/reveal or tabbed interfaces.

When the entire body element is replaced the focus will go to the top of the page, which is what users will expect when a new page loads. JAWS will not go into 'read all' mode, which is probably a good thing. It won't read out the new page title because this appears not to be supported at present although the specification supports it. It also won't read the number of heading, links and landmarks, but in my experience most users ignore that.

I would say that this technique is likely to be technically accessible and that the only problem is that screen reader users will take a while to work out why the website is not behaving as expected.

Steve Green
Managing Director
Test Partners Ltd

-----Original Message-----
From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Chris Pearce
Sent: 01 June 2013 05:12
To: = EMAIL ADDRESS REMOVED =
Subject: [WebAIM] Turbolinks / pushState

Hi,

The website I'm working on will use Rails Turbolinks:
https://github.com/rails/turbolinks/. Which basically uses HTML5 pushState. So what this means is there's no page refresh just 1 state between all pages, only the HTML body is being updated. This speeds up the website but I'm worried about accessibility esp. how screen reader users go with this setup. Only modern browsers support pushState with non-supporting browsers falling back to normal behaviour i.e. page refreshes.

Be great to get some feedback from anyone who's used this and whether its accessible.
I can't test with NVDA yet as it hasn't been setup.

Cheers,
Chris


Sent from my iPhone

From: Chris Pearce
Date: Sun, Jun 02 2013 4:24AM
Subject: Re: Turbolinks / pushState
← Previous message | Next message →

Thanks for the reply. I should be able to test something this week but I only have NVDA. The title (<title>) also gets updated along with the body according to the documentation. I wonder if I have to use 'aria-live' attr on the body element?

Chris

Sent from my iPhone

On 02/06/2013, at 12:18 AM, Steve Green < = EMAIL ADDRESS REMOVED = > wrote:

> It would be interesting to see an example of such a site, but all I have found is http://diveintohtml5.info/examples/history/fer.html, in which only a small part of the page is replaced using pushState, which I expect is what it was intended for.
>
> It works ok with JAWS, but the absence of a page reload will undoubtedly leave some users wondering what is happening. In that sense it's no different from any other dynamic content such as hide/reveal or tabbed interfaces.
>
> When the entire body element is replaced the focus will go to the top of the page, which is what users will expect when a new page loads. JAWS will not go into 'read all' mode, which is probably a good thing. It won't read out the new page title because this appears not to be supported at present although the specification supports it. It also won't read the number of heading, links and landmarks, but in my experience most users ignore that.
>
> I would say that this technique is likely to be technically accessible and that the only problem is that screen reader users will take a while to work out why the website is not behaving as expected.
>
> Steve Green
> Managing Director
> Test Partners Ltd
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Chris Pearce
> Sent: 01 June 2013 05:12
> To: = EMAIL ADDRESS REMOVED =
> Subject: [WebAIM] Turbolinks / pushState
>
> Hi,
>
> The website I'm working on will use Rails Turbolinks:
> https://github.com/rails/turbolinks/. Which basically uses HTML5 pushState. So what this means is there's no page refresh just 1 state between all pages, only the HTML body is being updated. This speeds up the website but I'm worried about accessibility esp. how screen reader users go with this setup. Only modern browsers support pushState with non-supporting browsers falling back to normal behaviour i.e. page refreshes.
>
> Be great to get some feedback from anyone who's used this and whether its accessible.
> I can't test with NVDA yet as it hasn't been setup.
>
> Cheers,
> Chris
>
>
> Sent from my iPhone
> > > > >

From: Alastair Campbell
Date: Sun, Jun 02 2013 4:21PM
Subject: Re: Turbolinks / pushState
← Previous message | No next message

Chris Pearce wrote:

> The title (<title>) also gets updated along with the body according to the
> documentation. I wonder if I have to use 'aria-live' attr on the body
> element?


That probably wouldn't do what you expect, partly because the title isn't
in the body, and partly because user-agents currently expect live-regions
to be small portions of text.

Rather than that, it might be better to check that the keyboard focus is
updated appropriately. As Steve said, people generally expect that
selecting a link takes you to a new page. If it does something more
dynamic, then make sure the focus is moved to the top of the new area.

For example, if selecting a link opens a new area of content, move the
focus to the top of that content.

hth,

-Alastair