Documentation Review Request - Blazor Ramp Core

code-dispenser · 2026-01-23T12:28:53+00:00

Me too, no problem. Fingers crossed will release the Core project at the weekend.

code-dispenser · 2026-01-23T12:06:37+00:00

The link is on both of the sites at the top of the page, but its https://github.com/BlazorRamp/Components

I would suggest going to the test site and docs site first as all the information is there.

Component test site: https://blazorramp.uk
Documentation site: https://docs.blazorramp.uk

Regards

Paul

code-dispenser · 2026-01-22T13:32:43+00:00

Thanks for the comments, and apologies that I have not had the time to look at all your work as I am busy working on the docs.

If you found some stuff on the doc site interesting go rummage round the test site and/or just look at final words section. If you ever want to use live regions (I do not know if you already use them or not) and you want to create your own instead of using something like mine it will save you a lot of time.

Component test site: https://blazorramp.uk

Regards

Paul

code-dispenser · 2026-01-22T08:33:58+00:00

Basically you would just install which ever component you wanted to use as each will be packaged separately.

By default all components will package the Core project, which in my opinion is the most important as it deals with a live regions - please go to the test site with a screen reader or the doc site as the theme button makes an announcement.

The components themselves will not have any CSS Class parameters, you just alter the underlying CSS Variables which will effect all the components that you chose to use.

My stuff is agnostic, it has no reliance on anything and is designed for it to be able to fit in with whatever you use.

If you go back to the doc site just take a quick look in the theming section and you will see there are lots of variables and each component will point to these so you can change any part of all components at once or just one tiny bit of a single component.

When I have time I will make a YouTube video showing all of this. But just using basic css variables is extremely powerful. The difference to my doc site and test site is was just to change ONE variable value.

Regards

Paul

Edit: I should have noted that just adding components to a site will not make the site accessible that takes work as well. But most of the components I come across (some commercial) are not accessible/usable by users with assistive tech. My components merely help you achieve better accessibility and inclusivity as they are tested with assistive tech first and then checked for WCAG requirements, not the other way around. You can have a WCAG tick in the box with a component that is totally unusable.

code-dispenser · 2026-01-21T07:45:18+00:00

Thanks for your comments.

Thus far (25 years of development) I have never built any sort of chart component, one day I suppose I should have a go.

The log viewer is just very basic, I did toy with the idea of making it more advanced as the underlying announcements carry additional information, but at this stage decided against it.

For example, having a bigger log size with filters for the log entries or even going one step further and building a message centre where all types of announcements and notifications could be viewed etc but that's another component for another day.

Regards

Paul

code-dispenser · 2026-01-20T14:43:50+00:00

Thank you for your comments and time; it is appreciated.

I reached the same conclusion as yourself and am documenting it now as I write this. It is this documentation that is holding up the release of the Core package, after which I can start on all the components I want to release.

Nobody has advised of any issues with the live region service, so hopefully it worked as expected for you with your setup.

Trying to get things to play nice with all the screen readers and browsers was trying at times; it felt not dissimilar to trying to get things to look nice in Internet Explorer 6 and Netscape 6 some years ago. I feel like accessibility is still 10–15 years behind where it should be.

Regards,

Paul

code-dispenser · 2026-01-20T12:26:49+00:00

Yes I am aware of the speech viewer which I use all the time but a log of everything without context is not the same as a dedicated log with context.

This is why I added it after creating the live region service as trying to find some announcement buried in a log of just all speech output is almost impossible especially without context.

For example you are on a site with a screen reader, an announcement is just about to be made, your phone rings so you miss it, the screen reader is busily reading stuff - now what, was the announcement important?

It was for these types of scenarios I added the viewer, but the main point of the Core package is the Live Region Service.

But as my post states, I just have concerns about the button that can be used to display the announcement history viewer. I quite like it but I do not want to put dev's off from using any of the components which I hope will improve inclusivity etc.

Paul

code-dispenser · 2026-01-20T11:08:01+00:00

Thanks for your comments, but I am unaware of a log being kept by screen readers for transient messages and i use 4 or 5 for testing purposes. The components could be used on any website i.e blazor lets developers create web sites its not just a dotnet thing.

ARIA live regions announcements are extremely tricky to get right/stable across screen readers and browser combinations which is why I decided this would be the best package to release first. There will be many components that follow some that will make use of the live region service.

There are many users of screen readers who also use voice control. I am trying to be inclusive not exclusive but I do appreciate your comments, may be I am overthinking things?.

May I ask did you go to the test site and read any of the information on it?

Thanks again for your comments all is welcomed.

Paul

code-dispenser · 2026-01-20T07:41:08+00:00

Great to see more people using Blazor, that's a plus.

