Front End development vs back end development

I have a bone to pick with all those people out there happily expositing to the world about the difference between “front end” development and “back end” development. Go google it, and you will find people who sweetly explain that the front end is about the appearance and experience of things -the user interface and user experience while the backend is about server side code – managing and processing data. It is about algorithms and business logic that is necessary to make a web application work.

This is true, for the most part, but there is bullshit – subtle and then not-so-subtle bullshit waiting in the wings. I have done both frontend development and backend development on the web, and I can tell you exactly where the B.S. starts to creep in. Front end development has changed dramatically over the past 10 years, in fact some might argue that front end development was hardly considered to be a real thing 10 years ago. The explosion of smartphone usage, the rapid advancement in browser technology, and the advancement of javascript into a more versatile and developer-friendly language has changed everything. Now most of your business logic could be run in the client – (on the front end in the browser). There is even a database built into your browser (IndexedDB). The point is that you could build a fully functioning web app with database storage without the need for server side code.

I would not advise you to do that. My point is that the premise that business logic belongs on the server, and that algorithmic code, or even API calls are always going to hide somewhere on the backend is simply not true.

There are things that are better to do in the client and the server respectively. Code that requires heavy processing or an extra level of privacy like a secret api key are good candidates for the server. Code that benefits from being literally in the palm of the hand of the user – like code that is fetching user GPS coordinates, or time zone – you want that in your client. There is a lot of wiggle room in the middle. There is a substantial amount of functionality that could be built on either the client or on the server. There are quite a few opinions on what should go where. I have my own opinions on that topic but I’m not going to wade into that discussion today.

What I want to talk about is the biased-B.S. There is a bias, a very prevalent bias, a little twinge belief that hides in the attitudes of dev managers and developers everywhere. That bias is the idea that backend development is more rigorous or more technical that frontend development.

It starts with something like the above suggestion that the business logic, the data management, or the “algorithmic” code must be in the backend and progresses to the suggestion that the frontend developers are working on “appearance” but not “functionality.”

Just a quick google search lead me to the following gems of B.S. from some otherwise respected bloggers, and vloggers:

from https://learn.onemonth.com/frontend-vs-backend-developers/:

• Frontend developers build how a website looks.
• Backend developers build how a website works

….

later in the article we see this:

“Backend developers, on the other hand, need to have critical thinking skills. A backend dev is often debugging code, as well as designing systems for how the user will interact with the website. “

Front end developers don’t need critical thinking skills?! Front end developers don’t need to know how to debug stuff?! Ummm… javascript is a programming language. HTML and css have to be debugged too they are actually languages. OMG, this statement is so bizarrely wrong it hurts.

A vlog that I didn’t make it all the way through suggested that without server side code front end developers could only build “static websites.” This statement has not been true for a very, very long time. But alas many of the people who think they know about building software on the web are stuck somewhere in 2011, when JavaScript was seen as inscrutable to many developers, no one really cared if their website looked good on a tablet, and even when companies developed client-heavy applications they expected users to only access those from their desktop computer.

We aren’t in that world anymore.

Not only that, but the world of web technology has been changing at an ever increasing pace. The premise that frontend development is less rigorous or that front end devs are less than, or lite developers is not even close to true. From my own experience, I found backend development to be a far simpler world than the one I now inhabit. The front end world is one in which code quality and a rigorous approach to development matters more, not less than it did when I wrote back end code.

But let me give you a little taste of what I have worked on in the past year.

I’ve had to write python, luckily I already had experience as a python developer. See there is this thing called server-side-rendering. That is when you build your client side appearance layer with server-side languages. So the idea that we front end devs might get by without knowing a server-side language is faulty at best. I’ve worked with PHP, python, ruby, and node.js. Node tends to be the preferred option for front end developers because you are likely already working with it, if you have any kind of task runner or build process.

I created my own build process for a front end application using node.js. We are on the server again. Funny how us front end developers can’t get away from server-side code even though we supposedly only work on the “appearance” of a web app. I also experimented with several libraries for that purpose – parcel.js, webpack.js, rollup.js. I am now mostly working with rollup.js. I occasionally work with gulp on my older projects. Gulp is a task runner that can double as a build process.

I built several client side applications in Vue.js. I started learning Svelte.js. I revisited Angular for a project, only to realize that it has changed dramatically since I last used it four years ago. I helped another developer get an extension spun up using React. I am not proficient in react. I am proficient in getting frontend libraries and frameworks to run in the SDK environment that I work in so I was able to help another developer get react working in our environment.

I trained multiple people in writing javascript tests in mocha.js. I learned how to build and style web components. For those of you that don’t know, these are custom components defined via javascript. You can encapsulate both javascript functionality and styles into these components. The last few weeks have seen me digging deep into the shadow dom API, and figuring out the nitty-gritty of working with and styling slotted content. I fixed obscure bugs that were only a problem in a mobile IOS app. But the problem was webkit-related and my cross-browser debugging experience turns out to be what was needed. Speaking of which, I did a massive amount of cross browser, and cross device testing and debugging. I helped a few younger devs get better acquainted with dev tools. I’ve got a good working knowledge of chrome’s dev tools, firefox’s dev tools, safari’s dev tools, Edge’s dev tools, and IE’s dev tools, all of which I’ve had to work with in the past 6 months. Internet Explorer 11 dev tools aren’t as bad as you might expect, particularly if you happen to remember the IE9 dev tools. I’ve spent some quality time working with SVG’s – I needed server side rendering in a python-based template of a custom, configurable icon library, so I templated svg in a jinja2 template.

I’ve trained multiple other developers on using Voiceover to test how well a component or extension works for screen reader users. I’ve trained multiple developers on how to make a web page keyboard accessible, screen reader friendly, and even helped to brief product owners on the new WCAG 2.1 accessibility standards. I’ve built and repaired many not-quite-responsive layouts so that they responded properly to all screen sizes. I’ve helped multiple backend developers understand git workflows better. I’ve helped multiple backend developers write better javascript. I’ve written unit tests in both python and javascript, and I’ve resolved many problems that arose in our python-based web server/sdk environment.

That is just a taste. The reason I’m feeling so bitchy about it is that I am not tolerant of the suggestion that what I do is not “development”. I’m not tolerant of the idea that I don’t need logic skills, critical thinking skills, an understanding of algorithms, problem solving and debugging skills, and a deep understanding of the ever changing technologies of the web. I’m not tolerant of the idea that my work is “appearance not functionality.”

When I was a junior developer I was comfortable in python and knew a little jquery (a javascript library), people assumed I could do anything. They assumed that I would want to know about architecture, about databases, about deployment, about getting users permissions sorted out in unix. They encouraged me to try things and learn them even when I told them I didn’t know how to do something. Now there are those that assume I know little, and that I want to know even less.

“You don’t need to come to this meeting, it is about the server architecture in the SDK. It’s not relevant to you…” Me: “You mean the server architecture I run every day and build stuff on top of… that architecture.” I do need to know it. I did. I learned it. If I hadn’t I would be running to another dev every time I ran into a minor hiccup on my local server, why would I want to do that?!?

