The Australian Government coat of Arms

Communities of practice

Responsive Image Slider / Carousel


I’m using the Bootstrap 4 responsive slider in my projects, but a consistent gov styled one would be nice.


Hey @AnitaWatters

I agree that image sliders being more consistent and accessible across government would be great.

The image slider component is often quite a controversial component see:

I would love to know your thoughts on what how to make an image carousel useful for an end user :slight_smile:


Yes, unfortunately that’s a very poor example of one. It moves too fast for the content and it has too many slides. We use Sliders on our Intranet Home page and on the Home page of the project I’m working on. In both examples they are used for news items and are kept to no more than 4 to 5 slides (max) - preferably only 3 to 4. They include an image to convey meaning, because that conveys a message a lot quicker than a bucket load of text and a brief heading or sentence about the article. There is often a clickable link within the slider and it take the user to a new tab with more information about that news item.

I feel that they do have their place, but they should be used in a measured and considered way.

When thinking about the end user, I’m thinking in terms of sites with large volumes and often static content. The slider grabs a users attention and directs them to new content.

The timing of sliders is important and particularly in your example, can have a negative impact for the user if it isn’t done properly. Too fast and there’s no point in having it, too slow and you’ll lose the users interest.

I test mine by reading out the content out-loud. If I can comfortably read the content out loud before it moves onto the next slide, then it’s usually a comfortable speed for others reading the content for the first time too. We also test with end users during Alpha and Beta phases as well, this round we haven’t had any negative feedback about the timing. We received positive feedback that the content was more ‘engaging’ then just reading the same content in a thumbnail list.


Thanks for the great reply @AnitaWatters you have some great points about how they can be used in successful ways :+1:

I am really interested to see everyone else in the communities opinion on this.

If you have any examples of screenshots/code or accessibility it would great to share them here if possible!


I’ve found with accessibility they can be problematic and greater support needs to be given building the component, but I understand AccessibilityOz have an image slider on their site which should be accessible so that would seem a good example to start with, but then I’ve tested it with JAWS and the results are mixed. I agree with @AnitaWatters though that they should be used pragmatically


I was trying to resolve the JAWS issue this week on my slider. I’m also working through bugs for Dragon Naturally speaking with it. It’s been sent back to the Assistive Technology team for re-testing. I’m sure that there is a solution, I just not sure that I’ve found it yet.

I was wondering if a more simple solution would be to hide the Slider from the screen reader altogether and include a screen reader only span that would include links similar to the “Skip to main content” type ones, where you could have the heading of each slide followed by an option to skip to the next slide, then the content of the Slide read to the user.

I dont use assistive tech myself and I’m trying to imagine this from the perspective of someone using the screen reader. If they have no visibility of the screen, then their user experience would be similar to someone who can see the screen and has the option to look at each slide or not. If they do have some view of the screen, it might be really annoying because what the screen reader is saying may not match what is displaying in the viewport.

I’d be really interested to hear from people who use a screen reader about how they experience navigating carousels. I’d go sit with someone at work, but I haven’t identified anyone in my office who uses one and the Assistive Tech team are in another state.


Hi Anita.
What about a link/button before the carousel that destroys it. So it instead renders simply as linear content?
This would help address the WCAG criteria 2.2.2. And still allow for all its content to be available to assistive tech. Not just the slide that happens to be visible at the time it receives focus.


My understanding was that only what is visible on page load was visible to the assistive tech, not what is visible when it receives focus? If I’m right, then triggering the slider to dismantle would still be considered a dynamic change on the page and new content remain inaccessible.

From the Guidelines for Speech-Accessible HTML for Dragon NaturallySpeaking and Dragon Medical:

“Dragon enumerates the elements on a web page only in response to a BeforeNavigate event. Dragon is unable to detect when the elements on a page have changed by means of script. In particular, it does not detect a text entry field that has been dynamically added to a page, or if it is in a DIV that has been hidden and redisplayed. The symptom is that dictation appears in the Results Box but does not get placed into the text entry field.”

I’m not that great with JavaScript, so maybe there is a way to get the page to reload or refresh or something after each slide, or even hook into the accessibility software somehow and ask it to refresh but I’m also thinking that this might have some sort of negative impact on the number of server requests or would complicate cross browser rendering or cause unexpected behaviours. It just seems like a far to complex path, like there should be a simpler solution.