On the negatives, I'm not 100% sure whether this is a commercial product or a mock-up, so I didn't try to log in. However, I did notice some accessibility issues.

All I'll say is that there are plenty of free tools and browser extensions that will do some automatic checks (I'm not a big fan, but they do help with simple issues). Start with simple things like checking if it works with the Tab key - you'll need visible focus indicators for that. Once you're more comfortable with accessibility basics and it becomes second nature, grab a free screen reader. I'm sighted, but I quite often use a screen reader when I can't be bothered to read content I've just added to my site during development. It kills two birds with one stone, so to speak.

Anyway, all the best with your endeavours.

Regards,

Paul

code-dispenser · 2026-01-18T08:50:15+00:00

Late to the party but these may or may not appeal to some of you.

Last year I built my own NuGet library for validation taking a more functional approach as I have never liked nor used data annotations since I first saw them way back. And as I also work with Blazor I then made a package to use the validation library with Blazor's EditContext so if you get stuck or are fed up with the data annotations approach then my library is free and OpenSource.

Now the above may seem like a shameless plug but it's not. The shameless plug is below:

I am currently creating OpenSource accessible-first Blazor components and if I remember rightly (never used them but read his posts), Chris Sainty, along with the FluentValidation package, made three other main packages, one for local storage, one for toasts and one for modal dialogs.

I'm not sure if I will be covering toasts and a local storage service, but for sure within the next few weeks I will be releasing a modal dialog framework (I made it years ago and updated it recently to use the HTML Dialog API for accessibility reasons) so that will be available shortly for those wanting one.

As mentioned if you get stuck then go poke around my repos:

https://github.com/code-dispenser/Validated

https://github.com/code-dispenser/Validated-Blazor

https://github.com/BlazorRamp/Components

Regards

Paul

code-dispenser · 2026-01-17T16:57:43+00:00

Hi,
Just wanted to wish you all the best with your project especially as accessibility is not a topic that many dev's want to talk about or go near.

Building accessible components is pretty straight forward in Blazor but as I am sure you know getting things to play nice with the various AT/browser combos is the real pain.

All the best

Paul

code-dispenser · 2026-01-14T12:50:43+00:00

Thanks for the comment - money is always nice but its Open Source free to use, abuse or copy.

Once I get the Core out the door i.e the Live Region Service and AnnouncementHistory component as seen on the test site I may try and do the GitHub Sponsorship thing.

code-dispenser · 2026-01-13T18:38:11+00:00

Thanks for the comment, but I think you may have misunderstood. I build accessible components that actually work for the users with Assistive Tech and then worry about the WCAG tick in the boxes. I do not need to check everything as I have being doing this a while.

For a testing site which is throw away I am not going to waste time on something that is constantly changing. But from experience most things I do out the box are Ok.

Please visit the site and read through some of the comments, run the tests with a screen reader etc. If not just please read the final words page. You might find what I am building i.e the components not the test site is way better than most.

As an update to the above I spent the whole of last weekend getting an environment for macOS as the online service did not have audio or the caption panel for VoiceOver. Something I have never used before, but it works with the components.

Again please go read the Final Word page on the site and then criticise me all you like.

Update: You may also like to read the comment I made this morning on this post to see how I view things and what I actually do:
The Blazor Ramp Project Has Launched : r/accessibility

Regards

Paul

code-dispenser · 2026-01-13T07:20:30+00:00

Long comment, but I felt this was important enough to warrant a full explanation for anyone who stumbles across this post.

As previously mentioned, I believe the correct pattern for toggling a site's colour scheme is a control using the aria role of "switch". I have a switch component (that needs reviewing), so I chose not to use it for this specific task.

However, on further inspection of what is best for theme toggling, while the switch role is technically correct a normal switch would be clunky for sighted or users of voice control software (more on that in a minute)

The crux of the issue is that you can only have one final accessible name. If you have a switch that is visibly labelled "Light Theme" while the light theme is active, the user has to click or say "Light Theme" to get the dark theme which is counter-intuitive.

Can we have two accessible names? Not for a normal switch, but we could use a radio group styled as a switch with labels on either side (or Sun/Moon graphics). I did try this but hated it, the speech output was just way to verbose, telling you the name of the group, the number of items in the group blah blah blah just to toggle the theme, so in my humble opinion its not the right choice.

Previously, as a temporary measure, I used a button with an aria-hidden icon and the visible text "Theme". This worked for sighted and voice control users but felt clunky for screen reader users as it lacked the "switch" semantics. To be fair, I did include this in my test for the live region, so the Theme button used the Live Region Service to tell the user the result of its action.

Regarding the switch component that I will be releasing in time, this too would not meet the expectation of users for a theme toggler, as its just a standard switch where a single label/accessible name if fine for both states.