Do you know how many times I have run into a time-consuming problem only to discover that there is a great tool for that – a tool that makes fixing that problem quick and easy… “We would have shown you how to use that tool but we didn’t think you needed to know. You are just working on the UI after all.” Several times. Several.

I had no idea moving to front end would require gaining a far wider skill set than back-end coding, but would also mean regularly dealing with people who don’t quite understand that you are a developer. And while front end development necessitates solid logic skills – the kind you might have picked up in a discrete math class, what you really need is something most back end developers don’t have: spatial reasoning skills. Spatial logic matters on the front end.

I don’t want to steer anyone away from the front end, it’s a great career path, just keep in mind that backend development is much, much easier and no one will ever doubt that what you do is “development.”

 

My Crazy Year in Web Dev

It’s been awhile since I’ve updated this blog. I thought an update was overdue. In the last year and a half:

I changed positions and title – I am now a “senior software engineer.”

I learned a lot of object oriented python.

I work heavily now in a python-based SDK environment at work.

I did several projects in Vue and realized that I had never done a deep dive into vue CLI.

I changed my approach to task-runners.

I started working with web components via svelte (I really love svelte).

I experimented with stencil.js (I don’t love jsx/tsx but I’m sure I could get used to it if I needed to).

I somehow ended up having to help train both react and angular developers in how to get setup in and use those frameworks in our SDK – I no longer have a deep familiarity with angular (it has changed a lot since I worked with it), and I’ve never worked with react outside of a handful of tutorials. But my already broad familiarity with javascript frameworks meant that I could help others figure out how to get it working correctly.

I no longer work with php or Drupal – I always hated how black-boxish drupal was and I found php to be awkward at best.

I mostly don’t use jquery anymore – I’ve gotten pretty comfortable leaving that old library behind, though I still have to support some legacy jquery code.

I still do accessibility and responsive web development and help to train others in this.

I’ve now done some major projects using svgs and I’m excited about diving deeper into working with svgs.

It’s been a crazy year and a half. One of the reasons that I really wanted to get out of my last position was that there just wasn’t typically time to get comfortable with newer technologies. As a result, I frequently fell back to what worked – jquery/php, while developers in other departments were showing us the awesome things they were building in vue.js or with web components.

I knew that if I wanted to continue really growing as a developer, I would need to move into a role that required leaving a few things behind (like php/drupal) and that required picking up some new skills.

The thing I’m most excited about is svelte.js. It acts like a framework but compiles to small vanilla javascript files. We are working on a components library using svelte.

I started playing around with it and very quickly I realized – wait I don’t have to create my own fancy build tool (setup another gulpfile), or try and get webpack configured correctly, or try to configure vueCLI’s config file in a way that the underlying webpack config file will get configured correctly (ugh)? I don’t have to dig through documentation to figure out how to build my files in such away that I can nest components inside of components? Really? Svelte comes with its own very simple build tool that runs with npm. It might be the easiest thing I’ve ever setup.

Honestly, I’m so tired of javascript frameworks. I’m so tired of time spent digging through other people’s codebase or documentation to figure out why I can’t do a simple thing that I should be able to do. I’m tired of fighting with deprecation.

It’s like this: imagine you have an elaborate javascript framework – one of those that does everything for you, and you have to spend time researching how to do something simple (like using the window object) the angular way, or the ember way, or the vue way – you finally get it working and assume that that way that the documentation recommended you do things would continue to work in the future. But it doesn’t. Because one day for very good reasons the developers behind that framework will need to change something in their syntax, they might even toss out that “way” of doing your thing entirely. Then you will have some period of time to take the updates (rewrite your code) or you could lose the ability to take security updates. The problem is that these tend to come out of the blue.

It seems like a normal day when suddenly you are stopping your existing project to go back and work on updating code from 6 months ago or 2 years ago because some controller is now deprecated in ember, and you were using a function that was inheriting from it. Oh, and you will need to update your documentation to, because you bothered to write some training material in how to use said function. There are people waiting on your current project who will have to wait longer, but the update can’t wait because nobody realized it would be a problem until stuff just stopped working…

Meanwhile, as a developer you can be very comfortable with a framework (like I was with vue 1.0) be asked to work on a project and find that you no longer recognize the syntax. You have to relearn something that you were skilled at, and yes that comes with the territory of being a developer these days, but I want to keep up to date with the latest greatest vanilla javascript, python 3.7+, css modules, svg features, accessibility features, browser APIs, and mobile gestures/devices. Seriously, I don’t have the time or interest in making sure that I also have the latest greatest understanding of what vue, angular, or ember are doing.

There is a lot of value in javascript frameworks, not the least of which is getting large teams of developers to adopt the same conventions for how they write their javascript. I am still planning on using angular on some of our bigger projects over this next year. But that being said, I always prefer to improve my mastery of javascript and other web technologies over improving my mastery of some random framework. The framework knowledge I learned 5 years ago is now obsolete. I started my career learning a pre-1.0 version of angular, backbone.js, and a pre-1.0 version of meteor.js. Very little of that knowledge serves me now. The python, vanilla javascript, and html/css knowledge I learned five years ago is still relevant.

I didn’t mean for this to become an anti-framework rant. Sorry about that. For some years “do you know x framework?” has been the litmus test at hundreds of employers for even getting an interview. That drives me nuts. It seems that many potential employers just want to filter for very junior or entry level developers who just happened to have done a single school project in React (it’s always react). The bootcamps have picked up on this and many of them train almost exclusively in React. That is supposed to impress those of us on the other side of the table. Obviously, it is working for the litmus-test-for-interview employers, but for those of us who are actually looking for skilled javascript developers to join our teams, the react-only developers are almost always a waste of time. They often don’t know basic javascript functions or basic html and css.

Overall, it has been a good year. I am finally working with some technologies that I am genuinely excited about and gotten out of the jquery/php trench, and we’ve added some great new people to our team.

 

The thing about Web Development is…

It is always changing. This is good but sometimes it can be a bit overwhelming. For example, ever since ES6 came out and the industry started moving more and more toward using the new specifications. I have started feeling like I don’t know javascript.

I have been writing in javascript for about five years now. The vast majority of it was in jQuery. Some of it has been with front end frameworks like Vue.js and Angular. I worked for about 6 months with meteor.js and node.js at my first development job. I can still drop some jQuery like no body’s business. I have built whole component libraries using jQuery, Scss, and HTML that are fully accessible and easy to implement. Yet when I see code that uses destructuring in complex ways, I am like ‘what the heck is that?’

It is javascript – the new javascript. There are quite a few parts that take some getting used to.

Arrow functions are another example. They are easy to understand and simple to implement. The syntax is simple and straight forward. But I could easily and quickly read and understand code that nested functions before that arrow came along. Now, I frequently see things that I have to take a moment to translate. Here is a fun, and simple example from the MDN docs:


setTimeout( () => {
console.log('I happen sooner');
setTimeout( () => {
// deeper code
console.log('I happen later');
}, 1);
}, 1);


This one is nice because it is fairly obvious what it does. But imagine if it wasn’t so obvious. I didn’t realize how much the word ‘function’ was serving as a visual queue for me until it started disappearing.

