I have used the ‘modal’ block a number of times on a page, with a trigger set on a element - which seems to me to be semantically correct for this use case.
I see in the modal markup that there is an empty anchor link rendered <a href="#" class="cc-mdl-close" aria-hidden="true"></a>.
This getting picked up in various accessibility testing tools as erroneous (Wave, Google Page Insights, WP Equalize Digital testing plugin) - and seems un-needed. Indeed, if I remove it from the DOM using devtools, everything still works.
Have I an incorrect setting somewhere causing this markup to be rendered needlessly?
Thanks, interesting… The problem is that in testing with VoiceOver (the macos screen reader) it is announcing the empty links at the bottom of the page even though all the modals are closed. See the latter part of this screencast: Loom | Free Screen & Video Recording Software | Loom
The problem now is that the modal is set to display:block, independent of its current state.
So when using the keyboard, users will tab through modal elements which are invisible to them when the modal is not active.
The tabbing is something we can have a discussion about, but I went through long discussions with someone who is quite well versed in all the accessibility part of things and I was told that it was very important to keep the modal accessible, which means that in no circumstance can it be hidden from the end user.
Fix: Move Modal block markup to end of content to not interfere with tabbable elements
I’m just summarizing the current state, not stating that everything is 100% accurate accessibility wise.
Not claiming myself as an expert, as my knowledge is only above average, I would say.
I still would prefer that the modal content is not accessible when the modal is not active, but that would speak against what Louis said above.
Also, I’m not a big fan of manipulating the DOM after page load, as the user has no control about it:
Still, there should be an option to opt-out, but I’m fine with it if that won’t happen.
Placing modals in that exact spot is achievable by using global parts and building templates with Fragments, so I prefer to do it by myself if required.
Nothing against the current default behaviour though, as it’s helpful for vast majority of the users, I guess.
As @Marius also mentions, I to am not convinced moving the model elements around in the DOM is the best approach here. If the intention is to keep modal content accessible without opening the modal (and I’m not sure this is necessary, but I defer to the advice you have been given), then moving it to the end of the page breaks the semantic context - which is arguably a bigger accessibly problem - because it now makes no sense to the user. It either announces twice (once when they activate the modal, and again at the end of the page, out of context), or it announce at the end of the page for no apparent reason given they have not elected to open the modal.
The other issue is how to prevent the empty anchors from announcing? This can’t be optimal as a meaningless announcement is clearly confusing for a screen-reader user, and it also reports as an error due to the empty anchor in all the automated testers we use too! The presence of the aria-hidden="true" doesn’t seem to prevent the announcement or the error reporting, interestingly.
Forgive me if I’ve missed something critical here, or have botched my implementation (quite possible!), but perhaps this needs revisiting?