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.


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.


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.


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.


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.


4 Ways Kiva’s Redesign Limits Keyboard Users

Kiva, a microlending non-profit that enables anyone to lend money to help end poverty, recently went through a site redesign. This included major changes to its global navigation, faceted search, and loan display. Here’s a snapshot of the Lend page highlighting four problem areas affecting keyboard users.

screen shot of the Lend page

1) Global navigation menu doesn’t open

When tabbing through the site, the second link is the “Lend” menu in the global navigation. Only by using a mouse can the “Lend” menu be displayed. Hitting the space bar or enter keys to try to access this menu just reloads the page.

Kiva needs to implement a keyboard-friendly solution like Adobe’s Accessible Mega Menu, available on GitHub. It enables users to access drop drown menus with the space bar, and then continue tabbing through the menu links. The esc key exits the menu at any time, returning focus back to the navigation item.

screen shot of a mega menu on Adobe's Accessible Mega Menu page

2) Hidden controls

The “Borrowers” facet uses hidden radio buttons and provides no feedback to a keyboard user when one is in focus. Here, I’ve disabled the CSS rule that hides the radio buttons.

screen shot of the hidden radio buttons for the Borrowers facet

I tried repeatedly to select one of these options using the keyboard but couldn’t. Kiva needs to allow users to select all form options, even if the radio buttons are visually hidden. Mouse users click on the form labels to select options but labels do not get keyboard focus.

Another set of facets employs sliders to filter results. These are completely inaccessible to keyboard tabbing.

screen shot of slider filters in the Kiva faceted search

I did a little searching and came across some accessible slider examples that allows keyboard focus on the handles then employs the arrow keys to adjust the values.

3) Focus, focus, focus

So many elements on the Lend page do not indicate they are in focus, from the above mentioned facets using radio buttons, to the lending controls for individual loans. In this example, the links for “Lend $25” and “Learn more” are visible only on hover. While the links can be tabbed to, there is no feedback that they are in focus.

screen shot of the loan gallery

Kiva needs to use the a:focus CSS selector consistently and ensure any JS used to show links works with keyboard focus too.

4) Stuck modal windows

Another facet option is to “Select countries” to filter loans. This link opens a modal window.

screen shot of the select countries modal window with checkboxes for each country

I tried tabbing through the country checkboxes but nothing happened because the modal window did not get focus. As I held down the tab key, I could see that I was continuing to tab through the links on the Lend page instead. My only option was to hit the esc key.

Final Thoughts

Making sure your site works with focus is important and easy to implement. For visual feedback, you generally can employ the same CSS rules used for hover. Another useful enhancement would be to provide a way for keyboard users to skip the search facets and go directly to the loan options. Reviewing this site has inspired me to create a future post centered on accessible faceted search.

Flipboard Accessibility Audit

I’ve never used Flipboard, so I decided to make my first visit an opportunity for a preliminary accessibility audit based on the WAI Easy Checks – A First Review of Web Accessibility heuristics.

It was a challenge to get the site’s source code because everything is rendered on the fly with JS. I had to use the Chrome inspector and copy/paste the code into an HTML file for upload to the W3C validation service. (And there is no fallback for users without JS.)

screenshot of a snippet of HTML that shows up when JS is disabled on the Flipboard homepage
JavaScript disabled on Flipboard homepage

The validation service returned many errors, but this audit explains three basic accessibility problems.

1) Images Lack Text Alternatives

So basic yet so overlooked, the home page images don’t have alt attributes. This includes both images that are linked and not linked.

For linked images, lack of alt attributes means a screen reader has no context for the link; it’s like a link without text. For all images without alt text, the screen reader will read the file name, which provides little to no context for the element.

screen shot of a National Geographic logo and The Wall Street Journal logo on background images

Linked image on Flipboard homepage

This is the rendered HTML for the National Geographic square:

<a class=" splash-tile partner" href="/section/national-geographic-ga7unkc6sb3qhid0?intent=invite"><img class="background-image" src=""><img src=""></a>

And this is how a screen reader would interpret that HTML:

LinkGraphic slash logo underline natgeo underline dark.svg

Always include the alt attribute in the <img> element. If the image is there for visual design only, include an empty attribute alt=””. For images that provide contextual information to sighted users, provide meaningful descriptions of the contents. also uses a lot of SVG, none which is accessible because there are no <title> or <desc> elements used to provide text alternatives for these graphics. For example, the Flipboard logo shows up as an empty link. SitePoint has a great article on how to create accessible SVG.

2) Form Fields Lack Labels

The sign up form on the homepage relies on placeholder text to do the job of field labels. The problem with this approach is that labels provide context for form fields that placeholder text can’t. Further the poor color contrast with the light gray text on a white background does not meet accessibility standards with a ratio of 2.28:1.

HTML for the sign up form with CSS disabled to show it does not have form labels

Labels don’t have to be visible, accessible by screen-readers only, but relying on placeholder text makes it difficult for users to remember what data to enter after they start typing; this is probably not a big deal for a three field form, but it’s a good idea to be consistent. This form could change the placeholder text into field labels while maintaining the same visual design.

screenshot of the sign up form with field labels always visible
Mock-up of field labels

This form does deserve some props for using a “Full Name” field instead of two fields for first name and last name, and for not having a “Confirm Password” field.

3) Poor Keyboard Access and Visual Focus

Many people cannot use a mouse (or finger) to navigate websites and rely on keyboards or assitive technologies to move between links. For this to work, links must

  • provide sufficient visual queues when they are in focus, and
  • be a logical order within the source code that closely matches the natural reading order

The simple litmus test for this is to try to tab through a site. I had a lot of trouble with Flipboard because none of the links had visual focus. For example, the “Sign In” link in the upper right changes background color on hover, but not on focus; so when users tab to this link, there is no visual indication of where they are on the page.

screenshot showing the sign in link box

Further, the “Sign In” link looks like it’s the first or second link on the page, but it’s actually the 12th link, requiring users to tab through the sign up form before they can sign in to use the site. That link needs to move up in the source code to be more readily accessible.

Some content is hidden from some users

Looking at the homepage with CSS disabled, I noticed two things that cannot be reached by everyone: a search box and a “Sign In” option that opens a modal window.

screenshot showing that the sign in link and search box are not visible when CSS is enabled

All content must be accessible to all users. While users can tab to the search box, it remains invisible on focus to keyboard-only user and it lacks both a field label and a form submit button. Ironically, search appears to be more accessible to screen readers than to visual users because I didn’t see search on the page.

The “Sign In” option functions as a link but is not marked up as a link.

<div role="button" class="tab-item login-button" data-
reactid=".0.$/.0.2.3:$signintabitem">Sign In</div>

Because it is not an <a>, users cannot tab to this element; it’s not really a link. I see this all the time, and there are several more examples on the Flipboard homepage. In my experience, this is lazy coding in a JS framework.


These three issues are just the beginning. The site does not make use of ARIA role attributes for navigation, proper headings for the document outline, or pass a logical structure check of the HTML. Flipboard needs to work with an accessibility expert to make its site inclusive. This web accessibility checklist is a good place to start.