When you are learning, arrow functions are simple and straightforward. The syntax is a clear improvement for a simple function.

 

//New version
const cubeThis1 = (a) => a**3;


cubeThis1(3);
// 27


//old version
const cubeThis2 = function (a) {
return a**3;
}


cubeThis2(3);
// 27


When you are working with someone else’s code, they haven’t named their functions and variables so well, and the functions are not so simple, then you might find yourself stopping to translate. Every now and then I rewrite the code in comments or in my own notes with the explicit ‘function’ syntax to make sure I understand what is going on. The implicit ‘return’ of the arrow function throws me off sometimes.

Destructuring can also get very confusing very fast, especially if the writer of the code does not adhere to clean coding principles. The syntax feels backwards to me like I learned to write “The fox will run” and now I am being asked to write “Run the fox will.”

So I am practicing writing code far more than I used too, or than I previously felt was necessary. I have returned to some of the code kata’s and code challenges that I used as a new developer to try those same exercises in ES6. I sometimes refactor my code with more ES6 syntax to see if improvements can be made, and I always think about how my code communicates with other developers.

In spite of all this, I still frequently feel like I don’t know the language well, or rather that I know it less well than I did just a few years ago. It is the programming language that I am primarily writing in, and have plenty of experience with.

But then, in my career I have also had to learn PHP, Python, Ruby, mongo, SQL, HTML, CSS/SCSS, and a half dozen frameworks with their own syntax. And that list could go on because there are the API’s you work with, the libraries, the modules, the automation tools, the testing tools, and the browser dev tools which are perpetually getting new updates. Somehow, the ground is always shifting in web development.

It is so easy to feel like somehow you are back at square one, in spite of the 5 years or more that you have been climbing the web development mountain range. I feel that way. The other day I wrote some code for a small expanding panel with all the needed aria-attributes for screen reader friendliness, for another developer. I knocked it out in a matter of minutes, and then refactored it in another 10. That is when I found myself thinking – “Oh yeah. I do know how to write javascript.”

New syntaxes, and the complexity of incorporating new skills into your existing methods can feel awkward and fill you with doubt. This is a note for my future self the next time I am learning the big new thing that scrambles the syntaxes that I am comfortable with: You are not alone, and you don’t suck at this, so keep moving forward. 

How Web Developers Feel About Print Designers Venturing into ‘Web Stuff’

Save Us From the Print Designers

Imagine you are a design agency who has been making amazing, trendy print and marketing designs for years. You can knock out a well crafted logo, billboard, or brochure with an exquisite awareness of the market you are targeting, and the needs of your client in a matter of weeks. Your clients love your work and they return to you again and again for every pixel perfect brochure and poster.

Then one day they ask you to take charge of their new website design. Why not? You already understand digital branding and social media strategies, so why not take the plunge into this fertile uncharted territory?

Wait. Hold up. Please. I just need a few minutes of your time, for the sake of my sanity and the sanity of web developers everywhere.

Should you take that plunge? YES, of course you should, but not without the very clear awareness that web design is drastically different from anything you have ever done. You just left the world of static pixels, perfectly positioned letters, and layouts that always stay rigidly the same. You are walking into an interactive medium, a multi-device/screen width medium, and a multi-user medium.

You are no longer working in a space where you can assume you have one kind of end user, one size of canvas, or static images that simply hang out on a static screen. You may have to consider how the content of the site will change over time, how easy your design will be to manage and update, and you will have to know a thing or two about web accessibility.

You will also want to know if users actually interact with the the interactive elements of your site, and what to do if that amazing carousel you designed turns out to be a complete dud at actually marketing anything.

Still want to move ahead? Good. The web is a powerful medium and as a digital design firm, you should want to be a part of it. But it is incredibly important that you know what you are getting into. You might also want to know why you are getting that weird look from your developers when you surprise them with the fact that you don’t know what a hover state is. But maybe I can help with that.

So here is a non-exhaustive list of things you should know if you want to design for the web, and also a few things that will keep you from driving your developers crazy.

You are Designing Something that Other Humans will Interact with

This is so basic that it is hard to know where to start. You are no longer designing just to catch someone’s eye, make your audience feel a certain way, or to make a product or company seem more friendly. You are now designing elements that you want users to recognize as interactive, and then proceed to interact with those elements. So buttons need to look like something a user might want to tap on or press. Somehow you have to indicate to your users that this is an interactive element. The same goes for links.

There are plenty of well established design patterns for this. Menu icons, button styles, and even standardized link styles will help in conveying that information to your users, but you also need to give some feedback that an interaction is occurring or that it has been successful. This is where hover states, active states, and focus states come in. You will frustrate your users if you give them buttons and links that don’t respond with they interact with them.

Interactivity is about responding to user input. Learn about the different states that you might add to a button, and don’t go crazy designing these states. Less is more when it comes to button and link effects, especially if you have quite a few of these on your website.

Content and navigation have to play well together

So now that you have realized that something needs to happen when your user presses that menu button, have you thought about content?

Let me guess. The client is providing their own content? That’s great, but I bet you are designing their navigation, and that navigation needs to have some relationship to the content… right?

So you are going to spend some time working with your client’s proposed site map. This is where your digital marketing prowess will come in handy, because you are going to tell them that submenus inside of submenus inside of submenus might not be a great idea, or that top level menu items probably need to be short and sweet and definitely under three words long.

You are going to realize when you start mocking up these menus based off of the site map, that their site map is implying some things that might not work so well. So have an idea of how you want to guide them.

If you think simpler menus are better for their design, then that main navigation might need to be slimmed down, and remember that the menu is generally for the end user not your client. It may look cool to have images, videos, and multiple columns of menu items in your dropdown menus but that may not actually be the best design choice for the site. Think about what your end users are actually going to look at and click on.

Welcome to the Mobile Web

Speaking of which, now is a good time to think about how that giant menu is going to work on mobile devices if you haven’t already. You can start with mobile rather than desktop, some designers really like to start with mobile, but you don’t have to. Just remember that on mobile most of those ‘click’s’ will turn into a ‘touch’ or ‘tap.’ ‘Hover’ isn’t a thing, and ‘swipe’ decidedly is.

Design with touch interactions in mind. All of those mobile menu icons and buttons are big enough for an adult human finger to touch them without touching other links or buttons at the same time, right?

You are also carefully designing with super small screen real estate in mind for all of those tiny iPhone 5 screens that are still out there.

I’m sure that you have already done a little bit of market research and figured out the range of devices that you would like your design to fare well on, and maybe even negotiated a little with your client on the edge of those ranges.

Hopefully, you have also talked to your developers about what they think is reasonable to support. Your clients will want to support everything imaginable. You will discover a growing expense that directly correlates with the age of the devices and browsers that you try and support. Supporting older devices and browsers are much more development intensive.

Sooner or later, you will have a client who owns a very decrepit Samsung tablet from back when no one knew Samsung even made a tablet, and they are going to want to know if their new fancy website is going to look good in landscape mode on that 8+ year old tablet that their kids are still using. The answer will be ‘no’ but you will need to find a diplomatic way to deal with the situation and similar ones that arise.

