GrahamTheDevSummary
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!
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:
