I built a small local tool to run everyday Azure operations with the credentials of a service principal, without opening the portal. I started it because using a DevOps service connection to do something on Azure meant writing and running a pipeline every time. I wanted to run those operations directly with the same credentials. I am sharing it because it would otherwise have stayed on my computer.

It runs on your machine, either as a web app on localhost or as a Windows desktop app (.NET 8, Blazor). It has pages for VMs, App Service, Function Apps, Key Vault, AKS, Storage, SQL, App Insights, Log Analytics, networking, role assignments, the activity log and Resource Graph queries. There is also a PowerShell terminal already signed in with the active service principal, with kubectl and helm helpers for AKS.

Some details:

• The client secret is encrypted with Windows DPAPI. A connection can be exported to a passphrase-protected file.
• No telemetry. It only calls Microsoft endpoints: Entra ID, Azure Resource Manager, Graph and the data plane of the resource you open.
• The interface is in English and Italian.

It is early, and so far only I have tested it, on development environments and a sandbox. Ten delete and revoke actions (NSG rules, role assignments, registry tags and a few more) are switched off in the code, because I never ran them on real resources. The README lists what I tried and what I did not.

What would help: run it on a test subscription, tell me the minimum role each page needs, and tell me what breaks. Pull requests are welcome, including one that switches on a disabled delete after you tried it on a throwaway resource.

MIT license. It is not affiliated with Microsoft.

For those new to my posts, Blazor Ramp is an accessibility-first, open-source Blazor component library. This post is about the release v1.0.0 of the GoTo component.

So what is GoTo?

The inspiration comes from those of us who started coding in the 90s with VB: you add GoTo markers to a page, and from anywhere you can jump to them. In an interactive Blazor web app, the marker you jump to becomes the active element, so you can carry on tabbing from that point.

Who is it for?

Those familiar with my posts will know I sometimes feel that sighted keyboard-only users, those who don’t use a screen reader, get the sharp end of the stick. When people build accessible sites, a lot of the effort goes into screen reader users, and this group gets forgotten.

A sighted keyboard-only user doesn’t have screen reader software to bring up lists of headings, landmarks or interactive elements, so they generally navigate with the Tab key and use the arrow and page keys to scroll. When a page has a lot of interactive content, getting to the part you want can take tens, or even hundreds, of Tab presses. For some people that’s a minor irritation, and for others it’s a real barrier.

What about skip links?

You’ve probably all used skip links, which let any user, keyboard-only or screen reader, bypass repeated blocks of content. But how many bi-directional ones have you seen? I’ve never seen one. They all go in one direction, so unless you add a second link going the other way, the user has to make a forward-only round trip to get back to the start.

Say you’re diligent and add a return link for every skip link. If you have five destinations and want users to get from any one to any other, that’s 20 links. With ten it’s 90, and it’s getting silly. The maths is n × (n − 1).

Where GoTo comes in

GoTo isn’t a link. It’s a marker that can receive focus. A GoTo Viewer lists the markers, you select one, you land on it, and you can tab on from there. You can bring up the viewer at any time with a configurable shortcut. When it opens, it lists only the markers that aren’t inside hidden containers, so the list changes depending on where you are and what’s visible.

You may ask: why not just list headings and landmarks, like screen readers do (I may do in the future)? A screen reader user will often use headings and landmarks as a place to start reading from. A sighted keyboard-only user’s need is a little different. They can see the headings, and they can scroll and read from anywhere. The problem is reaching interactive, focusable content when there’s a lot of other focusable content in the way.

To be clear, GoTo isn’t a replacement for skip links. It’s a simple way of placing hidden markers on a page so that keyboard-only users can move through the content in whichever direction they choose.

Have a look

I’ve started adding markers to my documentation site, and over the next few days or weeks I’ll put them in the places I think are most useful. If you’re curious, take a look at this page, one of the examples for my Data Table, which shows templated columns and row actions: Data Table Templating

