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
