E-mail List Archives
Thread: Return to Top Link
Number of posts in this thread: 13 (In chronological order)
From: JP Jamous
Date: Wed, Oct 17 2018 8:31AM
Subject: Return to Top Link
No previous message | Next message →
Folks,
Another interesting situation I have on my plate. There is a "Return to Top"
link that is supposed to jump the user to the page content or <main>. It
uses a Jquery to perform a page scroll.
I tested the link and sometimes it works and other times it fails. When it
fails, it jumps the screen reader user to the top of the DOM. The other
concern is that <main> has this markup.
<main id="page-content" tabindex="-1">
I don't like the tabindex="-1" because JAWS in IE causes problems when
tabbing.
Any idea what would be the best way to implement this so it is always
functional and does not malfunction at times? Any feedback will be greatly
appreciated.
--------------------
JP Jamous
Senior Digital Accessibility Engineer
<mailto: = EMAIL ADDRESS REMOVED = > E-Mail Me | <http://linkedin.com/in/JPJamous>; Join
My LinkedIn Network
--------------------
From: Swift, Daniel P.
Date: Wed, Oct 17 2018 8:48AM
Subject: Re: Return to Top Link
← Previous message | Next message →
JP:
Are you able to provide a link? To me, this sounds like the binding is taking place before the element that it links to is created (when it fails). Does that make sense? When I was developing for SharePoint, I remember encountering a similar situation and that was the cause.
Dan Swift
Senior Web Specialist
Enterprise Services
West Chester University
610.738.0589
From: JP Jamous
Date: Wed, Oct 17 2018 9:27AM
Subject: Re: Return to Top Link
← Previous message | Next message →
Unfortunately, I cannot because the pages are still in stage and have not
hit prod yet. Can you explain to me the binding concept please as I am not
familiar with how Jquery executes? Also, can you give me a general idea of
how you were able to work around it?
--------------------
JP Jamous
Senior Digital Accessibility Engineer
E-Mail Me |Join My LinkedIn Network
--------------------
From: Swift, Daniel P.
Date: Wed, Oct 17 2018 9:49AM
Subject: Re: Return to Top Link
← Previous message | Next message →
Absolutely - this code would cause a problem because the click binding function happens before the element is created (actually, before the element has the ID):
$(document).ready(function(){
$('#backToTop').click(function(){
$("#someAnchor").animate({ scrollTop: 0 }, 900).attr("tabindex","0").focus();
return false;});
});
$('main').attr('id', 'someAnchor');
});
The above example is pretty silly, but it illustrates the flaw in the click binding occurring before the element exists. Specifically, it is trying to bind the click destination to the element whose ID does not exist yet.
We ended up delaying the binding by using the set timeout function which was far from elegant. IMO, a better solution would've been using a loop to check for the existence of the object and then create the binding once it's found.
Does that make sense?
Dan Swift
Senior Web Specialist
Enterprise Services
West Chester University
610.738.0589
From: Jonathan Avila
Date: Wed, Oct 17 2018 9:55AM
Subject: Re: Return to Top Link
← Previous message | Next message →
> <main id="page-content" tabindex="-1">
Perhaps setting focus to the heading directly below the beginning of the main element would be better than moving to the main element itself to avoid any issues with tabbing issues that may result from tabbing after quick key navigation with screen readers. Some browsers may also require calling the focus method on the element as well.
Jonathan
Jonathan Avila
Chief Accessibility Officer
Level Access
= EMAIL ADDRESS REMOVED =
703.637.8957 office
Visit us online:
Website | Twitter | Facebook | LinkedIn | Blog
Looking to boost your accessibility knowledge? Check out our free webinars!
The information contained in this transmission may be attorney privileged and/or confidential information intended for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any use, dissemination, distribution or copying of this communication is strictly prohibited.
From: JP Jamous
Date: Wed, Oct 17 2018 10:49AM
Subject: Re: Return to Top Link
← Previous message | Next message →
That was exactly what I suggested to the developer. I would like to set the
focus on the H1, but the 34 other web sites that this component is a part of
do not all have a H1 after main. It is an ugly situation.
--------------------
JP Jamous
Senior Digital Accessibility Engineer
E-Mail Me |Join My LinkedIn Network
--------------------
From: JP Jamous
Date: Wed, Oct 17 2018 10:50AM
Subject: Re: Return to Top Link
← Previous message | Next message →
Perfect sense Dan. I really appreciate that.
--------------------
JP Jamous
Senior Digital Accessibility Engineer
E-Mail Me |Join My LinkedIn Network
--------------------
From: glen walker
Date: Wed, Oct 17 2018 12:39PM
Subject: Re: Return to Top Link
← Previous message | Next message →
What is the problem with JAWS and IE with the tabindex="-1"?
IE actually requires you to have tabindex="-1" on any element that might
receive focus or if that element is used in an aria-labelledby. Without
tabindex="-1", while the page might scroll to that element when focus is
sent to it (via javascript), if you tab after the page scrolls, the focus
wasn't really moved to that element and the tab focus goes to whatever was
after where the focus was previously.
This is documented on microsoft -
https://docs.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/accessibility/gg701963(v=vs.85)#accessible-html-elements
So I'm puzzled what problem you're seeing when using tabindex="-1"
Glen
On Wed, Oct 17, 2018 at 8:31 AM JP Jamous < = EMAIL ADDRESS REMOVED = > wrote:
>
> <main id="page-content" tabindex="-1">
>
> I don't like the tabindex="-1" because JAWS in IE causes problems when
> tabbing.
>
>
From: Jonathan Avila
Date: Wed, Oct 17 2018 5:28PM
Subject: Re: Return to Top Link
← Previous message | Next message →
Hi, the problem that I've seen with some browsers like Firefox is that when certain tabindex values are set on a container and the user presses H to move to a heading and then presses tab the screen reader sometimes doesn't move to the next focusable control after the heading because the tabindex on the container seems to throw it off.
Jonathan
From: JP Jamous
Date: Thu, Oct 18 2018 6:12PM
Subject: Re: Return to Top Link
← Previous message | Next message →
Similar to what Jonathan mentioned. If the <main tabindex="-1"> and the user
is reading using down-arrow, once the user presses the tab key to set the
focus on the next link in the DOM, the <footer> obtains focus because other
footer links have tabindex="-1".
Once I had the developers remove tabindex="-1" from <main> JAWS was behaving
as it does in all browsers. So bottom line, JAWS in IE11 was selecting the
next tabindex="-1" or tabindex="0" and bypassing the whole list of links on
the page content.
That only happens in JAWS 2018 and IE11. I tested it with JAWS 2018 and
firefox and Chrome and the problem was not present. The tab selected the
link that is next in the DOM from where the cursor was last in the DOM.
That surely confuses a user because the user expects the next link in the
DOM after the position of the cursor to obtain focus. However, the user is
immediately jumped to the footer and has to either shift + tab to go back or
loop around the end of the DOM back to the top.
--------------------
JP Jamous
Senior Digital Accessibility Engineer
E-Mail Me |Join My LinkedIn Network
--------------------
From: Birkir R. Gunnarsson
Date: Fri, Oct 19 2018 4:58AM
Subject: Re: Return to Top Link
← Previous message | Next message →
That sounds like a Jaws bug to me. I'd recommend filing it and having FS fix it.
I think we can't always work around screen reader bugs, especially
when the workaround may cause issues for other users (e.g. if removing
the tabindex causes the skip link to break for keyboard only users, in
this situation it might).
On 10/18/18, JP Jamous < = EMAIL ADDRESS REMOVED = > wrote:
> Similar to what Jonathan mentioned. If the <main tabindex="-1"> and the
> user
> is reading using down-arrow, once the user presses the tab key to set the
> focus on the next link in the DOM, the <footer> obtains focus because other
> footer links have tabindex="-1".
>
> Once I had the developers remove tabindex="-1" from <main> JAWS was
> behaving
> as it does in all browsers. So bottom line, JAWS in IE11 was selecting the
> next tabindex="-1" or tabindex="0" and bypassing the whole list of links on
> the page content.
>
> That only happens in JAWS 2018 and IE11. I tested it with JAWS 2018 and
> firefox and Chrome and the problem was not present. The tab selected the
> link that is next in the DOM from where the cursor was last in the DOM.
>
> That surely confuses a user because the user expects the next link in the
> DOM after the position of the cursor to obtain focus. However, the user is
> immediately jumped to the footer and has to either shift + tab to go back
> or
> loop around the end of the DOM back to the top.
>
>
>
> --------------------
> JP Jamous
> Senior Digital Accessibility Engineer
> E-Mail Me |Join My LinkedIn Network
> --------------------
>
>
>
From: Jonathan Avila
Date: Fri, Oct 19 2018 10:03AM
Subject: Re: Return to Top Link
← Previous message | Next message →
> That sounds like a Jaws bug to me.
I believe this may happen with NVDA and Firefox as well in some situations -- a bug is listed below
https://github.com/nvaccess/nvda/issues/7897
Jonathan
Jonathan Avila, CPWA
Chief Accessibility Officer
Level Access
= EMAIL ADDRESS REMOVED =
703.637.8957 office
Visit us online:
Website | Twitter | Facebook | LinkedIn | Blog
Looking to boost your accessibility knowledge? Check out our free webinars!
The information contained in this transmission may be attorney privileged and/or confidential information intended for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any use, dissemination, distribution or copying of this communication is strictly prohibited.
From: Isabel Holdsworth
Date: Mon, Oct 22 2018 2:09AM
Subject: Re: Return to Top Link
← Previous message | No next message
Hi JP,
As well as scrolling the page, does the <main> tag receive focus? If
so IMHO its tabindex should be set to -1, otherwise keyboard users
without a screenreader will encounter a strange focus order. If
screenreaders aren't working correctly with this set-up, then they are
buggy. This is how our dialogues work, and we don't seem to have any
problems with them. When the dialogue opens up, the container, which
has a tabindex of -1, receives focus. Then when the user tabs again,
the first focusable element within the container receives focus. It
seems to work fine.
Cheers, Isabel
On 19/10/2018, Jonathan Avila < = EMAIL ADDRESS REMOVED = > wrote:
>> That sounds like a Jaws bug to me.
>
> I believe this may happen with NVDA and Firefox as well in some situations
> -- a bug is listed below
>
> https://github.com/nvaccess/nvda/issues/7897
>
> Jonathan
>
> Jonathan Avila, CPWA
> Chief Accessibility Officer
> Level Access
> = EMAIL ADDRESS REMOVED =
> 703.637.8957 office
>
> Visit us online:
> Website | Twitter | Facebook | LinkedIn | Blog
>
> Looking to boost your accessibility knowledge? Check out our free webinars!
>
> The information contained in this transmission may be attorney privileged
> and/or confidential information intended for the use of the individual or
> entity named above. If the reader of this message is not the intended
> recipient, you are hereby notified that any use, dissemination, distribution
> or copying of this communication is strictly prohibited.
>
>