Why HTML Hates Costume Parties

Just as there are a bunch of rules in life:

• A baby does not come with an instruction manual
• The only constants in life are death and taxes
• Never play leapfrog with a unicorn – just think about the indemnity insurance!

There are also a few critical rules for digital accessibility. One of these is (drumroll please): HTML hates costume parties.

Okay, okay, maybe you have never heard of this rule, or maybe you have heard it in one of the other less artistic forms. Let’s take a closer look at some important aspects of accessibility for interactive components, specifically links and buttons. Let’s find out why (because of these components) HTML hates costume parties.  

At a costume party If a person dresses up as a flower no one is going to believe that a human has transformed into a flower. If another party guest were to throw compost and water on a person dressed as a flower, quite likely the flower person would kick up a bit of a stink (pun intended).

Always treat a guest as human, regardless of their appearance (and sometimes their behavior).

When we talk about digital accessibility, similarly there are critical rules we expect to follow with components. If you visually present a component as a different component e.g. present a link to a user as a button. Underneath the visual presentation the “button” is still a link and has all the properties of a link. 

Buttons Vs Links

Links and buttons are common in most websites. For these components to be accessible to everyone, including assistive technologies and people with disabilities people. From the outset it needs to be clear how the user can interact with an item. Generally three things drive this:

1. How the items visually presents to users
2. The items visible and accessible names 
3. The components role. Identified within the code itself.

When there is a deviation between these criteria it can be very confusing to a user. 

So continuing with our costume party analogy, let’s look at some of the other reasons HTML does not like costume parties

Have I hit it yet? 

For keyboard only users, or screen reader users navigating by the keyboard, generally the following principals hold. 

1. Links can be activated via the enter key
2. Buttons can be activated by the space key or the enter key
3. Divs are not interactive (unless a developer is rocking some “mad scientist” vibe)

If you dress your link to look like a button, as in the comic, some folks are going to wonder “have I hit it yet?” Many users are likely to try to activate with the spacebar and nothing will happen. So HTML hates costume parties and our users now hate the fancy dress we are applying to this websites components.

If you really need to force a link or a button into a costume, it is better to choose to make the button look like a link. Sighted users will assume activation through the correct key (and if they happen to try the spacebar which normally is not used for links, the button will still activate).

Links – What’s the password and where will it take you? 

The best parties always have a bouncer and a password (okay maybe just the underground ones). For links the password is href=“my_link_text_here” 

If your link does not use the standard href=“my_link_text_here” password, admittance is at the bouncer discretion. And some bouncers don’t always care for coffee on their guest list. (Coffee = Java, Guest list = Script. JavaScript links. OK I admit it, terrible joke.)

What I am trying to say is avoid JavaScript links and empty links or anchor tags. 

The href=“my_link_text_here” is an all singing all dancing password for you to use. It gives a standard result and is available immediately without any fancy manipulations. JavaScript and the other combinations become a little murky for accessibility. If the bouncer is feeling a little grumpy, you might be denied access.

Issues with JavaScript Links, empty links and anchor tags as links

A few issues you can encounter if you use JavaScript links and empty links or anchor tags

Buttons – like party goers there are three types

Three types of party guests

The bouncer – yeah he is back, ready to spring into action and reject people trying to join the party early

The party animal – They have already tapped the keg, passed out and likely to forget everything that happened at the party by tomorrow morning

All other guests – Excited but awkward in groups. Really great at performing a single activity.

The three types of buttons

1. Submit – used to submit forms and generally throw down validation errors and eject trouble makers from the party
2. Reset – used to clear or reset forms. After they activate they have no idea what happened before
3. Button  – very excited, but very single minded. They can do one activity but it could be anything, hopefully their nametag gives it away 

When designing your websites, always make a guest list, group your buttons into categories and make sure those categories end up in the code. Remember though, you generally only need one Reset/Party-harder if you want to keep the peace. 

Always have a present… duct tape it if you must

At every party at some point a present is going to get unwrapped at the wrong time. This could be due the gift giver being in the bathroom, an overly excited guest maybe a small child or pet, unwraping items in the wrong order, etc. At my place it is always Stormageddon (my cat). Often this timing can cause quite an upset. The solutions are:

1. Advising the unwanted, poorly timed, gift un-wrapper that they are in breech of good party etiquette.
2. Wrapping gifts in duct tape. It makes the gift impenetrable, however this can also block the git recipient
3. Removing all presents from the party until the designated un-wrapping time.

The same applies to buttons, at some point, someone will push that button at the wrong time. You can manage this by

1. Run a task which shouts at anyone who tries to activate the button early. Implemented through validation errors. If we relate this back to the party instance this might be chasing the cat that just had their murder mittens into your sparkiest gift
2. Disabling the button until certain trigger. Consider this as duct taping your present. 
3. Invoking the fun police and removing the button from visibility on the page and the accessibility tree. E.g. Hiding the presents from everyone until the right moment. “These are not the droids you are…” oops wrong analogy.  

Don’t be the fun Police!

How to implement a good button

With buttons, the default implementation should be for the button to be present and enabled. If the button is triggered too early, validations should be provided to the user to assist them to reach their end goal.

By disabling buttons we prevent users from making mistakes by activating a process early but think of this like a party where the presents are kept behind a clear wall with no logical way for the recipient to get through to them. It is escape room territory!

With a disabled button a user needs to actively figure out what they need to do to allow the button to be available so they can activate it. If the user is unsure of the steps they need to take, they are likely to get frustrated and abandon the process. This is more likely to impact users with cognitive disabilities. I have abandoned shopping carts and subscription renewals because I couldn’t figure out why their form was blocking the submit button. It’s sad because I usually enjoy escape rooms!

The third scenario where a button is completely non-existent can often be a sign of other poor design issues. Not only does it suffer from the same issues as the disabled button it also runs the risk of “appearing” on a page when a user is already past it’s focus point. It may not be announced to the user of it’s appearance on the page, and now the user has to lay hid and seek to find the button (especially if the button was not a “submit” type but just a standard “button” type). 

And That’s a Wrap (The party not the present)

Well unfortunately no party lasts forever. While there is so much more we could discuss, the hosts of this party are getting a frustrated and telling me I am WAY over my word limit! So as this party draws to a close remember to spread the word, that HTML hates costume parties. Let’s have three cheers: 

A11y, A11y, A11y. Always!