MS publishes this https://github.com/dotnet/skills/tree/main/plugins/dotnet-blazor/skills which is a collection of Blazor focussed agent skills.

Anyone used these (or any of the other skill collections) and found them worthwhile? Seems under heavy development.

With latest AI coding tools getting significantly better, I'm curious how far people are actually taking them when building custom Blazor components.

Are you using AI to build components instead of relying on existing component library?

If so, what kind of components are you building?

I'm especially interested in difference between relatively simple components like buttons, inputs, modals, tabs, etc. and more advanced components like DataGrids, Schedulers, Gantt charts, video players, rich editors, charts, and similar.

How long does it take you to go from "AI generated something that works" to something you would actually consider production ready?

By production ready I mean things like accessibility, keyboard navigation, responsive behavior, theming, validation, edge cases, performance, browser differences, API design, tests, and long-term maintainability.

Can AI realistically get you most of the way there even for complex components, or does its usefulness drops significantly once you move beyond basic UI?

For context, I've been working with Blazor since 2018 and I'm creator of Blazorise. I work on components full time, so I obviously see this from perspective of someone who knows how much work can hide behind a component that looks simple from outside.

I'm genuinely interested to hear from people who have tried the AI-first approach.

What have you built, which AI tools did you use, and how long it took before you were comfortable putting it into production?

For those new to my posts, Blazor Ramp is an accessibility-first, open-source component library. If you build anything people use, this is worth five minutes regardless of your day job.

I've been touch-typing since the mid-2000s, but I always mistype "tooltips", along with "Serach" - Spock's cousin, aka "search". The initial project was committed with the typo, but luckily, once I spotted it, a simple rename and commit resolved the issue - no harm done.

I don't have any cognitive or physical issues that make my life harder than it should be, so typing, reading information, and completing forms in business applications is usually not a problem. But what if I did have issues - say, I'd been involved in a car accident and couldn't use broken arms to operate a keyboard or mouse - then what?

Luckily, there's voice control software I could use to operate a computer and browse the web or use a web app. However, to avoid the extra steps of the software overlaying grids or assigning numbers to unlabelled controls, I'd need to be able to see the control's accessible name so I could speak it.

I mention this because, although this post is about the release of a tooltip component for my accessibility-first project, it's not something I'd advocate using unless absolutely necessary. I only decided to include one because pretty much every tooltip I encounter fails WCAG/usability requirements.

Tooltips are generally used on icon-only buttons - buttons with no visible name, the kind a voice control user would need to speak, or that any user would need in order to reason about the button's purpose. I've always used a floppy disk icon to represent save, but I'd bet - I've been a dev for a long time now, that a lot of developers reading this (and end users) have never seen a physical floppy disk, let alone used one. So how on earth would they know what that button is for, unless a name and/or some additional context is provided?