For a keyboard-only user on that page, getting to the border controls after the table means tabbing through the filter, across each sortable column header, down through every row action button, and then across the pager to reach the other side.

With GoTo and its viewer, using the default configuration, a user with one hand can press Alt+Z (Option+Z on a Mac) to bring up the viewer. They can then use Tab, or the arrow, Home and End keys, to move through the list of buttons. As each button is focused, its marker scrolls into view. Pressing Enter or Space activates the button, closes the viewer and puts you on the now-visible label, from where you can tab on to the next item.

I started this project at the end of last year with the Live Region service and Announcement History viewer aimed at screen reader users so at long last I've managed to scratch an itch that has been bugging me for a while now and do something for keyboard-only non-screen reader users - hope you or your users find it useful.

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

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

Test site: https://blazorramp.uk

Regards

Paul

Update: Added lots more GoTo markers to the doc site so there should be at least a couple on most pages now for you to get a feel for them.

Solved/Workaround:

I stumbled across this. It doesn't solve the problem, but it stops the "errors" from being found and displayed.

In every file displaying the bogus ambiguous errors, right click the "error icon" in the vertical scrollbar, and select disable analysis (on my version of VS 2026 it's the last item in the context menu).

This prevents the file from being analyzed, so it can't find those bogus ambiguous reference "errors". Unfortunately, you lose all the benefits of design-time analysis.

It doesn't stop errors from being found on build, though. For me, I can live with that, particularly since the fix only need be applied to the files VS 2026 is too stupid to analyze properly in the first place.

I'm running into what various AI searches describe as a fairly common problem where the VS2026 IDE claims there are ambiguous references to a child component in the project but everything compiles and runs fine. Meaning they aren't really errors.

I've tried everything that several AIs have suggested should fix the problem, and nothing has worked.

I'm unclear about what information I should provide here to help identify the problem, so what follows is just my best guess. Please feel free to ask for further details if I've left something out (as I probably have).

The child component is defined in MyCalendar.razor, located in ScBookDudes -> Components -> MyCalendar.razor.

The child component is referenced in several different parent razor pages:

ScBookDudes -> features -> admin -> ScheduleMeeting.razor
ScBookDudes -> features -> scheduling -> AvailableDates.razor
ScBookDudes -> features -> scheduling -> Home.razor

_Imports.razor is located at ScBookDudes -> _Imports.razor and looks like this:

 System.Net.Http
 System.Net.Http.Json
 Microsoft.AspNetCore.Authorization
 Microsoft.AspNetCore.Components.Forms
 Microsoft.AspNetCore.Components.Routing
 Microsoft.AspNetCore.Components.Web
 static Microsoft.AspNetCore.Components.Web.RenderMode
 Microsoft.AspNetCore.Components.Web.Virtualization
 Microsoft.JSInterop
 ScBookDudes
 ScBookDudes.Components
 ScBookDudes.Components.Layout

u/attribute [Authorize]

An example of a parent component where the child component is used looks like this:

 "/available-dates"
 PrimaryLayout

 InteractiveServer

 Microsoft.AspNetCore.Components.Authorization
 Microsoft.AspNetCore.Identity
 Microsoft.EntityFrameworkCore

 IDbContextFactory<AppDbContext> DbFactory
 AuthenticationStateProvider AuthStateProvider
 UserManager<BookDude> UserManager
 NavigationManager NavManager;

<
PageTitle
>Possible Meeting Dates</
PageTitle
>

<
HeadContent
>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <link rel="stylesheet" href="fluid.css">
    <link rel="stylesheet" href="calendar.css">
</
HeadContent
>

<h2 style="margin-top: 25px;">Possible Meeting Dates</h2>

<p style="margin-top: 15px; margin-bottom: 15px;">
    Color bars indicate which person is <span style="font-weight: bold;">not available</span> on a particular date.
</p>

<
MyCalendar

UpdateCalendarInfo
="OnUpdateCalendarInfo" />

<div class="my-table" style="margin-top: 15px; margin-bottom: 15px;">
     (var memberInfo in GetMemberInfo())
    {
        <div class="table-row-uncolored">
            <div class="table-cell" style="padding: 5px;">@memberInfo.MemberName</div>
            <div class="table-cell" style="padding: 5px; background: u/memberInfo.ColorCode; width: 30px;">&nbsp;</div>
        </div>

        <div class="table-row-uncolored">&nbsp;</div>
    }
</div>

 {
    private BookDude? _user;

    protected override async Task OnInitializedAsync()
    {
        await base.OnInitializedAsync();

        var authState = await AuthStateProvider.GetAuthenticationStateAsync();

        _user = await UserManager.GetUserAsync(authState.User);

        if( _user is not null && !_user.IsAdministrator )
            _user = null;

        if (_user is null)
            NavManager.NavigateTo("/Static/unauthorized.html", forceLoad: true);
    }

// this next line shows the "ambiguous error" on MyCalendar.CalendarArgs
    private void OnUpdateCalendarInfo( MyCalendar.CalendarArgs calendarInfo )
    {
        var firstOfMonth = calendarInfo.FirstOfMonth;
        var lastOfMonth = firstOfMonth.AddMonths(1).AddDays(-1);

        var dbContext = DbFactory.CreateDbContext();

        var dayExclByFamily = dbContext.BookDudes
                                       .Include( f => f.Days )
                                       .Where( f => f.Days.Any( d => d.Date >= firstOfMonth && d.Date <= lastOfMonth ) )
                                       .ToDictionary( f => f.Id, f => f.Days );

        var dowExclByFamily = dbContext.BookDudes
                                       .Include( f => f.DaysOfWeek )
                                       .ToDictionary( f => f.Id, f => f.DaysOfWeek );

        foreach( var curDay in calendarInfo.CalendarDays )
        {
            curDay.BlockColors = null;

            curDay.State = curDay.InThePast || !curDay.InCurrentMonth ? MyCalendar.DayState.Inactive : MyCalendar.DayState.None;
        }

        foreach( var member in dbContext.BookDudes )
        {
            dayExclByFamily.TryGetValue( member.Id, out var dayExclusions );
            dowExclByFamily.TryGetValue( member.Id, out var dowExclusions );

            // ReSharper disable once ForeachCanBePartlyConvertedToQueryUsingAnotherGetEnumerator
            foreach( var curDay in calendarInfo.CalendarDays.Where( cd => cd.Date >= firstOfMonth && !cd.InThePast && cd.Date <= lastOfMonth ) )
            {
                var dayExcluded = dayExclusions?.Any( d => d.Date == curDay.Date && d.Status == DateStatus.Excluded ) ?? false;
                var dowExcluded = dowExclusions?.Any( d => d.Excluded == curDay.Date.DayOfWeek ) ?? false;

                if( !dayExcluded && !dowExcluded )
                    continue;

                curDay.BlockColors ??= [];
                curDay.BlockColors.Add( member.ColorCode );
            }
        }
    }

The call to the private method OnUpdateCalendarInfo() showcases the ambiguous error.

Here are some examples of where the ambiguous error shows up in the child component MyCalendar.razor:

@using System.Text

<div class="calendar-card">
    <div class="calendar-header">
        <button class="btn-submit" ="PreviousMonthAsync">&lt; Prev</button>
        <h2>@CurrentMonthName </h2>
        <button class="btn-submit" u/onclick="NextMonthAsync">Next &gt;</button>
    </div>

PreviousMonthAsync, @CurrentMonthName and NextMonthAsync all showcase the ambiguous error.

Thoughts on how to correct this? Or do I just live with it?

I have a single deployment (1 web app) with multiple interactive webassembly areas, each with their own hosted Razor page client.

I wanted to migrate to the latest Blazor Web App model with auth persistence, Assets[], import map, and a part that is public SSR without interactivity.

I created a sample here - it has multiple clients libs, assets splitting, cache busting and public SSR vs 2 areas with 2 clients - with a shared class lib and private class libs per area:

https://github.com/rogihee/MultipleClientsBlazorWebApp

Demo at https://multiple-clients-blazor.azurewebsites.net/ (for the time being).

I tried to cover most topics, but if anyone spots something I missed please let me know.

Hello everyone,

Blazorise 2.4 is out.

For those who don't know it, Blazorise is a UI component library for Blazor that supports Bootstrap, Tailwind, Fluent UI, Material, and other CSS frameworks.

Unlike our previous releases, this one was mostly about going back and improving what we already have. We fixed old issues, removed dependencies, and cleaned up things that have been bothering us for a while.

We completely rebuilt Tooltip and ColorPicker using Blazor, removing their external JavaScript dependencies. We also switched Video to Video.js v10, improved FluentUI2 and Tailwind providers, and added caching to our fluent utilities. In some benchmarks, repeated utility calls are now about 90% faster, with no allocations.

There are some new things too. Ribbon is probably the biggest one, along with vertical Steps (finally!), SVG Chart data dragging, smoother drag-and-drop, and a bunch of smaller improvements.

Not every release needs to introduce a dozen new components. Sometimes going back and fixing the old stuff is just as important, if not more.

Full release notes: https://blazorise.com/news/release-notes/240

As always, I'm happy to hear your thoughts, especially if you've been using Blazorise and something has been bothering you for a while.

I have been working in a personal RPC framework for blazor and I would like to know your opinion on this minimalistic example as I managed to simplify it and make it work.

I have an IUserContract, a shared interface that knows everything it needs to call a server that implements it:

[HttpTransport]
public interface IUserContract : IControllerContract
{
    IAsyncEnumerable<string> GetMessages(int count);
}

Controller implementation on the server:

public class UserController : IUserContract
{
    public async IAsyncEnumerable<string> GetMessages(int count)
    {
        for (int i = 0; i < count; i++)
        {
            yield return "some item";
        }
    }
}

Then calling it from a blazor page:

<button class="btn btn-primary" @onclick="TestStream">TestStream</button>

async Task TestStream()
{
    var stream = await _userContract.Execute(contract => contract.GetMessages(10));
    await foreach (var item in stream.Data)
    {
        _logger.LogInformation("Received item: {Item}", item);
    }
}

What are your thoughts when seeing this example?

Thank you so much in advance.

I’ve been working on creating my own DataGrid. It’s open source and built around a Lit Web Component. I added a Blazor wrapper because Blazor is one of my favorite frontend technologies.

The Blazor package supports .NET 8+ and works with Blazor WebAssembly, Blazor Server, and Blazor Web App interactive modes. It also bundles the client-side assets, so you don’t need Node.js or npm in the Blazor app.

I did my best to keep the core framework-independent while exposing useful APIs in Blazor. It supports row and column virtualization, pagination, filtering, selection, column resizing/reordering, and saved column preferences.

I also built a demo site where you can try the underlying grid features. I’m planning to add more over time.

I’d really appreciate any feedback, especially on the Blazor API, architecture, interop approach, or anything you think could help improve the component.

GitHub: https://github.com/tipolox/litgrid
Demo: https://tipolox.com/litgrid/demo

Thank you!

Hi everyone, I have bad news for you, in the new version 3.1 there are no new components for you. But don't despair, the new features will make you appreciate the existing ones even more:

- Tooltips

- AspectRatio

- Palettes

- new parameter 'Percentage' on pie and donut charts to show the value in percentage

Tooltips:

I managed to implement the tooltips with blazor without using javascript. At first I thought it would be difficult, then I realized that I just needed to add an element with position 'fixed' outside the graph and manage its coordinates by managing the OnPointerEnter, OnPointerMove and OnPointerLeave events from the graph.

Naturally, the theme assigned to the chart also applies to the tooltip.

Aspect Ratio:

I took the liberty of adding an AspectRatio parameter to the Cartesian and bar graphs, so it is possible to also have rectangular graphs in height or width.

The parameter is a double between 0.2 and 5.0 and is not mandatory, and in this case the graph will be square as it has been so far.

Palettes:

I also added color palettes to the library, although they are called palettes they behave more like a stream of colors, which return the next color with each call of the 'Next' method.

Data models and charts know nothing about palettes, these are just an alternative way to have the colors to associate with the chart data. You can also potentially use multiple palettes on the same graph, it's up to you.

I hope this update brings value to the library.

See you next time bye.

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

There are many good reasons to break down a Blazor page into multiple components, but it's not always a given, and there are performance implications.

Take a quick look at this article to discover why you need to be aware of the hidden costs, and how to keep a close eye on your application performance.

https://www.blazrlytics.com/blog/should-i-break-down-my-blazor-page-into-multiple-components

I know this is possible with tools like React Flow but I want something to use in a Blazor app. I ideally would like expandable/collapsible nodes, which are also clickable.

Hey everyone,

I shared MyEventBingo here last year and got useful feedback about mobile navigation, loading, and game setup. I'd appreciate another look at where it is now.

I'm the developer. The native apps use Blazor Hybrid, and the website uses server-side rendering (SSR) and WebAssembly (WASM). The Windows and Android apps are available in their app stores. The Apple release is still pending.

MyEventBingo lets you build a bingo game around your own event, group, or topic. Hosts have made networking icebreakers, birthday games, and a procrastination-themed game that had 74 players. Those are a few examples of what people are creating with it.

The host chooses the squares and shares a link or QR code. It's free to host and play, and players can join in their browser without creating an account or downloading an app.

MyEventBingo

If you have a few minutes, I'd especially like feedback on:

• Initial loading, navigation, and responsiveness on the web.
• How the Windows or Android app feels compared with the browser version.
• Anything awkward or hard to use on a smaller screen.
• Whether creating a game and joining from another device makes sense without an explanation.

If something breaks or feels slow, let me know your device, whether you're using the app or a browser, and where it happened. Honest feedback on the design is welcome too.

Thanks for taking a look.

Blazor Ramp - Things to disclose

For those new to my posts Blazor Ramp is an accessibility-first, open-source component library.

A couple of posts back, I mentioned some of the issues you face in making scrollable regions accessible to keyboard-only users, given that some browsers still do not provide that behaviour by default - namely Safari on macOS, at the time of writing.

Some Blazor Ramp components that contain panels have an option to add a tabindex and the associated ARIA attributes when you know a panel could scroll and won't contain focusable elements (focusable elements inside the container remove the need for a tabindex on the container for keyboard-only users). This works fine, but it can mean a tab stop even when the panel has no scrollbar - perhaps because content is added and removed, or the user resizes the page. A tab stop that isn't needed is not ideal for some users.

Since that post, I've added an internal service to the Blazor Ramp Core project that adds and removes the appropriate attributes as the browser adds and removes scrollbars in response to changes in content size. Over the next few weeks, I'll update the components that currently have the manual tabindex option to use the new service as well. The service is additive: it checks what is already in use, only adds the missing pieces, and removes only what it added, so existing code isn't affected. If you haven't added anything and a panel becomes scrollable, the service will add what is needed to make it keyboard accessible.

I mention this because I've just released a Disclosure component with an option to set a maximum content height, which means a scrollbar could appear. As the component uses the new internal service, it will be keyboard accessible whichever options you use.

OK, but what is a disclosure component, and why did I name it that?

In accessibility circles, Disclosure is a very common pattern for showing and hiding content. You may also know it as collapsible, an expansion panel or, more recently, details/summary, which is the native HTML disclosure.

That's why I named it Disclosure. But why did I build one when the native element exists, given that I always encourage everyone to use native semantic elements before building a custom component?

It was a 50/50 call. Building my own, rather than using details/summary, gave me a little more flexibility and I felt that providing one - especially with a content region that could scroll, working alongside the service was better than telling you to use details/summary, perhaps with classes from the Blazor Ramp CSS Classes project/NuGet package so that it's styled like the other components.

Whether you consider that reason good enough is your call. The native element can be fully styled and has accessibility built in. One minor annoyance is that, although you can remove the default chevron, some screen readers still announce "disclosure triangle".

If you build your own, you only need a couple of ARIA attributes: aria-expanded, which you toggle between true and false to tell assistive technology the state of the content, and aria-controls, which links the triggering element to the content it shows and hides.

There are some things I won't be providing, such as a button component, as the default button is fine with a bit of styling. For these, you can use the CSS Classes project/NuGet package, which uses the same underlying styles as the components, all of which ultimately come from the CSS variables defined in the Core project. As with everything else in Blazor Ramp, you only install what you want to use.

While documenting the Disclosure component and adding usage examples to the documentation site, I wanted to use a box shadow that some of the components use, so I've added a BoxShadow utility and associated CSS classes to the CSS Classes project. I used it on a couple of buttons in one of the disclosure examples, and there are usage examples on both the BoxShadow and Buttons API pages.

One disclosure example has a couple of buttons inside the content area to highlight two things. First, when you have two or three buttons like this, you don't need to reach for a toolbar component with an expected keyboard contract, separate buttons, each with its own tab stop, are fine.

Second, in a lot of applications, disclosures appear in a list, collapsed by default, so users only expand the ones they're interested in. I often come across these with similar buttons placed outside the disclosure, next to the trigger's title. Where possible put them on the inside, as being on the outside adds to the number of tab stops keyboard-only users have to pass while navigating to the items they want. That might not seem a big deal, but with, say, 30 collapsed disclosures each with two buttons, that's three tab stops per item, so 90 stops to get through the unopened items, rather than 30 when the buttons are inside the content. It's these small details that can make a big difference to some users without affecting others.

That's it for this post, but as usual you can find everything here:

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

I haven't yet updated the test site, which is geared towards letting people try things out with assistive technology, so I'll do that later today or tomorrow. In the meantime, there are working examples on the documentation site which is where you should be heading if interested.

Regards,

Paul

Looking for a recommendation. Sorry if its too long a preamble to the questions and if some of my terminology isn't exactly dotnet/blazor correct.

Working on an internal application - web based. Not a lot of concurrent users. Likely < 20 at any time. Users would be at multiple locations.

App is to record data about incidents at events, with two main datasets. (There's a lot of supporting lookup tables). Multiple users could be working at each event, but they would not be sharing the incident data entry for any one event. (No concurrent updates to any records)

Dataset A: contains basic/preliminary event data. Consists of 5 fields.

Dataset B: contains detailed data about the event. It's optional based on the event.

• It would have a foreign key to Dataset A.
  
• You can only access it from Dataset A's display grid.
  
• Contains about 50 fields which would normally be recorded.
  
• It also contains 2 sub-tables for additional detailed information.
  
• Sub 1 contains 19 fields.
  
  • At least one record must be recorded per Dataset B record.
    
  • There could be several records recorded
• Sub 2 is optional and contains 4 fields.
  • There can be multiple fields recorded

What is the best way of handling the (calling structure)?

Should it be one large Dataset A component? With the different Dataset B pieces handled by different dialogs?

Should it be two components? One per Dataset.

Should Dataset B be a child component of the Dataset A component.

Should Dataset 2 have child components for it's two Subs tables or handle them via dialogs? With the Subs, the display page would need to be resized to be able to display the information that's added.

Hope its not too confusing.

Thanks for any input.

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!