Did I mention landscape mode earlier? You will need designers and developers that have a good grasp of responsive website design and development because you do not want to try and design for every possible range of device width and device orientation out there. That is to say that it is much better to have a website that reorganizes itself properly for different screen widths rather than worrying about hundreds or even thousands of different possible canvas sizes and orientations.

Three designs should cover most of your needs: i.e. a small mobile layout for small devices in portrait mode, a medium layout for tablet devices, and a large layout for desktop. There are plenty of well established breakpoints out there for responsive web design and development. Use those if possible, and try not to veer into making too many unique ones of your own. Every new design variation equals more development time, which will add up to a much larger expense. If your client is footing the bill for all of that development time you will need to keep that in mind and err on the side of frugality where possible.

Web layouts are dynamic

I mentioned it above, but it is worth mentioning again, you cannot control or design for every possible device size and orientation. There are just too many of them, and guess what? Each of those devices has multiple browsers that run on them that might also impact how your design renders. So you need to develop an understanding of how HTML and styling can respond to different device sizes and orientations.

For example: text wraps. That’s why putting five words in a menu button is a bad idea. it’s going to wrap on mobile, and suddenly one mobile button is going to be much bigger than all the others. The same way you have limited usable design space on a business card, you have limited space in a menu item, and this is especially important when considering if your clients might want to add more menu items in the future.

Text wrapping is one of those very necessary parts of the web that endlessly baffles print designers and clients who are accustomed to the pixel perfect arrangement of a well crafted brochure. Text has to wrap. Do not try to perfectly design where a line of text breaks across every screen width.

Millions of dollars, possibly more, is wasted every year by print designers and not-so-web-savvy clients trying to get their developers to write custom code and styling to keep lines of text from breaking in inconvenient places. This will come up often. So remember, you are not designing a poster or a billboard.

Text is going to wrap based upon the space that it has to work with, and a skilled developer’s job is to make sure that the layout responds correctly.

Did you notice how all that extra text didn’t leak out of the button, it didn’t disappear or get cut off, and it didn’t end up jumping on top of anything else? Did you notice how that callout box managed to contain all of your extra text and expand as the paragraph got taller and narrower on different screens? Your developer did that. Your welcome.

Background images — it is a remarkably similar problem to text wrapping. When aspect ratios change, which they will for different screen width, how the background image covers the area will change. That means a focal area or area of interest in an image might shift or even get cut off.

Honestly, I’ve had to explain it to more than a few print designers. Why does this image position differently in a panoramic space — lets say 300px height and 1600px width, than it does in a mobile space that is 200px by 400px… Because it does.

Developers have a little bit of leeway in tweaking this but frequently we end up with clients that want the focus point on one image in a standardized layout to be on the left, but on another page it will be on the right, and can we shift that when we get to small screens? Can we customize it across all 50+ pages of our website for each layout (mobile/tablet/desktop)? This can get hairy and time consuming very quickly. So pick good images for the space that they are designed for and maintain some consistency across similarly designed pages.

Also, you should consider just having different images for mobile that are already optimized for the space they are in. It is often substantially easier to just give the developer the correctly sized and cropped image for that small screen than trying to get them to spend hours tweaking how a large image responds to a smaller canvas.

Website content changes

If I had a nickel for every time I worked with a designer who designed a page layout without considering how it would look if the content was entirely changed, I would have quite a few nickels.

So what happens to that carefully designed callout box if it suddenly had a three line heading instead of a three word heading? What would happen if your client put an image there, or a bulleted list? Sometimes your custom layout may need some content restrictions, and you may need to work with your developer to figure out the best way to make that happen. You will also need to communicate these issues with your client who I promise will imagine that they can add whatever they like to whatever space that you have designed for them.

Digital Content and Services should be adaptable to a wide range of users

This is the hard part but also the best part of working on the web.

Your website shouldn’t be a brick!

What do I mean? I mean back when most content was delivered via printed pages in a book or newspaper, you could safely assume that your users were going to navigate with their eyes and fingers right? Content came in a very static form, like a brick. It didn’t change and you could reasonably expect your users to figure out how to work with what you were presenting them. If they couldn’t work with what you were giving them then they just got left out.

Likewise, on the web today, many designers and developers assume that their users will navigate their website with a mouse, well functioning eyesight, perfect lighting conditions, and a never-dimmed backlit screen.

Don’t assume anything is consistent about your users, and more importantly remember that digital content is not brick-like. Digital content is infinitely adaptable and that is why you should be trying to serve the widest range of users that you possibly can. That means supporting users that want to navigate via mouse, keyboard, touch, screen reader, and even voice interfaces.

Digital content can easily be resized, recolored, shifted, relocated, downloaded, repurposed, or even read out-loud by end users devices. This can be challenging to stay aware of and work with, but it is also what makes the web such an incredible medium to be a part of.

You can get started with accessibility by just being aware of a few important things:

Contrast matters — find a good contrast checker and aim for 4.5:1 or higher for all of your standard text content. Larger text (24px and larger) can use a 3:1 contrast ratio, and be be aware of how readable text is when sitting on top of a background image.

Don’t disable zoom — ever.

Avoid autoplaying content.

Leave your focus outlines on — keyboard users use these for navigation. You can improve the design of them if you like, but please don’t get rid of them.

Use HTML and styling instead of text images where ever and whenever possible.

Respect heading order — document structure should be logical and not based on styling preferences.

Test your forms and workflows with a screen reader! Trust me. You have one built into that Mac you are using for your design work. I promise you have one. “Command F5” — try it out.

There is much more to accessibility but that will get you started.

Check out this article on how to get involved in global accessibility awareness day: http://globalaccessibilityawarenessday.org/participate.html.

A few other things that you can say that will make your developer laugh (or groan) at you

“Did you know that fonts render slightly differently across different browsers?”

Dev: Yes. Its actually a much bigger problem across operating systems.

“Why can’t we just let the responsive HTML to do it’s thing?”

Dev: You know HTML doesn’t magically become responsive on its own? Right?

“How come this giant square image doesn’t look right in this narrow space designed for a panoramic image?”

Dev: We gave you image dimensions, could you possibly use those?

“Why does this image load so slowly? It’s only 10mb.”

Dev: That image file size is 100 times bigger than it needs to be.

“We need images appropriately sized for the web? Can you optimize my 200+ images for me and then re-upload them to our site?”

Dev: Let me google ‘3rd party image optimization’ for you.

“Embedded 3rd party content doesn’t need to be accessible… does it?”

Dev: “It does in fact need to be accessible.”

“I’m working on my meta-keywords.”

Dev: Your SEO techniques are about 10 years out of date.

“Can you turn off that weird blue line around my buttons?”

Dev: That’s the focus state, and it is essential for keyboard navigation.

“What is a hover state? / What’s a style guide? / What’s a wire frame?”

Dev: What kind of design did you say you had experience in?

“Why can’t we customize where the text in this callout breaks across every page — all 50 of them, for all devices.”

Dev: If you went live without these perfectly customized text breaks, would you have a single website visitor ever notice or care? Seriously, if the answer is ‘no’ you might not want to spend developer time on this.

“We need motion on our site, can you add (insert random effect here).”

