Due to certain factors and some realisations on my part, I have not released a new Blazor Ramp component for a few weeks. I had planned to start releasing input components a couple of weeks ago but needed to get other things in place first.

What prompted me to write this post was coincidentally a post made by the author of Blazorise, in which he mentioned both accessibility and inputs. Given this topic is fresh in my mind, I thought I would share some accessibility issues surrounding inputs ahead of a release.

Please note I have not looked at the Blazorise inputs for at least two years, so I have no idea what improvements have or have not been made alluded to by the author. This post is solely about what I considered when making my own text input component, which is pending release.

For the impatient - as I needed something for discussion a few weeks ago on another forum, I put a preview of the input on my test site, still accessible via the direct link: https://blazorramp.uk/Experimental

A quick quiz

Old school forms and validation: no JavaScript, no ARIA, user fills in form fields, posts data to the server, server checks the fields and if invalid writes a summary stating which fields are invalid and why, along with how to fix them. Negating, say, the need to set focus to the validation summary area, you would likely pass a WCAG audit, assuming the messages are clear and well written.

This is Blazor, so most developers will need to make choices about where, when, and how validation occurs. Most developers I know would choose between using the default Blazor text input with onchange, so field validation is performed when focus is lost, or oninput, so field level validation occurs after each keystroke. In tandem with this, or separately, you may then validate or re-validate when the user presses the submit button, assuming it is not disabled. Some developers disable the submit button until all fields are valid.

To reiterate: the old school way works perfectly well. You do not need ARIA, and there is no WCAG requirement to perform field level validation. So why do we do it?

I have no idea, but over the years we moved towards field level validation with instant feedback for the user. Whether this is a better experience I cannot say with certainty - I am not a UI expert, I personally like it, but that is for you to decide.

This post would be over now if we stuck with old school, so let us continue down the field validation path with instant or near-instant feedback prior to form submission.

ARIA and field level validation

To do this we are going to need some ARIA attributes, namely aria-invalid to let assistive technology users know when a field is invalid, and most likely aria-describedby to link hint text and error messages to the input. Many developers also use some form of live region, perhaps by giving the element that houses the error message a role of alert. ARIA live regions, simplified, are regions monitored by assistive technology which communicate changes in content back to the user ( I would also steer clear of aria-errormessage, another post).

When I mention linking via aria-describedby, it is literally that. On the input control you add the aria-describedby attribute and give it the id or ids of one or more elements where the content lives. When focus is placed on the input, a screen reader will announce the accessible name of the input - hopefully its visible label rather than an aria-label, as a visible label benefits both sighted users and voice control softwared users. The screen reader will then read the content from the linked elements.

This is useful because you can, for example, include the id of hint text so that when the user first enters the field they are advised of what is expected. On error, you can additionally include the id of the element housing the error message, so on focus the user hears both. I sometimes remove the id of the hint text when there is an error, if the error message alone is sufficient, as there is only so much noise a screen reader user can reasonably handle. Removing the id does not remove the content - it remains on the page for all users to see.

Required fields

First stumbling block: required fields. You can indicate a field is required with text in the label, text in the hint, or an asterisk. If using an asterisk, mention at the start of the form that fields marked with an asterisk are required.

Do not place the asterisk directly next to the label text, as screen reader users will hear things like "First Name star", "Surname star" and so on. Instead, wrap it in a span with the aria-hidden attribute so it is not announced. The screen reader user will know the field is required because you will have also added the aria-required attribute, and the screen reader will announce the label name followed by "required."

If you are using text in the label or hint text to indicate the field is required, omit aria-required, otherwise the user will hear things like "First Name required, required."

One more thing before I move on: if you are thinking CSS can help here via a pseudo element with content, be aware that screen readers can read this, so you would need to exclude the asterisk using the alt content syntax.

Validation in practice

Now that hurdle is out of the way, let us consider a simple validation scenario. The user must enter between three and fifteen characters, letters only in a required field. Simple enough. Let us use field level validation with oninput.

The user types "P", validation runs, a message appears, aria-invalid is set to true, the id of the error element is added to aria-describedby, the element is revealed, and because that element uses role="alert" the screen reader announces the error. All good?

The user then types "a", "u", "l" - now valid, aria-invalid is removed, the message disappears. The user then types a space - invalid again, aria-invalid is set back to true, the message reappears in the live region, and the screen reader announces the error again. Every time the field transitions from valid to invalid, the screen reader announces the error. Some auditors will raise this as a WCAG violation on the grounds that the user is being interrupted whilst they are trying to type.

Let us try onchange instead. The user types "Paul" followed by a space, then presses Tab and lands on the next field. Validation runs on the previous field, a message is displayed, aria-invalid is set. But what about the live region? Suppose the first field was First Name and the next is Surname. The screen reader announces "Surname" as it is now focused on that input, but then also reads the error message from the previous field, followed by the information for the current one. The order may vary, but regardless of how the messages are worded, the experience can be genuinely confusing.

