Headless-UI “Fully Accessible” – it’s not your fault you believe the ? BS ? [accessibility rants]

This content originally appeared on DEV Community and was authored by InHuOfficial

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! ? Oh and for the 55 people who saw this post yesterday - sorry I mis clicked and posted before it was ready ?‍♂️

"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 ever 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. We are going to have to remove the semantic information later using role but we need to start from the right place!

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 - graceful degradation!

Anyway, if the relevant WAI-ARIA is supported it works ok, so a minor point I suppose.

They can't even use role properly

Next thing - on the <div>s (that should be <li>) they apply role="none".

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

I can't blame them too much for this one though - even WCAG guidance can't get this right!

I mean, you didn't think you can just copy and paste official WCAG recommendations did you? Of course not, loads of their examples don't follow their own best practices.

A lot of them show how to take semantically incorrect elements and apply the correct semantics to them, loads of them are outdated and some of them are just plain wrong - don't worry I have included WCAG in my rants before).

Anyway, I am not docking any points for this one, in a few years it will be usable for everybody, they technically followed the spec and they probably just looked at some examples which misguided them.

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

Next issue (and now we are getting to ones that do matter): 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. You don't have to have this feature but they decided to implement it as it is recommended. But their incorrect implementation can cause massive confusion if the menu is dynamic.

For example: if "delete" is sometimes disabled (as it isn't applicable at that time) I might press d a couple of times, find it doesn't cycle to delete as expected 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 with graceful degradation in mind.

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 many 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) but they have that annoying Tab issue, 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.

However - if you can, for one second, imagine coping with your design not being pixel perfect do you know what is even better than their implementation...a <select> element. It...just...works.

Hell I blame browser vendors for this one, if they just added the option to style the drop-down part hardly anybody would be trying to build their own!

Other components

Look I am already exhausted, I have already made 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 to drive the message home:

Switch (toggle)

role="switch" only has about 80% support - which would be fine but they start building the component from a <button> (why, WHY! I tell you why - even MDN uses a fucking button as the base for a switch). 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? If the switch role is supported you can use for="idofswitch" but if it isn't supported, this association doesn't work.

Screen readers might handle this quite well but Dragon Naturally Speaking (which a lot of people rely on) can't even handle correctly marked up semantic <label> elements - it really won't stand a chance with this pattern.

Anyway, we could always add some visually hidden (screen reader only) text to the button I suppose.

Obviously you still need a visible label, but you could just add text above the switch to solve that couldn't you?

Well 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.

In case you were wondering, that is expected behaviour, clicking a label checks a checkbox and a switch is essentially just a fancy checkbox...ah who cares, there are only a few ** million** people with conditions that cause accuracy issues who rely on good design in the world, we can ignore them.

But it also helps with WCAG compliance. The headless-UI toggle example does not comply with tap target size requirements of 44 css pixels (it is close though at 38px tall) - but as that is a styling issue I also can't dock any points.

However if it had a properly associated label, that can be included in the tap target area and their example would be fine.

But they used a <button>, so it won't work properly without WAI-ARIA..it is a shame, they were so close to not fucking this one up!

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 HTML5 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 section.

Nobody could possibly find them!

These secret elements are <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, no CSS, no JS and it just works:

{% jsfiddle https://jsfiddle.net/8pt23eLy/ result html %}

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.

Their modal traps focus to the same level of success as the rest of their "accessible" library - it doesn't, it isn't, they 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 to be fair 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.

And to further defend them half of the issues they have are because guidance is just a mess.

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 questioning me, a couple of issues in this article are really minor, that is the problem with angry rants, it is hard to judge where the big problems are rather than minor ones).

And that isn't just headless-UI, there are a lot of these "accessible" libraries and templates that...aren't!

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

No, I wouldn't use it personally (at time of writing) and no that isn't because I am on the "not a TailWind fan" side of the fence.

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.

With that being said, the real question is:

"If I know nothing about accessibility, should I use it".

I would actually say yes ?, it will be more accessible than something you try and build yourself (for everything other than the "disclosure" item, just use <summary> and <details> as I said - they dropped the ball with that one!).

Just don't go advocating for it's use like it is perfect!

And if you aren't looking for a quick fix and actually want to make your site "a great experience for people who rely on assistive technology" rather than "compliant with WCAG" then there are much better options.

Don't worry, there are plenty more rants left in me that will cover:

• little known libraries that do a much better job on accessibility.
• a rant or two on the difference between a compliance mindset and a great experience mindset when thinking about accessibility.
• rants on individual components such as custom select, checkbox and radio, menus etc. wherever I see terrible examples getting lots of upvotes, a rant will emerge I have no doubt ?.

Give me a follow for that (and some more serious tutorial style posts and proper discussions on things....all coming soon!)

And finally, 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!

This content originally appeared on DEV Community and was authored by InHuOfficial