Dev: Motion, like any design element should be used with purpose and moderation. Please don’t just add motion because you think it will make your site more “modern.” Your site visitors will be impressed with well designed animations and effects that work cohesively with your site design and serve its overall strategy. This is the age of the smart phone, I promise no one is impressed with your perpetually moving ads and gratuitous parallax effects.

“We would like this to autoplay.”

Dev: I promise you do not have users that like autoplaying content! You don’t!

In conclusion

Obviously, there are more things to learn, but this should get you moving in the right direction and hopefully reduce the headache of the developers that end up working with you.

I know the web is a very familiar place for you, but there is a good chance that interactive and accessible design is very new territory. That doesn’t mean you shouldn’t be here. There is always room for better design on the web.

Do you remember what it was like get “access” to the web when you were young, and when the web was much younger? Remember when you used the word “access” to complain when you couldn’t load a page, download a video, or “access” your email? There are still users struggling to get access to many online sites and services out there and they would love to interact with your carefully crafted website. Keep those people in mind and build/design for the widest range of users that you can.

Resources

Auto-Forwarding Carousels, Accordions Annoy Users & Reduce Visibility
We recently ran a usability study in the U.K. where one user was attempting the following task: “Does Siemens have any…www.nngroup.com

CSS outline property – outline: none and outline: 0
The CSS outline property is an accessibility requirement, yet often abused by many web designers, why do they do it?www.outlinenone.com

WebAIM: Color Contrast Checker
You are here: Home > Resources > Color Contrast Checkerwebaim.org

Activating Interactive Element with Keyboard

element.click();

From Mozilla Developers Network

The HTMLElement.click() method simulates a mouse click on an element.

