plone
Formtabs - tab links - A11Y
This PR fixes an accessibility issue in the top/side menu in the content-types.
Previously, the menu items were rendered as <a> elements without an href attribute. According to the HTML specification, an <a> without href must not be used, since it is not considered a valid link. This caused problems with keyboard navigation (e.g., skipping the element when using Tab).
Now, these elements are rendered as <button> instead, since they perform actions inside the page (toggling tabs / opening menu) rather than navigating to another resource.
Why
<a>must only be used for navigation when it has a valid href- Using
<button>ensures proper semantics and accessibility - Improves keyboard support and screen reader behavior
Changes
- Replaced
<a>without href by<button>in side menu using semantic-ui props - Preserved styling and behavior
- Improved keyboard navigation and screen reader support
https://github.com/user-attachments/assets/d68c1fd4-a4c3-4783-b237-57aa819594b3
📚 Documentation preview 📚: https://volto--7308.org.readthedocs.build/
@stevepiercy I fixed my component Cypress test, but the acceptance tests are still failing and I have no clue why. I didn’t touch those files, yet they are failing on the title field, ex: cy.get('#field-title').type('An Example');.
I don’t know what I can do to fix it.
@Wagner3UB You can rerun the tests. Some tests fail randomly. I restarted.
@Wagner3UB I restart but the tests keep failing. So it might be something related to your modifications.
@Wagner3UB @wesleybl when tests that are unrelated to my changes fail, then my first check is against requirements and dependencies whose version may have changed since the tests last passed. You can compare logs of CI runs for acceptance tests at https://github.com/plone/volto/actions/workflows/acceptance.yml. Compare the last passing run and the first failing run to find the culprit.
Also, one more a11y thing to consider, and something that the Classic UI team ran into. Form tabs suck for several reasons, and accordions may be a good replacement. See github.com/plone/Products.CMFPlone/issues/4106.
Another awful thing to handle with both of these types of forms is when, for example, Tab A has a required field that is empty, but you're on Tab B which hides content in Tab A, and when you submit the form, where should the validation error message display? I much prefer to keep these forms in manageable units. That might be done by submitting the form field data when it changes, but I can't tell from the video.
Compare the last passing run and the first failing run to find the culprit.
Where the test fails: https://github.com/plone/volto/blob/d2ef6a5d442513bd9b05923c1db41a6d9872667a/packages/volto/cypress/tests/coresandbox/selectWidgetsFamily.js#L13
Cypress can’t find a content type named "example", and therefore fails to find #field-title.
My problem is understanding why a button inside the sidebar, with a configuration change (not the base one), interferes with the creation of a content type. And this line is there for 4 years!
The failing tests also fail on the 18.x.x branch, I'm going to approve this while I check what those tests are for. FYI @sneridagh
The failing tests are coresandbox fieldTypeValidation.js and selectWidgetsFamily.js that apparently try to add an object of type example.. I don't know where those come from but I can't find where the Content-type is added in the tests in the first place.
@pnicolli The coresandbox profile is in plone.volto and adds a type with lots of fields that can be used for tests. https://github.com/plone/plone.volto/tree/main/src/plone/volto/profiles/coresandbox
Please make sure that we end up fixing this in both 18.x.x and main, not only 18.x.x.
@pnicolli The coresandbox profile is in plone.volto and adds a type with lots of fields that can be used for tests. https://github.com/plone/plone.volto/tree/main/src/plone/volto/profiles/coresandbox
Please make sure that we end up fixing this in both 18.x.x and main, not only 18.x.x.
@davisagli I ran the tests using Cypress, and it looks like when I run the command make acceptance-backend-start, Docker spins up a version of the backend that’s missing the “type example”, which causes the test to fail.
I’m running the tests on a clean 18.x.x branch, so there’s no interference from any of my local changes.
Unfortunately, I’m not sure how to move forward beyond what I’ve already tried, so I’d really appreciate some help resolving this issue.
cc: @giuliaghisini @pnicolli