Hello and welcome to episode ten of Front End Center! To those who’ve been listening since the beginning, thank you! For those who’re just listening in, welcome! It’s amazing how time’s flown, but there’s still so much more ahead!

Speaking of new and old users alike, this week I wanted to start talking about accessibility in modern design and development. It’s a topic that can innocently fly under the radar, or deliberately be swept under the rug. If responsive design for mobile devices is a can of worms, then the effort and understanding of accessibility might seem a bit like a Lovecraftian nightmare.

Let’s start at square one: What is accessibility from a front-end web perspective?

The following description headlines the W3 Consortium’s guidelines for accessibility:

“The Web is fundamentally designed to work for all people, whatever their hardware, software, language, culture, location, or physical or mental ability. When the Web meets this goal, it is accessible to people with a diverse range of hearing, movement, sight, and cognitive ability.”

Most developers think of very specific issues, if they’re already familiar with accessibility. One of the most basic is ensuring there are informational and relevant “alt” tags on images for your website. This ensures that those with poor or failed vision can still get use and context from images they otherwise wouldn’t be able to see. They can choose how to adapt your accessibility offer in a way that suits them best, like magnified text or a screen reader.

Some front-enders build and maintain a list to check off accessibility issues they know of and can accommodate quickly. At certain stages of building, just run your finger down the check-boxes: Alt tags, check. Keyboard-only navigation, check. Search-engine optimization of content, check!

Ensuring these basic mechanics are met is a good thing! They’re often overlooked and sorely missed by those who genuinely need them. They shouldn’t be the limit of our approach to accessibility, however. Every part of design and development can factor into making our work more accessible around the world.

One of the W3’s recommended items is actually a relevant first point. They encourage that all podcasts have a text-based transcript to accompany them. Unlike development details like “alt” tags, this is a little more outside the box. I’m not specifically coding or designing the podcast itself differently to increase accessibility, but instead am adding to it in another medium.

I’ve made a point of including text transcripts on the http://fec.fyi website from episode one, without even realizing it was an industry recommendation. Being able to read quietly, or along with the audio, is a big convenience regardless of any physical disabilities. It also means my content is indexable by search engines, and can even be translated into foreign languages without repeated and excessive listener transcription.

Visual design and user interfaces can be a landmine of accessibility issues that sneak up unexpectedly. Many websites the employ banners or content-relevant images will include text in those images to make use of exact positioning and fancy fonts. What you gain in convenience, however, has an equal cost in value. Like our podcast transcripts, including actual text on your page has big returns. Image-based text can’t help your SEO, can’t be read by screen-readers, and can blur or distort if the image renders poorly.

While it takes a little more effort, text will provide a crisp and clean experience for any of your users, whatever their device or access method.

My enterprise team encountered a surprising issue that struck right to the core of accessibility and user experience while working in an Office 365 environment recently. While weighing our options for content customization in a meeting, one of our developers noticed that an entire navigation menu had vanished from the top left corner of the page.

The confusion didn’t get any better when we figured out what had happened. At certain screen sizes, the entire left hand column of the page suddenly compacts into a brand-new menu button, right where the missing menu used to be in the top left. This reorganizes a few existing items in that section.

In a move that still has us scratching our heads, the Houdini menu isn’t just moved over, but completely jumps the page and ends up in a wholly different set of navigation items on the RIGHT hand corner.

Maintaining the suspect pattern, it also reorganizes its new neighbors to ensure confusion is equally disbursed everywhere possible.

As the web plays catch up to apps and dedicated programs with more complex UI behavior, events like this are becoming more common. Handled carefully and with obvious transitions, they range from useful to minimally not dangerous. Handled poorly, and they become a user experience nightmare. Even worse for accessibility, how does this affect alternative methods of website navigation? Hopefully, it limits itself to being just unintuitive. At worst, it may make large portions of a website completely inaccessible for users.

Another area that often misses recognition for accessibility is the architecture of your front-end. HOW did you build your website? Responsive design makes sure your user can engage with your website once it’s loaded on their device, but it can be a long road just to get there. What happens when a mobile user has a weak signal that makes dialup look like a reliable champion? It doesn’t matter whether you’re considering a consumer market in a third world nation or your own signal next time you road-trip through the Midwest US. That’s an access problem.

This isn’t to say every website needs to use only a few colors and less than 200 lines of JavaScript. Some projects simply need complex and data-heavy resources. To maximize accessibility though, consider how you implement those elements. If you fail to load a core resource, how does the rest of the site handle that? Are there fallbacks in place to maintain core functionality and circumvent or even jettison effected content?

Accessibility considerations are everywhere on the internet. They’re impacted by how you design, how you develop, how content is delivered, and how it can be accessed. Not every single situation or challenge can be anticipated or prevented. We’d never launch a single website if we tried to perfect accessibility. That doesn’t mean that we can’t pull ourselves out of our own habits and plan ahead to build a better experience for everyone, everywhere. Think outside the box and make a difference.

And speaking of making a change, I’d like to make a request of anyone listening! In light of making it to episode ten, I’ve started ramping up some more in-depth analysis of Front End Center’s potential audience and quality. I’ve included a link in this episode’s description on SoundCloud, as well as on multiple pages of http://fec.fyi that leads to a questionnaire about the show.

I’d like to keep making Front End Center about the people who listen, and ensure that you get everything you can from it. Being able to identify strengths and weaknesses across the project will be a huge help with that. And if there’s somewhere I’ve dropped the ball on accessibility, make sure and let me know!

Until next week, thanks for listening! Let’s see where the next milestone brings us, shall we?