WebAIM: Web Accessibility In Mind. Contrast Rebellion - to hell with unreadable, low-contrast texts! The Accessibility Project. Making elements keyboard focusable and clickable. When you want to make an element on a web page clickable in order to trigger a JavaScript function, the best option is to use an element that has native support for keyboard interaction.
In most cases a button (either <input type="button" /> or <button type="button"></button>) is the most appropriate element. It lets everybody trigger your function, whether they use a mouse or not. Unfortunately, many (maybe even most) developers do not use the correct HTML elements for this. Instead they often use elements that have no native support for keyboard interaction, like span, div or li.
A slightly better choice is the a element since it can receive keyboard focus as long as it has a non-empty href attribute (i.e. So why do so many developers choose the wrong element to trigger functionality? Another reason is lack of knowledge. What do I suggest then? Use real buttons and style them so they look the way you need them to look. Option 1 is easiest and most robust, so that’s what I recommend. Making an accessible dialog box. In today’s web applications, dialog boxes are about as common place as they are in desktop applications.
It’s pretty easy to show or hide an element that is overlayed on the page using a little JavaScript and CSS but few take into account how this affects accessibility. In most cases, it’s an accessibility disaster. The input focus isn’t handled correctly and screen readers aren’t able to tell that something is changed. In reality, it’s not all that difficult to make a dialog that’s fully accessible, you just need to understand the importance of a few lines of code. ARIA roles If you want screen reader users to be aware that a dialog has popped up, then you’ll need to learn a little bit about Accessible Rich Internet Applications (ARIA) roles. In most cases, dialog is the role to use.
When an element with a role of dialog is made visible, the browser tells the screen reader that a new dialog has been opened. Dialogs are also expected to have labels. Setting focus to the dialog Conclusion. How-to: Hide Content - The Accessibility Project. Developers commonly use display: none to hide content on the page.
Unfortunately, this simple and common action is a bit problematic for screen readers. Screen readers sometimes ignore display:none1. This means the content will be read despite being “hidden”. To hide content completely from screen readers use the following: And for good measure you could consider adding the ARIA attribute aria-hidden="true" to the element. There are also real world situations where you want to hide elements (e.g., a form label), but you still want text to be read by a screen reader.
Consider adding these HTML classes and CSS rules to your base stylesheet and use them when applicable.