{"id":198,"date":"2021-05-16T12:29:19","date_gmt":"2021-05-16T12:29:19","guid":{"rendered":"https:\/\/a11y-tools.com\/blog\/?p=198"},"modified":"2026-04-06T13:18:46","modified_gmt":"2026-04-06T13:18:46","slug":"enough-with-the-role-play-lets-get-back-to-the-basics","status":"publish","type":"post","link":"https:\/\/a11y-tools.com\/blog\/2021\/05\/enough-with-the-role-play-lets-get-back-to-the-basics\/","title":{"rendered":"Enough with the role-play\u2014let\u2019s get back to the basics"},"content":{"rendered":"

This article originally featured on the TPGi blog but lost images\/some formatting during a site update and rebrand, so I am re-publishing it here (minus any comments that were added at the time) until such a time as the original article is fixed.<\/strong><\/p>\n

Having read Steve Faulkner\u2019s post a short while ago about the often-questionable use of roles in HTML<\/a> when a more suitable native HTML element would be far better, I was prompted to come up with something that would help in some small way to alleviate this problem. Immediately, I had the idea of creating a user style sheet that specifically called out potentially misused roles.<\/p>\n

But before we continue any further, let\u2019s just take a step back and briefly remind ourselves why using a native element is better than redefining a nonsemantic <div><\/code>. For this, we will use the classic case of the button (and apologies to all those for whom this is old hat).<\/p>\n

How to make a button \u2013 the hard way<\/h2>\n

To create a button from scratch, you could <\/em> add a role<\/code> of \u201cbutton\u201d to a <div><\/code>. You would also need to add a tabindex<\/code> attribute so that keyboard-only users can activate this link, so you end up with this:<\/p>\n

\r\n<div role=\"button\" tabindex=\"0\">Details<\/div><\/code>\r\n<\/pre>\n
By default, this will neither look nor behave like a button, which isn\u2019t exactly ideal. Here is said button as viewed in the browser:<\/p>\n
\"The<\/p>\n
So, we can (and should) style it to look more like a button by adding some padding, a border, some hover and focus styles (the usual buttony traits) and eventually you will end up with something like this:<\/p>\n
\r\n[role=\"button\"] { margin: 10px 20px; display: inline-block; padding: 10px; border: 1px solid gray; background: #efefef; text-align: center; border-radius: 5px; font-size: 20px; }<\/code>\r\n<\/pre>\n
\n\"A
\nWith some hand-rolled CSS added, this now looks like a button (hover and focus styles\u2013not shown in the CSS exmple above\u2013also need to be crafted)
\n<\/figcaption><\/figure>\n
The problem here is that when you click on it or try to activate it using the keyboard, it does nothing. You still need to hook up some JavaScript to capture the click events and allow the button to be activated with Enter<\/kbd> key or Space<\/kbd>. So it\u2019s time to roll up the sleeves and write some code. Here is a script that does this:<\/p>\n
\r\nfunction doButtonyThings(){\r\n alert(\"Something button-like happens\");\r\n}\r\n\r\nconst allPseudoButtons = document.querySelectorAll('[role=\"button\"]');\r\nArray.from(allPseudoButtons).forEach(pseudoButton => {\r\n pseudoButton.addEventListener('click', event => {\r\n  doButtonyThings();\r\n });\r\n pseudoButton.addEventListener('keyup', event => {\r\n  if ((event.keyCode===13)||(event.keyCode===32)) {\r\n   doButtonyThings();\r\n   if (event.keyCode===32) {\r\n    event.preventDefault();\r\n   }\r\n  }\r\n });\r\n});\r\n<\/code>\r\n<\/pre>\n
Note that we also have to add even more script to make sure that when Space<\/kbd> is pressed, it doesn\u2019t do the default action of scrolling the page, something that\u2019s often forgotten even when Space is supported. This usually results in the button action taking place and then the page immediately scrolling away from wherever that action presented itself. Frustrating.<\/p>\n
In reality, the script that adds keyboard support will probably be much more complex than the example above. In most cases where people are creating buttons out of <div><\/code>s, they aren\u2019t hand-crafting small pieces of JavaScript. Rather, they are relying on heavy JavaScript frameworks to take care of this (think sledgehammers and nuts). But let\u2019s assume that one way or the other we now have something that looks like a button and behaves like a button. Because it is exposed as a button to assistive technology through its role<\/code> attribute and it responds to keypresses, it is accessible. It took some effort to get here but job done, right?<\/p>\n
How to make a button \u2013 the simpler way<\/h2>\n
Let\u2019s not beat around the bush, though\u2014it would\u2019ve been far simpler to do this:<\/p>\n
\r\n<button type=\"button\">Details<\/button><\/code>\r\n<\/pre>\n
About the hardest thing to do here is to remember to add type=\"button\"<\/code> to ensure that the button won\u2019t act as a submit button when it\u2019s inside a <form><\/code> element. But with just that markup, you get a button that\u2019s exposed to assistive technology as a button, looks like a button and responds to keypresses without having to add more JavaScript.<\/p>\n
So instead of reinventing the wheel each time, let\u2019s try to use what the browser already provides.<\/p>\n
User stylesheets to the rescue<\/h2>\n
I have a number of user style sheets that I use in my daily work that I can toggle on and off to highlight certain aspects of a page. It\u2019s not as robust a process as interrogating the actual markup in developer tools, but it does provide a quick at-a-glance view of the page, and it can give you very high-level overview about how the page has been developed. For example, I have user style sheets that indicate structural elements such as sections, lists, headings and tables. I have another style sheet that specifically looks for  aria authoring patterns<\/a> such as  tabs<\/a>, tree menus<\/a> and suchlike, and it attempts to visually indicate where certain patterns have not been adhered to. These ones are less robust, but as before, they can sometimes alert me to problems that require further investigation even before I run any automated testing tools.<\/p>\n
With the use of roles, I knew that there was a possibility that one of these diagnostic style sheets could be used to alert where a role<\/code> is used and, furthermore, indicate even more clearly cases where a role<\/code> has been applied where a native HTML equivalent would have been a far better option. I set about creating this style sheet, an excerpt of which you can see below (covering just buttons and links):<\/p>\n
\r\n[role=\"button\"]:before,\r\n[role=\"link\"]:before {\r\n  content:\"\ud83d\udea8 ROLE:\" attr(role);\r\n  border:2px solid darkred;\r\n  color:darkred;\r\n  display: inline-block;\r\n  padding: 0 5px;\r\n  margin: 2px 5px 2px 0;\r\n  border-radius: 5px;\r\n  background: white;\r\n  font-size: 16px;\r\n  font-family: sans-serif;\r\n  font-weight: bold;\r\n}\r\nbutton[role=\"button\"]:before,\r\na[role=\"link\"]:before {\r\n  content:\"\u26a0\ufe0f ROLE:\" attr(role);\r\n  border-color:orange;\r\n  color:black;\r\n}<\/code>\r\n<\/pre>\n
In essence, it\u2019s looking for role<\/code> attributes that we know have native HTML equivalents, and it screams at you. If the role<\/code> is applied to the equivalent HTML element, that scream is downgraded to a general grumble and some shifty, judgemental looks.<\/p>\n
Here\u2019s an example of it put to use on Gmail:<\/p>\n
\"Gmail<\/p>\n
In the spirit of openness and also so that others might be able to correct any heinous mistakes that I may have made, I\u2019ve  made this role-highlighting user style sheet available on GitHub<\/a>. Look for the CSS file named \u2018reveal-roles.css\u2019. (And also feel free to extend and enhance with pull requests as you see fit.)<\/p>\n
You\u2019ve found some issues. Now what?<\/h2>\n
It\u2019s one thing to highlight issues or potential issues on a page, but we ultimately want to be able to fix those. If you can 100% reliably identify a problem on the page, then you should be able to rectify it in a reasonably robust manner. With this in mind, I created a tool which I have called Role Reverser<\/a>. Using the same set of selectors used in the diagnostic style sheet, the tool can be used to interrogate markup that you paste into it, then replace any nonsemantic role-attribute-based HTML elements with their native HTML equivalents. Here\u2019s a before-and-after example:<\/p>\n
\"Side-by-side<\/p>\n
If you\u2019re a developer, this at least helps you understand what you might need to change on the page to make your markup more accessible by default. It also helps an accessibility practitioner quickly provide that semantic version in remediation advice that they give when auditing a site.<\/p>\n
The tool lets you paste markup into it to generate a more semantic version of the source markup, but you can also run a bookmarklet version of the tool on any page to see the effect of changing to native HTML elements. Going back to our old friend Gmail, here\u2019s the summary of what the tool finds on the page:<\/p>\n
\"JavaScript<\/p>\n
The alert reads:<\/p>\n