I think this is partly because the form labels are not actually correctly associated with their fields, newer browsers don't use the `name` for this, so you have to use `id`, but the fields lack an `id` attribute.
That being said I am surprised that this, I guess, makes it just ignore them as form fields altogether? It otherwise looks fairly normal as far as login forms go.
"I think this is partly because the form labels are not actually correctly associated with their fields"
yup, running accessibility tools in a browser will surface this particular issue on a large number of forms.
last time i accessibility bug bashed i took a bunch of notes for follow on bugs to file if this got any dev attention.
other areas of the site with similar problems:
- post editor
- emoji picker
- page creation
- edit profile
cohost devs have not acknowledged or solved any of the bugs that come up in a search for "accessibility" for at least 8 months. https://help.antisoftware.club/support/search/topics?page=1&term=accessibility
as of time of posting, this filed bug still reproduces.
if you too would like to file an unacknowledged and unfixed accessibility bug, you can retrace any of those areas or just sort of vaguely wave a screen reader at cohost while recording with obs. it will be like hitting the broad side of a barn. you may find this nvda cheat sheet useful: https://dequeuniversity.com/screenreaders/nvda-keyboard-shortcuts
you don't even have to futz around with a screen reader either, there's still some delicious keyboard bugs floating around. (like this recently filed keyboard trap: https://help.antisoftware.club/support/discussions/topics/62000184660 )
i'm sure there's great posting and bug finding to be done on cohost but this is blocking for me. why spend any time on a site where even the login form is inaccessible? lol. unfortunately, it does not seem likely to be fixed without substantial community pressure to get the dev team to care about these issues and as of now that community pressure has not emerged. so it goes.
This is an incredibly urgent issue. Bumping this request.
also feels pretty urgent to me
Hey all, investigating this one, we can't seem to perfectly replicate the issue with VoiceOver or Windows Narrator. Some videos of the issue along with what software you're using would be helpful for us to track this down.
I can see that screenreaders aren't picking up error messages, but it is reading the labels above the forms.
Can I get some more info on what the ideal behavior here would be? Thanks!!
@kara
We made a video that should explain the issue <3 There's no errors on the website, things are just labelled in a way that make effective traversal inaccessible.
(Sorry to post to YT but the file is too big to upload here and we have no energy to muck around encoding.)
Sorry, last thing we are going to say, this is what we think the issue is but we might be completely misunderstanding. We aren't sure what error messages should be announced. yup.
so, as of writing this, the markup for the login page has been updated, so at least when you tab navigate in nvda or navigator on firefox it will announce the field you are on.
as for the other half of core of the bug, being able to have perceivable error messages... that's still not entirely fixed on either nvda (or having run thru the scenario on narrator) or narrator either.
i'll provide new videos and commentary for the current behavior i'm seeing on the latest firefox with the latest nvda and narrator.
but first, uh, a few small digressions:
> perfectly replicate the issue with VoiceOver or Windows Narrator. Some videos of the issue along with what software you're using would be helpful for us to track this down.
I list the software combination I'm using to file the bug in the first step as NVDA and Firefox, and the video attached to the bug has that empty form scenario.
NVDA, non visual desktop access, is a relatively common open source screen reader. You can download it here: https://www.nvaccess.org/download/
There is a method to this choice, namely that since i do not have nor can afford a JAWS license, NVDA is the next most commonly used screen reader combination with browsers on platforms i use. (I don't have an easily workable mac right now)
WebAIM's screen reader survey can provide some data here: https://webaim.org/projects/screenreadersurvey9/#browsercombos
NVDA with some browser represents roughly 30% of user share. Narrator is fine and important to test for, but personally i wouldn't put it as the only or first screen reader i tested, given this data.
> Can I get some more info on what the ideal behavior here would be?
I'll revisit this more directly in the context of the filed bug but at a high level, there's a few core principles behind WCAG that are useful tools for figuring out what behaviors are desirable or undesirable.
Content on the web should be
1. Perceivable
2. Operable
3. Understandable
4. Robust
These are described in much more detail in the WCAG spec: https://www.w3.org/WAI/WCAG22/Understanding/intro#understanding-the-four-principles-of-accessibility.
The underlying problem here is that there's still plenty of information that is still not perceivable to users of a screen reader.
These pages describe labeling in forms in a bit more detail, which may be useful when going thru other parts of the site.
https://www.w3.org/WAI/WCAG21/Understanding/labels-or-instructions.html
https://www.w3.org/WAI/WCAG21/Techniques/html/H44
https://www.w3.org/WAI/tutorials/forms/labels/
Thinking through unfiled bugs and with a feeling there's probably plenty that's broken or changed in the intervening months since this bug was originally filed, i think i'd prioritize keyboard + screen reader fixes along the critical path from account creation to login to page creation to first post. Then, with most of that happy path resolved, fix keyboard bugs in untested/broken portions of the site before then testing and fixing other lurking screen reader issues (since screen reader users predominately navigate with the keyboard)
WCAG link on some techniques for keyboard accessibility here: https://www.w3.org/WAI/WCAG22/quickref/#keyboard
-----
>we can't seem to perfectly replicate the issue with VoiceOver or Windows Narrator
So the flow is still, in my view, broken on narrator as is; with an additional issue discovered in this process.
In the empty login case:
email and password are both labeled enough to be announced on tab navigation, this is good.
The role="alert" on the warning text will announce when the dom element changes, fine.
but then, when you submit the empty login form, the error state is not announced again. Tabbing between the empty fields to resubmit won't re-announce what is empty, because the elements with the role="alert" don't change or update in the meantime. So then, we're back to where we started with the original bug filing: there are errors displayed but they are not perceivable and they are not announced on a failed submit of the login form.
For the sake of completeness, and in light of file size constraints, i will attach the same scenarios with firefox and nvda in another message on this thread. (nvda-firefox-empty-form-scenario.mp4 and nvda-firefox-bad-account-details-no-announce-error.mp4) They're broken in mostly similar ways as explained above, so we don't have to revisit that.
Sorry for the late response, I'll pay more attention to my email and thus this thread in the next few weeks. Progress is being made! Great! We're still not there yet. bug's still not fully fixed. so it goes.
as promised, the videos for the nvda/firefox scenarios (nvda-firefox-empty-form-scenario.mp4 and nvda-firefox-bad-account-details-no-announce-error.mp4)
polynymity
86 people have this problem