User Experience and Accessibility

User Conversations

One of the primary tools in identifying UX needs for a site is user conversations. The conversation should look very similar to the one we had with the customer, but in this case you would be speaking with somebody interacting with the site instead of the primary stakeholder for the project.

The key concept to understand is not to present the user with your own ideas, you should focus on asking questions and clarifying your understanding of what they're telling you. In general, you can follow these steps:

1. Ask an open-ended question about an area you want to learn more about.
2. When they pause, repeat back your understanding of what they just said.
3. If you don't understand something, ask if they could provide more information.

There are a lot of great videos on YouTube covering this topic. This one covers this concept in a lot more detail and is pretty good, but any by "Startup School" or "Y Combinator" are pretty high quality. Because startups gain traction when the functionality isn't quite there and have to rely on a strong positive impression to keep momentum, advice for those companies is heavily centered on UX.

After speaking to several users, you'll start building up an understanding of the different kinds of users who use a system. You'll start identifying patterns and it can be helpful to summarize these patterns so they can be easily referenced later on. One way to accomplish this is to create fictional characters called Personas, which tell a story about how they use the system.

Testing Assumptions

User conversations and personas are great in identifying possible ways to improve the system, but it's easy to make assumptions that don't play out in practice. There are a number of techniques you can apply to verify that the changes you make have the intended effect.

One tool in this arsenal is A/B testing. Simply put, you split your sites traffic in half, presenting each group a slightly different version and then measure the impact the difference has on some sort of goal. For example, during a presidential debate a candidates fundraising site could split traffic between a photo of the candidate and their opponent, measuring which one leads to more people clicking on the donation link.

If A/B testing isn't possible for some reason, you can still identify some metric and observe if it improves after a change is released. We'll cover these ideas in more depth when we get to monitoring later in the semester, but the key idea is that you need to verify that the change you're making is actually creating the intended effect.

Although their practices can get rather unethical, Facebook is famouse for using these techniques to foster growth. I recommend this interview with Mark Zuckerberg if you want to learn more about how they approach growth. At all but the largest companies, having a dedicated growth team is probably a poor investment, but that doesn't mean that these ideas can't be applied at a smaller scale to ensure your changes are effective.

Page Structure

The foundation of an accessible site is well organized HTML. You can throw in all the alt and aria- attributes you want, but none of that will be as powerful as a simple organization that mirrors the actual structure of the content. Peppering your page with divs and spans to provide hooks for styling is tempting, but any time you end up communicating a concept through CSS you exclude people who can't see that styling.

Of course, what do you use to structure the page if you want to minimize divs? HTML5 introduced a number of Semantic Elements to serve this purpose. When one of these applies to the content you're trying to encapsulate, they are a very good choice to use instead. That's not to say that you'll never find yourself needing a div, but very often you can replace it with something that has more meaning like nav or header.

Annotations

Sometimes you need a visual aid to effectively convey something to people who can see, or you need to build something that doesn't have a semantic tag. In these cases, there are special attributes you can use to annotate the element.

Images are the classic example, there's no way that somebody visually impaired will be able to benefit from the information delivered by it. In these cases, you can use an alt attribute to provide a description of what you're attempting to communicate. Tailor this content to what you're attempting to accomplish, more isn't necessarily better, think about the impact you're trying to achieve for sighted users and limit it to that.

When you do need to use a div for some reason, try to come up with an Aria Role to describe the concept. As noted on the site, very often these days there's a semantic element to achieve the same purpose, but Aria attributes can provide important clues to communicating your intent.

Other Limitations

A lot of the material I've covered has been geared towards the assumption that the user is visually impaired. But as I mentioned above, your considerations should extend to other limitations as well.

Consider somebody who has difficulty using a mouse. To work around this problem, they would use keyboard controls to move around a page, but this only works if things like tab work as expected. This doesn't mean you have to create a bunch of custom keybindings, just keep your HTML structured in a rational way. Semantic tags and ordering your elements in the order you want them to read will go a long way towards achieving this in modern browsers.

Also keep in mind that just because somebody has visual limitations doesn't mean they'll be using a screen reader. For example, somebody who is color blind can use most websites without a problem, but would struggle if color was conveying something important. Even if you have hooks in place for screen readers to tell the difference, they'd be unable to benefit from that.

Testing

You can use tools to simulate the experience these users will have on your site. There's no better way to identify accessibility issues than experiencing the same thing they do.

For example, you can use a screen reader to browse the pages and get a pretty good idea of where it's difficult to interact in that way. There are browser plugins that exist that simulate different kinds of color blindness. What about navigating through the site without using a mouse? Put yourself in their place and see what's difficult.

Course Improvements

As part of preparing for this lesson, I went through this site and addressed some accessibility issues. The biggest one I discovered was an underuse of semantic elements to structure my articles, I wasn't using article or section tags to break down their structure. You can see all of my changes in this commit.

Of particular note is my introduction of the Date component. One of the things I learned while reviewing my semantic elements was that dates should be wrapped in a time tag, and coupling that with the logic to convert the Date object into a string meant a lot of repetition in the codebase. So I captured that concept into a component that I can use reuse.

This notion of reuse is an important concept in programming, one that will allow you to keep things organized as complexity grows. Whenever you find yourself doing the same thing over and over, it's worth taking time to figure out how to eliminate that duplication. A useful acronym to keep in mind is DRY for Don't Repeat Yourself, it's not uncommon to hear people talk about how code isn't very DRY or how they're DRYing out the code.