2

I have a question about web accessibility. In the case of SPA(single page app), blurring navigation links on click is proper or not?

Proper: Replacing contents via AJAX in SPA is same as moving page in traditional web page. In other words, the context of page is changed, therefore, the navigation links SHOULD be blurred when they are clicked.

Improper: You know the reasons. Removal of the focus ring leads to serious accessibility issues for users who navigate and interact with interactive content using the keyboard, as W3C and WHATWG said.

Then, what do you think? Which one is proper?

One more, this is not about the focus ring or the visual effect. Only what I concerned about is the "meaning".

chatoo2412
  • 118
  • 1
  • 6

3 Answers3

4

I'm not clear what you mean by blur in this context, but in an SPA keyboard focus-management is a requirement.

Simply applying an on-blur to links when clicked could be quite harmful as screenreaders may send an onclick JS event when selecting a link.

For both visual keyboard users and screenreader users, when a link is selected and the content updated by JS, the focus (as in JS .focus() ) should be moved to the top of the new content. That content element may need tabindex="-1" in order to make it focusable.

For example, if you have a main content area that is updated with new content when a link is selected, move the focus to the top of the new content when it has loaded.

If you are also having an issue with focus outlines onclick, the best option is to remove any CSS which changes the outline due to :focus. See my article Fixing outlines on click for that and an another option.

See also this answer to the general issues for SPAs.

Community
  • 1
  • 1
AlastairC
  • 3,277
  • 21
  • 15
1

It depends on the context.

  • If you have a link "next page" and the link stays there, you can just notify the user with an aria-live region that the main content has been modified. And the user expects one other click to go to the "next page" again without having to scroll down to the same link.

  • If the link itself disappears and was part of the old content, yes of course, you this.blur() it if necessary, as if the page were normally changed.

  • If this is a navigation link to go to a specific page, then the user has no reason to click again on it, then you can induce a normal page change and this.blur() this link.

Note: I used the this.blur() verb because "blurring" was really blurring my mind, but you can use any javascript alternative like focusing on other part of the page

Adam
  • 17,838
  • 32
  • 54
  • Are you sure that using this.blur() is a good idea? The user has selected a link, they should expect to go somewhere. Just booting the user off the link could lead to landing on random places, or the very top of the page. Have you tested this? – AlastairC Oct 14 '16 at 08:15
  • @AlastairC The user has to ignore the technology behind a click. If a click induces a page change from his point of view, then the technology may emulate everything a page change would do like removing the focus() from the page itself (and moving to top). It would be very disturbing to click on a bottom link of a page and see no modification (for instance using a screen magnifier may still display the same selected link without giving a clue that the action was lead) – Adam Oct 14 '16 at 09:01
  • Exactly, in the case of a link, shouldn't you move the focus to the new/changed content? (If it is a button then there is some expectation that something else on the page will change.) – AlastairC Oct 14 '16 at 12:15
  • 1
    @AlastairC It depends on the link nature and the expectations on the link itself. The application should act like a standard web page using hyperlinks in order to be predictable. When we use an "in-page" link, we expect the focus to change, while if we click a standard link, the focus should go back to the default (blur() in most cases, but your application may chose to place the focus elsewhere on page load). If the focus does not move, then we should use a `button` (https://www.w3.org/TR/wai-aria/roles#link). – Adam Oct 14 '16 at 13:21
  • I asked around, and most people (accessibility aware devs and screenreader users) thought focusing on the new content would be best, but it does depend on context: https://twitter.com/alastc/status/789117252343885829 – AlastairC Oct 21 '16 at 12:26
  • @AlastairC Thanks for the feedback. Very interesting answers and answerers. I am not promoting any solution, but as long as we can ignore that this is a SPA, then it seems ok for me. Maybe there's also a difference between SPA standalone applications and SPA web sites. The expectations won't be the same. – Adam Oct 21 '16 at 18:54
0

The question is not clear, so i am responding based on what I understood;

If you want to inform users about the change on page, you need to use ARIA tags such as live regions etc. Using css effects will not have effect on screen readers. Thus, you need a method to inform screen reader that certain part of the page has been updated.

Mnf Gl
  • 87
  • 3