-
Notifications
You must be signed in to change notification settings - Fork 0
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
Improve accessibility of Umbraco Forms #1038
Comments
Tried incorperating this with @rickdoesburg in our custom views, but it was a bit of an if/else fest, not very neat and not upgrade friendly :-). |
Thanks for these suggestions. I've been having a look this morning to see what we can reasonably apply. 1, 4 and 5 seems straightforward. 3 seems to be a bit tricky to be able to sensibly wrangle the generalised mark-up rendering to support this. For 2 I'm looking at adding a new property on the definition of a Then we can amend the mark-up to something like this:
I'm aware that this could be presentationally breaking (e.g. if someone has used and styled the default theme, but their CSS doesn't target the new elements). But currently considering that would be OK to do so long as we make it clear in the release notes and blog post that accompany the next minor release. Please let me know if you have any further thoughts. |
Thanks for the response, Andy. Changing the implementation of point 2 would already be a great improvement, and I think your example markup is good. The markup of the single checkbox is indeed just fine, and they are correctly 'linked,' so you could just leave it as it is. My example about it being used as a 'consent' option wasn't correct because users could simply use the 'consent' field, which does have the extra label. It's great to hear that my suggestions are being considered for implementation! |
These updates as discussed above will be part of the next releases. We've taken a call that to avoid the potential presentationally breaking change mentioned, that for point 2 - the use of fieldset/legend - it will be necessary to switch on the changed rendering in configuration. That way anyone relying on existing CSS won't experience any change when they upgrade, but anyone still can opt into the this more semantic rendering of radio and check box lists if they want to. For the next major, we'll remove the configuration and make the newer and improved mark-up the default. The following will be added to the documentation and shared theme on release, but just to also include here, the setting will be:
We'll then use that to populate a field on the A property
|
I was tasked with styling some forms in an Umbraco website we're building, and I've noticed a couple of accessibility issues. We were able to work around some of the issues, but it would be better to have them fixed in Umbraco Forms itself.
span
(@Html.ValidationMessage
) that's present on page load doesn't notify screen readers that the contents have been updated after an unsuccessful submit. The validation-element should containrole="alert"
. WCAG.3.3.1. Fields should also get anaria-invalid
attribute if they're invalid after submitting.CheckBoxList
andRadioButtonList
could be improved. Currently these elements are rendered using the same loop as the other fields. Resulting in:While according to w3 it should be:
Radio button groups should always be grouped using
<fieldset>
. The legend for a group of controls can also highlight common attributes of all controls, for example, to advise that all fields in the group are required.required
oraria-required
should be added to indicate required fields.aria-describedby
. See example 2.This item has been added to our backlog AB#30809
The text was updated successfully, but these errors were encountered: