Availability of CSS Styled <a/"> versus a checkbox without a form
I am updating the HTML for a site and currently the list of items is presented as filters or refiners, which are flagged as checkboxes with tags, but not in the form. Then, for "SEO considerations", they added an <a / "> tag that doesn't wrap around it:
<label>
<input type="checkbox" name="one" value="one" /> Refinement One
</label>
<a href="/url-for-adding-one"></a>
This clearly doesn't add the full SEO cost, but a kind of clunky HTML since the checkbox is not needed: the page works by listening for clicks on the shortcut and triggering the ajax load, no form. To be clear: there is no form, let alone form submission, so the checkbox is only available as a visual cue. I want to replace it with background images on the anchor and check the box completely like this:
<a href="/url-for-adding-one">Refinement One</a>
<a class="checked" href="/url-for-adding-two">Refinement Two</a>
To the client this is cool, but their main concern is accessibility and how this change will be reflected to screen readers ... my personal thought is that it should be better than checkboxes without a form, but I want a better answer that my gut check.
Do you know any consequences of the availability of replacing checkboxes with links in this situation?
source to share
The correct answer here is to use ARIA, specifically the attribute aria-checked
. It is specifically designed for accessibility.
However, I think your desire to get rid of the checkboxes is wrong. Anything that acts like a checkbox --- that is, it has a checked state and an unmonitored state that controls something on the page should probably be a real checkbox. This gives you very good behavior in terms of not only screen reading but also what keyboard and mouse users expect.
You can always wrap <a>
around <label>
.
source to share
If the page works by listening for clicks, it violates the accessibility requirement "Make all functionality accessible from the keyboard" in principle . In practice, however, pressing the Enter key on a focused element is usually treated as a corresponding click, that is, a click event is triggered.
Checkboxes without a form are not a problem per se, never were. Of course, they can only work on client-side scripts.
Link usage may be related to history accounting rather than SEO (because pages referenced this way are rarely related to search queries). If desired, then the choice is to do link management and duplicate link. Duplication can be confusing, especially in unusual viewing situations, so the link approach looks better. If the purpose of the link is to immediately trigger some action, then it would be better to have the style look like a button. Thus, the checkbox, even as a pure graphic object, would be unnecessary.
If you want to show the user the parameters that have been made (similar to displaying a checked checkbox), this can be done, for example. showing a list of the currently selected parameters (possibly with buttons for deselecting).
source to share
The question is, do they look similar and behave like checkboxes with visible users. If these are items that visually look like checked / unchecked and can have this state by clicking a button, then they behave like checkboxes, so they need to be shown as such to flasher users.
The problem with using simple anchors here is that the screen reader will just read them as link elements, so the screen reader will wait for navigation to navigate, not something that toggles state on the page. In addition, information about checked states will not be read, so the screener user will not know if the item is checked or not.
The ideal situation here is to continue using the real checkboxes as in the original code. (Drop the empty tag A
, this is a problem for keyboard users as they can enter it, but it has no screen presence - for sighted keyboard users - and no content text, so only the "link" is read on the screen, leaving the user confused about what it focuses on.)
The advantages of using real controls input type=checkbox
are that they just work; familiar mouse users, familiar keyboard users, and on-screen tool users get a good experience. They are available for mouse and keyboard; firmware will be declared as flags and will pass checked / unverified status. (It doesn't matter that they are not in actual HTML form.)
-
For what it's worth if you have good reason not to use input type=checkbox
, and instead had to use A
, which has been modified with click handlers and background images to behave as if it were a checkbox - and I don't think there is good reason for this route! - then you can use the WAI-ARIA attributes to mark the control with additional semantic hints so that it starts drawing it as a checkbox with the correct state; this involves adding role="checkbox"
andaria-checked="true"
, eg. Also, since users expect checkboxes to respond to space as well as typing, you will need to add keyboard handling as well. And you will need to test this with firmware to make sure it actually works. It's a lot of work to duplicate what is input
already for you! However, this approach makes sense when implementing custom controls that HTML does not yet provide convenient equivalents, such as menus, sliders, tree structures, and the like. Some of them eventually - or already - turn into HTML anyway.)
source to share