When click() is used with supported elements (such as an <a style="text-decoration: none; color: #3f87a6; margin: 0; padding: 0; border: 0;" title="The HTML element is used to create interactive controls for web-based forms in order to accept data from the user.” href=”https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input”&gt;), it fires the element’s click event. This event then bubbles up to elements higher in the document tree (or event chain) and fires their click events.

The most important thing for you to remember when trying to make your site’s interactions work with a keyboard is that when navigating with a keyboard, “hover” is not a thing. When keyboard users want to interact with an element they expect to be able to hit enter/return to activate an element. Luckily, the keyboard return event syncs with the mouse “click” event.

Hence, if you know how to make something activate on a mouse click, then you should already be able to make it work with a keyboard. However, unlike the mouse where user navigation is more implicit, you will need to think about how the user navigates to the “clickable” element and whether or not they can visually see that they have arrived at the “clickable” element.

This is where visible focus states become especially important and I have an entire article dedicated to this topic.

Navigation and Interaction

This is where the keyboard interaction can get a little bit dicey. You may have carefully and cautiously made every interactive element on your site activate via keyboard, but this will not matter if the keyboard user cannot navigate to those elements, or are not able to see that they are on the interactive element when they want to activate it.

With a mouse, we don’t have to worry as much about how that navigation occurs. We can safely assume that the mouse user has some kind of arrow or cursor with which to see where they are on the site and to indicate which elements they are interacting with. In addition, most sites use changes on hover to give further visual cues to the mouse user that they are on an interactive element.

Unfortunately, it is not uncommon for some interactive elements to be completely in-accessible to keyboard users because they cannot navigate to them.

It is helpful to think through how your keyboard users navigate to, and interact with an element, in order to fully test whether or not your interactive elements are actually keyboard accessible.

Steps for keyboard interaction

For the sake of this example, we will pretend that we have an accordion element – a series of collapsible elements that expand or collapse by clicking on a bar or button.

Imagine that the keyboard user wants to navigate to and open the first item of an accordion element in order to view the content inside of it.

1. Step one – The user navigates to the element using their keyboard.
   • This is typically done by clicking on the “tab” key.
   • The tab key will immediately move keyboard focus to the next focusable element on the page.
   • The user will see the visible focus outline on that element and will continue clicking “tab” until they successfully arrive at the element that they want to access.
2. Step two – The user arrives at the element they want to interact with
   • The user knows they are on the correct place because the element with keyboard focus is clearly visible – this is typically shown via a blue outline or dotted line.
3. Step three – The user clicks “enter/return” to activate the element.
   • When a button element is used the user should also be able to use the spacebar key to activate it.
4. Step four – The element activates.
   • The accordion panel expands and the user should be able to navigate into the new expanded element if there are focusable items inside of it, or if they are using a screen reader.

Step 4 isn’t really a step – it is the outcome, but it is important to think about what we expect the user to be able to do once that element has been activated. Frequently, the element being activated is a menu or navigation list with links to additional content.

Activating the element, is often only part of the process. It is also important to verify that the user can interact in the expected way with whatever has changed on the page. In this case, it was a an accordion panel that expands. If that panel contained interactive content then it would also be important for the keyboard user to be able to navigate into the new panel and interact with the content inside of it.

A Process for Verifying Keyboard Usability of an Element

Here is a basic list of items that you can check to see if your keyboard interaction is working well. Please note: I am not listing techniques for accomplishing these items here as that would be a much longer article.

Before element activation

• The keyboard user can navigate to the element.
• The keyboard user can see that the element that they want to interact with has focus.
• The keyboard user can activate the element via a click of “enter/return” on the keyboard or with a spacebar click when a button element is used.

After element activation

• The keyboard user can immediately navigate into the activated element.
  • This is especially important for pop-up windows and drop down panels.
  • For example, the user should not have to navigate through the remainder of the page to get to a popup window or panel that just activated.
  • In the case of a pop-up window/modal that is sitting in front of the other content, you should immediately move the keyboard focus to the new element.
• The keyboard user can interact with the content inside of the activated element if there is interactive content. A screen reader should also be able to be aware of and read any content that has been displayed.
• The keyboard user can close or deactivate the content.
  • Deactivating the interactive elements is especially important when those elements block other content on the page. This is a common issue for dropdown menus and popup/modal content.
  • “Re-clicking” the focused interactive element that is open or active, is generally expected to close it again.
  • Connecting a “close” or “deactivating” event to the “Escape” key is also a common practice.
• The keyboard user can navigate away from the deactivated element.
• In cases where the activated element is overlaying or blocking other content, the activated element should close or deactivate if the user navigates away from it.

Consider User Expectations and Unplanned Behavior

Generally, the keyboard users expect to be able to re-click an element in order to deactivate it. However, it is not uncommon for developers to build in other shortcuts like closing an item on an “Escape” key press. It is a good practice to have a backup way to close a panel and “Escape” is the most common, however do not assume that your user knows that the backup or shortcut method is there. If your users expect to be able to re-click an element to deactivate it, and you do not have a good reason to not have that functionality, then you should probably build that in.

Also, think about what happens if the user fails to close the element.

Suppose you have a large video popup that takes over most of the screen. You would not want the user navigating behind this element, and trying to interact with elements behind the popup that are not visible when the video panel is open. In this case, and in cases where an activated element covers part or all of the content underneath, you should force the content to close or deactivate when the user navigates away from it. That way, content that is blocked does not continue to be obscured once the user is no longer interacting with the overlaying element.

Resources

• https://webaim.org/techniques/keyboard/
• http://accessibility.voxmedia.com/
• Visible Focus States

 

 

 

 

 

Alt Text in Context

Using ‘alt text’ on images and icons

One of the common mistakes that web content creators and developers make when trying to make their sites accessible is related to “alt text.” We are told somewhere in the web development classes, boot camps, and tutorials that “alt text” is how you make an image accessible. This is not entirely true.

“Alt text” is the text you add to an “alt” attribute on an image. If you have ever seen a broken image on a site that shows a description of the image, it is the alt text that provides that description. In HTML, it looks like this: <img src="example.jpg" alt="image description" />

A little clarification is overdue. First, if you are using an image via an img tag (as opposed to as a background image) then you need an “alt” attribute. This does not necessarily mean that you need “alt text.” The “alt text” is the literal description that you put into your “alt” attribute. So when do you need one?

When Text Descriptions on Your Image are Essential

Text descriptions are absolutely essential in specific cases. Here are the circumstances in which alt text is not only necessary but crucial for your site’s accessibility.

• The image is serving as an interactive element such as a link or button – screen readers will use the alt text to describe the link or button.
• The image conveys information that is not otherwise available in a text form such as in an infographic.
• The image includes text – please note – for accessibility purposes you should avoid using text in images whenever possible. However, in some cases such as for logos, text in an image is sometimes necessary. That text should be conveyed via the alt tag.

Also note, that if the same text is available near the image such as in a long text description or caption below the image, then the alt text may not be necessary.  The w3c has a nice decision tree for helping you determine when a text description is needed:

https://www.w3.org/WAI/tutorials/images/decision-tree/

When Not to Use Alternative Text

Imagine that you are a non-sighted user perusing the web site of a business that you are interested in and you here this: “Summer rates available for a limited time. Large yellow sunflower.”

That second sentence is the alternative text for the lovely sunflower image that the business uses across their site to accentuate their brand. The question for the business owner is: do you really need to tell your non-sighted users about the yellow sunflower –  everywhere that it occurs? More importantly, do you think that is what they want to know about?

For accessibility purposes, you should have an alt attribute on your images. However, in many cases you can use a null attribute. <img src="example.jpg" alt="" />

Notice the alt=”” in the code above. This is an empty or null alt attribute. Leaving the alt attribute empty tells screen readers that the image should be ignored.

Images that are only decorative in nature should get an empty alt attribute so that screen readers will know to ignore the image. You can still convey images that are intended to convey an emotional appeal by describing the image. Keep in mind that text descriptions of an image may have a bit of a different feel than the image itself.

Remember Cognitive Load

Before you fill your site with atmospheric images with descriptions like “Smiling happy couple,” and “Older couple, happily walking through a park,” think about what you really want to convey to your users. Too much information can negatively impact your intended message.

For screen reader users, cognitive overload from too much repeated information, or unneeded information is a frequent complaint. So make sure that that atmospheric image conveys useful information to your users before you add a text description to the alt attribute. Your users are generally on your site for a purpose, and unless you are a stock image site, they probably don’t want to know exactly how happy the images of the people you add to your product pages are. Instead, focus on the actual product, information, or message that you are hoping to convey.

Resources

• https://www.w3.org/WAI/tutorials/images/decision-tree/
• https://css-tricks.com/some-things-about-alt-text/
• https://developers.google.com/web/fundamentals/accessibility/

 

Web Accessibility Basics – Focus Outline

This is the second article on my web accessibility basics series. See Web Accessibility – Where to Start to find out more about contrast standards.

Visual Navigation

Have you ever been comfortably navigating your laptop or desktop computer when suddenly your mouse cursor disappears? Maybe it froze or got lost in some black hole off the screen. It is incredibly frustrating because your computer usage comes screeching to an immediate halt. You literally cannot interact with your computer without that little visual indicator of where you are on the screen.

The mouse arrow, pointer, or cursor provides a crucial component of your computer using experience. It is the visual indicator of where exactly you are working in the interface. In websites and applications it provides additional visual queues. The arrow may change to a pointer or finger icon when you are over an interactive element such as a link.

When you are visually navigating and interacting with a computer screen the visual queue provided by the mouse arrow, a blinking cursor, or a pointer makes the difference between a usable and not usable interface.

Visual Navigation Via Keyboard

Now that you know how very crucial it is to have a visual indicator of where you are on your computer screen, imagine that for some reason you are not using a mouse to navigate. There are number of reasons that this might be the case. You may need to use a keyboard to navigate due to a having a limited range of motion in your wrist, or because you have a child in one of your arms. You may be using a screen reader to read the contents of the screen to you and not using the visual interface at all.

In these cases, having functional keyboard navigation is incredibly important. The visible focus state is the keyboard user equivalent of the visible mouse cursor. Keyboard users can use the tab button to jump between links, buttons, inputs, and other interactive elements on the page. So how do they tell exactly what they are interacting with on the screen? They need a visible focus state.

Luckily browsers set visible focus states by default. If you have ever seen that bright blue outline around a link or button (typically a dashed line in internet explorer and firefox) then you are familiar with the visible focus states.

So Where is My Visible Focus State?

Unfortunately, these outlines are often disabled by developers due to design teams disliking them, and in some cases responsive frameworks like Foundation will disable them by default.

You can actually customize your focus outlines in css using the focus pseudo-class.
a:focus {
outline: 1px dashed red;
}
button:focus {
outline: 1px dashed #222;
}
input:focus {
outline: 2px auto blue;
}


The above code applies outlines to their respective html elements on a page.

Set Visible Focus States on All Interactive Elements

You should also have visible focus states on any interactive element on the page. By default focus states are applied to form inputs, buttons, and links (‘a’ tags). For example, if you have a slide out panel, or series of sliding panels like an accordion menu system, then you should have a visible focus state on the element that activates the hidden panel.

It is a good idea to use a button element anytime that you want to have an interactive panel on a page that toggles open and closed – e.g. drop-down panels, accordions, etc.

By default button elements are focusable. Another common method is to us an ‘a’ tag with the href attribute set to “#”. This will create a focusable element for the activating element of your panel.

It is important that interactive elements be focusable by keyboard users, and for the focus state to be visible. That gives your keyboard user a visible queue of what element they are on. Non-focusable elements may not be findable by the keyboard. In other words, your keyboard users may have no way of knowing that an element can be interacted with if you do not use a focusable element, and set a visible focus state to make it clear when that element gets focus.

Additional Resources

• Outline none
• https://css-tricks.com/almanac/properties/o/outline/

In the next article I will discuss how to make your interactive elements activate with the keyboard.

The Unfortunate State of Professional Web Accessibility

Cross posted from medium.

I see it happen on a regular basis, a client insists that their site is “fully accessible” or “fully WCAG 2.0 AA Compliant,” and it isn’t even close, and I don’t mean “they missed a spot,” or that there is some narrow area that I would have personally handled differently. I am referring to giant, obvious, even basic accessibility issues that still exist on the supposedly compliant site. Usually, the culprit is a web-related services company who added “accessibility remediation” to their service offerings without fully understanding what that meant or gaining the necessary expertise.

Let me be clear, any improvement in the accessibility of a site is good, even if the site is far from “fully accessible.” We do not want the perfect to be the enemy of the good. There are, however, a great many companies offering “complete compliance”, “certified compliance”, “certified ADA compliance,” and “certified WCAG 2.0 AA compliance,” that have in reality, chosen to pay attention to only a fraction of the standards that they are claiming to attain.

To state it in another way, if a company is certifying a website as “fully WCAG 2.0 AA compliant” then they should know every WCAG 2.0 AA success criteria inside and out. They should understand the best practices that are recommended by the W3c and by the web accessibility industry. They should be well aware of common failures for every success criteria and how to spot them. They should know the strength and weaknesses of automated testing and when manual testing and QA are needed (which will be something like 70-80% of the work that they do). They should know what it means to get as close as reasonably possible to that conformance level as a site can get. And they should absolutely be aware that while a high level of conformance is possible, perfect conformance is not.

Here are some of the major accessibility failures I see regularly on allegedly “WCAG 2.0 AA certified” websites.

Text Images

No, you may not just use text images wherever you feel like it. Text images are not accessible. They cannot be resized, or restyled for users that have vision or cognitive issues. That is why they are effectively prohibited where they can be recreated via css and actual text. There are a narrow range of exceptions to that rule for items like logos, and depictions of font families. I see this all the time on these supposedly remediated sites — dozens to hundreds of ads and banners that use images of text. Often the developers of these sites do not even attempt to include all of the text from the image in the alternative text attribute, which violates another success criteria.

Contrast

If you do not understand the color contrast requirements, then you are missing one of the most basic accessibility requirements. The problem is that there is a little bit of variation in the contrast requirements based upon the size of the text. Some “accessibility remediation” providers seem to have decided that a 3:1 ratio is all that is needed for all circumstances. Sorry, no. For fonts that are smaller than 24px and not bold the criteria is 4.5:1. If your font is bold that change happens at 18.66px — smaller than that and bold still needs the 4.5:1 ratio.

Pause moving content

Does your content move, rotate, animate, or update, for more than 5 seconds? Then you need a pause button. That means that unless it stops moving entirely and never moves again by the 5 second point, then you should have some sort of pause button that stops the movement. Your auto-rotating banner is entirely non-compliant without this. Your animated flash ad in the sidebar is non-compliant without a pause button. Where is it?

Forms need labels

Yes, there are some exceptions to this rule, but those exceptions are there for circumstances where a label would not provide a benefit, or might make the interface more confusing. You can’t just toss your form input labels because your design team thinks a form looks “cleaner” without them. This is such a basic requirement, that it amazes me how often I see sites that completely neglect this, or use some other technique to try and work around it. Placeholder text is not a replacement for labels or instructions, because placeholder text disappears when you type into its associated input.

Focus States

Have you ever tried to navigate your computer with a mouse after the cursor has disappeared. You can’t do anything, because you can’t figure out where you are on the screen. Focus states are the equivalent of the mouse cursor for keyboard users. If you have disabled focus states or overridden the defaults with something effectively invisible, then you have a site that is not navigable with a keyboard, and hence not accessible. Visible focus states are an explicit WCAG 2.0 AA requirement.

Hidden panels that are not properly hidden

So you are casually using your keyboard to navigate through a website when suddenly your focus state disappears, and then it reappears 40–50 tabs clicks later. It probably just disappeared into a hidden menu that was not fully hidden from the DOM. This happens when developers hide an element by using off screen positioning or some other similar technique rather than “display: none” or “visibility: hidden.” The result is that you just failed the keyboard operability requirement, the visible focus states requirement, and the focus order requirement. It’s like a three-for-one failure, and it really does create a terrible experience for keyboard users.

Look Ma, I beat the automated accessibility checker!

Automated accessibility testing tools are very important, however, they can give you false positive results, false negative results, and they really only cover a small fraction of the accessibility issues that need to be fixed. The vast majority of the issues (75–80%) can only be found via manual testing. But that doesn’t stop less-than-well-trained remediation companies from simply trying to beat a specific accessibility tool, rather than developing a full remediation plan. In the process, they often create problems worse than the ones they are trying to fix.

I have seen sites that put “display: none” on their form labels. This accomplishes nothing. It does not provide readable labels or useful instructions to any of your users. But it does fool some accessibility testing tools.

On another occasion, I saw a site in which the “accessibility remediation company” realized that that css icon fonts (Font Awesome in this case) needed some sort of text inside of a link. Screen readers cannot read css icon fonts, and so when they are used for a link, the developer needs to provide some sort of text to the assistive technology users. The developers at this firm solved the problem by using a span element with “display: none” on it, inside the link. The span had the proper text of the link — the names of the associated social media websites in this case. Unfortunately, assistive technology does not read elements that have “display none” on them. So what did this accomplish? It passed an automated accessibility tool, while not actually providing readable text or a functional link to assistive technology users.

Assistive Tech users are not the only users you are trying to reach

Don’t “screen-reader-only” your skip link. Seriously, don’t do it. Think of all the sighted people with mobility issues that really do not want to tab through all of your navigation. Think of them, please. And while you are at it, labeling inputs in a form actually helps everyone understand what your form is for. Please don’t “screen-reader-only” your labels on anything that is not a super simple, very small (like single input) form. I understand that sometimes you are trying to squeeze a little search box into a small area of a header somewhere, it is already obvious that it is a search box, and that a label could be redundant. But did you really just “screen-reader-only” all of the labels on your “contact us” form? Seriously, don’t do that. For those not familiar with the concept of “screen-reader-only,” there are multiple techniques for visibly hiding an element while making it still readable to screen readers. Sometimes, these techniques are both necessary and appropriate, but like any useful techniques they can be misused and misapplied. Remember to consider how those without assistive technology might be using your site. Users with mobility impairments, but not vision impairments are often forgotten in the push to make a site “screen reader friendly.”

Don’t Forget HTML validation

It’s actually really important that your HTML be parseable. Browsers are very forgiving when it comes to developers using poorly formed code, deprecated code, and even misusing their HTML. If you don’t ever try out the validator, you will never figure out that those <style></style> tags are really only supposed to go in the head of your document, not the body. You might never figure out that your CMS is injecting duplicate ID’s into your page. You might never notice that half the attributes you are using on your tables were deprecated a long time ago. Not every piece of software that attempts to read your page will be as forgiving as a browser, and all of your careful efforts to make your site accessible could be in vain, if it turns out to be non-parseable.

Headings have an order

That’s what the numbers are for. H1, H2, H3… They should go in order. They are not there to satisfy the styling plans of your designer. They should be used in a logical way. Your H1 should be closely related to the title of the page, or be a clone the title itself. Each subheading that is not nested inside of another heading will probably be an h2 at this point, subheadings nested inside of h2’s should be h3’s, etc. There are multiple requirements that relate to this, but the most relevant is likely that the structure of your page should be programmatically determinable. If you are using fake headings like bold font in the place of an actual h tag, or mis-ordering your headings, your page structure will not be understandable to assistive tech users.

Use roles and aria attributes correctly

Semantic HTML elements have implicit roles, you should know what those are. Both aria attributes and roles are meant to be used in specific ways, and have rules for how they are used. Some aria attributes are not allowed on specific html elements. Some areas of your page are considered landmarks, and should have appropriate roles associated with them. Sometimes, remediation firms completely muck this up, and even, on occasion, make up their own roles or aria attributes. Seriously, you can’t just make up your own “aria-stuff”.

The bigger picture

There are so many other issues that are necessary to address to make a website WCAG 2.0 AA compliant — i.e “fully accessible.” The things I listed above are actually the very basic requirements. And when a remediation company has misunderstood, or even completely failed at the basics, then I already presume that they are missing the much more complex issues.

If they can’t figure out contrast or form label requirements, I am going to presume they do not know how to support 200% zoom, or that they have not adequately screen reader tested their sites on IOS devices. They probably never noticed how very inaccessible their mobile menus or accordions are. I am also going to presume that they do not have a clue about how screen readers deal with form input validation, or if their forms are even usable with assistive technology.

Imagine, for example, if every single form on a site was completely unusable to non-sighted users, in spite of the fact that the site was “certified accessible,” because it was using an old inaccessible version of captcha. I have witnessed this on multiple sites, and it is tragic. The owner of the site sincerely believes that they are serving all of their users with a fully accessible site, while entirely failing in one of the most crucial areas.

As developers, we have been misusing and abusing our HTML for years. We have developed and propagated css techniques that fail to consider how both third party software, and assistive technology users will interact with our sites. We have almost entirely neglected the concept of keyboard navigation while designing our desktop sites around the interactive presumptions of mouse and trackpad use. And we have embedded widgets and tools into our sites that block some groups of users entirely from using the services offered by our sites. This is why a deep understanding of website accessibility is crucial to not just those developers that specialize in it, but to all developers who work with the web.

Web Accessibility – Where to Start

Many businesses, when faced with the prospect of making their websites accessible do not know where to start. This post is intended to help with that.

The easiest place to start for most web site designers and administrators is with color contrast. Color contrast refers to the level of contrast the text on your site should have to its background.

There are two primary levels that you should be aware of the 3:1 contrast level for large text, and 4.5:1 contrast for small text. Large text is text that is 24 pixels in height or larger.

A common error is to presume that the 3:1 ratio is good enough for all text across your site. Unfortunately, it is not. Because smaller text is more challenging to read it requires a higher level of contrast to be legible. Small text and this generally includes your standard body text, needs to have a 4.5:1 contrast ratio. In addition, you should never use text, even fine print text on your site that is smaller than 10 pixels.

If you are in doubt whether or not your text should have the 3:1 or 4.5:1 ratio, err on the side of caution and just use the 4.5:1 ratio.

Determining Contrast

There are a number of tools that will check your contrast levels for you. Developers typically use a tool like Webaim’s wave checker to determine the contrast ratios on their site. This comes in a convenient chrome extension. In addition, you can use Webaim’s color contrast checking tool to try out individual colors and backgrounds.

Why is Text Contrast Important?

For a number of years it became somewhat fashionable in website designs to use very faint text, particularly in form fields and in footers. This low contrast text causes major problems for site users who have low visibility. You do want your site visitors to be able to read your content, right? That is why you put the content on your website, right? So give it enough contrast to be legible to the widest range of users possible.

The Design Dilemma

I really like creating awesome website designs. I am consistently amazed at what css can do now that it couldn’t do 15 years ago. When I made a website in high school (circa 1998), I spent hours putting little bevels and drop shadows on my buttons. That was when CSS was this fancy extra thing that seemed like way too much trouble to bother with. Now a few extra lines of code and gradients, drop shadows, and even circular buttons are easily done with zero photo-shopping involved. It is really amazing, but I also love the process of figuring out the logic of working out the back-end.

On my final project I was most proud of creating my own search engine for our app that searched our database by geocode (latitude and longitude) and returned all the results within a ten mile radius. Of course I didn’t create the actual function that calculated area of a circle from a specific set of coordinates plus a radius, and then looked for lat/longitude coordinates that fell within that range, but I know I could have. I took two semester of geology and the physical geology class involved a lot of work with maps and lat/longitude coordinates plus geometry has been one of my passions since I was a kid… so yeah I could figure a range of latitude and longitude coordinates that fit within the area of a circle on a map.

I love that stuff. I love figuring out how to create sophisticated search queries and return only the desired results. I love that exact sort of problem. My dilemma is what to focus on.

Visual design is great, I already have reasonably good skills and experience doing it, and I have already had one job that I loved, doing exactly that. The downside: the difference between good designs and great designs is often just subtlety. Take a look at one of your favorite websites -WordPress for example. It looks like a pretty simple design. But check out all the subtle effects that someone had to put there. Subtle borders on each box, a very subtle gradient on the “publish” button, a soft-drop shadow below the top bar, the hover effects that occur a little slower than most, the single well functioning drop-down menu. It’s all stuff I could do, but the hours and hours of tweaking and subtle changes I would have to do to get it just right, well that’s the trouble.

I was raised in a family of artists and I have a great eye for creating graphics and taking good photos, but I am constantly in awe of what I see on just basic website designs these days. It’s gotten so zen. Gradients so subtle you wouldn’t notice if you weren’t looking, show up as hover effects in my gmail account. Ever-so-slightly rounded corners, here, there, everywhere. Css animations controlled by milliseconds, because even though most people aren’t going to consciously notice, we do notice subconsciously. That sense of a site being just “thrown-together” by some internet-marketer or spammer versus the professionalism of google, wordpress, and facebook is all in the subtlety.

So maybe I miss the days when creating my own tiling brightly colored backgrounds for my geocities-site impressed everyone (mwa ha ha). It’s a little of that, but there is also the very real understanding for me that modern webdesign is about mastering subtlety, and I think I would rather master programming logic, and solve those interesting back-end challenges that require a thorough logical thought process, a little bit of pseudocode, and a few trips to google to figure out.

It’s a big dilemma for me. Geometry and o-chem were my favorite subjects in school because they required both logic skills, and the ability to understand problems in a visual way. I’m back to feeling like I have to pick one. I just don’t quite understand why a 3px border-radius makes a button look so much more professional than leaving it with regular corners. There’s got to be some logic there but what is it, and how do I anticipate it? I feel like I’m just copying. It looked nice when wordpress did it… so why not?

On the other hand, the stuff I have read about user interface design and user experience is the most fascinating and thought provoking material I have found on the internet. The potential for changing how people think, learn, and interact is kind of huge, and it all comes down to thinking about, and understanding the user experience -which brings in an understanding of learning, of human psychology, and of intuition. Dismissing UX/UI as an area of focus is like dismissing the open source movement in the 90’s as being a viable movement (lol – Linux, rails, and github have been my life-blood for the last 3-months).

So yesterday, I started re-working the design and user interface of my final project, today I started getting into the nitty gritty of how search engines work, tomorrow more css-sass, a few days ago I was learning regular expressions, and this week I want to add javascript functionality to a periodic table app I’ve been working on.

It’s fun, it’s fascinating, it’s invigorating, and the focus is long-gone.