Open joachimesque opened 1 year ago
After poking at the code, I noticed that there's an aria-label
on the form
element, which doesn't help. From MDN:
The aria-label attribute is intended for interactive elements only. Use aria-label to ensure an accessible name is provided when none is visible in the DOM for all interactive elements, like links, videos, form controls, landmark roles, and widget roles. https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-label
I'm opening a PR that'll move that attribute to the input, and add two properties: one to define a value for the input's id
attribute, and one that'll be used to disable the aria-label, if a label element is used instead.
Hmm I do believe that aria-label
is valid on a form
. I'll try track down the initial reference implementation. You can see some evidence of this here: https://www.tpgi.com/short-note-on-aria-label-aria-labelledby-and-aria-describedby/
The aria-label, aria-labelledby, and aria-describedby attributes can be used with: ... • elements that have a landmark role – either implicit (header, footer, main, nav, aside, section, and form) or explicitly set via the role attribute
You can also see this references in WAI-ARIA 1.1 through the search
and form
roles (and the parent landmark
)
I'm surprised there isn't a <label>
or aria-label
on the search input, that seems like an oversight on my part. I think my original intention was a <label>
element paired with the input, and the aria-label
on the form itself as a landmark.
I am eager to make improvements for accessibility, I'm sure there is a lot we're currently missing, but I would like to make sure that they're changes in the right direction — do you know of a great a11y pattern/example of a live search that we can use as a reference for any changes?
Thanks for your answer! I had overlooked the fact that form
s have a landmark role, so the aria-label
is valid, and I jumped the gun on that one :)
As for the best practices, I'll find some examples—it will also be useful for the aria-live
question in #162
I would like to make sure that they're changes in the right direction
I have extensive professional experience building accessible front ends and would be happy to contribute.
do you know of a great a11y pattern/example of a live search
I don't think the fact that search is live needs to impact the label.
I think my original intention was a <label> element paired with the input
It's possible to have multiple Pagefind instances on a page. So approaches that rely on unique id
s, for example using an adjacent label, aren't a good fit. I recommend aria-label
on the input. (Using a wrapper label comes with CSS complications.)
--
There isn't standard copy everyone uses for search inputs. WAI uses "Search" on their site and in their tutorials — https://www.w3.org/WAI/tutorials/forms/labels/#using-aria-label.
If Pagefind did the same, we could make a new translation string, with the same defaults as placeholder
.
--
Let me know if I can open a PR.
Any progress on this? Testing my website with the Wave Accessibility tool throws the error "Missing form label A form control does not have a corresponding label." cc @bglw
Currently, the UI doesn't provide a way to link a label tag to the input (via an id attribute on the input), or to specify an
aria-label
if no input tag is used. By default, any input should have a label (be it from a label tag or anaria-label
attribute) in order to be understandable by screen readers. The fact that there is no way to direct a label tag to the Pagefind UI input or to set an aria-label attribute cancels the whole component’s accessibility.Considering the default design of the Pagefind UI, here's how it should work:
aria-label
attribute set to a predefined value (via a translation key)aria-label
attribute (perhaps by overriding the translation key?)aria-label
attribute (if I want to use a label tag)id
attribute to the input in order to direct a label tag to the inputaria-label
attribute if noid
is defined