It’s referring to an HTML label tag.
This is the “right” way to mark up a label for a form field.
aria-labelledby is a work-around when the label can’t be marked up by a label tag (e.g. see this recent answer)
aria-label is an alternative when for whatever reason there isn’t a tag ...
Since all items are already loaded, the "load more" function is there probably only for visual clarity and not for performance. When using a screen reader, there is no benefit in having to load more items, as this function only exists to have a nicer overview for people who can see. If this is true, all items can be made directly accessible for screen reader ...
I have a suggestion, but it depends on how complex your build can be (i.e., what are the limitations of the build/developers).
A while back, I actually spent some time building out table-design guidelines for College Board. One thing that became very useful was allowing "excess columns" to reside in an expanded portion of a row, displayed in a stacked view ...
For keyboard and screen reader users, this can be very confusing. If you're trying to tab through the fields to get to whatever's after the fields, it would cause a search to be submitted just by navigating through the page.
Performing some action just by tabbing through the fields would be a violation of WCAG 3.2.1
In general, it's best to not move the user's focus. So if your "load more" button is still visible on the page after the new content is loaded, then the focus should stay on that button. Leaving the focus on "load more" will help comply to WCAG 3.2.2
Also, for accessibility purposes, it would be nice to announce how much more "stuff" was just loaded. ...
There aren't clear solution.
It is worth asking several users what is more convenient for them.
In my opinion, once the screen is still in place, the screen should remain unmoved -
when the number of items on the list goes out of sight on the screen the screen position should change to the first new visible list element
Origin of this solution is aimed at ...
There are two changes to be made if you are working on an accessible tooltip solution.
Avoid automatic presentation of a tooltip when user focuses a UI control with keyboard. There are warnings about it in WCAG.
There must be a clear action that would invoke a tooltip. Also, there must be a separate action that closes it, such as close button inside. ...
Yes it does. Hover state is just one of the states of a UI control, so every requirement is applicable.
Only disabled (inactive) state is exempt from colour contrast requirements.
See Success Criterion 1.4.3 Contrasstrong textt (Minimum) Incidental
I do not have an example, but some thoughts about such a toggle:
If you use a WCAG 2.0 conform contrast in the first place the toggle wouldn't be necessary. And there are more benefits in that: the readability of your site will be enhanced for all users.
Having a toggle might make some user feel handicapped because they need to change the settings of the ...