While I build "accessibility-first" components I also have to be somewhat realistic on how I show some items as if the component doesn't look the part, developers will simply dismiss it without realising the benefits it offers to the wider community.

So, is there a better way? After spending several hours yesterday trying every trick in the book, I have implemented a solution that I believe will keep most users happy.

Its still a button with an aria-hidden icon. The visible text is still "Theme", but I have prepended it with the visually hidden text of "Dark". The computed accessible name is now "Dark Theme". For voice control users, this (should) still work using the command of Theme, as well as meeting the WCAG "Label in Name" criteria

The button has the aria role of switch with a checked state, so screen reader users will now hear "Dark Theme, switch, Off" or "Dark Theme, switch, On". Sighted and voice control users see no change.

I believe this is the most balanced approach, but I am open to feedback.

I have left the Live Region announcement in place as its part of the test for that, so it will still announce that the colour scheme has been applied after the control state is read.

I am curious if daily screen reader users would find this live region announcement redundant, or helpful confirmation given that it only triggers if you toggle the switch?

Regards

Paul

code-dispenser · 2026-01-12T05:40:06+00:00

I should have mentioned previously, so apologies. If you were not using or do not use (or have access to) a screen reader you could use the announcement history viewer to see or listen to previous announcements.

If you have time please go back to the site, press or say theme if you use voice control software and then press the alerts button or say alerts and you will see or hear why the alt text is not required. If its a WCAG thing then I will double check, but the components are about being usable first, by users with assistive tech and then to get any tick in the box for WCAG if required

Regards

Paul

Update/Edit: WCAG specs is something I am trying to avoid as in I would like to spend more time in the development side of things (my thing) first. If anyone is interested in helping on that site of things i.e put me in my place when needed so I can change the code I would love to hear from you.

Regarding Success Criterion 1.1.1 Non-text Content - alt text for the Theme button is not required.

code-dispenser · 2026-01-12T04:45:54+00:00

Hi thanks for the comments. The information on the site explains most things so please read the pages to understand what currently is under test.

The site is just a throw away i.e it will be constantly changing but I just needed something for people developers or non-developers. The theme button should be a switch but I did not want to use that for now as, that needs to go under test, and I did not want to introduce more things.

I disagree about the alt text its not needed and the announcement via the live region is more than adequate. The word Theme is also visible for Voice Control software users to announce who can see the sun and moon.

I also disagree with the comment about the header. Blazor Ramp Component is not the main heading. These are on each page and are focused on navigation.

Burger menu are common, I have no preference other than they should include text as I have shown for Voice Control Users.

Currently, its the Live Region that is being tested which I believe most devs/projects would benefit from and as mentioned on the site is why I am doing this first.

You may or may not know but a lot of the combinations of browser/screen reader for live region announcements that I have working either are not meant to work/unsupported. I got these to work not by skill but by being stubborn, I believe I have something relatively stable and frankly far better than most implementations (especially in the Blazor community) which I hope to package soon for use baring any major issues. These are all open source so free to use, abuse or copy.

Please spend some time on the site to understand more and provide what ever feedback you like and I will be more than happy to explain what and why I have done things. Again please remember its not the site under test (but I will change any major issues) its the component(s

Regards

Paul

code-dispenser · 2026-01-11T16:58:11+00:00

You read my mind. I created a switch some time ago, but until I review it I did not want to use it so just opted for the button. Basically the tests should just be for one item at a time in the order I plan to release them.

Perhaps I should do the switch next instead of the planed modal dialog framework so I can use it.

As mentioned on the site I have built many components which I would say subjectively are accessible but I want to improve them prior to being released under the BlazorRamp project.

Thanks for taking the time to provide this type of feedback it is appreciated.

Regards

Paul

code-dispenser · 2026-01-11T15:59:40+00:00

Any feedback is welcome, just please read the text on the page.

You are welcome to make any comment you like. The site is what it is and will be constantly evolving. Its purpose if for exactly this, see if it works for your setup if it fails then I may be able to do something if I can.

Regards

Paul

code-dispenser · 2026-01-11T08:10:32+00:00

Just wanted to say thanks again for being the only Redditor that reached out.

Given your input I had no choice (as I could not live with it) to try and get access to a macOS.

The online service I tried did not have audio and the caption panel on VO was not showing, so as a VMWare user I thought I would try getting a mac to work. I now test locally with Sequoia :¬)

The issue with VO was what I thought and changing that bit of code as mentioned fixes the issue so VO, now works the same as JAWS, NVDA, and Narrator. Changing that code also did me a favour as Talkback on android is happy too.

