DEV Community πŸ‘©β€πŸ’»πŸ‘¨β€πŸ’»

Cover image for The problem with the "typewriter” effect and how to fix it
Savvas Stephanides
Savvas Stephanides

Posted on • Updated on • Originally published at savvas.me

The problem with the "typewriter” effect and how to fix it

About

So you want to show off your portfolio website and you want to add some fancy graphics to show off your Javascript skills. What better way than by adding a fancy "typewriter effect" to show the world your multi-faceted personality?

It's nice, sure! But there's a problem. And it has to do with accessibility.

The problem

Simply put, blind people visiting your website with screen readers, just can't see what the hell you've written on that section.

When their screen reader goes over that section, it will read whatever is currently written there. For example if "typewr_" is displayed at the time the screen reader has focus, it will read just that. That will confuse your screen reader visitors and most probably leave your website.

For example, let's create a typewriter effect on our website that cycles through the words "Developer", "Designer" and "Coffee addict".

The HTML will look something like this:

<h1 id="typewriter-effect">
  <span id="text"></span>
</h1>
Enter fullscreen mode Exit fullscreen mode

Some Javascript will then be added to populate the <span> letter by letter. See CodePen for the complete example.

If we visit your website using VoiceOver on iOS (a popular screen reader feature for the iPhone), the section where you have your typewriter effect will sound like this:

Coffee underscore. Heading level 1

because at the time of focus, "Coffee_" is displayed on that section.

See here for a video with audio.

Far FAR from what you want your user to read. You'd want your user to read something like "Developer, designer and coffee addict".

The solution

ARIA attributes to the rescue!

We are going to use ARIA labels to do two things:

  • aria-label in order to tell the screen reader what to actually say instead of what's in the heading or <span>.
  • aria-hidden="true" in order to tell the screen reader to skip the typewriter effect altogether and read the label instead.

That way, when the screen reader user goes to the heading section, they'll get exactly what you want. The HTML will therefore now look like this:

<h1 id="typewriter-effect" aria-label="Developer, designer and coffee addict">
  <span id="text" aria-hidden="true"></span>
</h1>
Enter fullscreen mode Exit fullscreen mode

Check this CodePen for the complete example.

Check this video to see how the screen reader now reads your page. THIS is what we want! πŸŽ‰πŸŽ‰πŸŽ‰

But why?

I hear you ask:

  • Is is that important to be accessible?
  • Do I actually need to make some novelty feature such as the typewriter effect accessible to screen reader users?

The answer is Yes and Yes. It is your responsibility to make your website accessible and inclusive. And not just as an afterthought. Accessibility should be part of your default workflow. Use semantic HTML. Add alt tags to all your images. And yes, use ARIA attributes where necessary. Be inclusive. Be human.

How about you?

Do you have a "typewriter effect" on your website? Have you made it accessible? If yes, what steps have you made to make it accessible? Let me know!

Top comments (8)

Collapse
 
eddyvinck profile image
Eddy Vinck

It's a valid concern, and something often forgotten on many developer portfolios. Nice article!

I'm a big fan of the visually-hidden class for these kinds of problems too. If the contents of your typewriter effect are important, it might even be a more suitable choice because the search engine will pick up on it. At least from a quick search I can't find any sources indicating that search engines pick up on aria-label or similar attributes.

Collapse
 
savvasstephnds profile image
Savvas Stephanides

It's a valid concern, and something often forgotten on many developer portfolios. Nice article!

Thank you! I have visited countless portfolio websites with the "typewriter effect". Nothing against it, but none of the site developers bothered to make them accessible

I'm a big fan of the visually-hidden class for these kinds of problems too.

Same! Both methods are valid but visually-hidden class gives some flexibility as to what tags to use.

If the contents of your typewriter effect are important, it might even be a more suitable choice because the search engine will pick up on it

More often than not, they're not, since it's difficult for search engines to pick up on typewriter effects in the first place. Good idea though.

Collapse
 
adam_cyclones profile image
Adam Crockett

Would role=presentation work better or about the same?

Collapse
 
savvasstephnds profile image
Savvas Stephanides

Not sure that’d make a difference to be honest. My knowledge of roles is a bit fuzzy.

Collapse
 
adam_cyclones profile image
Adam Crockett

From my understanding role from aria specification, where role is presentation you are not hiding the element entirely just telling the AT that the Symantecs should be ignored. Im about to say something stupid but role presentation does the same thing as aria-hidden almost. πŸ€·β€β™‚οΈ Somebody else will know.

Thread Thread
 
alexanderjanke profile image
Alex Janke

Only 90% sure about this so take it with a grain of salt:
presentation role does remove the semantics but not on focusable elements (buttons, links, ...) - except images I think(?).

aria-hidden is a lot more aggressive and removes pretty much everything, including child-elements from the AT

Thread Thread
 
savvasstephnds profile image
Savvas Stephanides

Makes sense. I still got a lot to learn about roles

Collapse
 
darkwiiplayer profile image
π’Š©Wii πŸ’–πŸ’›πŸ’šπŸ’™πŸ’œπŸ’πŸ’Ÿ

It is your responsibility to make your website accessible and inclusive.

Well, I mean, not really; just as it isn't your responsibility to make the website for anyone in the first place. In the end it's just a means to reaching a bigger audience, which is probably what you want when you're building a website.

Of course, things are different when you're getting paid for building the website.

This post blew up on DEV in 2020:

js visualized

πŸš€βš™οΈ JavaScript Visualized: the JavaScript Engine

As JavaScript devs, we usually don't have to deal with compilers ourselves. However, it's definitely good to know the basics of the JavaScript engine and see how it handles our human-friendly JS code, and turns it into something machines understand! πŸ₯³

Happy coding!