I'm a web developer, graphic designer, type designer, musician, comicbook-geek, LEGO-collector, food lover … as well as husband and father, located just south of Copenhagen, Denmark.
My whole point is not looking at it as a modal for screen-readers, but as content you navigate to and from, using the fragment identifier # (and bits of JS to focus on the previous id, when you change the fragment identifier to just #).
I assume inline links (yourdomain.com/#about) works just as well on screen-readers?
For people without screen-readers it will function as a modal, with focus-trapping etc., but for screen-readers as content you navigate to and from.
PS! I just tried "Narrator" in Windows, and it correctly jumped to the modal and back when I “closed” it.
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.
The link part would work fine, the problem comes with understanding content. A hyperlink saying "close" is not very useful to a screen reader user without knowing they are in a modal for example (could possibly be fixed with an aria-label explaining but still not sure if that is ideal).
Also in a sandbox it is fine but in the real world a modal would be used to alert information etc. So at places where you are likely to use it it would be expected to have a button anyway (such as in a form)? (Maybe there is a use case but I can't think of it at the moment)
The other issue is when JavaScript is turned off if you open the second "modal" and then close it you are returned to the top of the page, could possibly be fixed by giving the link that opens it an ID and making the close buttons point at that instead though?
One thing that would improve it is moving the id to the heading of the "modal" but that would make the selector hard work for :target.
As a concept I do think it is good, but the problem is expected behaviour.
The use case I can think of is for cookies consent if you had the "modal" open on page load.
I will think about it more as I think you have a concept that probably has some good use cases but until I think of the use cases I cannot recommend best actions to fix things (if you have some use cases in mind that would be great).
I'm a web developer, graphic designer, type designer, musician, comicbook-geek, LEGO-collector, food lover … as well as husband and father, located just south of Copenhagen, Denmark.
The :target-based modal works just fine for non-screen-readers using only CSS and HTML.
With JS enabled, it works fine for people like me, who cannot use a mouse.
But for screen-readers, with inline links, the behaviour can be unexpected.
I need to know how screen-readers normally announce inline links, using fragment identifiers - I'll look into that.
Because, could it potentially be enough to set aria-hidden="true" on the modal by default, and change this to false on the hashchange-event?
And set the aria-label to "Back to previous loccation"?
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.
Thanks for your comprehensive review!
My whole point is not looking at it as a modal for screen-readers, but as content you navigate to and from, using the fragment identifier
#(and bits of JS to focus on the previous id, when you change the fragment identifier to just#).I assume inline links (
yourdomain.com/#about) works just as well on screen-readers?For people without screen-readers it will function as a modal, with focus-trapping etc., but for screen-readers as content you navigate to and from.
PS! I just tried "Narrator" in Windows, and it correctly jumped to the modal and back when I “closed” it.
The link part would work fine, the problem comes with understanding content. A hyperlink saying "close" is not very useful to a screen reader user without knowing they are in a modal for example (could possibly be fixed with an
aria-labelexplaining but still not sure if that is ideal).Also in a sandbox it is fine but in the real world a modal would be used to alert information etc. So at places where you are likely to use it it would be expected to have a button anyway (such as in a form)? (Maybe there is a use case but I can't think of it at the moment)
The other issue is when JavaScript is turned off if you open the second "modal" and then close it you are returned to the top of the page, could possibly be fixed by giving the link that opens it an ID and making the close buttons point at that instead though?
One thing that would improve it is moving the id to the heading of the "modal" but that would make the selector hard work for
:target.As a concept I do think it is good, but the problem is expected behaviour.
The use case I can think of is for cookies consent if you had the "modal" open on page load.
I will think about it more as I think you have a concept that probably has some good use cases but until I think of the use cases I cannot recommend best actions to fix things (if you have some use cases in mind that would be great).
Again, thank you for your comprehensive answer!
To recap:
:target-based modal works just fine for non-screen-readers using only CSS and HTML.I need to know how screen-readers normally announce inline links, using fragment identifiers - I'll look into that.
Because, could it potentially be enough to set
aria-hidden="true"on the modal by default, and change this tofalseon thehashchange-event?And set the
aria-labelto "Back to previous loccation"?