-
-
Notifications
You must be signed in to change notification settings - Fork 110
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tweak markup so screen readers use correct context of ID and title #1840
Comments
You should widen the scope of this and improve all uses of |
This is important and will be a lot easier now we have the UI library. As we gradually migrate all controls over to the library, we'll ensure that aria labels are consistently applied. So, best practice for those horrible clickable toggle state controls is actually to label them as the state they are in, and not the action that will happen if activated? Or both? E.g. |
I'll take ownership of this when I can get back onto Textpattern work. I'll also read up on the latest accessibility stuff as I've been away from web design work mostly this year, so a little rusty. |
Yes in the case of those toggle controls, that would be a better option. In general, always first ponder - is there a textnode in the HTML ? If yes, then, do I really need to add an Thought: what could be an improvement for all users for that particular case: add the “Edit” word in the HTML and use that as link-name.
|
Nice idea and scope, thanks @phiw13 |
I have now removed any Any other accessibility updates I'd rather leave until the new UI system is being used. Any issues can then be raised and fixed as individual items at that time. Thanks. |
For yes/no and on/off combinations (such as on the prefs panel), I guess we need to add
What do you think? |
For the radio combo sets on the Preferences panel (e.g) I don’t think you need to add any |
On those prefs radios, doesn't the label just state "yes"/"no" - not the overarching summary of what the preference is? So, if I tab to the radio combo, wouldn't the screen reader just read out "yes" for example, without the parent summary being read out? If so, that is bad. |
You are right, the labels actually don’t say much about the actual question for each field. Ignore me. t The |
OK, I'll attempt to action this later today. |
@Bloke the advanced options on/off combo seems to have an erroneous extra Example HTML, where the
|
Hmmmmm. I must have messed up. I'll try and investigate tonight |
Spurious. It may be because the I think there's a reason for having the label inside the div, but I'd have to comb the commits to find out what it is. Unless @phiw13 can remember offhand? |
We had some discussion at the time you did the rebuilding of the plugin edit panel, where those labels were already inserted (UI Library?). I still see absolutely no need for that construction. Not sure where that discussion was, in the context of a commit maybe? Or was it in the forum ? my GH is never good, and a quick search on the forum turns out nothing ATM. |
I found the previous discussion, in this forum thread. |
EDIT: No, hang on. I've just analysed it further. Scratch the above. The UI controls don't render a label by default. They only render individual labels for each radio/checkbox element in the set. What does create the label is calling |
That seems fine to presume to me - the combination children themselves have the labels on them. The summary title for that pref should not have a label. So, the example that was mentioned few posts above (noting the use of an
|
https://forum.textpattern.com/viewtopic.php?id=51932
Follow up from @Bloke:
The text was updated successfully, but these errors were encountered: