Headless-UI "Fully Accessible" - it's not your fault you believe the BS [accessibility rants]

In case you haven't read one of these posts before, the anger is just for fun, the message is really important, I am not actually angry!

On a side note: There is something wrong with you all! You all seem to like me being angry and ranting at you, people are going to think I am a monster if this carries on!

"Fully Accessible" - what a crock of sh*t

I have seen loads of people praising headless-UI for accessibility, mentioning it in comments or even writing articles about how accessible it is, just regurgitating the crap they have been fed (you know, like the articles where "React virtual DOM is faster than vanilla JS DOM manipulation"...that sort of crap / poor understanding).

I mean I don't even blame them for believing it, they say it right on the home page:

"fully accessible UI components"

and when someone makes a claim with a popular library, of course they aren't full of crap!

I mean, it isn't like people can just write what they want.

A quick word from our sponsor, MagiGrow!

So before we continue, let me just tell you about today's sponsor...MagiGrow!

Do you want bigger boobs?
Just apply MagiGrow ointment 3 times a day and you will soon be sooooo front heavy, you might just topple over! Nobody will talk to your face again!

Do you want an ass that just won't quit?
Use MagiGrow on your butt and you will cause earthquakes when you twerk!

You will be that Thicc after using MagiGrow that people will call you "bowl of oatmeal"!!

Oh and guys, we haven't forgotten you!

Want a bigger dick?
MagiGrow for Men, has got you covered too.

Apply liberally and you will soon have horses jealous of you!

Tripod won't even be an accurate name for you as one "leg" will be longer than the other two.

Order today! Only $69.69

(I mean, I wouldn't just write some random, made up crap to make a point...you do believe me that I am sponsored by MagiGrow and it works don't you!?)

Ok we get it, don't believe everything you read.

Yeah sorry, the ointment isn't real...and neither are headless-UI's claims.

Don't believe me? Let me break down the first example they give.

Menu-drop down.

Right, first one they showcase, there shouldn't be too many problems with this one surely as they are leading with it?

