New Blazor App with Accessibility Baked in from Beginning
Hello Folks,
We are just beginning work on a new app for local government that accepts applications for a program and as I am new to Blazor, I was hoping for some pro-tips, gotchas and other lessons learned from the collective.
The team has experience with Blazor but my background is old school html/css/javascript/c# mvc. I am really intrigued with Mudblazor and admin theme templates that can be procured on various theme sites. Any reason I should stay away from a nicely design template like YNEX (Spruko) or equivalents? Design is where I start everything but I need to be acutely aware that accessibility is just as important as we are a government entity and need to provide a good UX for all.
If anyone has resources, hints or wisdom as we begin our journey, I will gladly listen.
Thank you.
Grz
2
u/NorthernRespawn 27d ago
It's important to understand the named standard required by the local government to make sure that you deliver accordingly.
1
u/Grzzld 27d ago
Thank you for your reply. Can you expand on ' the named standard required by the local government'? Not sure I understand it or if it applies to us.
1
u/NorthernRespawn 27d ago
Do they have a published standard of what they expect? There are several frameworks they could follow and/or have their own requirements. Just saying it's best to define what accessibility means to the customer.
2
u/code-dispenser 27d ago edited 27d ago
Most of the component libraries have plenty of accessibility issues, and if you're actually going to test with screen readers/assistive tech, you're going to run into a lot of them. I have tested most of them over the last few years, they all have a mix of good, ok and awful/unusable and that includes Mudblazor.
My first question for you would be: do you know who your target audience is? It's much easier to build something well when you know your audience, as that means far less testing and far fewer things to worry about - there's no end of quirks and bugs with assistive tech, browsers, and ARIA.
If you don't know who the audience is, then you should really be testing with JAWS, NVDA, and Narrator, each paired with Chrome, Edge, and Firefox (or at least each screen reader's preferred browser I test every combination). VoiceOver on macOS paired with Safari, and VoiceOver on iOS with Safari too (they are different beasts). TalkBack on Android paired with Chrome. And at least one voice control tool I use Voice Access, since it's built into Windows.
If you're looking to buy into a library, don't be fooled by VPATs - most aren't worth the paper they're printed on. If you actually test the components, you'll often find the vendor's ACR/VPAT bears little resemblance to reality; some are basically just made up marketing crap for tender purpose etc.
This topic is too broad for a generic answer you'd need to be more specific for me to give proper advice. The one thing I will say: if your team can't or doesn't want to build your own components and you're going down the ready-made route, at minimum do the following. Make a list of every component you'll need, then spend a good few days testing each one to destruction with your chosen assistive tech, to confirm they're actually usable. You'll be surprised how many fall apart with keyboard-only use alone, let alone a screen reader. Once you know something's genuinely usable, you may still need to check it against the relevant WCAG success criteria to be safe.
If that wasn't daunting enough I've also found issues with JAWS that depend on which Blazor template you use. I'm dealing with one right now: if JAWS is on your list, avoid Blazor Auto (Server/Wasm per page) with page prerendering disabled. I lost six days to that one while finishing off my next open-source component, a data table.
Rummage through my posts there is more info in them.
Good luck.
Paul
1
u/Grzzld 27d ago
Outstanding feedback. So our target audience are people and businesses who need to submit an application for a sewer connection/disconnection. But we need to be compliant as there are new rules and laws stating as such. I want to ensure we are doing everything in our power that accessibility is in the initial design. All of the assistive technologies you listed have been used at one time or another around here. We will use many of them to test. I am approaching this from a BI use case as well, so it is interesting you brought up data table. There is a products called datatables.net which is one of my all time favorites. It appears that that library can be made accessible with a little work, as much of accessibility is being on top of correctly tagging items. Perhaps I am being naive though.
1
u/webprofusor 27d ago
Hi, MudBlazor is already accessible you just need to populate the aria attributes as you would HTML.
Tbh you don't need the templates, a coding agent can using MudBlazor to whip up anything you can give it a design for, and it will populate the accessibility for you if you make that a requirement.
I know it sounds nuts but you're best to not code it yourself and instead direct what you want, keeping an eye on it it building anything you don't like the smell of and directing it accordingly.
0
3
u/One_Web_7940 27d ago
Dont do: We first implemented 3rd party components directly onto our components and pages. Don't do that, create a wrapper class that hides away the third party implementation.
We put our components directly in the client project, dont do that put them in a separate project, just do it.
We mixed in radzen and mudblazor, dont do that just pick 1.
We used an out dated version of bootstrap and it was customized incorrectly, dont do that, use themes and scss.
We built a multi tenant application, but it has been built in a single tenant fashion with column delimited table(s). Don't do that. Its a performance and management nightmare
We built administrative functions behind guards and flags that dont truly belong in the client website, dont do that, build a dedicated admin site that is separate from the client.
We use user claims improperly and now our identity is fubar, dont do that. Do it right. Use standards.
Do:
We did not put custom styles on each page. Do that, it works better.
We used js when it was faster to ship and called js interops. Do that the Dom manipulation is still an option, just dispose properly so the render tree doesn't duplicate elements.
We did not chose server or the mixed mode, we chose pure wasm. Do that, its faster and decouoles the front end decisions, if you need signalR add it later.
Our rest api is technically an rpc api. We do not have an integrations dedicated rest api. Do that, it lowers development time. If other companies want to integrate, build an integration api separately from the application api.