Designing Fictions, Part 5: Accessibility Testing

This is the last installment to my process of designing my Fictions homepage. I’ve previously covered how I used typography as the base of the design, how I believe in writing thoughtful, semantic HTML as a foundation, on which I wrote CSS and designed in the browser. Lastly, I covered the sparse use of JavaScript on the page, including how it was and wasn’t used to animate elements on the page.

In this last installment, with all that covered, I’ll talk about the final touch up that many of us fail to handle in web design and development: accessibility testing.

Accessible Content for the Minority.

Ensuring the content is accessible by keyboard users and sighted users who use screen readers (the two overlap a lot) is a lot like testing for browser compatibility: we want to ensure that while the majority of our users are well served, the minority are also afforded good access to the content.

These days, when presented with a web app that looks and behaves beautifully with a mouse (with jazzy animations and whatnot), I’ll drop the mouse and try to see if I can tab myself across the entire page. More often than not, I fail. All those fancy frameworks and animations ain’t gonna impress me if you force your users to use a mouse to interact with your interface. I can only imagine worse if I was using a screen reader. Sigh.

Accessibility, From Beginning to End.

I said “touch up”, because accessibility is not something you do only at the end. It is an approach, a method, something that should be embedded in your work from the start. In an earlier post, I mentioned writing semantic and thoughtful HTML to create a digestible roadmap for users. That is the foundation of accessibility. But once we actually test things out with a screen reader and listen to our content, we will realize that there are a lot of problems well structured and coded HTML cannot solve. That’s where ARIA comes in to lend support.

Taking Things Further with ARIA.

The synopses on the Fictions homepage is a good example. Remember how I used the attribute “aria-hidden” to hide and show my synopses? I didn’t use the attribute because it’s cool, I used it because the attribute tells the screen reader when an element is shown or hidden. So when the synopses are hidden, the screen reader will come across them, find aria-hidden="true", and choose not to read them out to the user. Similarly, when they come across a synopsis that has aria-hidden="false", it knows to read out the content to the user.

That is, by making use of ARIA properties that are not native in HTML to enhance the content, I’m making it easier for users of screen readers to understand and access the content.

Making Things More Verbal.

On top of that, once I started listening to my content, I realized that more words had to be added in order for sighted users to understand the context.

Take for instance the span of text that tells the user which year a certain piece of fiction is created:

Partial screenshot showing the Scraps subsection, with a "2014 -" text beside it
“Scraps” is the name of the fictional work in question, in case you’re wondering.

An average user who visually interprets web pages will have no problem associating the numbers with the year each work is created. Once you have the user listen to this segment without any visual aid, though, the context is completely lost:

After hearing “Find out more about Scraps—button; 2014”, the listener will no doubt be wondering: what the hell does “2014” mean? Is that the year in which they are made? Is that the next fictional work? Or does it describe Scraps? There’s no way the listener can be sure, if I didn’t provide more verbal explanation to clarify things.

As such, in cases like this, I had to add words to the existing HTML content, words that are meant only for the listeners of content. This is achieved by wrapping such content in a visuallyhidden class like this:

<span class="works__year"><span class="visuallyhidden">Created since </span>2014 -</span>

Once I put in the extra effort to add in text to describe the content further, it makes a whole lot more sense now:

Finally, a Little Help From JavaScript.

Did I mention I also added aria-controls to the button/speech bubble icon that toggles the related synopsis? Ideally, with this control, I will now be able to communicate to the user that the button controls if the synopsis is visible for reading. As this article explains though, aria-controls is unevenly implemented across OSes and vendors. So just because I added aria-controls to establish a relationship between the speech bubble icon and its related synopsis doesn’t necessarily ensure a smooth experience for the user.

When the user presses the button that says,”Find out more about (name of the work)”, yes, I set the aria-hidden attribute of the related synopsis to false, but the user doesn’t know that. He will not know that the button opens a synopsis that can be tabbed to (I can use tabindex=0 to allow it to be tabbed to), and the first time he clicks the button he will no doubt be unsure as to how to proceed next.

That’s why I like to make things simple for my users by using JavaScript. In this case, by using Javascript to focus on the synopsis the moment they click on the button, I am ensuring that there is no room for him to be confused. Once he clicks the “find out more” button, he is directed to the synopsis in question and details are read out to him. After all, he did already indicate his intention to find out more, so why should I make him tab just to achieve that?

In this way, accessibility is an exercise in thinking for the user and placing yourself in the user’s shoes, and it is this step in the process that I was particularly careful about not leaving out, even if the webpage already looks functional.

The Amount of Work That Goes to One Page.

I’ve written a total of 5 posts to outline the approach to redesigning my Fictions homepage—a single webpage that is by most standards a simple one. Yet, as you can see, careful thought has to go into the typography, markup, layout, interactivity, and accessibility to make the page look good and function correctly. And I have not even gone into the details of testing the page on older browsers and portable devices (which I assume most professionals are more than well-acquainted with).

I’d, therefore, like to see web design and development as a rigorous discipline, with which there’s always room for improvement and experimentation. By sharing my personal approach, I hope that fellow professionals who read these posts will find new inspirations and ideas for their own projects. Every project, of course, is different, so my approach to designing Fictions will—and does—differ from my approach to designing, say, this blog. That is why I have largely shunned the mention of specific tools and focused mainly on the approach. As the industry matures, so will the tools change, but the basics behind designing a beautiful, functional page will always stay the same. Or so I hope. Thank you for reading this series, and I sincerely hope you’ve learned something from it.