UX

All posts tagged UX

Setting Up an Accessible Web Page: Making Images Accessible (A UX Accessibility Blog Post)

Posted by kayladsween on June 20, 2017
Posted in: Usability. Tagged: , , , , , . Leave a comment

This UX Accessibility Blog Series, “Setting Up An Accessible Web Page,” will walk you through the basic elements of an accessible web page in hopes that you can take what you’ve learned and apply it to more complex pages. This blog series is loosely based on Heydon Pickering’s book “Inclusive Design Patterns: Coding Accessibility Into Web Design.”

 

We’ve talked about what needs to be done to make images accessible multiple times before, but since the relationship between these elements and accessibility/inclusivity is an important conversation to have, we’ll go over them (maybe in a bit more detail) again.

Why?

As we’ve discussed in a previous blog post, images can help users comprehend what they are reading better by giving them something visual to associate with the text. For example, if you’re looking at houses to buy on Zillow, the pictures can help you decide if you are interested in the house even more than the text description alone of the house.

Visually impaired users do not have this luxury. They rely on only the text descriptions of pictures to help them gain a better understanding of what the images on a page are. Text alternatives are read by screen readers to the user in place of the image. Also, in the event that your user has a slow internet connection (out in the field, internet outage, etc.), the images on your page may not load at all, causing the alt text to be displayed in place of the images themselves. Adding alt text to your images also satisfies the first principle of web accessibility, perceivable. For these reasons, it is imperative that clear, descriptive alternative text be added to every image.

Every image should have an alt attribute. (bolded, italicized, and underlined because it’s just that important)

If your image also happens to be a link, make sure the alt text describes the link destination and not necessarily the image itself. For example, you have the FNC, Inc. logo on your page that links to fncinc.com, such as in your footer.

In this case, using “FNC, Inc. Logo” may not be very helpful. You’ll need to make sure the alt text says something like, “FNC, Inc Home Page”. According to Penn State’s accessibility article, “Image ALT Tag Tips for HTML,” providing a full description (saying “FNC, Inc. Logo. Directs to FNC home page”) is unnecessarily redundant.

Purely Decorative Images

Images that are used for purely decorative purposes, such as a horizontal line that separates two sections, don’t necessarily need a description. Penn State’s article uses a rainbow divider image as an example.


<img src=”examples/spectrumtooltip.gif” alt=”A Rainbow line used as a divider” >

Screen reader says “A rainbow line as a divider.” If you have eighteen rainbow toolbars, the screen reader would repeat this eighteen times. This text is irrelevant to a screen reader user and increases reading time.

In this case, adding the description in the alt attribute could just annoy the user. However, every image must have an alt attribute, so we can add the alt attribute, but leave it equal to an empty string. This satisfies the HTML requirement of having an alt attribute but also keeps screen readers from just announcing “image” when encountering an <img /> tag that doesn’t have an alt attribute.

Again, every image must have an alt attribute.

Setting Up an Accessible Web Page: When and How to Use a Menu Hamburger (A UX Accessibility Blog Post)

Posted by kayladsween on June 20, 2017
Posted in: Usability. Tagged: , , , , , , . Leave a comment

This UX Accessibility Blog Series, “Setting Up An Accessible Web Page,” will walk you through the basic elements of an accessible web page in hopes that you can take what you’ve learned and apply it to more complex pages. This blog series is loosely based on Heydon Pickering’s book “Inclusive Design Patterns: Coding Accessibility Into Web Design.”

 

Sometimes, to save screen real estate, it is necessary to use a menu icon to denote that the navigation region can be toggled into view. This is very common on small interfaces, such as smart phone screens. Using the hamburger icon to denote a collapsible menu has become convention for showing that menu options can be shown or hidden.

Why do we need an icon at all? Specifically, why the hamburger menu icon (glyphicon-menu-hamburger)?

It’s been long established that images help sighted users comprehend the meaning of certain functions faster than text alone. This is especially helpful when your target audience consists of users that could speak different languages or have poor reading ability. However, this doesn’t mean that we should remove text all together and only use icons to denote meaning. Newer internet users may not understand the meaning of a glyphicon, but they can read the word “menu” next to the icon and understand from then on that icon means “menu”.

The hamburger icon represents a list. As discussed in the “Site Navigation” blog post, navigation sections are conventionally denoted by using an unordered list. The three horizontal lines of the hamburger icon are used to represent a list. Assuming your navigation mimics a list, this greatly assists the inclusivity of your web page by following convention. As Heydon Pickering says in Inclusive Design Patterns: Coding Accessibility Into Web Design, “convention is a friend to inclusion.”

Glyphicons vs SVG

In his book, Pickering recommends using SVG to render icons. SVG stands for Scalable Vector Graphics and, according to Wikipedia, is an XML-based vector image format for 2D graphics that supports interactivity and animation. SVG images and the behaviors associated with them are defined in XML text files, which means they can be searched, indexed, scripted, and compressed. This can be extremely helpful when it comes to accessibility. SVGs also have the ability to change with the text color. Therefore, if a user has their browser set to invert colors, the SVG will change colors just like the text.

However, SVGs can be a bit more complicated than just using glyphicons, especially since glyphicons come standard in Bootstrap and Ensemble. Since glyphicons are a text font, they tend to behave like text. When the user resizes the screen or inverts the colors of their browser, the glyphicon will react to these changes just as text would. The only downside to using icon fonts is that some users may choose a different font that doesn’t play nicely with glyphicons, such as users have dyslexia and change fonts to reduce the difficulty of reading.

Communicating State

When using a menu hamburger to show that your navigation region is collapsible, it is important to use the aria-expanded attribute to allow assistive technologies to communicate the state (collapsed or expanded) to the user. If your menu is collapsed by default, add aria-expanded=”false” to your menu button. Make sure that the value of the aria-expanded attribute toggles between true and false depending on if the menu is expanded or collapsed.

Conclusion

When considering against using a menu hamburger or any other convention for an element, consider the implications on your users. Especially in the case of collapsible menus, it’s important to follow convention and communicate the menu’s state to maximize the odds that your users will understand exactly what you’re trying to convey.

Setting Up an Accessible Web Page: Site Navigation (A UX Accessibility Blog Post)

Posted by kayladsween on April 18, 2017
Posted in: Usability. Tagged: , , , . Leave a comment

This UX Accessibility Blog Series, “Setting Up An Accessible Web Page,” will walk you through the basic elements of an accessible web page in hopes that you can take what you’ve learned and apply it to more complex pages. This blog series is loosely based on Heydon Pickering’s book “Inclusive Design Patterns: Coding Accessibility Into Web Design.”

Why do we use an unordered list?

Using an unordered list is something that we’ve been doing since about 1997-2000 when HTML4 and XHTML were becoming standard. At this point, it’s just convention. We can style anything however we want these days, but we keep using unordered lists as navigation. In the event of a CSS failure, the navigation bar will revert back to a regular unordered list. This bulleted list of blue, underlined links is a visual indicator that this list serves some kind of navigational purpose. This way, we’re including older users, older devices, assistive technology users, and those experiencing a CSS failure all in one!

We wrap the list in a nav tag to trigger additional semantics and behaviors that allow AT users to better understand the purpose of this list of links. For example, screen reader users going through the navbar might hear “navigation landmark. List. One of five. Link: home.” It’s easy for your user to understand that they are in the navigation bar, how many links it contains, and if they want to go home, they can do so immediately after hearing the “link: home.” The nav element also automatically offers some screen reader users the ability to hit the D key and hear the list of navigation links while on any other part of the page.

More on Navigation Conventions

Although we like to make things look cool and new, sometimes it’s just best to stick with what we’ve always been doing, especially when it comes to navigation conventions. The human brain uses schemata to understand new things. This schemata acts as a cache for understanding, if you will, constituting the prior experience which the current experience is compared to. As humans, we like what’s familiar to us, so we’ll compare things to other things we’ve seen just to make sense of it.

When it comes to navigation bars, we don’t want to make our users think, which is a common idea in usability. This is why we typically see navigation bars at the top of the page with font larger than the rest of the page and different links right next to each other. It’s familiar to us. We can look at that and immediately know that this is the part of the page we need to use to be able to see other pages on this website.

Know where you are to know where you want to go

Another helpful aspect of navigation bars is when they show which page you’re on by making that navigation link or button “active.” Just like when maps in malls have the “you are here” dot, we need some visual “you are here” indicator in the navigation bar for the user. Typically this is built into the framework, so all you need to do is add some Javascript that adds the active class to whatever link represents the current page.

The active class usually does a good job of showing the user where they are, but the problem is that the active indicator is usually only color. This violates WCAG 2.0 Success Criterion 1.4.1 (Level A): “Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.” To solve this problem, sometimes an arrow can be used to indicate the current page. For example, in the default template in Ensemble, the left-side navigation has an arrow that shows the user which page they are on.

Although color alone isn’t a great indicator of showing the user which page they are on, it is important not to add other things to show the active page unless it is in Ensemble or it has been approved by UX.

Accommodate Multiple Navigation Areas with aria-label

When using a screen reader with more than one navigation bar (think secondary nav in Ensemble or a side navigation, as shown above), it is important to differentiate the two. A screen reader would label them both as “navigation”, as that is the default label for anything with the role=”navigation” or nav element. To solve this problem, WAI-ARIA has a global aria-labelledby relationship attribute to provide a label with heading text.

Setting Up an Accessible Web Page: Keyboard Focus (A UX Accessibility Blog Post)

Posted by kayladsween on April 4, 2017
Posted in: Usability. Tagged: , , , , . Leave a comment

This UX Accessibility Blog Series, “Setting Up An Accessible Web Page,” will walk you through the basic elements of an accessible web page in hopes that you can take what you’ve learned and apply it to more complex pages. This blog series is loosely based on Heydon Pickering’s book “Inclusive Design Patterns: Coding Accessibility Into Web Design.”

 

It’s important for your users to know where they are on your page at all times. This is especially true for your keyboard users, who often find it difficult to determine their location on a webpage.

Some elements, such as those that use divs, do not automatically receive keyboard focus or allow the user to navigate to them via the keyboard. Elements that are clickable but wouldn’t receive focus normally, such as infographic boxes in Ensemble, need to have the tabindex=”0” attribute added to them. Interactive elements should always be accessible. This way, keyboard users can navigate to them, see that they have received focus, and hit enter to navigate to the same place a mouse user would be able to navigate to.

For elements that are mostly text, such as paragraphs, keyboard focus isn’t necessary, although some users may find it helpful. To make sure blocks of text receive focus, add the tabindex=”0” attribute to your paragraph tag. This will addition will only enhance the experience of your keyboard users without adding any unnecessary visual noise for your mouse users.

Interactive elements that are written using semantic HTML have keyboard focus features baked in. Some examples of these would be <input type=”[text,email,tel,etc/checkbox/radio]”>, <button>, <select>, and <textarea>. Even though these elements are typically accessible, it’s important to always test your page for keyboard accessibility by tabbing through and making sure the tab order is logical.

Browsers typically implement their own focus styles, which are usually fuzzy blue halos or dotted lines. I like to use the browser default, but there are other ways to add styles to make focus more obvious than what is implemented by the browser. It is important, however, to NEVER remove or add styles that contradict the browser’s default implementation of focus styles. These are very important and help a variety of users.

An example of an improved focus style would be gov.uk’s implementation. They give the focused element a different background color from the rest of the text on the page.

keyboardFocus

Setting Up an Accessible Web Page: Inline Links (A UX Accessibility Blog Post)

Posted by kayladsween on March 22, 2017
Posted in: Usability. Tagged: , , . Leave a comment

This UX Accessibility Blog Series, “Setting Up An Accessible Web Page,” will walk you through the basic elements of an accessible web page in hopes that you can take what you’ve learned and apply it to more complex pages. This blog series is loosely based on Heydon Pickering’s book “Inclusive Design Patterns: Coding Accessibility Into Web Design.”

Links Should Be Underlined

Conventionally, links have always been underlined. With the rise of frameworks and CSS usage, the amount of underlined links has started to decline in favor of using text-decoration:none on anchor tags and only changing the color of the link to differentiate it from other text. This is no good. Links should continue to be underlined for the sake of all of your users.

It is hard for most users to differentiate a link from other text if they are different in color alone (especially colorblind users), but it also makes it more difficult for the user to determine if it is a link at all. Some users may think the different color is meant to show emphasis instead of denote a link.

Another problem is that some users may skim paragraphs in search of links. These links stand out more when they are both underlined and a different color from normal paragraph text.

The only exception to this is navigation bar links. Most people understand that your navbar will take them to other places on your website, so there’s no need to underline these links.

I touched on this in my Accessibility workshop and in a past blog post, “Four Benefits of Designing for All Users.”

It’s important to create links that concisely describe where the link points to. For example, if I was sending you to the blog post mentioned above, instead of saying “to visit my blog post, click here” I would say “Check out my blog post on designing for all users.” When the user clicks on “my blog post on designing for all users” they know exactly what to expect when they get there – a blog post about designing for all users.

Some users elect for their screen readers to read through the links on the page as a way of skimming the text. If all of your links are just “click here,” “more,” “here,” etc., it makes it hard for screen reader users to know where the link will take them to. Hearing all of these links out of context can also be very confusing and disorienting for the user to experience.

Using the word “link” in your links also is redundant if you’ve already followed my recommendation above on underlining the link and used a tag to denote your link. The user will be able to tell that it’s a link based on the underline. A user who relies on a screen reader would know that it was a link because typically screen readers tell the user when they’ve encountered a link.

Setting Up an Accessible Web Page: The Paragraph (A UX Accessibility Blog Post)

Posted by kayladsween on March 7, 2017
Posted in: Usability. Tagged: , , , . Leave a comment

This UX Accessibility Blog Series, “Setting Up An Accessible Web Page,” will walk you through the basic elements of an accessible web page in hopes that you can take what you’ve learned and apply it to more complex pages. This blog series is loosely based on Heydon Pickering’s book “Inclusive Design Patterns: Coding Accessibility Into Web Design.”

Readability is Important

It’s important for all of your content to be easy to read and concise. While there aren’t a lot of guidelines that say whether your paragraphs are accessible or not, there are a few things to keep in mind when writing content for a website:

  • Keep it short

    • If you can say something in 5 words instead of 20, say it in 5. People typically don’t like to read. They especially won’t read something if they think it’s too long.

  • Passive Voice

    • Don’t use passive voice unless absolutely necessary. Using the direct alternative tends to be easier to understand and shorter than its passive counterpart.

  • Redundancy

    • Saying the same thing twice in different ways is usually just a waste of effort. Users rarely will benefit from having the same thing said to them twice. (This bullet point is a good example of what not to do.)

  • Variety

    • If your content is long, try to vary the length of sentences within your paragraphs and even the paragraph lengths themselves. Varying the length and sentence structure helps encourage your users to focus.

Readability also includes typefaces, spacing, type setting, line height, etc. For the sake of keeping this blog post under 50 pages and rehashing too many things that are already taken care of in Bootstrap and Ensemble, we’ll stick to some basic ways to help make your paragraphs more readable.

Justification

It may be tempting to use text-align: justify; on your paragraphs so that they’re all even on both sides. Though this works in print form, it doesn’t carry over to web as easily and is actually considered bad practice for web content. While it may make your paragraphs appear a little neater, the readability of your content suffers. Since justifying content tries to make all of the lines in your paragraphs equal, the spacing between words and breaking up words can be distracting for your user. Hyphenating words across lines isn’t even supported by some major browsers, and even if it is, the Javascript used to do it is extremely large because it needs to be able to reference every English word to find the best way to hyphenate them.

Your users will only care that your content is left justified. Jagged lines on the right side of your page should be the least of your worries when it comes to usability and readability.

Contrast

Make sure your main content has sufficient contrast. If you’re not sure if your content has sufficient contrast, check the background color and font color with WebAIM’s Color Contrast Checker. The contrast between the text on your page and the background is very important when ensuring your content is readable. 4.5:1 for large text (18+ point font, typically) and 7:1 for normal text (14+ point font, typically) or higher if possible. High contrast between the background and the foreground is helpful for all of your users.

Setting Up an Accessible Web Page: Skip Links and The Main Element (A UX Accessibility Blog Post)

Posted by kayladsween on February 8, 2017
Posted in: Uncategorized. Tagged: , , , . Leave a comment

This UX Accessibility Blog Series, “Setting Up An Accessible Web Page,” will walk you through the basic elements of an accessible web page in hopes that you can take what you’ve learned and apply it to more complex pages. This blog series is loosely based on Heydon Pickering’s book “Inclusive Design Patterns: Coding Accessibility Into Web Design.”

<a href=”#main” class=”sr-only sr-only-focusable”>Skip to Main Content</a>

Screen readers start out by first, as we discussed in the last blog post, announcing the page title. The next thing it starts to announce is the navigation bar. If this isn’t the first page the user has visited on your site, they may not want to hear the navigation spiel over and over again. It will also help keyboard users to not tab through every link in your navigation to get to where they need to go in your main content. “Skip to Content” links can help your users bypass blocks of repeated content and generally have a better experience on your website.

It is important for this skip to content link to be the first element in your body tag for it to be beneficial. These skip links shouldn’t be visible by default because a lot of your users won’t need it (and it’s kind of an eyesore). To show your skip content link to those who actually need it, just add class=”sr-only sr-only-focusable”. This ensures that screen readers will read the skip content link immediately after announcing the page title and will be the first thing your keyboard users can navigate to.

<main id=”main”>

The main element is used to contain the main content of the page (of course). This content will be unique from page to page. According to the W3C HTML Editors Draft, the main element “consists of content that is directly related to or expands upon the central topic of a document or central functionality of an application.” It was introduced to HTML5 formally as a way to map the ARIA role “main” to an HTML element, (ideally) eventually phasing out the need for role=”main”.* Many screen readers and other assistive technologies recognize the main tag as where the main content of the page begins and gives the user a way to bypass repetitive content, such as navigation bars.

Since the main element represents the main content, it should be used only once per web page. It also can’t be used as a child element of any other document outline element, such as <article>, <aside>, <footer>, <header>, and <nav>. Also, it is important to make sure your navigation bar is not included in your <main> element since it is repeated on all of the pages of your website.

Some people still print out web pages. This is very possible since we work with clients that sometimes need to go out in the field and have the information we provide to them on hand. The main element also makes it easier for us to accommodate users who print out our web pages. The main element helps these users by targeting an area of our page that has all of the information they need to be able to print (i.e. data tables) and none of the stuff they don’t (i.e. navigation elements).

*NOTE: You should still use role=”main” until all browsers map the role to <main> automatically. I believe IE11 and earlier still don’t. In older versions of IE, it may be necessary to add document.createElement(‘main’); since it doesn’t recognize main as an element.

</main>