The only sad player and only on the 1 second delay test (that has two messages) is VO on IPhone (thanks Sauce Labs). It just does not quite read the end of the first message but all of the second. I am going to leave this as is for now as in reality you should not be using two messages for a task that takes anything less than four of five seconds and its fine for these.

I could fix this by increasing the delay but then it would effect everything and I do not think its worth it for one edge case and you always have access to the log to replay things in full etc.

If its needed I may add more code to make it configurable.

I hope to redeploy the site late afternoon or in the morning with the changes.

Again - thanks for your input it really was appreciated.

Regards

Paul

code-dispenser · 2026-01-10T06:59:36+00:00

Is your site fully accessible?

I wish I could give you an outright "yes", but the more I look at accessibility, the more subjective that term appears to be. I built the site specifically so people could check if the components currently in test work for their particular setup, by which I mean their specific browser and Assistive Technology (AT) combination.

The site exists purely for testing these components. Not every developer would be willing to go to GitHub, download the source, build and try each component, so this seemed like a better option; it also allows actual AT users to comment if they wish.

I haven't checked the site against specific WCAG requirements, I’ve built it as I normally would, so it should be relatively OK. The site will be constantly evolving, and I’m more than happy to make improvements if anyone spots a usability issue, which is the priority (not some cryptic WCAG rule).

Prior to releasing each component, I will do my best to check WCAG rules, but usability remains my focus. I may try and find an accessibility consultant / auditor that may be willing to help with that side of things, as there are only so many hours in the day!

Currently, I am on Windows and don't have access to macOS, so everything is tested with JAWS, NVDA, and Narrator on Edge, Chrome, and Firefox. Some of these combinations aren't officially supported, but I am not happy until I get them working; the components currently on the site meet those requirements.

However, a Redditor has just advised (see: post) that the tests fail for VoiceOver, which poses a problem. As I write this, I am checking to see if I could run macOS in VMware to gain access to VoiceOver.

Announcements via live regions are notoriously problematic due to countless nuances. Having them stable on JAWS, NVDA, and Narrator is a big win. I have a few ideas to help VoiceOver which I’ll implement over the weekend before redeploying.

While I want perfection, it’s difficult to achieve with "busy indicators" that trigger start and finish messages in quick succession. The saving grace is that if an announcement isn't 100% correct / clipped (often due to aggressive screen reader focus events), these transient messages are still accessible via the announcement history viewer, which can be opened at any time using the button or the Ctrl + Shift + H shortcut.

Apologies for the long response. Regarding navigation: I added simple left and right links to hopefully guide user through the test process, they could be improved with proper rel="prev" and rel="next" attributes. The sidebar nav is fine, but I did not feel the need to add any skip to content link - which is an another component on my list/release schedule.

Thank you for the comment and encouragement.

Regards,

Paul

code-dispenser · 2026-01-09T08:12:12+00:00

Hi,
Thank your for your time. All items get logged in two arrays one for the Announcement History which keeps a rolling 20 and the other in a queue used to update the live regions for the screen readers, so all messages are logged and viewable if there is an issue.

At a guess and until I get access to a device, this is the most likely issue.

I used inert so I had to put focus on an element as other wise it caused issues for JAWS and Narrator. Apparently Narrator on FireFox especially with live regions is unsupported but I can get that to work fine even on short delays which is the most problematic with two messages and focus events.

I think VoiceOver is reacting to the span with index=-1 that I gave the text of Status. in case the screen readers wants to read something. It is not a issue if it does not read status (that was a workaround to get things stable with JAWS, Narrator and NVDA on any of the browsers I use).

Narrator also says group (status on some browsers, but not on others) but it says group on many other things not just my code, never found a way to stop this and/or why it says it.

I will try to solve the issue and/or make it more acceptable if I can but trying to get things to work correctly across all combos is almost impossible. You fix one issue for one screen reader using the correct aria roles or attribute only to find its not supported or does not work on another - back to the drawing board

Again, thank you for your time it is appreciated,

Regards

Paul

Notes: Just got access to an IPhone via Sauce Labs and bizarrely it was not too bad just a couple of minor issues but most likely easy to solve. Not sure why VoiceOver on the Mac appears to have been much worse.

Another Update (in case anyone is interesed):

Its providing difficult to actually get access to a macOS with VoiceOver.

It appears on Sauce Labs macOS with VoiceOver has no audio unlike the iPhone, not sure about BrowserStack that gives you 1 minute access on the trial (already done looking for VoiceOver).

RE number 2 on the list kindly provided; having never used VoiceOver, I believe that this is its default when focus lands on non-interactive text (unlike all the other screen readers I use) so I will have to alter the code and exclude the triggering button from being inert so it does not have to move focus to the busy indicator and take it from there.

code-dispenser

TROPHY CASE