What about navigating back to the previous field? The user presses Shift+Tab, lands on the field, and will hear something like "First Name, required, invalid, [error message], [hint message]." This part actually works reasonably well - it is the use of aria live regions that is most likely to trip you or the user up. Use them carefully, test thoroughly, and only reach for them when genuinely necessary.

The submit button

Where possible, leave the submit button enabled. Run validation there - in tandem with field level validation if you like - and if the form is invalid, use a live region to inform the user that there are errors and invite them to review the summary. That is the appropriate moment to reach for an aria live region announcement, with focus placed on the error summary.

None of the above would be caught by any automated accessibility tool. You would likely pass automated testing and then fail an audit conducted by a human, whilst also providing a poor experience for screen reader users.

The question you are probably now asking is: how do you inform the screen reader user of an error when moving between fields, without using an aria live region and its associated problems? Honestly, I do not have a definitive answer. What I do know is how to avoid annoying the user or a WCAG auditor.

Sometimes, myself included, we try too hard without the necessary understanding all the issues and end up creating problems for the very users we are trying to help. Concentrate first on providing a good validation summary experience, then consider field level validation. It also does not have to be one size fits all - with my own input component, each instance can be configured individually: use oninput for this one, onchange for that one, omit the hint text when there is an error on another, and so on.

I also have a preferred alternative approach to handling field level errors, which I will discuss when I release the input component. A preview can be seen on the experimental page linked above.

Autocomplete - do not overlook it

One thing worth flagging before the end: autocomplete. Under WCAG autocomplete is a requirement for fields collecting certain types of personal data. Not implementing it is a WCAG failure, and it is a commonly missed one. In my own input component I am not adding a parameter for autocomplete, for various reasons, as you can simply use attribute splatting and add it yourself where needed - but you do need to be aware of when it is required.

Why the delay?

I knew I needed to improve my documentation and provide several pages for each component. To do that I needed to build a new component first - what I call a NavGroup component, also pending release - which allows you to create a nested navigation structure for side menus in an accessible way. Multiple documentation pages also means more content to write, and so on.

One final important point: in many cases, having an accessible component is not enough on its own. You will also need guidance on how to use it correctly, which is why I am taking a separate documentation pages approach. There are so many nuances in accessibility that I cannot simply hand you the component - I need to provide guidance alongside it, and there are only so many hours in the day.

Sorry folks, I am just that human guy, Paul, not Claude or Gemini.

Hi, I'm new to blazor and I'm currently on the account authentication phase of my project, the problem I keep getting for weeks now is the non restful login/logout accounts of my blazor server. The only solution I could think of is to make a condition based on the user's url:

    @* Apply the dynamic render mode here *@
    <HeadOutlet @rendermode="CurrentRenderMode" />
</head>
<body>
    @* Apply the dynamic render mode here *@
    <Routes @rendermode="CurrentRenderMode" />

    private IComponentRenderMode? CurrentRenderMode
    {
        get
        {
            // Get the current path (e.g., "login", "account/register", or "")
            var path = NavigationManager.ToBaseRelativePath(NavigationManager.Uri).ToLower();

            // If the user is on the Login page or any Account page, render STATICALLY (null)
            if (path.StartsWith("account"))
            {
                return null;
            }

            // For all other pages (Home, Admin, etc.), render INTERACTIVELY so MudBlazor works
            return InteractiveServer;
        }
    }

But the problem with this is while there's no SignalR connection on a static SSR, component's such as burger menu collapse, toggle theme, etc, won't work since there's no active connection to interact, only if I switch to an InteractiveServer.

Is this fine? I feel like there's a better approach here. Please excuse my naivity. Thank you!

I'm having some trouble getting a site I created cached by the wayback machine on archive.org. In the cached version, I can see the navbar but the content section is blank. The colors and styling appear correct.

Does anyone have experience addressing this in general or have any specific tips I could follow? I would really appreciate some experienced advice here. I really don't want to re-build something without knowing it will fix the issue.

Thank you so much.

for my app, I'm seeing these browser-console errors logs after each deployment:

Error in mono_download_assets: Error: download
Microsoft.AspNetCore.SignalR.Client.Core.<HASH>.wasm for ...

Other assemblies also faced this error. Fix is simple user has to refresh page to fetch latest resources.

Claude suggested this fix:

1. Reload on noticing error in console in JavaScript. (also uses sessionStorage to prevent reload loop)
2. disable cache for `blazor.boot.json` in program.cs

The fix looks ok for me. But I want to know anyone faced this issue and solved it before?

I'm using Hosted Blazor with InteractiveWebAssembly.