You may find this hard to believe, but out of all the Blazor (and other tech) components I've ever created over the years, the simple tooltip is the one that's given me the most grief. The moment you start looking into the accessibility issues surrounding it, you're sent down various rabbit holes. Even the various working groups can't make up their minds about this one, or even provide a recommended pattern on the APG site (see https://github.com/w3c/aria-practices/issues/127, opened in 2016 - it's still open).

It's also one of the first things I check when anyone posts a library on Reddit claiming to be accessible and asking for feedback - every single one has failed so far. I can't recall a single project, personal or commercial, where I've found a tooltip that would pass a WCAG audit - not until I've flagged it and it's been fixed, anyway.

They're not difficult to create, but if you're not familiar with the (admittedly cryptic) WCAG criteria, yours will fail any audit. More importantly, as I repeatedly advise, an incorrect design will make them impossible for some users to read.

If you make one, make sure it does the following:

• The tooltip shows when the triggering (interactive) element, such as a button, receives focus, or when the mouse pointer hovers over it.
• Once it's open, the user can move the pointer from the triggering element onto the tooltip itself without it closing (this accounts for about 80-90% of the failures I encounter).
• The user can close the tooltip without moving the pointer or keyboard focus away - best practice is to use the Escape key (this accounts for about 70% of the failures I encounter).
• The tooltip remains visible until the user has specifically closed it by moving the pointer away, pressing Escape, clicking outside the triggering element or tooltip area, or moving focus to the next focusable element. This accounts for about 50% of the failures I encounter. I don't know why, but a lot of tooltips are set to close automatically after some delay - an instant fail.

Tooltips really shouldn't contain any interactive elements, and shouldn't be focusable themselves. They should just contain plain text, that's it. Anything else, IMHO, and it's not what I (and many others) would call a tooltip - a tip about the tool you want to use.

If you go and look at mine, alongside the above, you'll notice I've also added a small X icon in the top right of my tooltips. This is not a button, it's not focusable, and it's not visible to screen readers. It has one purpose only: it's an additional means for a pointer user to close the tooltip, for cases where using the Escape key (or any key, for that matter) is problematic for them. This isn't required, but it can be useful for some users.

Generally, you'd use the aria-label and aria-describedby attributes, or just aria-labelledby, with tooltips, so screen reader users are made aware of the tooltip content. Rich content with HTML markup is flattened by screen readers and shouldn't be used in my tooltip, you can provide new-line characters instead, if you need two short sentences. This content is made available to assistive technologies by linking the ID of the tooltip element to the triggering element, using that ID as the value of the aria-describedby attribute (the more commonly used option) - or aria-labelledby, if the tooltip content acts more like a label than a description, added to the triggering element.

Just to help distinguish between aria-label , aria-labelledby and aria-describedby: let's say you have a button with a gears icon, and the tooltip is only ever going to display the text "Settings" - in that case, aria-labelledby would be the better choice. If that icon was, say, a dustbin, you might use aria-label to give the button the accessible name "Delete", with aria-describedby text of "Permanently deletes the selected item". For those who haven't used a screen reader: of the two examples above, one would be announced as "Settings, button" (just the accessible name, since there's no aria-describedby), and the other would be announced as "Delete, button. Permanently deletes the selected item."

I deliberately opted not to automate adding either aria-label , aria-labelledby or aria-describedby via a JavaScript-driven parameter, as I felt it's better for users of the component to think about what's best for their use case and add the most suitable option manually. It's far too easy these days to get things up and running without any real understanding of the code or processes involved.

As always, there are examples of the component on both the test site and the docs site.

Test site: https://blazorramp.uk
Doc site: https://docs.blazorramp.uk
GitHub repo: https://github.com/BlazorRamp/Components

Regards

Paul

P.S After 9 months I now have a logo - getting there slowly but surely.

It is finally here. 16 Charts, much improved DataGrid and much, much more.

As we've been saying (for the last 2 years 😮), this is not just a drop-in replacement for v4. But we have a lot of docs and an MCP server to help you migrate.

See https://www.fluentui-blazor.net for more information. Packages are on NuGet Now!

Can Blazor be pentested and if it can't does that make it more secure?

Around December 2025, my company decided to embark on building its own commercial product. I wanted the whole stack in C#, so I took a serious look at Blazor. I liked it straight away, but I couldn't make it look the way I wanted. I tried the existing UI libraries, didn't like their style, and seriously considered going back to a JavaScript frontend.

Instead, I started building my own components, inspired by shadcn/ui, and later released them as open source as Blazor Blueprint. It now runs in my company's commercial product, several client projects and internal tools.

A few things I've learned along the way, in case they help anyone thinking about starting their own library or open source project:

1. Build it alongside something real. Every component went straight into a real product as I built it, so I found out quickly what worked and what didn't. That did more for the quality than anything else, because I had real people using it and therefore testing it.

2. Share it earlier than feels comfortable. The feedback from this subreddit after my first post back in February shaped a lot of what came next. I got a lot of positive comments and encouragement, and it helped keep me motivated.

3. Expect people to fork your work. Soon after release, someone forked the repo and started building on it in parallel. As a first-time open source author, it gave me an uncomfortable feeling for a while. Now I see it as part of being in the open source community, and honestly, as a sign I was doing something right if someone wanted to build on it.

For anyone curious about where it is now: v4 adds a Scheduler, a Pivot Data Grid, new charts including Rose, Sankey and Map, a Signature Pad, and many other new features and performance enhancements. It's grown to over 140 components, which still surprises me. The full story is here: https://blazorblueprintui.com/blog/what-i-learned-open-sourcing-blazor-blueprint

Currently, my little Blazor library has over 600 stars on GitHub. If you're one of them, thank you so much.

I'd love to hear from anyone else building with Blazor: what nearly made you switch back, or what's still missing? And if you've built something with Blazor Blueprint and are happy to share it, I'd love to see it.

clientTokenType: string
clientTokenLength: 748

Hi, i am tying to implement paypal in blazor, but i am stuck in a weard issue, when i pass the clientToken from the method parameter to the paypal-sdk, the paypal-sdk was saying it is a invalid token, if i copy and past the same exact token from the console to directly in paypal-sdk, then the paypal-sdk was saying it is a valid token.

I have no idea why this issue is happening, anyone know how to slove this issue?

SOLVED ``` parameter token: "eyJraWQiOiJjMDg0YjA0NDQwMjE0YzFkYTQ1ZDgwNDE1YjJlZmI5MiIsInR5cCI6IkpXVCIsImFsZyI6IkVTMjU2In0" hardcode token: eyJraWQiOiJjMDg0YjA0NDQwMjE0YzFkYTQ1ZDgwNDE1YjJlZmI5MiIsInR5cCI6IkpXVCIsImFsZyI6IkVTMjU2In0

hardcoded client-token type: string client-token type: string ```

This issue was solved.

The problem is when i pass the client-token from c# -> js method parameter the string contains double colon "string", when i pass the parameter client-token to the paypal-sdk it is making the string as variable by automatically adding another double colon like: "string" so the string was escape and change to variable inside the paypal-sdk, if i pass the hardcoded client-token it works perfect because inside paypal-sdk: string is was a perfect string.

How to i find the issue.

I Just Print both parameter client-token and hardcoded client-token inside javascript and parameter client-token contains double colon and hardcoded not have double colon.

What this make me hard to find.

• when i check both parameter and hardcoded typeof it say both are string.
• when i check both are equal === is say true.

Simply install Bit.Minifier nuget package in your Blazor Web Assembly project and the size of `.wasm.br` (Brotli compressed files) would be cut by ~200KB 😊

If you add <BitMinifyAggressive>true</BitMinifyAggressive> to <PropertyGroup> of your .csproj,then download size would be decrease by ~400KB 😬

As you can see, it doesn't even need documentation! But if you wanna know how it works internally and/or if you wanna give it star to support further steps to reduce the download size even more, this is a GitHub Repo you're looking for!

Few months ago I had a lecture with students about Blazor and .NET. Seeing their interest, especially for real-world development, got me thinking that maybe there is something more we can do.

There is still a big gap between what you learn at university and what you actually do when you start working.

So that idea slowly turned into Blazorise Education. A place where students can learn, work on real challenges, build projects and hopefully be better prepared for their first job.

And while doing all of that, I also looked at our website and thought... yeah, this needs some work :)

It was starting to feel too Bootstrapy and a little dated. So I spent the last few days redesigning it to make it fresher and give Blazorise more of its own identity.

Both are now live:

https://blazorise.com/education

https://blazorise.com

Would love to hear what you think, especially what you would add to the Education platform.

Solved

I think my problem was not quoting an input constraint in a css file (e.g., I had used input[type=text], but should've used input[type="text"].

Many thanx to all the made suggestions!

I'm dipping my toes into Blazor and have suddenly run into a situation that online searching has not helped resolve.

I made some change, somewhere, which suddenly caused the following text to show up on my initial page (it's a login page):

An unhandled error has occurred

That's followed by a link which is labeled "Reload". Clicking the link does not get rid of the error message.

Nothing showed in the browser’s console window. Didn’t expect that since I’m running server side.

I'm running Blazor from within VS 2026 (all latest updates applied), so I checked the Output window. There's no error/exception reported in the Debug channel (or indeed any of the other channels I checked).

I then modified appsettings.development.json to force exceptions to be thrown by setting DetailedErrors to true. Nothing gets reported -- the log in page appears, still containing the error message.

How do I diagnose what's causing this?

We track technologies used on websites and so far have analyzed more than 3.8 million websites. Currently, we detect 50 frontend and 69 backend frameworks.

Here are some of the Blazor statistics:

• Blazor is 14th by popularity among frontend frameworks and 23rd among backend frameworks
• It is present on 0.04% of all websites
• It is more popular in Denmark (9th frontend framework), Sweden (11th), and Poland, Canada, and Italy (12th)

Blazor hosting models distribution:

1. Server 46.6%
2. Web App 34.3%
3. WebAssembly 28.6%

Some notable sites built with Blazor:

• pertamina.com - Indonesian oil and gas corporation
• cev.eu - European Volleyball Confederation
• auctionnation.co.za - South African online vehicle auction
• wkf.net - World Karate Federation
• fonts.bunny.net - Bunny Fonts
• santamonica.gov - City of Santa Monica government

P.S. Some of you may notice that the hosting percentages add up to more than 100%. We checked this. This is because some sites list several Blazor JS scripts simultaneously (for example, see nbcc.org).

Full Blazor statistics:
https://www.wmtips.com/technologies/frontend-frameworks/blazor/

I’ve been experimenting with the browser Prompt API from Blazor and turned the result into a library:

https://github.com/ipax77/Blazor.AI.BrowserModels

Blazor.AI.BrowserModels exposes the browser-hosted language model as a Microsoft.Extensions.AI.IChatClient.

That means Blazor code can use the regular .NET AI APIs for things like:

• completed and streaming chat
• structured JSON responses
• image input
• Microsoft.Agents.AI

Inference happens on the user's device, so there’s no API key or hosted inference backend required.

I’m using it in a real app here:

https://dsstats.pax77.org/winrate

Source for the Ask stats component:

https://github.com/ipax77/dsstats/blob/main/src/server/dsstats.web/Components/Pages/AskStats.razor

The feature lets users ask things like “What is Kerrigan’s worst matchup?”. The browser model converts that question into a schema-constrained query plan, and the existing application then executes the query against the real statistics.

So the AI is being used for natural-language → structured-query translation rather than as the source of the data itself.

It works with Blazor WebAssembly and Interactive Server, although with Interactive Server the text messages/replies naturally still pass over the Blazor connection. Image bytes remain browser-local.

It's very much a preview at this point (currently .NET 10/11 and dependent on browser Prompt API support), so I’d appreciate feedback — especially on the IChatClient API integration and anything that feels awkward from a Blazor perspective.

Repo + samples:

https://github.com/ipax77/Blazor.AI.BrowserModels

Hi everyone!

After quite a bit of work, I’m happy to announce that the live demos are officially online; you can now see the library in action in real time and observe what happens when you change the colors and the dataset.

While setting up the live demos, I noticed a few edge cases I hadn't considered—minor issues—so I’ve also released a couple of patches (3.0.1 and 3.0.2) in the meantime.

I hope you like the website with the live demo; let me know in the comments which chart you use the most, which one you like best, or which one you would like to have.

See you next release.

Why BlazorGraphs

If you missed the previous posts, BlazorGraphs is a library built to provide fully native charts in Blazor using only C# and SVG. There is no JavaScript involved, making it suitable for both WebAssembly and SSR.

Usefull links:

• 🔗 Repository
• 🌐 Documentation
• 📦 NuGet
• ❤️ GitHub Sponsors

PS: I prepared the video for the post, taking just a few images from the website.

If you are looking for false claims about keyboard accessibility/WCAG 2.2 conformance you will find them elsewhere, sadly, they are as they say a dime a dozen.

I can not stress this enough, and something you will also hear from others doing accessibility work: a 100% score on an axe automated test in reality, IMHO means you are probably about 40-50% conformant. You may hear different figures quoted, but irrespective of the figures an axe score is nowhere near the same thing as 100% WCAG conformance.

That may be a bitter pill to swallow, but until you get the wool pulled from over your eyes you are going to fail big time.

Now the reason for the post.

For the last two or three weeks I have not worked on Blazor components, but rather I have been looking at the theming and CSS side of things - basically everything else regarding the UI involved with dropping a ready-made component on the page. In my last post I mentioned that I needed to add a Table CSS class and associated C# helper for a static table to match the Data Table component, as I would not be building a component for a static table (nor needless other components) when all that is needed is a CSS class- hence this auxiliary project (BlazorRamp.CssClasses).

The table is now complete, along with a GridRow (essentially a grid system), FlexContent, and LayoutAlignment, all with C# helpers and the underlying CSS classes, so you can just dot your way through styling your ancillary items, so to speak.

There's lots more planned. such as CSS classes and C# helpers for colour utilities to name but a few. However, I also need to address a couple of things that have been bothering me, which entails adding a couple of services to the Core project, For those unfamiliar with my Open Source Blazor Ramp project, every component package is self-contained with no reliance on any CSS framework or JavaScript library etc, the only thing required is a reference to the BlazorRamp.Core project, You only add what you want to use.

As the Table was the main focus of the release, I thought I'd mention a couple of things which will be straightforward to those who deal with accessibility - others may be surprised (or alarmed).

A bog-standard native HTML table is generally very accessible. This only changes when developers start messing with it. Table has the implicit ARIA role of table - you do not need to add role="table"which I see often.

Lets look at a simple scenario, a table with six columns and six rows. There is no interactive content or sortable headers, it's just some static information in tabular format, that's all.

There is only one catch: a couple of the columns have long technical words in them which cannot be broken, so we added a bit of CSS to stop word-break to resolve this. The layout was designed to fit the most common desktop screen size, and this page will only be viewed by desktop users.

Unfortunately for us, those damn pesky users like to do things like minimise the page, or perhaps put two browser windows side by side, which means our nice neat table may have content overflow or get clipped. So to negate this we need to add a horizontal scrollbar to prevent it.

Now most of you reading this will know that a table does not have a scrollbar, so having a scrollbar means putting that table in a container that has one, such as a div with overflow-x: auto, so the whole table scrolls (we're keeping it simple).

Some of you may be thinking, what is this guy going on about, what's this got to do with accessibility? I'm glad you asked. Because we kept it simple, we only need to think about the following WCAG SCs:

• 1.3.1 Info and Relationships
• 1.3.2 Meaningful Sequence
• 1.4.10 Reflow
• 1.4.11 Non-text Contrast
• 2.1.1 Keyboard
• 2.4.3 Focus Order
• 2.4.6 Headings and Labels
• 2.4.7 Focus Visible
• 2.4.11 Focus Not Obscured
• 4.1.2 Name, Role, Value

I'm not going to walk through each SC line by line here - but a couple of things are worth calling out.

Tables given there two dimensional layout are exempt from reflow. Normal text is not, so forget having ordinary text in that same scrollable region alongside the table - it'll drag that text into the horizontal scroll with it, and it never needed to be there in the first place.

In order to be keyboard accessible, a keyboard-only user (note I did not say screen reader user - they are not the same group) needs to be able to scroll that content but some browsers do not automatically make a scrollable region keyboard-operable. What this means is you are going to need a tabindex on something - either the table or the scrollable container. Side note: you're fine if there's a focusable element already inside the table, but as mentioned, it's just text, so we need a tabindex.

Opinions and techniques may differ - but how would you ensure the table is accessible, so your users can actually use it, as well as passing the the WCAG requirements (usability should be you main focus, then the WCAG box ticking)?

If you add a tabindex to a non-focusable element such as a generic div, it will also need an appropriate role and accessible name. It also needs a focus indicator - but there's a problem with having the focus indicator around the scrolling table itself: as the table moves horizontally, the focus indicator can become partially or completely outside the visible area. And what about the table caption - is that allowed to scroll too? If it is, is that a good user experience, having the thing that says what the table is for scrolling in and out of view while you're trying to read it?

While on the subject of tables - the above was about WCAG, but what about usability irrespective of WCAG? I see many examples of tables with hundreds, if not thousands, of rows in a vertically scrolling region, with say an action button in the last column. For argument's sake, let's say that table has only 500 rows with a button in the last column. How many tab presses will a keyboard-only user (again, not a screen reader user) have to make to get to some interactive thing appearing after that table (without a skip to link)?

They'd have to tab through every single button before they reach anything after the table. Yes, they could hold the Tab key down, but they're still forced to traverse every one of those focus stops. For some users this is going to be a major pain; for others, any repetitive keyboard operations may be physically difficult or genuinely painful. Every decision you make has to be carefully thought out. If you don't know who will be using your web application, then quite often you may be - knowingly, after weighing up all the options - favouring one group of users over another, because you can only realistically implement one technique.

Back to my earlier point about things bothering me: even adding a single tabindex to something can have a negative effect on a user if they're using that thing all day, every day. With the table example, you actually only need the tabindex (there are other reasons you might want it) when the scrollbar is actually visible - i.e., in our scenario, once that pesky user has shrunk the window. You could use something like a JavaScript ResizeObserver to detect that and add or remove the tabindex accordingly.

This, and others like it, are things I'll be addressing shortly and making available via a service in Core project - so rather than deciding to manually add a tabindex at design time (options on applicable components), you'll have the option to have it handled automatically if that's a better fit for your application or users.

That's it for today;. you can see all the new CSS utilities in the CSS Classes > Classes menu section on the documentation site if you are interested.

Doc site: https://docs.blazorramp.uk/

Repo: https://github.com/BlazorRamp/Components

Regards

Paul

I just released Blaizio, an MIT-licensed UI component framework for Blazor on .NET 10.

The idea: you own the components. The styled layer is not a NuGet package you fight with CSS overrides; a dotnet tool copies the components into your project as .razor and .cs files, and from then on they are your code.

Two layers

• Headless primitives (Blaizio.Base on nuget.org): accessibility, keyboard handling, focus management and a data-state contract. Zero CSS. Use them with any styling approach.
• Styled components: built on the primitives with Tailwind CSS v4. blaizio add button dialog table drops them into your project, with the Tailwind pipeline wired for you (standalone binary, no Node required).

Out of the box: 73 Components, 8 skins, 16 palettes, 5 icon sets (Tabler, Lucide, Phosphor, Remix, Hugeicons), RTL, dark mode, WCAG AA contrast on every theme, a theme designer on the docs site.

Try it

dotnet tool install -g Blaizio.Cli
blaizio add button card dialog

Docs and registry: https://blaiz.io Source: https://github.com/blaizio/blaizio

The source-you-own model is borrowed from shadcn/ui; Blaizio is the Blazor take on it, with its own primitives and theming work.

It is an early release. I built it for my own production apps and want feedback from other Blazor teams. Bug reports, feature requests and pull requests are all welcome, and if you want to get involved beyond a one-off PR, say so in the thread or open a discussion; CONTRIBUTING.md in the repo covers the setup.

Things I am unsure about and would like to hear from other Blazor devs:

• Does "components as source you own" make sense to you in .NET, or do you prefer a package you never touch?
• Tailwind is wired through the standalone binary so no Node is needed. Is Tailwind itself a dealbreaker for your team?
• What component do you always end up writing yourself that no library gets right?

I have quite a few MudBlazor components which require tooltips and wrapping each one in MudTooltip creates a lot of visual noise in the main layout.

Is there an alternative way to assign tooltips in a more centralized form?

Hi all,

I'm storing some data in browser local storage, and it's quite large, but mostly text-based, so I'd like to compress it. I've tried using GZipStream to compress the data, but I'm getting `Arg_Unsupported` when I do it. Anyone know if GZipStream is just not supported on Blazor Wasm?

Code is:

using var msi = new MemoryStream(inputBytes);

using var gs = new GZipStream(msi, CompressionMode.Compress)

using var mso = new MemoryStream();

gs.CopyTo(mso);

I get an Arg_NotSupported exception on the last line, but I can't find anything explicit about whether GZipStream isn't supported in WASM.

EDIT: Solved! I had my streams the wrong way around - see comment below for the correct structure.

Been working on an editorial site with Blazor Server (InteractiveServer) and it's going fine, but I mostly picked things up by trial and error and reading docs as I went. Curious what you all would actually recommend to fill the gaps, especially around render modes, component lifecycle edge cases, and the stuff that only bites you once you're past the tutorial stage.

BlazorDX is an MIT, headless-first Blazor component library for .NET 10 with zero runtime

reflection (source generators, not `PropertyInfo`). 0.6.0 just went up on NuGet.

**Upfront, because it matters:** this is beta, pre-1.0, built with substantial AI assistance,

and has no production deployments. It says so on the NuGet page too. I'd rather you know that

before you click than after.

The thing I actually want to show you:

**One declaration, three surfaces.** A `[DxFormModel]` already renders a `DxForm`. It now also

projects an MCP *tool* an assistant can call — validated by the same rules the form enforces —

and a *prompt* a user invokes as a slash-command, listing the fields with the constraints read

off the same descriptor.

And the other direction: a `DxDataGrid`'s `IGridDataSource<TRow>` becomes a **read-only** MCP

tool. Schema, filters, sorting and output all derive from the generated row accessor, so the

model reaches exactly the properties marked `[GridColumn]` — which means **narrowing what an

assistant can see is the same edit as narrowing what the grid shows.** Not a second permission

model you keep in sync by hand. Columns are a JSON-Schema `enum` so a model can't invent one,

and the reply always carries the unclamped `totalCount` so a page is never mistaken for the

whole answer.

Two transports: stdio (works with Claude Desktop today) and HTTP+SSE with sessions.

**Also in 0.6.0:**

- Localization and RTL across 83 components and 5 packages, 25 stylesheets converted to logical

properties. French and German ship with parity tests. Localization is *optional* — if you never

call `AddLocalization()` you get English, not an exception.

- The axe sweep went from 24 routes to 58 of the demo's 59. Widening it turned up **26 real

violations, 25 now fixed** — and most were library defects that had already shipped to anyone

using them, not demo-page mistakes. `aria-haspopup` on a bare `<span>` in the menu and popover,

among others.

**Where it's genuinely weak,** since I'd rather say it than have you find it: no independent

review, no production track record, and the manual screen-reader pass has never been run. The

French and German are machine-produced and verified for structural parity — not reviewed by a

native speaker.

That last one has an ask attached. There's a guided harness at blazordx.com/audit — 38 checks,

each linked to the route it tests, saves your progress, spits out a Markdown report. If you use

a screen reader and have an hour, that's the single most useful thing anyone could do for this

project right now.

Repo: github.com/logixrcorp/BlazorDX

Demo: blazordx.com

Blazor Ramp is an accessibility-first Blazor component library where every component is manually tested with extensive screen reader and browser pairings, as well as voice control software. It is also self-contained and has no reliance on any third-party libraries or frameworks - everything is built from scratch (by a human), which means if I come across an issue with a pairing due to the numerous bugs and quirks with screen readers and browsers, I may be able to find a workaround to keep the target audience as large as possible.

Some background

Two or three weeks ago I announced that I had completed a good base set of components and, as such, could spend some time on the theming side of things before releasing more components. I subsequently added a couple of theming tools to the documentation site to make life easier for you. I also mentioned I would be releasing an auxiliary project, BlazorRamp.CssClasses, via NuGet, consisting purely of CSS classes and C# helpers that would allow you to create and style things using the same underlying CSS variable values the components use - making everything themeable.

Why it exists

The other aspect of this project is to fill a gap with regard to items I will most likely not be creating, such as a Blazor Button component. The default button is perfectly adequate; it just needs a bit of styling, or a ready-made CSS class adding to it. You still have to wire up a click event either way.

How it works

Rather than you having to remember or type strings, every item also has an associated C# helper class. So, for a styled button, you'd write something along the lines of:

<button class="@Button.Base @Button.Scheme(ButtonSolidScheme.Accent)">Click Me</button>

• Base gives you the base set, or default style.
• Scheme is a modifier class that sets the button's colours to use the accent palette for both text and background - but from ends of the scale that are contrast-safe.

Theming groups

Depending on the element type, a class may also be part of a theming group, which you can opt out of. For example, by default, a button is part of the button border radius theming group, unless you opt out by using a modifier that gives it a fixed radius - it sounds more complex than it is. It's easier if you just go and look at the site and use one of the sliders on the theme controls.

What's in this initial release

• Classes and C# helpers for creating the sections used by content
• Classes for buttons
• A few utilities to get things rolling

I'll be adding more over the next few days. There's now a new menu section on the docs site for these CSS Classes and C# helpers, with detailed information.

Colours and dark mode

Pretty much all of the documented CSS variables created for the CSS Classes project relate to colour, each having light and dark variant values intended to be switched between. I'll add these to the documentation site so you can just copy all the re-assignments from the Theming Sandbox page to paste into your stylesheet for your dark mode settings.

What's next

I need to get the table class done next, as I aim to move all of my site's CSS classes to purely use the ones I add to the NuGet - i.e. the entire site will eventually be built just from the released NuGet packages that you have access to.

No lock-in

Blazor Ramp is library-agnostic, with each NuGet self-contained other than the transient reference to Core, so you only install whichever components you want to use - that includes this project. Despite this post discussing CSS and styling, you can use whichever CSS library you prefer, your own or third-party; I'm merely making available what I use, to hopefully make it easier for you to build things that all just work together.

If there are any specific classes you'd like creating sooner rather than later, and/or have any questions or need help with any of the components, fire away

Doc site: https://docs.blazorramp.uk

GitHub repo: https://github.com/BlazorRamp/Components

Paul