Enhance accessibility of the Blazor Input components by adding aria-invalid

[TheCakeMonster]

This might arguably be considered a bug, rather than a feature request, as a site built with Blazor is not correctly accessibility-enabled when built with the standard components. However, I'm listing this as a feature request for now, as maybe there are scenarios where accessibility is not a legal requirement.

The issue is that the InputText, InputDate, InputTextArea, InputNumber and InputSelect are not truly accessibility compliant at the moment, although they are very close. They would achieve better compliance if they emitted the aria-invalid attribute as part of the rendered HTML output.

aria-invalid is used by screen readers to identify to people with limited visual acuity that a field is not valid and needs to be changed.

The logic to achieve this is already present, because the controls already add CSS class modifiers to the <input> element based on their validity, so I think extending the base component to additionally emit area-invalid should be a relatively easy change.

I can't see an easy way for a developer to modify this from outside of the component - additional attributes can't be used to achieve this, for example, as the attribute should only be output when the control is not valid.

[javiercn]

@TheCakeMonster Thanks for contacting us.

You could achieve this yourself today with something like this:

public class AccessibleInputText : InputText
{
    public override Task SetParametersAsync(ParameterView parameters)
    {
        base.SetParametersAsync(parameters);
        if(EditContext.GetValidationMessages(FieldIdentifier).Any())
        {
            AdditionalAttributes = AdditionalAttributes ?? new Dictionary<string, object>();
            AdditionalAttributes["aria-invalid"] = true;
        }
    }
}

@SteveSandersonMS I believe what I suggested would work, is that not the case?

@danroth27 @SteveSandersonMS In case my suggestion is valid, do you have any concern about putting this in the box? I think this would be a reasonable up for grabs.

[mkArtakMSFT]

@danroth27 this aligns well with our Accessibility enhancements. Should we actually make these components part of the framework, or should we simply provide docs on how to do this?

[SteveSandersonMS]

It's a good suggestion. I think we should make this a built-in feature of the Input components. Specifically, the InputComponentBase base class would have a protected property called something like ValidationARIAAttributes that subclasses (such as InputText) can emit into their output using @attributes=@ValidationARIAAttributes.

[javiercn]

@SteveSandersonMS That sounds good. I think this one is also a good up-for-grabs or a good starter feature. It's small, well scoped and we have a clear design for it. (The one you suggested).

My recommendation is we mark it as up for grabs, and if we get to it before anyone else does, we simply implement it.

The design would be what you suggested.

InputComponentBase would have ValidationARIAAtributes that would be applied by the base component and derived components would simply do buider.AddAttributes(<<index>>,@ValidationARIAAtributes)

Do we need to consider what happens if a user explicitly sets one of these attributes in their markup?
(I'm not super familiar with the aria-* attributes, I know there are a bunch that make sense to apply all the time and others that only make sense in certain cases, I guess if we decide to do this we would look at the list of attributes, decide which ones to support in the components and tell users to not use those in their markup, or to let what the user did win)

[SteveSandersonMS]

Wrong Steve in the mention I think!

Do we need to consider what happens if a user explicitly sets one of these attributes in their markup?

Our @attributes feature already supports precedence. We'd let developer-supplied values override the built-in ones.

My recommendation is we mark it as up for grabs

I've nothing against it being up for grabs, but if someone does choose to contribute here, then either (a) they will need to do something really minimal, such as supporting aria-invalid only, or (b) we will have to get deeply involved in design, because it's not clear there's any trivial way that things like validation metadata can surface in the form of aria-required and similar. I suspect that's not something that could really be done in a completely automated way, at least not without being tied to a specific validation framework.

[javiercn]

@SteveSandersonMS I corrected the Steve. Seems like you got overriden by a more powerful one 😃. You are right, aria is definitely more complicated than it looks like, maybe we can identify the subset we care about that wouldn't be controversial.

In any case, I'm fine if we do this, just thinking of opportunities for contribution.

[ULSTechology]

public class AccessibleInputText : InputText
{
    public override Task SetParametersAsync(ParameterView parameters)
    {
        base.SetParametersAsync(parameters);
        if(EditContext.GetValidationMessages(FieldIdentifier).Any())
        {
            AdditionalAttributes = AdditionalAttributes ?? new Dictionary<string, object>();
            AdditionalAttributes["aria-invalid"] = true;
        }
    }

AdditionalAttributes is exposed as a read-only dictionary, so adding arbitrary items to it like this doesn't appear to be supported. However, this code gave me the clue I needed - create a new dictionary, add the existing members from AdditionalAttributes, set the new attribute, and then assign the new dictionary back to AdditionalAttributes. That works; accessibility is indeed achieved this way (at least for the aria-invalid attribute, which seems to be the most important in this particular regard.)

aria-required can easily be added by the developer in the razor markup of their edit form, so that seems fair enough to me.

        public override async Task SetParametersAsync(ParameterView parameters)
        {
            Dictionary<string, object> newAdditionalAttributes;

            await base.SetParametersAsync(parameters);
            if (EditContext.GetValidationMessages(FieldIdentifier).Any())
            {
                // Copy the existing attributes to the new, writeable dictionary
                newAdditionalAttributes = new Dictionary<string, object>();
                if (AdditionalAttributes != null)
                {
                    foreach (KeyValuePair<string, object> attribute in AdditionalAttributes)
                    {
                        newAdditionalAttributes.Add(attribute.Key, attribute.Value);
                    }
                }

                // Set the invalid attribute we were here to manipulate
                newAdditionalAttributes["aria-invalid"] = true;

                // Assign the new list of attributes back to the underlying property
                AdditionalAttributes = newAdditionalAttributes;
            }
        }