[META] improve accessibility of Refreshless module. [#2695755]

Comment #1

28 March 2016 at 22:36

andrewmacpherson created an issue. See original summary.

Log in or register to post comments

Comment #2

andrewmacpherson commented 28 March 2016 at 22:42

When a page updates via RefreshLess, the <title> does not update.

If a user switches to another window or tab (say to do something in their word processor) they may have difficulty finding their way back to the correct browser tab.

Log in or register to post comments

Comment #3

andrewmacpherson commented 28 March 2016 at 23:00

A screenreader doesn't announce that the page has changed, because no full-page load has taken place.

Testing with ChromeVox:
Normally when clicking a link to a new page, ChromeVox makes a special noise when the link is activated, then another special noise to signify a new page loaded, then announces new page title.

With RefreshLess, activating a link causes the link-activation noise, then repeats the name of the link. The new "page" is not announced, and the the keyboard focus shifts to the site-name (home) link.

Log in or register to post comments

Comment #4

andrewmacpherson commented 28 March 2016 at 23:40

Testing with Firefox, Windows 8.1, NVDA 2016.1 (default NVDA settings, I never fiddle with them).

Normally, following a link cause the new page title to be announced.

With RefreshLess there is no audio feedback. The page content changes, but the title isn't announced. NVDA doesn't make many special noises for events.

Log in or register to post comments

Comment #5

andrewmacpherson commented 28 March 2016 at 23:56

Come to think of it the page title not changing could cause problems for anyone who refers to the window/tab title, not just screenreader users.

Added #2695773: Update HTML title element when following RefreshLess links

Log in or register to post comments

Comment #6

andrewmacpherson commented 29 March 2016 at 00:21

Title:	Screenreader accessibility with Refreshless module.	» [META] improve accessibility of Refreshless module.
Issue summary:	View changes

Added #2695777: Announce new content to screenreader users when navigating using RefreshLess.

Changing this to a meta-issue, updating title and summary.

Log in or register to post comments

Comment #7

andrewmacpherson commented 29 March 2016 at 00:21

Issue summary:

View changes

Log in or register to post comments

Comment #8

mgifford

he/him

English

commented 29 March 2016 at 15:15

I'm very interested in hearing more about this and BigPipe accessibility issues.

Log in or register to post comments

Comment #9

wim leers

Ghent 🇧🇪🇪🇺

commented 29 March 2016 at 16:06

#8: this is RefreshLess, not BigPipe.

@andrewmacpherson: #2695773: Update HTML title element when following RefreshLess links is a duplicate of #2692317: Make everything in <head> update: <title>, <meta> tags, etc..

Log in or register to post comments

Comment #10

wim leers

Ghent 🇧🇪🇪🇺

commented 29 March 2016 at 16:06

Also, that's not even an accessibility issue, it's necessary for this to work correctly at all. But this is an alpha release of a prototype. Please bear with us :)

Log in or register to post comments

Comment #11

andrewmacpherson commented 29 March 2016 at 17:23

Thanks Wim. No worries, I understand it's very new. I was keen to try it with a screenreader because I expect it to be a popular module that site builders just enable-and-forget.

Log in or register to post comments

Comment #12

wim leers

Ghent 🇧🇪🇪🇺

commented 29 March 2016 at 20:20

That's the ambition :)

Log in or register to post comments

Comment #13

mgifford

he/him

English

commented 29 March 2016 at 20:24

Yup. I'm with @andrewmacpherson seems like there is a lot of potential here. As far as BigPipe, I was just following "Combined with the BigPipe module (which offers significant improvements for the initial page load), this should make just about any Drupal site feel significantly faster." from the project page. I have reached out to Facebook, but haven't heard back from them... I should just go bug Jesse and get her to give me the low-down.

Log in or register to post comments

Comment #14

wim leers

Ghent 🇧🇪🇪🇺

commented 29 March 2016 at 22:45

Oh, right. I misread! Sorry :)

+1 to all that.

Log in or register to post comments

Comment #15

andrewmacpherson commented 30 March 2016 at 23:31

Issue summary:	View changes
Related issues:		+#2692317: Make everything in <head> update: <title>, <meta> tags, etc.

Log in or register to post comments

Comment #16

jessebeach commented 31 March 2016 at 01:29

The history API with push/popState might cause a screen reader to recognize a page transition:

https://developer.mozilla.org/en-US/docs/Web/API/History_API

Log in or register to post comments

Comment #17

wim leers

Ghent 🇧🇪🇪🇺

commented 31 March 2016 at 08:47

Jesse is here!! \o/

Jesse, this already uses the History API. And see the link at #2695777-7: Announce new content to screenreader users when navigating using RefreshLess which points out that there are also big accessibility problems with Turbolinks itself. Which suggests BaseCamp has poor accessibility.

Log in or register to post comments

Comment #18

wim leers

Ghent 🇧🇪🇪🇺

commented 27 April 2016 at 09:55

Status:

Active

» Fixed

#2695777: Announce new content to screenreader users when navigating using RefreshLess has landed. AFAICT that means all accessibility issues have been addressed.

Log in or register to post comments

Comment #19

andrewmacpherson commented 27 April 2016 at 12:46

Issue summary:

View changes

There a few more things to do, been meaning to check in and write them up. Sorry, they went to the back of my mind...

1. Focus behaves unpredictably. Let's say we follow a link in the main menu. It's still there after the page is updated, and focus remains there. But if we follow a link which doesn't exist on the resulting page (e.g. a link in main content) then focus ends up... somewhere. Often focus goes to the site logo link.

I propose we programmatically shift focus back to the start of the body element after following a link. This is where focus would be if we were loading the page for the first time in entirity (or Refreshless wasn't enabled). Pressing TAB for the first time would bring the skip-to-main-content link into focus.

2. The viewport didn't shift - but I see this has been fixed with a scrollToTop() method in the latest code, and it's behaving well. Nice!

3. Let's document the accessibility. From personal experience of talking about accessibility at dev meetups, it's commonly thought that Ajax or single-page apps are inaccessible. It would be good to let module evaluators know what has been addressed so they can enable it with confidence.

Log in or register to post comments

Comment #20

andrewmacpherson commented 27 April 2016 at 12:45

Status:

Fixed

» Active

Log in or register to post comments

Comment #21

wim leers

Ghent 🇧🇪🇪🇺

commented 27 April 2016 at 12:50

Issue summary:	View changes
Related issues:		+#2713499: When navigating to a new page, it should be scrolled to the top + navigating to a fragment on another page broken in Firefox

I propose we programmatically shift focus back to the start of the body element after following a link. This is where focus would be if we were loading the page for the first time in entirity (or Refreshless wasn't enabled). Pressing TAB for the first time would bring the skip-to-main-content link into focus.

Makes sense!

The viewport didn't shift - but I see this has been fixed with a scrollToTop() method in the latest code, and it's behaving well. Nice!

Yep :) In #2713499: When navigating to a new page, it should be scrolled to the top + navigating to a fragment on another page broken in Firefox.

Let's document the accessibility. From personal experience of talking about accessibility at dev meetups, it's commonly thought that Ajax or single-page apps are inaccessible. It would be good to let module evaluators know what has been addressed so they can enable it with confidence.

Great plan!

Wanna open child issues for 1 and 3?