Today, Brad Frost wrote about the importance of providing accessible web experiences on low-powered devices (like an e-ink Kindle).
My wife’s cousin suffers from debilitating migraines. She’s done everything to reduce the migraines’ frequency, from dramatically altering her diet, to trying every available medical treatment, to even moving several times to different climates. Because of her condition, she has to minimize time spent with backlit screens.
Her solution: she uses the experimental web browser on her e-ink Kindle. And she finds that many sites either don’t work or crash her browser.
I advocate building sites in a layered, fault-tolerant way, but I don’t always test my sites on the worst of the worst devices. Curious, I fired up my wife’s five year old, hand-me-down Kindle (version 2.5.2) and pulled up a few sites I’ve built.
What I discovered
The good news: the last three major sites I’ve built work, and work surprisingly well. Even a recent web app I built, which unlike those new hottness single-page apps still uses server-side rendered code, was navigable and displayed all of the key content.
However, there are a few gotchas.
Elements hidden with CSS are visible, creating redundant, confusing markup.
The Kindle ignores anchor links
As an accessibility best practice, I include a skip navigation link at the top of my documents. This hidden anchor link let’s screen reader users skip the navigation and jump right to the body content—handy when navigating several pages of content using in-document links.
The skip nav link is displayed visibly (again, because CSS is ignored), and I’m ok with that. But clicking the link doesn’t actually skip the navigation as it should. That’s bad for UX and accessibility (and also means anchor links don’t work).
SVGs and web fonts aren’t supported
Not surprisingly, SVGs aren’t supported, and neither are custom fonts (even web-safe ones). Everything is rendered in the Kindle’s default system font.
Images display just fine
My sites included both JPGs and PNGs, and both of those rendered without issue (albeit in grayscale).
Update: Contrast Is Important
In the comments, Nico pointed out that color contrast is critically important for e-ink displays. They have a tendency to leave remnants of previous text when scrolling, making lighter text harder to read.
Follow a11y recommendations for color contrast and you should be good here.
Generally speaking, if you follow web accessibility best practices, you’ll be in great shape. The basics for supporting almost any device:
At this time, I’m thinking that this is such an edge case, having a site that’s useable and includes all content (along with some weird markup) is good enough.