I had planned to do my own write up on the subject of whether links should generally be underlined within body copy, both for accessibility and usability, when I found this excellent write-up from Adrian Roselli who provides a comprehensive outline of research and recommendations in six sections:
I think links should be underlined in most contexts because it’s a clear visual indicator of what is a link, and it’s the default browser behavior. Please give this one a read and let me know if you agree!
Last week, the Fitbit iOS app introduced an updated dashboard that more closely matches the UI of the desktop site. For reference, this is what the dashboard looked like for years.
Stats are now tiles
The dashboard moved away from a vertical listing of stats to a more friendly tile layout, which allows more information to be displayed at the same time on a small screen. Tapping a tile still takes you to a weekly snapshot of the data point.
Add, remove, move tiles like iOS
After tapping the ‘Edit’ button, you can remove tiles (or add them back) and update the layout by holding and dragging tiles between spots. You can choose between four stats—steps, calories, miles, and exercise minutes—as the main data point displayed in the largest tile at the top.
After tapping the ‘Done’ button, you see the updated dashboard with only the tiles you’ve selected. I’ve chosen to remove both calorie tiles.
Pull to sync your device
Fitbit now employs the ‘pull to update’ pattern to sync your device with your iPhone, which is by far my favorite improvement. This is an easy, one-step process whereas before you had to tap to the sync screen then tap to sync.
Goal statuses
The dashboard still uses green to indicate a daily goal has been met, but it made two other changes:
It now uses a blue color instead of orange to show a goal in progress
It uses a circle instead of a bar to indicate progress
I like both these changes. The orange always looks a bit like a warning and wasn’t very inviting. The circle gives a clearer indication that you’re reaching the end of something.
Final thoughts
I like these updates a lot and they have improved my experience using the app. I hope one of the next updates is separating out the ‘track exercise’ and ‘log exercise’ features. While the ‘add’ button was made more visible by making it part of the app navigation at the bottom of the screen, it still does not provide ‘log exercise’ as its own option even though there is plenty of room.
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.)
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.
This is the rendered HTML for the National Geographic square:
And this is how a screen reader would interpret that HTML:
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.
Flipboard.com 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.
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.
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 assistive 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.
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.
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.
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.
Recommendations
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.
