An internal reviewer suggested that our Plone site should have skip links for accessibility reasons. I believe they are referring to https://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-skip.html which suggests that skip nav links aren't always needed. This prompted me to see if Plone was satisfying this requirement in some other way but all I have been able to find is a changelog for plone.app.layouts 2.5.8 which removed a skiplinks viewlet.
The change log says "Get rid completely of the plone.skip_links viewlet because it already doesn't worked OOTB since always and this does not follow modern a11y methods and we are dropping support for outdated ways [sneridagh]"
Can anyone shed some light on how Plone 5.x is satisfying this requirement, or perhaps provide a more detailed answer of why this is not needed that I can pass on to clients?
The current (and since quite some time) thinking is that it is much better to use proper HTML5 entities, supported by ARIA landmarks, to indicate the semantic role of regions of a page.
The end-user using assistive technologies knows very well how to skip links, and they are deeply familiar with the various keyboard-shortcuts that screen readers and other technologies provide to jump directly to the "main", to "navigation" etcetera.
Having each individual site define their own skip-links is counter-productive; it can mess with the generic keyboard controls, and it requires users to learn the keys per website, which is silly. Much better to define the semantic meaning of your page regions correctly, then the end user knows how to handle them.
So, for standard Plone 5, the regions are correctly marked as <nav> or <aside> and with appropriate ARIA region landmarks.
For what it's worth, this is for a USA federal government website and we recently got flagged for not having a skip link from them using a tool that appears to be https://www.deque.com/tools/worldspace-comply/. Unfortunately I don't think it matters if skip links are out dated in terms of actual accessibility if the client is going to use a tool that requires them.
As you linked to it before, the criterion 2.4.1 clearly states that there are multiple 'sufficient' techniques. Only one of those is using skip-links, and there are better alternatives now.
Of course, if your client uses an outdated tool to 'tick boxes' rather than follow the WCAG way (which is much more about what you want to achieve, not exactly how you should do that), you could be in trouble. Then, I'd say, add skip-links using Diazo or in your theme.
But do tell them their tooling, and their thinking that a11y is just a set of boxes to tick without actually thinking about accessibility, is outdated.
Hoping for you they don't also require IE6 compatibilty
I am a bit surprised that a Deque tool reports this; their axe-plugin for Chrome/Firefox is excellent and does a very good job at avoiding false positives, and gives good hints at how to interpret results and giving multiple alternatives on how to comply.
Sadly I'm facing this as well. The client runs Deque WorldSpace Comply on a Plone 5 site and doesn't care what the "right" way is to do a11y, just so long as the number of items flagged in the report goes to zero.
While we're on this topic, what are the top resources for those dealing with a11y in 2019. I understand that there will still be those that want to check boxes but I'm interested in what makes sense now. For example I know about https://www.nngroup.com/topic/accessibility/.