The documentation that I have for JAWS is mostly pointing towards ARIA support as a way of making all content accessible to the screen reader. It also seems to rely heavily on accurate html syntax/semantics to navigate. For example, (using the Bootstrap 4 Carousel) I had carousel indicators at the bottom center of the carousel that just look like dots, but the current slide has a slightly different styled dot. Without ARIA role=“button” - these spans had no context or meaning for the JAWS user. I ended up inserting screen reader only spans with a button tag inside it containing “Slide 1 of 4”, “Slide 2 of 4” etc to give more meaning to what these otherwise empty spans do.

This doesn’t resolve the Dragon issue, but it seems to support JAWS accessibility (again, its with Accessibility for testing, so fingers crossed) - but my thoughts were that if I pulled the content out entirely into screen reader only spans, then the content would be present on the page, but not displayed to the sighted user, but could be linked somehow to the dynamic content, maybe by some sort of ARIA labelled-by or by ID reference of something?

The Dragon user can see the page, so if they use voice commands to access what they can see, but we use the screen reader only content (that is fully loaded on the page having been removed from the dynamic content) to give effect to what they are asking, then their experience of the page, would be as if it is working on the visual content rather than the hidden content.

Hope that makes sense…?


Assistive Tech should read from the browser DOM. After the html, css and javascript has done its thing. Further to this, AT should be able to pick up on and announce changes to content within elements that contain a role=“alert” and/or aria-live attributes.

I was introduced to an interesting page a few days ago called the:
Basically a webpage page with a bunch of A11y errors in code. But zero A11y errors in DOM. Plus with the offhand comment:

There are no accessibility errors on this page. If your tool finds some, find a new tool.

Sounds like Dragon NaturallySpeaking positions itself more as a productivity tool than an Accessibility tool. A greater focus on dictation and read-back. I’ve never used it myself, I do most of my testing with NVDA.


Hmmm. I did think it odd that it didn’t find certain page content, but I still have to build for the range of accessibility tools that our Department offers staff. Some staff use Dragon when they have or are recovering from Repetitive Strain Injury (RSI) or in other rehab situations and they use the tool as much for navigating software as they do dictation.

We found that elements that gracefully degrade when Javascript is turned off were fine, so maybe another approach could be to turn off the JS and see what the carousel does then.

Certainly gives us some options to explore, but unfortunately changing the software that I need to code for is outside of our scope.


This would be an interesting shift in design direction if this component were adopted.

We were originally advised by the DTA that carousels were universally a bad thing and should be completely removed from our old site as a top priority and replaced with cards in all instances. This was for all the reasons outlined in Alex’s link. Even if you make them accessible, very few people see past the first slide and no one clicks on any of them.

If there is to be a carousel component we would appreciate some guidance on when to use it instead of cards, if ever.


@podgkin The DTA currently don’t have plans to add a carousel to the Design System for all the same reasons. — But we’re happy to support a conversation around how they can be built in a more user-friendlily and accessible way for the benefit of all the teams who need them.


Carousels are often considered to be anti-usability and anti-accessibility and people argue endlessly as to whether image carousels are UX assets or liabilities. However, while we may deride them they a fact of life and often required by marketing and comms groups.


As @treb said, the DTA doesn’t have any plans to add a carousel to the Design System at this stage, so I’m sharing a couple of resources to assist those of you who find they are required. The W3C developed a tutorial for an accessible carousel at Web Accessibility Tutorials - Carousels and Smashing Magazine published some tips for making them work for users at 10 Requirements For Making Home Page Carousels Work For End Users (If Needed).

If you do find you have to provide a carousel, you must make sure it works for all by testing it with people with disability.


We’re up to our second round of testing with the Accessibility team. They are testing the carousel for accessibility mainly with Dragon Naturally Speaking and JAWS screen readers. Hoping to have some code up on GitHub for open source feedback and testing by the end of the week :slight_smile:


Hi, Sorry this has taken so long. I’m not familiar with GitHub and I’m pretty new to coding in general. I’ve managed to get it up on GitHub, but I dont want to mess up the Design System code. So, here’s the link to what we have so far.

Please make any and all suggestions for how this can be improved.

Note: I haven’t uploaded any images to sit inside the carousel, if you want to play with it yourself, make sure that the images you choose are all the same width and height.


Nice job @AnitaWatters I really appreciate the hard work and sharing it with the community.

I’ll see if I can give some feedback next week :slight_smile: