I think it's possibly expected behaviour for changing tabs as it does reset keyboard focus.
As for the podcast page I think the page itself needs looking at, I can't see a way to start a podcast without the mouse. I don't think it's related to this PR though.
Accessibility First DevRel. I focus on ensuring content created, events held and company assets are as accessible as possible, for as many people as possible.
Changing tabs shouldn't reset focus as it is all done via AJAX, instead you should either use aria-live and say "loaded" when complete or focus the first item in the list (SPA pattern).
That issue you quoted is a tough one with the current pattern. I would suggest on that page that nothing is focused initially and the first Tab press is used to activate the skip links as there is no real way of differentiating keyboard and mouse users.
To be fair the whole pattern is a little unusual, I like it, but normally on navigation you would expect nothing to be focused on a page change and the first tab to show the skip link.
On a SPA application you would expect the <h1> of the page to be focused once loading is complete.
As Dev.to is a hybrid I think the solution implemented is a nice balance and the work done on this is great, just some minor points which may be there own issues.
Accessibility First DevRel. I focus on ensuring content created, events held and company assets are as accessible as possible, for as many people as possible.
I will have a proper read but I dont see an aria-live region in the elements tab in dev tools to indicate the current page?
From a skim read that looks to be the pattern they settled on?
SKip link focused, aria-live to notify of current page?
I might be missing it though as I am not on my main PC and it is hard to assess from here.
The advice now looks like this:
Provide a skip link that takes focus on a route change within the site, with a label that indicates what the link will do when activated: e.g. "skip to main navigation".
Include an ARIA Live Region on page load. On a route change, append text to it indicating the current page, e.g. "Portfolio page".
Changing tabs shouldn't reset focus as it is all done via AJAX, instead you should either use aria-live and say "loaded" when complete or focus the first item in the list (SPA pattern).
The tabs on the home feed aren't true "tabs" in the usual sense of toggling a small section of page visibility - they're actually links within a nav and clicking on them results in a fresh page load, which is why a user would need a skip link to get them back to the main content with ease.
Podcasts skip links do not work when on an actual podcast page
Looks like a page was missed when implementing the skip links! We'll get a quick fix up for that ASAP - nice spot 🙌
Accessibility First DevRel. I focus on ensuring content created, events held and company assets are as accessible as possible, for as many people as possible.
Ah I see, because of the prefetching making it load instantly I thought it was an AJAX call, my bad! I should have checked the network tab before opening my mouth 😂😋
I will have a proper read but I dont see an aria-live region in the elements tab in dev tools to indicate the current page?
You're right! It's not related to @metamoni
's PR, but actually I missed this when implementing the skip links originally - we'll get this fixed 😄 But yes, that's the pattern we've been incrementally adopting, based on the research presented.
Accessibility First DevRel. I focus on ensuring content created, events held and company assets are as accessible as possible, for as many people as possible.
It is a really interesting pattern I haven't seen before so I look forward to seeing it in full form.
I think the aria-live region is the way they decided to address the problem I raised (I still haven't had chance to test, just my gut reaction from experience) in that if you manage focus it will interrupt reading the page title etc.
I hope the pattern works well as I do actually prefer the keyboard interaction this way (1 extra tab stop removed is always welcomed!) and once you have all had the headaches of implementing it I can learn from out of the way I might just be stealing it 😋🤣.
Thanks for the super quick responses @s_aitchison
!
Sorry @metamoni
didn't mean to hijack this as the work you have done is great!
Accessibility First DevRel. I focus on ensuring content created, events held and company assets are as accessible as possible, for as many people as possible.
I would imagine the fix for this would be super simple for a quick fix while a more flexible solution is created:
Add an aria-live region to all pages for site announcements. ID = "ariaLiveDiv";
// page load complete stuff before hereletannouncerDiv=document.querySelector("#ariaLiveDiv");announcerDiv.innerHTML=document.title;//the focus step after page loadmySkipLink.focus();
It would stop gap the issue while you set more meaningful text for each page (as the titles aren't always the best for things like comments etc but work great for the core part of the site such as articles, reading list, home etc.)
Accessibility First DevRel. I focus on ensuring content created, events held and company assets are as accessible as possible, for as many people as possible.
I just had a thought that I am hoping I am wrong about.
I haven't fired a screen reader up (will do that later when on main PC) but I have just had a horrible thought...if the link is focused on page navigation does it interrupt reading the page title etc. If so this whole pattern would make accessibility much worse for screen reader users as every page you land on would just be called "skip link" as far as they are concerned and they would have to use other controls to ensure they are on the right page.
Accessibility First DevRel. I focus on ensuring content created, events held and company assets are as accessible as possible, for as many people as possible.
Sorry, I think I need to explain this point further as I think I made it confusing mixing the two patterns together.
When you manage focus on a page load (adding focus to the skip link or focusing a <h1> etc.) it will interfere with a screen reader normal announcement, which would be to read the page title etc.
On a true SPA application (content loaded via AJAX - header and footer remain rendered) focusing the <h1> is the preferable action as there is no page refresh so the page <title> will not be read out. This helps screen reader users both know where they are and also know the page has loaded. (This is assuming the <h1> for the page is descriptive.)
However in dev.to I was incorrect as the page does actually reload so it isn't a SPA pattern and we can ignore that bit (I goofed!!).
In this case the page loads like a normal site, even for the home page feed tabs etc.
So we fall back to a normal pattern. A screen reader would start to read the page title but we interrupt it with focus management focusing the skip link. This makes navigation via a screen reader more difficult as you cannot confirm you have landed on the correct page via the title being read out automatically.
This is why we were having a discussion about adding the page <title> content to an aria-live region on the page. That way we can still use your skip link focus, but a screen reader user will also hear the current page title and know where they are.
Now they could just press Enter to get to the <h1> and hear what page they are on (except for podcasts page as that appears to be a <h4>?) But at that point they have skipped navigation...so they would have to go back to the navigation if they had made a mistake.
It wouldn't take long to get used to the pattern, it is just not expected behaviour (and expected behaviour is one of the core things to look at on accessibility for screen readers to make discovering a new site easier).
It isn't a huge issue, it has just inadvertently made the experience a bit worse for screen reader users while you improved the keyboard usability greatly for others. The joys of accessibility is that stuff like this happens all the time! 🤣
I hope that makes more sense, but if not let me know! Honestly I should have just done a jsfiddle or codepen as the concept is really simple...it is my terrible explanations making things difficult! 🤣🤣
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
There's a follow up about the same issue on search
Describe the bug
When I hit "return" on desktop to make a search on the platform, I see the keyboard nav "skip to content" element show up.
To Reproduce
Expected behavior
This element should not become visible.
Screenshots
Desktop (please complete the following information):
I think it's possibly expected behaviour for changing tabs as it does reset keyboard focus.
As for the podcast page I think the page itself needs looking at, I can't see a way to start a podcast without the mouse. I don't think it's related to this PR though.
Changing tabs shouldn't reset focus as it is all done via AJAX, instead you should either use
aria-liveand say "loaded" when complete or focus the first item in the list (SPA pattern).That issue you quoted is a tough one with the current pattern. I would suggest on that page that nothing is focused initially and the first Tab press is used to activate the skip links as there is no real way of differentiating keyboard and mouse users.
To be fair the whole pattern is a little unusual, I like it, but normally on navigation you would expect nothing to be focused on a page change and the first tab to show the skip link.
On a SPA application you would expect the
<h1>of the page to be focused once loading is complete.As Dev.to is a hybrid I think the solution implemented is a nice balance and the work done on this is great, just some minor points which may be there own issues.
The pattern was taken from this blog post.
I will have a proper read but I dont see an
aria-liveregion in the elements tab in dev tools to indicate the current page?From a skim read that looks to be the pattern they settled on?
SKip link focused, aria-live to notify of current page?
I might be missing it though as I am not on my main PC and it is hard to assess from here.
Under "Recommendations: finding common ground"
The tabs on the home feed aren't true "tabs" in the usual sense of toggling a small section of page visibility - they're actually links within a
navand clicking on them results in a fresh page load, which is why a user would need a skip link to get them back to the main content with ease.Looks like a page was missed when implementing the skip links! We'll get a quick fix up for that ASAP - nice spot 🙌
Ah I see, because of the prefetching making it load instantly I thought it was an AJAX call, my bad! I should have checked the network tab before opening my mouth 😂😋
You're right! It's not related to @metamoni 's PR, but actually I missed this when implementing the skip links originally - we'll get this fixed 😄 But yes, that's the pattern we've been incrementally adopting, based on the research presented.
It is a really interesting pattern I haven't seen before so I look forward to seeing it in full form.
I think the
aria-liveregion is the way they decided to address the problem I raised (I still haven't had chance to test, just my gut reaction from experience) in that if you manage focus it will interrupt reading the page title etc.I hope the pattern works well as I do actually prefer the keyboard interaction this way (1 extra tab stop removed is always welcomed!) and once you have all had the headaches of implementing it I can learn from out of the way I might just be stealing it 😋🤣.
Thanks for the super quick responses @s_aitchison !
Sorry @metamoni didn't mean to hijack this as the work you have done is great!
I would imagine the fix for this would be super simple for a quick fix while a more flexible solution is created:
Add an aria-live region to all pages for site announcements. ID = "ariaLiveDiv";
It would stop gap the issue while you set more meaningful text for each page (as the titles aren't always the best for things like comments etc but work great for the core part of the site such as articles, reading list, home etc.)
Wow, some interesting discussions here while I was at work. Thank you, @inhuofficial and @s_aitchison , I'm learning a lot from all of this 😄
I just had a thought that I am hoping I am wrong about.
I haven't fired a screen reader up (will do that later when on main PC) but I have just had a horrible thought...if the link is focused on page navigation does it interrupt reading the page title etc. If so this whole pattern would make accessibility much worse for screen reader users as every page you land on would just be called "skip link" as far as they are concerned and they would have to use other controls to ensure they are on the right page.
There is an h1 on every page. This is the first item read out by screen readers after you hit Enter on the skip link.
Sorry, I think I need to explain this point further as I think I made it confusing mixing the two patterns together.
When you manage focus on a page load (adding focus to the skip link or focusing a
<h1>etc.) it will interfere with a screen reader normal announcement, which would be to read the page title etc.On a true SPA application (content loaded via AJAX - header and footer remain rendered) focusing the
<h1>is the preferable action as there is no page refresh so the page<title>will not be read out. This helps screen reader users both know where they are and also know the page has loaded. (This is assuming the<h1>for the page is descriptive.)However in dev.to I was incorrect as the page does actually reload so it isn't a SPA pattern and we can ignore that bit (I goofed!!).
In this case the page loads like a normal site, even for the home page feed tabs etc.
So we fall back to a normal pattern. A screen reader would start to read the page title but we interrupt it with focus management focusing the skip link. This makes navigation via a screen reader more difficult as you cannot confirm you have landed on the correct page via the title being read out automatically.
This is why we were having a discussion about adding the page
<title>content to anaria-liveregion on the page. That way we can still use your skip link focus, but a screen reader user will also hear the current page title and know where they are.Now they could just press Enter to get to the
<h1>and hear what page they are on (except for podcasts page as that appears to be a<h4>?) But at that point they have skipped navigation...so they would have to go back to the navigation if they had made a mistake.It wouldn't take long to get used to the pattern, it is just not expected behaviour (and expected behaviour is one of the core things to look at on accessibility for screen readers to make discovering a new site easier).
It isn't a huge issue, it has just inadvertently made the experience a bit worse for screen reader users while you improved the keyboard usability greatly for others. The joys of accessibility is that stuff like this happens all the time! 🤣
I hope that makes more sense, but if not let me know! Honestly I should have just done a jsfiddle or codepen as the concept is really simple...it is my terrible explanations making things difficult! 🤣🤣