Accessibility Blues

Wanna print that?

Before you start making fun of me, because I added a print stylesheet to a website in 2019, let me please explain why I did it at all. You might think, the time where corporate bosses where smoking cigars in their offices while their secretary printed out every email for them are mostly over. And I really hope, you are right with that assumption. But there are some exceptions, where people use to print websites quite often: Invoices, cooking recipes, event tickets, technical manuals or gift vouchers — to name just a few. As I am currently working on a cooking website, having a good print stylesheet is still worth it in 2019 without any doubt. It’s probably more important for most of your users, than using some fancy markup such as Schema.org or Microformats to make the recipes machine-readable and thus importable into a digital recipe manager.

Writing a relatively simple print stylesheet took me the better time of two whole days, because the state of print support in browsers is almost as bad, as it was about 10 years ago. Okay okay, we don’t have to make our pages print nicely in IE 6 any longer, but besides that, things still work differently from what we are used to, when using modern CSS. Do you use flexbox for implementing a sticky footer even on short pages, where the screen becomes much taller than your content? Congratulations, Firefox (v66) will only print the first page and nothing beyond it. Grid is also inconsistent across different browsers, so you can neither use that for defining your layout. Both Flexbox and Grid are fine for smaller sections, though. But you gonna have to use <table>s , floats and absolute positioning again, if you want to do just a bit more than having a centered text block on your printed page. Oh, and don’t even think of using mask-image or your masked elements will not get printed at all. The latter one is obviously a bug, but I’m sure almost no one is aware of that behaviour.

The only positive aspect of the current situation — namely, that browsers vendors don’t care enough about printing websites — is, that you can safely rely on older articles and tutorials, that have been published a decade ago and most of the tips given there are still valid for the latest and greatest browsers. I can also recommend reading Designing For Print With CSS, which was published in 2018 by Smashing Magazine and is a good starting point to get into the topic. But as always, try to test with as many devices and browsers possible, if you’re expecting a decent result.

Link: Learn more about screen readers SINGLE RIGHT-POINTING ANGLE QUOTATION MARK

Screen readers are a different topic though. While not every website needs to be printable, we should try our best to make websites accessible. Bonus: if you’re using aria-* attributes a lot, it can save your HTML from classitis, because every browser beyond IE 6 allows you to hook into these attributes for managing things such as states, plus displaying and hiding of content, without the need of using additional class names as styling hooks. As aria-attributes are not project-specific, you don’t have to remember different naming conventions for states (e.g. .btn.is-active, .btn.isActive, .btn--is-active etc.) over and over again.

So I fired up VoiceOver on my MacBook to read throught the page and ended up with many awful-sounding text like in the headline above. But Fabian, haven’t you thought of that before? Yes I did! I though that using aria-hidden, aria-label and other properties would make my page just sound fine in any screen reader, but aparently I was kind of naïve. After googling about these issues for a while, it turned out that support for aria-attributes is much worse and inconsistent, than I could ever imagine. I stumbled across four years old unresolved a11y bugs in Blink, Gecko and WebKit and couldn’t stop to bang my head against the wall after that. How in the world could an average developer be able to deal with this? Seemingly, the most prioritized goals set by browser vendors are not found in the field of accessibility. But hey, we got WebUSB (at least in Chrome)!

But what really makes me mad about the situation is, that we are leaving people out, because we don’t seem to care enough. And in comparison to making a sticky footer and test it across all relevant browsers, testing different screen readers doesn’t come for free. I’m using macOS, so VoiceOver was already installed on my computer, but some competing products have to be bought separately. And most developers will never/are not able to spend hundreds or even thousands of Euros for testing e.g. in JAWS, which seems to be a popular choice. I cannot blame anyone who does not want to spend the price of a decent notebook computer for a software, they just use for testing their websites. The only thing that will help here, is to have diverse teams, including visually-impaired or blind members, who use screen readers on a daily basis. But to be honest: that’s not realistic for every (small) team or freelance developer. Nevertheless, we should never treat people with disabilities as an edge-case.

lynx https://fabianmichael.de/en

Okay, we’re getting ridicoulous here (who uses text-based browsers in 2019?). But I once read the tip to use a text-based browser such as lynx or w3m to test accessibility. Why? Because a text-based browser sees only text, which is similar to a search engine and — more important in this context — a screen reader. Okay, let’s go: Special chars broken? No problem — set document encoing to UTF-8 (and don’t forget to save settings to disk). Ahh, here comes the real trouble: Lynx has awfully bad support for HTML5, which results in links not being selectable, once you place a block element like a <div>, <h2> or <figure> within them. Also, don’t expect handy attributes like hidden to work in lynx or any other text-based browser. But besides that, you can still get some insights into how you pages will be read by a screen reader and without any JavaScript. I hope, these browsers will finally catch up and get basic HTML5 support one day. You might wonder, why I even care? Because I want the web to be accessible for everyone as many people as possible. Text-based browsers are especially great when being logged into a terminal, when browsing from a remote location without a broadband connection or after disaster, when your connection speed feels like it’s 1998. You might say: »But these are edge-cases …«. You will keep call them edge-cases only as long as long as you’ve never found yourself in such a situation. There’s a reason, why CNN Lite exists. It’s for the sake of giving people access to news, when they need it the most.

Conlusion

In the end, we need better standards and more consistent implementations between browsers! The device landscape has become pretty diverse over the last years and that’s a great thing. But as a Firefox user on desktop with an iPhone SE on-the-go, I am already experiencing the struggles of designers and developers of keeping up with that first-hand. There have been several times, when a mobile website was not optimized for my smartphone, because everyone assumes that smartphones have bigger screens nowadays. This often leads to overlapping elements, unclickable buttons (nice if you cannot close that damn cookie banner to access the content). When I’m one the bus, I am seeing a lot of people using exactly the same phone as I do. I wonder, if they are as much frustrated as I am. When other designers ask me what canvas size to use in Sketch for the mobile layout, I always tell them to use the iPhone 5/SE screen size, because its relatively small. On the desktop-side of things, I don’t want to count how many times I had to switch my browser, because some jerk did only test a website in Chrome, but not in Firefox (or Safari or Edge). We can do better and we need to do better, if we want the web to become a better place for everyone — sometimes at the cost of our developer experience. Testing websites in many browser across different screen sizes is annoying as f*ck, but we owe it to anyone using our products. But we also need browser vendors, the W3C, screen reader vendors and anyone I possibly forgot to mention to work better together. Responsive design is already hard enough without all the inconsistencies that we have to deal with on so many layers. If we want to give everyone a voice on the web, that can be heard (or read) by anyone else, the plattform has to be capable of letting everyone create accessible websites and content without calling licenses for a ton of proprietary software their own.

PS: Don’t forget to test your websites in older browsers, even if it sucks to do that. Sustainability also means, that you should not force people into upgrading their devices, just because you’re lazy. Look around you, there’s a ton of people using old Android and iOS devices (the latter ones often running on iOS 9 or 10. iOS 9 means no support for CSS grid.). They may not have the money to buy a new phone or tablet, but maybe they also just don’t care, as long as their current device does its purpose just good enough. That doesn’t mean, that every CMS backend or intranet tool has to be compatible with an 8-years old iPad, but try at least to keep the frontend of public websites and online communities accessible to people, even if it does not look as fancy in their browser. Progressive enhancement and graceful degradation are your strategies of choice.