The main point is, please do the basics. When designing a website, ensure controls with button-type behavior (interaction, affects the current page) are designed as buttons and regular text links (go to an external page, anchor on page, or external document) are designed like text links (such as blue underlined text).
When developing a website, ensure buttons are coded as buttons (the button or input element) and links are coded as links (the anchor element).
Here are some reasons why it’s so important:
accessibility and usability
a more robust website (support older user agents, non-JS, etc.)
lighter and less complex code
more consistent implementation so easier to maintain
Remember that for accessibility, no matter how much ARIA and trickery is done, there will mostly likely still be problems. When blurring the distinction between a button and a link, assistive technology (and/or the user) can be confused as to what’s what. View the beginning of this presentation by Derek Featherstone for a good example of this.
This advice sounds simple, but this elementary guideline is broken quite often; once you start to look, you’ll find it everywhere on the web, especially web apps. There’s no need to create confusion (the design) and to re-invent the wheel (the development). Sticking to the basics will make it easier for everyone, most importantly the user.
For an example of proper implementation, check out Easy Chirp.
A short while ago, my author @DennisL read the excellent book Don’t Make Me Think, Revisited by acclaimed usability professional Steve Krug. Dennis was so impressed with the book, he tweeted a series with quotes, mostly relating to accessibility (as well as design and usability). So in case you missed it, here they are:
Webpages require a prominent “You Are Here” indicator. ~Don’t Make Me Think Revisited (pgs 77-78) by @SKrug#webdesign#ux#dmmt
Follow Harold in his quest to make an accessible website for his company Jiffy Brothers! This is an entertaining two-part video series about a fictional company and its website. It’s produced by The Human Resources Professionals Association (HRPA) of Ontario, Canada. Watch out for Boris!
I don’t think that a carousel itself is super terrible. But in my experience, carousels are hardly ever coded with accessibility in mind and hardly ever designed with decent usability. In addition, supporting smaller devices is an issue and coupled with the poor usability data, carousels are overall a bad idea. If you absolutely must implement a carousel, here are some design/interaction tips:
Let the user start the carousel animation.
Give the user the ability to pause the carousel.
Ensure the controls have textual labels.
Ensure the control of the currently displayed panel is indicated visually and programmatically.
Ensure the controls have ample hit areas (for mobile, fine motor disability).
On the development side, a carousel can be challenging to make screen reader accessible. It seems that the most straight forward approach is to use the ARIA tab model which is pretty straight forward and fun to do! Here’s a summary of what to do in the markup:
Each carousel content container has a role of tabpanel.
Each control, typical designed as dots, has a role of tab.
The container of the controls/tabs has a role of tablist.
Add aria-labelledby to the tabpanels which point to the id of the associated control/tab.
To each control/tab, add aria-controls (which points to the id of the associated tabpanel) and aria-selected (boolean) attributes.
Here are some code resources to help make sense of this. This first by Marco may be most relevant: