Texas Gas Service Homepage

Another accessibility disaster. It’s great that people are finding creative ways to use JavaScript but it is not okay to ignore progressive enhancement techniques.

Your users should never see this instead of content:

Our site requires javascript, please enable javascript and refresh the browser window.

JS frameworks do a disservice to the Web after all the innovation and hard work that has gone into creating a separation model for content, presentation and client-side scripting.

drawing of a peanut M&M candy showing content as the peanut, presentation as the chocolate layer and client-side scripting as the candy shell
Layering content, presentation and client-side scripting – Drawing by Dave Stewart

The Texas Gas Service website gives us lots of examples. Let’s see how well we can use the site without a mouse, a.k.a tabbing through.

(Step 0: What is with this trend to play videos as background images? I thought we learned this lesson years ago. Having movement your users can’t disable is annoying and bad practice. Stop it.)

screenshot of the Texas Gas Service home page with user login form
Texas Gas Service homepage
  1. Links I can’t click; let me count the ways
    From the “I want to…” select menu to the hamburger menu to the footer, dozens of “links” are not marked up as <a href> and cannot be tabbed to, nor would they be read as links by a screen reader.

    screen shot of the expanded I want to... menu
    These aren’t links

    This is lazy and wrong. If something is a link, make it a link. Fake links achieved with JS only are a large accessibility barrier.

    <div click.delegate="goTo('home', true)" class="btn pill-btn white-fill-btn au-target" show.bind="!session.loggedIn" au-target-id="111">Pay my bill</div>

  2. Tabbing order fail
    The tabindex attribute can be a really useful tool. It can also completely screw up a user’s ability to access important information, like the “username” field. When I could not tab to the “username” field, I looked at the code and saw the field was set to tabindex=-1. I had to look this one up. Here’s a 2014 explanation from The Paciello Group:

    When tabindex is set to a negative integer like -1, it becomes programmatically focusable but it isn’t included in the tab order. In other words, it can’t be reached by someone using the tab key to navigate through content, but it can be focused on with scripting.

    From my perspective as a customer who visits this page, being able to log in is the number one user story but it isn’t possible using a keyboard.

  3. Form validation errors
    The only time the “username” field seems to get focus is if that field is empty when clicking the “Login” button. Plenty of client-side field validation solutions work without removing a field from the tabbing order.

    screen shot of the login form with validation errors for the empty username and password fields
    Login form validation errors with login button disabled

    If a user tries to login with bad data, a small modal window with a an unhelpful developer-style error message of “Login failed” appears at the top right of the page. There is no associated help text about the causes of the error, or which fields have errors, and focus is removed from the form making it that much harder to update the data.

    screenshot of the error message login failed in a modal window
    Login failed error modal window

    Adding to the confusion is the little green check in both fields indicating what would usually mean the field data is valid. But for this form, a green check merely indicates that a field isn’t blank. There isn’t any robust client-side validation occurring at all.

Pet peeve: What is the point of removing the browser scrollbar from the page? It provides a simple and useful way to indicate where I am on the page. This is something I really miss on mobile devices.

Bad Forms – WHY?

Forms.

So easy to get right, yet so often poorly constructed.

Today I came across this gem with a contrast ratio of 1.26:1, as in barely above 1:1 which is invisible. Gray on white should always have contrast checked.screen shot of a form fields with light gray text on white

Other form infractions include

  • Using placement text as labels. Once a user starts typing, it’s no longer clear what information was requested or what format the data should be in.
  • When tabbing through the form, there is no visual indicator when you’re on a select field or a button.
  • I just don’t see the point in trying to reinvent the form experience. In this case, they’ve chosen a skeuomorph design, attempting to recreate a paper form experience digitally.
  • I like the address suggestion but it’s not possible to tab to it and select anything.screen shot of the address field with a drop down of address suggestions
  • I could not tab through the t-shirt size options and select anything using the arrow keys, even though these were coded as radio buttons.
    screen shot of the t-shirt form field with circles for each sizeUsing the browser inspector, I unhid the radio buttons and then could tell that after I made a selection, I was tabbing through the radio buttons.
    screen shot of selected radio button for shirt size
  • It was really hard to tell if I could tab to the submit button without visual indication. Adding a button focus style with the inspector showed that it was getting focus.

So much has been written about the IA of good forms, the proper markup of form elements and form usability, it’s amazing to me designers don’t follow a known pattern for an account creation process. It’s not the time to get fancy.

News in Slow Spanish Website

I want to improve my Spanish—a language I started learning in elementary school, took two classes in during high school (regrettably, I took French in college) and encounter almost daily living in Texas. When I heard a News in Slow promo on NPR, I decided to check out that option. The main draw is being able to hear conversations along with reading the words. Accessing the site as a new user, I ran into many usability issues. I’ll review these:

  • Home page
  • Accessibility
  • Navigation
  • Links

At the end of the post, I’ll add a mock-up of a few suggested changes.

Home page

screen shot of the News in Slow Spanish home page
Home page for News in Slow Spanish

First impression: It’s dated looking but the core task is front and center. I immediately clicked the ‘play’ button to hear (and read) the episode. That was fine, happy to have independent volume control.

After a few seconds, though, I realized something was off. Some of the pronunciations indicated that this was news in Spain Spanish, not the Spanish we use around here. Feeling frustrated, I stopped the audio and started looking around to see if there was some option to pick different Spanish. Eventually, I saw a select menu at the very top of the page, above the logo, allowing one to switch between “Spain” and “Latin America”. Selecting “Latin America” reloads the page with a different color scheme but there isn’t anything that clearly indicates what kind of Spanish the page uses.

Accessibility

The tabbing order is inconsistent with the display order. Some controls are inaccessible with a keyboard, most importantly the ‘play’ button for the audio clips. Curiously though, there are some keyboard controls for interacting with the player.

Hover menu shows shortcuts for play/pause, moving forward/backwards and volume control
Help text showing keyboard shortcuts for the player

Much of the transcript text is marked up to look like links and when you hover over that text, it shows the English translation. None of these is visible through tabbing.

Marked up transcript showing an English translation on hover
Title text displayed on hover

Some content is gray text on gray background with low contrast which, even as large headings does not pass WCAG.

The quizzes rely on color only to indicate whether an answer is right or wrong. (Is that really “purple”?)

Quiz answers in blue are correct
Quiz example

When trying to sign in, the form loads in a modal window without focus making the task impossible. Pressing ‘esc’ does not close the modal window, leaving you trapped.

Navigation

This site uses the older convention of left navigation as the global site navigation. I’m focusing on the top and local navigation components used to access the contents of an episode.

Screen shot showing the left, top and local navigation
Site navigation

Top navigation

On the site’s home page the only link in the top nav is a ‘home’ link that is right aligned. It’s hardly noticeable. Once you interact with the local navigation for an episode, the top nav gains a second link: ‘episode’ with a down arrow.  Having no idea what the arrow did, I clicked it and suddenly an up arrow appeared next to it. Using these arrows is how you’re able to access past episodes…one-by-one in chronological order.

screen shot of the top navigation with home, episode and up/down arrow links
Top navigation

It’s important to note that the ‘home’ link does not take you back to the episode’s start page but to the site’s home page. The site logo also brings you back to the site’s home page, making the ‘home’ link confusing and redundant.

Switching between episodes feels clumsy to me. I’d like to see episode searching in the top navigation area.

Local navigation

The local nav works as expected. It’s a list of links across the top of the episode content. The link for the section you’re on is bold to show place in site.

Screen shot of the local nav with Grammar highlighted
Local navigation bar

I think the local nav should stand out more. These links are what most users probably access the most every time they return to the site for a new episode. It feels like they are purposely small and crammed in there so that they all fit on one line for visual rather than usability reasons.

My big criticism here is that there isn’t a link to take you back to the episode start page.

Links

The use of blue in the color scheme really confused me. Sometimes blue text is a link, more often it’s not. Blue (#0000ff) is the default color for links in most browsers and various shades are used as the link color on many, many sites.

Using blue isn’t a problem but using it inconsistently and for something other than linked text within this color scheme is seriously problematic. The most annoying issue for me was the big “Episode #” text which looks so much like it should be clicked to get you back to the episode’s start page. It’s not a link :/

Let’s look at an example: at the bottom of the home page is a section for searching past episodes.

Search episodes
List of episodes with search

What here is a link? Convention tells me that the gray text indicates something that is not a link, that is disabled. That’s true for the ‘first’ and ‘previous’ links in the pagination bar. It’s not true for the episode titles which open an accordion when clicked. Maybe they expect people will see the dates in pink and click there?

With the accordion open, the “Episode #” turns blue and is clickable in this context because clicking it closes the accordion!

Screen shot of the episode details expanded
Episode accordion expanded

The link colors of the icons further the confusion with the play button being blue while the volume controls are pink. The fix here is to use colors consistently. I’d stick with using blue for links only.

Suggestions

I’m not going to attempt to make broad visual design or branding changes here, just information architecture and legibility tweaks.

screen shot of my changes to the News in Slow Spanish home page
My changes to the home page
  1. Tightened up the header, moving the Spanish selector into the utility nav, adding a search box and removing the existing top nav links.
  2. Moved the local nav up to be more obvious; removed the “News in Slow Spanish” text from the title (redundant) and added ‘previous’ / ‘next’ links to still allow for tabbing between episodes.
  3. Made sure only (all) links are blue!
  4. Decided to highlight the text with translations in pink since they aren’t links, just text with title tool tips. See mocked-up help message that can be removed by the user.
  5. To improve legibility, I removed the weird slanted background image in the header; removed the gray background from the transcript area; increased the line height of the transcript text; and bumped up font sizes for other text.