GrahamTheDev

Posted on Mar 24, 2021

Fixing dev.to accessibility [part 1] - 4 fixes that would take less than 10 minutes!

#a11y #inclusion #webdev

Summary

Dev.to is pretty accessible, there are some minor things they could do to improve though.

As part of this series I am going to slowly unravel things that dev.to could do to improve accessibility. This is not an attack on dev.to, I am hoping Ben, Jess etc. see this and take note though as whoever is advising on accessibility is missing some super simple stuff and quick wins! It is always good to have a second pair of eyes on something like this, so I hope to be that second pair of eyes!

In this first article let's start with 4 fixes that I would call "10 minute fixes" - or "triage"!

1. Sidebar navigation icons

The first one is a simple fix and I want to start off really easy! This is the "20 second fix".

The "home" SVG icon has a title - which is good (normally).

However here it is within an anchor that already has the text "home" so the link text will read "link home graphic home" in some screen readers.

1. Solution

Remove the <title> from the SVG!

For completeness I would encourage the use of role="presentation" as well and focusable="false" to fix a bug with IE where SVGs are added into the focus order of the page (assuming the site functions on Internet Explorer...haven't checked that yet!).

New html:

<a href="/" class="crayons-link crayons-link--block">
    <!-- add role="presentation" and focusable="false" -->
    <svg role="presentation" focusable="false" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 44 44" width="24" height="24" role="img" aria-labelledby="aofnu596u25u51zk4lid8elbrz1m351y" class="crayons-icon crayons-icon--default">
!<--remove the title -->
<title id="aofnu596u25u51zk4lid8elbrz1m351y">Home</title>
<!-- rest of SVG as normal -->
    <g class="nc-icon-wrapper">
        [SVG paths]
    </g>
</svg>
    Home
  </a>

Simple!

2. Headings

The site skips heading levels.

In fact the first heading on the page is a <h3> called "My Tags".

The next heading on the page is a <h2> for "Get The Daisy DEV Fall Jacket".

Then we get to the <h1> on the page and then all the other headings are <h3>s for the posts.

As headings are one of if not the most used way that screen reader users familiarise themselves with a page heading order is important.

We could let all of the above slide as I can understand the reasoning behind the usages - but the big one, the one that needs fixing is the use of a <h2> for the podcast.

I am not sure if this was a conscious decision to try and make podcasts more prominent in the heading structure but it completely ruins the logical structure of the page as all other posts below the podcast appear to be sub-headings of the podcast.

Why is it important?

Screen reader users use the keys 1-6 to cycle through headings (h1 - h6 respectively) as one of the primary ways to navigate a site.

If someone using a screen reader is used to using <h3>s to navigate articles on dev.to then they may completely miss the podcast!

Also the heading level errors discussed previously could mean important items are missed.

2. Solution

A slight "rejig" of heading levels and one DOM order change and everything would be perfect.

To fix the first issue simply move the <h1> in the source order to be the first item in the DOM. This may require using some visual trickery or a slight redesign of the page so I can understand if this one doesn't get implemented.

However for the rest of the items the fixes are simple!

Make the heading for "My Tags" an <h2> as that makes a lot more sense.

The same goes for "listings", "news" etc. (right hand navigation). They make a lot more sense as <h2>s as then a screen reader user can discover them and jump to them a lot more easily.

Finally make podcasts a <h3> so they don't ruin the relationships on the page.

3. Missing `alt` attributes

Now I know what you are thinking, you can't control user content (well we can but that is not a simple fix - more on that in a future installment!)

But the advert contained on the left hand side advertising DEV merch is surely controlled by dev.to.

3. solution

Add an alt attribute to the image!

This also solves another issue, the image is wrapped in an anchor tag. At the moment that anchor tag has no discernible text.

Adding an alt attribute would fix that as the accessibility tree could be built to use the alt attribute as the text for the hyperlink.

A two for one accessibility win! (although yet again I would probably "rejig" this bit as there are 2 anchors leading to the same place - the image and the text should ideally be within one anchor, in which case we would hide the image with alt="" etc.)

4. Keyboard usage for non screen reader users

Do you know how many Tab stops there are on each article? Between 8 and 12 depending on the number of tags added!

So if I want to reach the 10th article in the feed that is between 80 and 100 tab stops.....which is exhausting!

4. Solution

The structure of each article entry is perplexing to me.

First the whole article is a hyperlink, which means they have nested hyperlinks - so this is against the HTML standards which state:

Anchor Content model:
Transparent, but there must be no interactive content descendant, a element descendant, or descendant with the tabindex attribute specified.

Then the user profile image is a link to their profile, but so is their name, but as a separate link!

Then we have the date as a link? But that leads to the article. Then we have the article text....also leading to the article.

Then we have the tags which each lead to the individual tags pages (which is fine)

Then we have the reactions and the comments which all lead to the article and finally a save button (which is also fine).

What should they do instead?

First remove the hyperlink around the whole article, it isn't particularly useful and for screen readers it means that all of the content may be read out as link text (for clarity, the aria-labelledby they use here could possibly be ignored as there are active elements within the article link).

Second we need to handle the profile picture and link text being separate links.

I am going to suggest something that will upset automated testing tools - add tabindex="-1" to the profile picture. That is the simplest fix as it is still clickable by mouse. There are better fixes but these are meant to be simple fixes!

Next remove the hyperlink on the date, this leads to the article so is pointless as the article title leads there too.

Then leave the link on the article title (<h3>) as it is and the links on the tags (personally I would remove them to save tab stops but baby steps!).

Next remove the hyperlink on the reactions and comments, they serve no purpose here.

All in the tab order on an article goes from

Focus Article            >     link to article
Focus profile picture    >     link to profile
Focus author name        >     link to profile
Focus date               >     link to article
Focus H3 title           >     link to article
Focus tags (1-4)         >     link to tag(s) (1-4)
Focus reactions          >     link to article
Focus comments           >     link to article comments*
Focus "save"             >     save the article

* (leave link to comments maybe?) However I would argue that a skip to comments within the article is more usable as who comments without reading an article anyway?

to:

Focus author name        >     link to profile
Focus H3 title           >     link to article
Focus tags (1-4)         >     link to tag(s) (1-4)
Focus "save"             >     save the article

A saving of 5 tab stops which means reaching the 10th article now requires 50 less key presses!

*Note: * This is not the only thing I would do here, yet again these are simple fixes, I would add arrow key controls so you can just press up and down to jump between articles. I would also change the DOM order or the items in the article so that the title <h3> was the first item on the article but this would require some thought and possible redesigns and yet again these are simple improvements!

Conclusion

The fixes above would take next to no time and would make huge improvements to accessibility.

In the next part in this series I am going to focus further on keyboard functionality, covering things like focus indicator fails, additional controls (such as being able to use arrow keys to navigate articles more quickly) and the scourge of all keyboard users - infinite scroll!

This posts was designed as a very gentle introduction, in the next article I will also start linking to WCAG guidance that affects each part I mentioned.

This article was inspired by the latest dev.to podcast, go give it a listen!

A11yship is multi-dimensional — with Crystal Preston Watson and Marcy Sutton

Ben Halpern for The DEV Team ・ Mar 24 '21

#discuss #podcast #a11y

Ben, Jess - hit me up if you ever need some accessibility guidance, hopefully I can give something back to the community you guys have built 😋 ❤

Additional

As a complementary series to this I am also doing a series on "hacks to improve accessibility", which are ways to triage accessibility short term while a "proper" fix is implemented.

Check out the first part of that series:

Article No Longer Available

Top comments (17)

GrahamTheDev • Mar 24 '21

@ben , @jess I hope one of you picks this up and gives it to whoever deals with accessibility.

Once again can I say I love dev.to and I hope this series helps in some small way to make it even better!

Ben Halpern • Mar 24 '21

On it

GrahamTheDev • Mar 24 '21

If you decide to tackle number 4 I am happy to put a few options together for a “proper” fix, the suggestions here are purely quick wins.

Great to see you so responsive! ❤️

Christina Gorton • Mar 24 '21

I'll be checking our repo tomorrow to see if these are already issues and if not adding them to our repo. If you would like I can link them to you here and you can contribute if you have time!

Christina Gorton • Mar 24 '21

I know some of the keyboard ones you mention will be in a later post are known issues in our repo. I think our wonderful community members Rafi and Andrew Bone have been working in them 😊

GrahamTheDev • Mar 25 '21

Hi Christina

Sure link them here, not much time at the moment as trying really hard to get into a habit of writing but once I have done the entire series I will go through and see if any need adding to the repo.

Then when I have a nice pattern I will see if I can pick any of them up and help of course, however I am normally a bare-bones developer so I may be limited in which ones I can pick up! 🤣🤣

Andrew Bone • Mar 25 '21

For number 4 did you know there are keyboard shortcuts? You can press j and k to navigate between articles more easily. But tabbing with take you to each area within the post tile (this is also how twitter does it).

GrahamTheDev • Mar 25 '21

Yes but only through mashing buttons! It was only when you just said it then I realised you followed twitter pattern (or should I say the gmail pattern taken from some old editor in the 80s!), didn't even click 🤣

Also discovered the shortcut to search with ? but I have not discovered anything else?

Is there a page with shortcuts on as I could not find it? If there is then I will include that in my next article!

Also I feel there there is some key combination to change the number of articles jumped at a time with j and k hidden somewhere as I have managed to make it jump by 2 articles and 5 articles at a time but only by accident! Or is that some strange bug I discovered!

I approach everything as if I do not know any key combinations, hence the arrow key suggestion (which will also have a toggle) as that would be logical for 99% of people.

However perhaps that approach is not correct for a site that is likely to attract an unusually high proportion of power users, so I may need to curb my general thoughts on things.

I look forward to any input you have on my suggestions for anything that is best judgement!

Andrew Bone • Mar 25 '21

There is currently a bug that caused the the shortcuts to compound. It's actually a side effect of this issue

Preact Components not unmounting due to InstantClick page lifecycle events. #11458

nickytonline posted on Nov 17, 2020

Describe the bug

I know how to fix it @reobin . I will create an issue and put a PR up for it. We need to explicitly call unmountComponentAtNode in an InstantClick.on('change', () => {}) event. This is something that normally we wouldn't have to do, but because we use InstantClick, it's necessary. It also explains why I saw components repeated in the Preact dev tools.

I need to do it for pretty much all out components that get mounted via render. e.g.

import { h, render } from 'preact';
import { unmountComponentAtNode } from 'preact/compat';
import { Search } from '../Search';
import 'focus-visible';

document.addEventListener('DOMContentLoaded', () => {
  const root = document.getElementById('header-search');

  render(<Search />, root);

  InstantClick.on('change', () => {
    unmountComponentAtNode(root);
  });
});

To Reproduce

You will not see this behaviour as it's something under the hood. It manifests itself in an issue like #11371

Expected behavior

Preact components should be unmounted when an InstantClick even changes the page.

Screenshots

Desktop (please complete the following information):

OS, version:
Browser, version:

Smartphone (please complete the following information):

Device:
OS, version:
Browser, version:

Additional context

View on GitHub

I wrote an article asking how we can get better discoverability the other day but as of yet there is not a list of shortcuts.

Just press / should take you to the search, I think shift + / is still calling / functions though, I'd like ? to open a list of shortcuts one day 😅

forem.dev/link2twenty/keyboard-sho...

GrahamTheDev • Mar 25 '21

You know I should really look through all the bugs in the repo shouldn’t I lol!

Saying that it is way more fun having you “swat me down” on things that are already known 🤣🤣😜

Andrew Bone • Mar 26 '21

? no longer initiates search. That's one step closer

Neha Sharma • Mar 25 '21

One more suggestion for alt tag I can think of is:

Use image name as an alt tag. When the user is not providing any alt tag the image name can be used (assuming they will upload a meaningful name).

However, this needs to be handle when the image has no purpose for the screen readers.

GrahamTheDev • Mar 25 '21

I will be covering alt attributes for user generated content in a future post.

Although that is a great suggestion the big problem is that people are even worse at naming images than they are at filling in alt attributes.

A second issue is that images are named my-magical-image or myMagicalImage so trying to parse the text out of an image name can be frustrating at best, impossible at the worst!

To give you a hint - I will be making alt attributes more prominent when you upload an image and an integral part of the upload image workflow, see what solutions you come up with around that and we can compare notes when I write the article 😀😀

GrahamTheDev • Apr 21 '21 • Edited

@hellonehha I should have said - check out the following article and try the image uploader, not quite there but it should give you an idea of what I am thinking to address this issue.