They start with a <button> (A great start, it is semantically correct...you did read my rant on buttons didn't you?).

They also apply aria-haspopup="true" (so screen readers can let people know that this opens something up) - looking good so far.

They even remembered to apply aria-expanded="true" when the menu is open (so screen readers can let people know that the menu is open).

And they add aria-controls="idOfTheMenu" (so screen readers can let people know what this button controls and make associations).

It looks pretty accessible so far doesn't it! 10 / 10!

The list is where it all goes to

I mean, first thing is first why if you have a list of buttons would you not use...a LIST.

It is just a <div> with a load of <div>s with buttons in them.

The list should be a <ul> with <li> containing the buttons. SE-fucking-MANTICS people.

Instead it is a <div> with other <div>s inside it. (yeah they added some WAI-ARIA, but seriously why not start with the right elements in the first place!)

Why does it matter? Because an <ul> has a secret super power. It allows screen readers to announce how many options there are ("list with 6 items"). This is really useful information if you can't see and your screen reader doesn't support the WAI-ARIA properties used.

They can't even use role properly

Next thing - on the <div>s (that should be <li>) they apply role="none". Who told them to do that? A <div> doesn't have a role - so what is the point of that?

Oh and they obviously haven't even read the WAI-ARIA spec as the editor note says not to use role="none" yet (use role="presentation").

I am guessing someone read the role="menu" spec and got confused and that is why they added role="none" to an element without a role (or maybe they didn't, who knows!).

Anyway, it is just wasted bytes, no big deal, it doesn't do any harm at least.

Why are they interfering in keyboard controls they shouldn't?

Next issue: you can't Tab out of the menu...this isn't a bloody modal. Once the menu is open you can't Tab to the next control.

What the hell are they thinking?

Was it too difficult for their little brains to work out how to close the menu if it didn't have focus anymore?

It isn't like they made it so you can Tab to the next item in the menu itself, so they effectively just removed functionality for no reason.

And why can't they follow simple patterns for keyboard controls?

Then there is the cycling of items in the menu.

If I press the up arrow when the menu opens (or when I have the first item in the list highlighted) it should go to the last item in the list. It doesn't.

Same with if you are on the last item in the list and press the down arrow, it should cycle to the first item. It doesn't

Or what about the fact that you should be able to jump to items based on their first letter.

I press d it jumps to "duplicate"...as expected. I press d again and - it does nothing. It should jump to "delete". It doesn't

That last one is even more painful as they "half arsed" the solution. But it can cause massive confusion if the menu is dynamic.

If "delete" is sometimes disabled as it isn't applicable I might press d a couple of times, find it doesn't cycle and think "oh, I obviously can't delete this item".

WAI-ARIA is not a fix for everything, in fact it is a last resort!

Finally, because of their massive over-reliance on WAI-ARIA to correct their crappy HTML this is likely to not be particularly Robust, which is what R stands for in the WCAG principles known as POUR

WAI-ARIA is like CSS - it isn't universally supported, and there are loads of compatibility issues, so you need to use it sparingly or with graceful degradation.

But hey, that is just one component, maybe we can do better with some of the others.

Listbox (select)

Ah they can't possibly get this one wrong.

I mean, other than the fact that you can press Space to select an item, which is really weird (because they used <button> elements that accept both space and enter to activate them) I can't spot any new issues we hadn't seen previously.

Obviously they treat it like a modal again, disabling Tab for no reason.

Oh and I can't just change options using the arrow keys like I should be able to, pressing up or down opens the list (which is fine if you can tab out of the list and it remembers what item you had used the arrows to get to) so I have to press Enter or Space to close the list before I can move on.

You know what - it is passable, I will put the angry man away for a minute as I have seen far worse attempts.

Other components

Look I am already exhausted and finding 10 accessibility errors in just two components already makes my point.

But because I know the Tailwind zealots are going to want to defend their precious cult, let me just list a few more issues in short hand:

Switch (toggle)

The role="switch" only has about 80% support - which would be fine but they start building the component from a <button> (why, WHY!). Using a checkbox would be a better base.

Also - by using a <button> as the base how do they expect you to add an associated <label> that is visible? I suppose visually hidden text (text that only a screen reader can see) will just have to do.

I mean, who cares about people with cognitive impairments who may need to see the label to reassure them that they are on the correct control?

"But you could just add text above the switch to solve that"....you could, but then what happens when someone who needs a larger tap target (i.e. someone with Cerebral Palsy or Parkinson's disease who may have accuracy issues) tries to click on the "label" to activate the control.

That is expected behaviour, clicking a label checks a checkbox...ah who cares, there are only a few hundred million people who rely on good design in the world.

Disclosure component

I mean, most would call this an accordion but hey, who am I to judge on naming components, let's call it "magic expandy thingy" from now on. I don't want things to be clear for anyone.

So with the "Magic Expandy Thingy (MET)" they have used buttons and all sorts of crap...I haven't even looked if they have done that correctly...I really can't be arsed.

Why?

Well because we have this fantastic, super modern technology called HTML5. Don't worry if you haven't come across this before, it only came out in 2008, it is still quite new!

In the HTML 5 spec are a super secret pair of elements.

So secret that they cleverly hid them as the first item mentioned under Interactive Elements.

Nobody could possibly find them!

<summary> and <details>. I mean, to be fair to headless-ui, MDN call the summary element the "HTML Disclosure Summary element" - so perhaps their naming of the pattern was based on that? But then that would mean they know about the elements...and chose to ignore them...ah forget it, I can't work out what they are thinking!

Here - try it for yourself, I am sick of explaining things to you:

Now if you want to go and add your 47 utility classes to that - you can, <summary> and <details> will work in 96.6% of browsers and even degrade gracefully in IE (not that it matters, if you think headless-ui is accessible you won't support IE anyway, probably saying things like: "it's End Of Life (EOL) bro"...so who gives a shit?)

Dialog (modal)

Oh I am excited to see this one. I mean just read the blurb on the site:

A fully-managed, renderless dialog component jam-packed with accessibility and keyboard features, perfect for building completely custom modal and dialog windows for your next application.

It is "Jam-packed" with accessibility and keyboard features, exciting!

Ok so when the modal is open it applies aria-hidden="true" to all other content on the page right? It adds tabindex="-1" to all other interactive elements on the page so they are inactive right?

Does it fuck.

You see they think that keyboard users only use Tab.

They haven't even laid eyes on a screen reader, never mind used one.

In a screen reader you don't navigate with Tab, you navigate with arrow keys, the numbers 1-6 (to jump to headings), k (to cycle through links) etc. etc.

Your modal traps focus to the same level of success as the rest of your "accessible" library - it doesn't, it isn't, you failed. I can get to everything on the page with a screen reader and not even know that there is a modal.

I didn't even take the time to see if this returns focus to the button that activated it when it is closed, someone please tell me they at least implemented that??

Radio Group

Yeah I know, I skipped "popover" - couldn't even be bothered as it is essentially the same as a modal so all the same problems will be there. So I moved onto radio group.

I can't even be bothered here either as the first thing I saw was <div role="radio". Honestly what is wrong with using a fucking <input type="radio" for a fucking radio group

That is it, I am done, fanito, finished...headless-UI is obviously written by a load of fucking amateurs.

Conclusion

Yet again, the anger is for fun.

In reality the headless-ui library does a better job than a lot of libraries when it comes to accessibility, and I applaud any company who is at least trying to make things accessible.

I just get annoyed with the "fully accessible" crap they keep saying.

I understand that in marketing "bigging yourself up" is essential, but this is too far and is misleading people.

If they just said "accessibility focused" library I would think "Yeah, not a bad job, few issues, but on the right track at least".

But no, they are leading developers into thinking that they can just drag and drop their components into their application and they will be WCAG compliant. That people with disabilities will be able to use their website without any issues. They won't

If you take anything away from this article, don't believe the crap that companies feed you, research it yourself, question everything (including me).

Would you use headless-ui though after all that, putting your "non-angry head" on?

No, sadly I can't recommend it (at time of writing).

They don't use semantically correct HTML as the base and if you want an accessible library - you gotta start with the basics (using the right native elements for the job) and progressively enhance them.

I will happily return to this article if they improve things and change my opinion!

For the Algo!

My new sign off experiment!

If you enjoyed this article, give it a , if you thought it was special give it a and above all, don't forget:

Leave a comment for the algorithm! Even if it is just to tell me to stop being so angry !

Oh and if you are a Tailwind evangelist...sorry that I attacked your religion, you will be OK don't worry! Leave a comment defending it by all means!