I love using the Search Pane extension and continue to learn more of its features. The one thing I can't figure out is having the search panes pass Siteimprove accessibility scans. it flags the input fields of the search panes as Input field has no description. Below is the suggested methods to resolve the issue but I cannot figure out how to implement any one of the suggestions. Does Search Panes supports one of the suggestions below? If so, is there an example? If no support now, are there plans to include accessibility features?
ARIA4 Using a WAI-ARIA role to expose the role of a user interface component
ARIA14 Using aria-label to provide an invisible label where a visible label cannot be used
ARIA16 Using aria-labelledby to provide a name for user interface controls
G167 Using an adjacent button to label the purpose of a field
H44 Using label elements to associate text labels with form controls
H65 Using the title attribute to identify form controls when the label element cannot be used
Accessible web apps are very important to us and this would be a fantastic addition to our tools.
Many thanks for your message! I completely agree with how important accessibility is and we've put a lot of work into DataTables core and other parts of our software to make sure they are accessible.
SearchPanes is relatively new, so it hasn't received the same amount of attention in that regard. None of us on the team use accessibility enhancing software, so I always hesitate to just bang in some aria labels and call it done! I would much rather have some input from the accessibility community on what we should do to the software to make it actually useable for them, rather than just checking off a few boxes.
Do you use assistive software on a day to day basis yourself? Any guidance you can give us, or introduce us to those who might give us feedback so we can improve the software, would be very welcome indeed.
I personally do not use assistive software on a regular basis other than adjusting the font size larger. When coding, I do check my work with a combination of Siteimprove (chrome plug in) web scanning and as well as SonarCloud CI pipeline scanning. We also check for proper tabbing through the application and use good descriptions in the aria-labels. Sometimes we will use a screen reader as another check of the descriptions we use in the labels.
All is referenced to the the w3.org website. I'll go here if I need some code examples or for an understanding of a particular topic. To us, this is the Bible that we need to follow.
https://www.w3.org/WAI/design-develop/ is also a great website for developers, check it out if you haven't already.
If there is anything I can do to help, please let me know.
You can also reach out to my supervisor, Christopher Jasinski at Christopher.Jaszinski@utrgv.edu. He is aware of our accessibility needs on our software that we produce.
Web Software Engineer
University of Texas Rio Grande Valley
@Ray.Garza It looks as though all you need to do is add a label (or aria-label) for the input. Very straightforward. At the same time, removing the placeholder would definitely enhance accessibility. While technically "valid", placeholders are notoriously problematic for AT users, and should not be used as a substitute for labels.
University of Wisconsin–Madison
Many thanks for your feedback on this. Taking this example which has a DOM structure of:
You would suggest adding the
aria-labelattribute to the
inputin addition to the placeholder? We actually use the placeholder to show the title for the column that the specific pane is operating on, so dropping it would (ironically) be bad for accessibility for those who aren't using AT.
As I tried to explain, placeholders should not be used as substitutes for labels (or label-like purposes).
To indicate the title of the column the pane is associated with, I suggest using a more semantic element, such as a
As for the input, I take it that you do not want to visually display a label for design reasons. While label elements are generally preferable, if the visual design does not accommodate one, then
aria-labelis a suitable substitute. If you use an
h3as already suggested, then you can use
aria-labelledbyand reference the id of the
hNelement. Kill two birds with one stone.
And drop the placeholder attribute (make that three birds).
As for why
placeholdershould be avoided, please see:
I hope this helps,