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 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! 🤣🤣