Great that you're shipping a11y improvements! I was looking at one of my forms (one-page test form using a single text input) and noticed a few things that might be worth following up. Sharing them here in case they're useful: Required (to comply with WCAG 2.2 AA) - The input "label" is currently an h3 element, which causes a few cascading issues: clicking it doesn't focus the input, the heading hierarchy jumps from h1 → h3 (skipping h2), and when combined with aria-label on the input, screen readers may announce the question twice. A label with a proper for attribute fixes all three at once. - The progress element is missing an aria-label, so its value won't be communicated to screen reader users. MDN docs with details: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/… Recommended - The required attribute and aria-required="true" are both present on the input. required alone is sufficient and the recommended option when using semantic HTML such as input. (aria-required should rather be used for non-semantic form controls.) Debatable/nice-to-have - Setting progress value="1" max="2" (50%) when the user has completed no fields yet is arguably misleading. Worth discussing what the right default is.
Thanks Brent, this is genuinely helpful. A quick note on the first one: the <h3> label comes from building the question with a Title block. We also have a Label block that renders a proper <label for>, which fixes the click-to-focus and association. You did surface a real bug underneath it though, we set aria-label on the input unconditionally and it ends up overriding the label, so we'll fix that too. We've tracked the rest as a batch and will work through them: dropping the redundant aria-label so the real label wins, adding an aria-label to the progress bar and rethinking its starting value, and not emitting aria-invalid until a field has actually been validated. The required / aria-required overlap is harmless but we'll tidy it up while we're in there. Really appreciate you testing this so carefully, please keep it coming. 🙏
You're welcome! 🙂 > A quick note on the first one: the <h3> label comes from building the question with a Title block. We also have a Label block that renders a proper <label for>, which fixes the click-to-focus and association. I see! I wasn't aware of the label option. A few more thoughts on using the heading element as a label: - if you use the h3 as the input's label, I think you will need to use aria-labelledby="id-of-h3" on the input instead of aria-label to avoid duplicate titles. Not sure if this is what you're describing with the overriding behavior - most people will probably not think of replacing the default h3 with the label, creating the less accessible form by default - a genuine label will be most accessible (out of the box): using a heading element as the label doesn't create the click association, for example > not emitting aria-invalid until a field has actually been validated I removed that bit because I'm actually not sure if this is a problem. According to MDN/W3C, aria-valid="false" is the default, so I would think it's okay. > The required / aria-required overlap is harmless but we'll tidy it up while we're in there. Indeed (as long as you keep the required attribute)! (These are quick replies, would still have to test to be sure.)
Hey Brent, We now use aria-labelledby and point it at the heading. We only keep aria-label when a question has no visible title at all. aria-invalid: agreed, we left it as is. required: it stays. We only drop the extra aria-required. Thanks again, your feedback really helped. 🫶
I also flag that the accessibility for screen reader users is lacking. The ability to use the variety of check box items differs and sometimes it reads out the questions and other times it doesn't. Proper labelling and complying to WCAG standards shouldn't be that difficult to fix and I wonder where this is in your development roadmap
As many others have stated, keyboard-only and screen reader users have insufficient access. To add to some of the accessibility errors: the forms have incorrect field labeling (https://www.w3.org/WAI/tutorials/forms/labels/), lack of grouping for related form controls (https://www.w3.org/WAI/tutorials/forms/grouping/), lack of feedback for screen reader users after form submission. It would be great if all errors were listed at the top (https://www.w3.org/WAI/tutorials/forms/notifications/).
I second these requests – we'd love to use Tally in our B2G products, however accessibility is insufficient.
Thanks for flagging this, Jonas — we appreciate you bringing up the accessibility concern. We'll take your suggestion into account. 🙏
We want to use tally for government websites, but unfortunately the forms are not complying with accessibility standards.
Agreed, there are some big inconsistencies in accessibility that need to be addressed before we could recommend this to partners. Some of it is very basic basic stuff (broken labels associations for some elements like datepicker, lack of form HTML element, incorrect focus management for error handling) and some is more advanced but needs to work (dropdown component doesn't read selected element on screen readers).
Hi Niamh Kelly, this is possible via the `::` block settings button of the Image block. Let me know if I can help further.
I was also trying to navigate with keyboard using tab, but for multiple choice enumerated with alphabet letter A, B, C or numbers 1, 2, 3, I expected to just work when typing the corresponding letter or number, as in competitor Type Form. However it doesn't, you still have to navigate with up/down and press Space to select (Enter will try to Submit which is general won't work mid-form since most fields are generally required).
Accessibility isn't aweful at all, but some more complex inputs, like the mentioned select, but also the datepicker, are not accessible at all. This is a must feature for such a otherwise fantastic product. Not being able to fill out a form is one of the most annoying things for people.
Update: big accessibility improvements are live 🎉 Thank you all for the detailed, thoughtful feedback on this thread. It directly shaped the work, and we've just shipped a significant round of accessibility improvements to forms in respond mode: - Selects and dropdowns are now fully keyboard operable (open, arrow-key navigation, type-ahead) and announce their selected value to screen readers - Checkboxes and other option fields are now properly grouped with fieldset/legend - Consistent, correct labelling across inputs so screen readers reliably announce the question - The form is now wrapped in a proper form element - On a failed submit, focus moves to the first field with an error, and validation errors are announced to screen readers - Screen reader feedback after submission - The date picker, time picker, and international phone country picker are now keyboard and screen reader accessible We take accessibility seriously and we're committed to continuing to improve it. If you run into anything else while testing, please keep it coming, it genuinely helps. Thank you again for pushing us on this. 🙏