What is Web Accessibility?

Web accessibility is about putting people first. It’s about digital equality and inclusion. It’s about understanding the diversity of users and designing for the needs of the widest range of people – including (but not limited to) those with situational, temporary, changing or permanent disabilities. It’s not about edge cases: designing for inclusion makes the design better for everyone. It’s not about “them”, it’s about us.

So, why’s the process of creating digital products so broken that we – often unintentionally – create exclusions, or simply make the products difficult to use? How can we try to fix the accessibility process?

The Cost of Accessibility

Accessibility does have a cost: it’s the cost of being professional and doing the work well. It’s operational cost, not a line item in a project. This of course requires initial training, awareness and organizational changes, but once your organization designs, develops, delivers and sells with accessibility in mind, the cost becomes close to nothing. Retrofitting accessibility is expensive, so the trick is to start early and proactively integrate it into the work processes. You can either do it now and save money or do it later and lose money. Or you can skip it altogether, but then your customers will take notice.

It’s important to understand that accessibility is neither a feature nor only a checklist. It’s a facet of quality user experience and as such, it can be a crucial differentiator and competitive advantage in the product or service you’re selling. By ensuring your product is accessible you might even avoid a lawsuit when the new European accessibility legislation becomes binding law.

Some Reasons for Poor Accessibility

• Myths
• Business decisions
• Lack of knowledge, experience, time or money
• Ignorance
• Vendor lock-in (authoring tools/3rd-party software)
• Culture or organizational structure

More specifically, I have identified the following areas of improvement:

1. Accessibility Audit
2. Evaluating by Principle
3. Prototyping with Idealized Static Content
4. Automated Checklist Accessibility
5. Awareness, Motivation and Training
6. Company Culture and Organizational Structure

Let’s break these down one by one.

1. Accessibility Audit

If you ask a consultant to do an accessibility audit for you, the result is often just stating the obvious: the product has barriers to accessibility. Every product has. The key is to turn accessibility audit into an organizational learning experience by working closely with the client and suggesting better practices that ensure success. It’s important to try to reduce complexity around accessibility and help solve the root causes in a sustainable, predictable and actionable manner.

2. Evaluating by Principle

It’s common to report accessibility issues by abstract principles – after all, that’s how the Web Content Accessibility Guidelines (WCAG) are organized. However, a better approach is to think holistically and in terms of accessible Design Patterns. After you learn to evaluate and identify problematic patterns, you can use better ones.

3. Prototyping with Idealized Static Content

Prototypes and designs should offer various ways of consuming dynamic content. We all have different levels of vision, hearing, dexterity, and cognition. Even for “perfectly abled”, sometimes the situation is less than ideal: reading on your phone in bright sunlight, using your device with one hand only, or when you’re constantly interrupted when you’re trying to complete a task. These are just some simple examples.

4. Automated Checklist Accessibility

Automated accessibility testing is important, but it only tells you if it finds failures in code. These technical failures highlight just a very small percentage of all possible issues that people can experience using the product. It doesn’t tell you if the product is actually usable. Relying only on automated tests can help you achieve technical compliance, but the quality metrics should be based on accessible user experience and the ability to get things done. This means that you should always test with real users, in addition to automated testing.

5. Awareness, Motivation and Training

Product design decisions may affect the targeted audience in unexpected ways. You just might not be aware of why, how and how much. That’s why it’s important to have a Change Agent or a Champion in the organization creating awareness and transparency around possible accessibility issues. However, accessibility should be owned by everyone involved. Share the knowledge, collaborate and encourage “yes, and“ behaviour.

Finding the right arguments for a change can be challenging. It may be better to show and not tell. It’s easier to understand things after you’ve experienced them firsthand. Whatever you do, make sure to challenge the status quo and address ignorance and myths with training and workshops. The sometimes heard “…but this is a web app” excuse of not building accessibility in from the beginning is just one example of flawed thinking that needs to change.

6. Company Culture and Organizational Structure

Accessibility requires structural and process changes and a holistic view of the organization as a living system. Old-school functional silos must give way to cross-functional teams. Much like a good Scrum Master removing impediments to the team’s progress, so can the team eliminate barriers to accessibility and usability. High-performance teams already know that the key to achieving results of this caliber requires a mindset switch.

Examples of Integrating Accessibility into Your Process

• Create and use accessibility Personas when researching and designing
• Create an inclusive Design System driven development workflow
• Add accessibility guidelines in your Definition of Done and make sure the team has a shared understanding of them

Conclusion

I hope this post has given you some new ideas on how to integrate web accessibility into your workflow. We’ve seen how a little bit of empathy, awareness and leading by example can go a long way towards improving the lives of people using your product or service and make a positive impact on bottom line.

Remember: all technology is assistive.

Style guides and pattern libraries are a great collaboration and communication tool in cross-functional teams. These tools have many names and variations (see styleguides.io), but in this post I’ll just call them style guides. Essentially they break down the user interface into its component parts, and serve as a resource for new designers and developers to locate existing patterns for further use. Decoupling the UI from application data, and splitting the UI into components often results in a more consistent and efficient UI for users.

Problems

Style guides are often static, with no direct connection with the app templates. As Ian Feather emphasizes in his excellent article, A Maintainable Style Guide, once your style guide falls out of sync with your application it has entirely lost its purpose. So how can we ensure your style guide is relevant and always up-to-date?

Main Style Guide types

So far, I’ve worked with the following four main types of style guides:

• Loop through a component directory of styled markup snippets (examples: Pattern Primer, Barebones)
• Analyse the CSS and render the style and markup from the Sass/CSS comments (examples: Hologram, KSS)
• Maintain a larger, atomic design system (examples: Pattern Lab/Atomic Design, Lightning Design System)
• Consume the same component API for both the app and the style guide (example: Lonely Planet style guide)

I prefer the last option: a living style guide with the same shared components used everywhere. I’ve worked with style guides on different tech stacks over the years, but since I nowadays work a lot with React, I’ve created a simple Living Style Guide with React on Github.

I didn’t do much styling as I wanted to keep things simple in this project. If you want to read more on how to structure your CSS, see Architecting CSS for Responsive Large Scale Applications.

Style Guide Driven Development

Having a style guide drive your design and development work really helps in establishing a shared vocabulary in the team. It also helps in finding patterns in the UI, saving extra development time as we can consolidate similar components. We want to create atomic design systems, not pages, so having all the components in one place ensures that we can test and iterate over them more easily. When you need new components, build them first in the style guide, consuming the same data than your app does. Then you can mix and match these components to compose pages for production.

Finally, I don’t think style guides can be fully automated. They are part of the workflow, showing the whole organization’s commitment to a coherent design system. You’ll want to define your components – and the data they consume – one way or the other, and also describe their usage for team members with different roles. This is just one way of doing it. I hope you find it useful – and as usual, feedback is appreciated on how to make it better.

Living Style Guide with React on Github

I’ve adapted the way I write CSS many times during the years. In recent years I’ve settled with a hybrid set of methodologies that work well for me and the team, so I thought I’d document my approach here. A few years ago people released new JavaScript MVC frameworks almost on a daily basis. Now the same is happening to CSS: new CSS frameworks and toolkits are released regularly, which is a sign people actually care!

Problems we’re trying to solve

Some of the problems in CSS land:

• Selectors mixing layout and look & feel, doing too much
• Nested selectors tied to their location in the DOM, reducing scope for reuse (contextual styling)
• CSS and JavaScript tightly coupled
• Design patterns not abstracted enough
• Specificity issues
• Different developer preferences
• Time spent in debugging/fixing issues due to style leaking

Many articles have been written on the topic, I’m just restating the problems here to explain how I arrived at my favorite setup. And no, vjeux’s CSS-in-JS, driven mostly by ReactJS folks, does not provide all the answers to these problems. More on that later.

Requirements for scalable CSS design system

According to my experience, these are the main requirements for a scalable CSS architecture that minimizes side effects:

• Components should be able to live anywhere in the DOM and in the layout, without things breaking or styles leaking
• Components should be open for extension
• Each component should be responsible for a single part of the UI
• Components should be composable (like LEGO bricks), for building bigger components and pages
• And finally, the system should communicate useful information to developers in class names when reading a DOM snippet.

With those requirements in place, let’s see how we can achieve this.

Methodologies

I use a mixture of SMACSS (splitting the rules across base, layout, component and state layers), BEM (component-level naming conventions) and OOCSS (abstracted reusable patterns and utilities). The reason why I like these methodologies is that they define a high-level abstraction, leaving the actual implementation and syntax details to the team to decide.

Base

This layer contains only all base element defaults and reset rules, no classes/IDs. You should never use IDs for styling anyway.

Layout

This layer contains the major layout and grid rules, with classes always prefixed with .layout- or just .l-. These classes may be used also on component level if necessary, to create minor layout in components. In this case, they can live in the same DOM element than the component top-level namespace but again, prefixed with .l-.

Component and modifier

Components should rely on their parent container for sizing. They should only know how to style themselves and do that job well. The less the components know about their surrounding elements or their external spacing, the better. Components can be composed of other components but they should inherit rules only from the base, not from other components. I’ve used BEM many years now (Harry’s Mindbemding article is recommended reading).

Component state

State classes should be prefixed with .is- or .has-, and scoped to the component or sub-element and never global, for example .tweet.is-favorited. Media queries also modify component state.

So what’s the difference between a state and a modifier? It can be difficult to decide sometimes. The difference is subtle: state classes describe component’s appearance in various states, whereas BEM modifier classes describe modifications in component’s base appearance, regardless of state. Very subtle (and somewhat theoretical).

Utils

This is where lines again become blurred. What’s the difference between a component and a utility? In my mind, component is a namespaced singleton whereas utility is common functionality or atomic property that is applied to many objects (components). How you want to call these is up to you and your team. Some people prefix utility classes with .u- to indicate their purpose.

I use utility classes mostly for managing white space (such as .ml1 which would be defined as {margin-left: $white-space1;} in Sass for example), but they can be basically anything. Just remember they have to be different from layout and component namespace classes. Spacing classes is a feature that’s missing from many popular frameworks, which is why I prefer smaller, modular and designless toolkits. I particularly like Scut, SUIT CSS, Basscss and Tachyons, to name a few. They provide useful pieces of reusable functionality, either as simple atomic classes doing one thing, or larger mixins implementing certain feature (for example centering an element on both axes). I’m also using the OOCSS media object extensively.

Basic example

See how much meaningful information you can extract from the markup snippet below. It demonstrates the use of all the class layers described above.

<div class="l-row">
  <div class="l-row__unit l-row__unit-3">
    <div class="accordion" id="js-accordion" data-ui-component="accordion-stream" aria-multiselectable="true">
      <h3 class="accordion__heading is-expanded" role="presentation">
        <a href="#js-acc1-p1" id="js-acc1-t1" role="tab" aria-selected="true" aria-controls="js-acc1-p1" tabindex="0">Tab heading</a>
      </h3>
      <div class="accordion__panel media" id="js-acc1-p1" aria-labelledby="js-acc1-t1" role="tabpanel" aria-hidden="false">
        <div class="media__img">
          <img width="150" src="" alt="" />
        </div>
        <div class="media__body u-text-truncate">
          <h2 class="h1 ml1 mr1">Module Headline</h2>
          <p>The media object saves hundreds of lines of code.</p>
        </div>
      </div>
    </div>
  </div>
</div>

Responsive design and exception handling

Now let’s throw responsive design into the mix. How do you apply a layout, media object or utility only for certain screen sizes? What if you sometimes want that class to be responsive, and sometimes not? As always, it depends.

Let’s take media object as an example. Consider these design scenarios:

• I want the media object to be responsive all the way from small to large screens
• I want the media object layout to be applied only on, say, large screens
• I want to keep the same media object layout on all screens sizes

How would you manage these three situations? It’s helpful if we can identify the default case first. What do you think the default rule should be? What are the exceptions here? I’d argue that since we want to use mobile first approach, responsive should be the default, and if we want to override that, we’d use a modifier. Here then the default class would be media-object (with media queries), and for the second case, we’d add media-object--page-lg that would override relevant rules up until large screen. For the third case, we’d use media-object--page-xs and add our overrides there. Since responsive is the default, overrides would only be rare edge cases: exceptions. Alternatively, we could use state classes since media queries belong to component state domain, like so: .media-object.is-page-xs. Up to you, as long as you do it systematically in your team.

Managing variations

The caveat here is that at some point, you’ll realize you have too many minor component variations. This is not a failure in code, it’s a failure in design system. The solution is two-fold: talk to the designers, and use Style Guide Driven Development. Your future self, your colleagues and your users will thank you.

Contextual styling

Also worth reminding is that contextual styling should be kept to a minimum. A component may be designed to look different inside another component, but that doesn’t mean that it should be implemented with contextual styling. There is no nested component context, and that is simply because components don’t know of each other. A component can be positioned inside another component, but that responsibility belongs to minor layout classes (or utilities). Nested components’ job is simply to render themselves. If a component happens to look different when it’s inside another component, it’s because that nested component is using a component modifier, not because it’s inside another component. When you understand this, you’ll experience the full power of scalable CSS components, modifiers and utilities.

The future

The approach I’ve described in this post has worked very well for me and my team the last few years. We’ve had very few style leaks and practically no UI regressions. I mentioned in the beginning that I’m not a fan of CSS-in-JS. It’s an interesting experiment and an honest try to solve the issues CSS has, but it feels a bit over-engineered and too tightly coupled with JavaScript, solving some of the problems but creating others. Some argue that CSS classes should only define the stateless appearance of a component, while state styles should be inlined, to encapsulate behaviour in one place. Fair enough, good point, but if you start putting styles inline, where do you stop? You have to go all the way, otherwise it gets too messy. I’m not completely against it, I’m just not convinced that CSS-in-JS would support designer/developer workflow that well, not to mention backend developers who also touch frontend code. Maybe it works well in certain projects. Keep in mind though that it locks you down to your selected JavaScript framework.

With that said, I find CSS Modules concept quite exciting and will be following it very closely going forward. Best practices change all the time. You decide what’s best for your team and product. It’s best to keep your mind open.

Tools

This post is not about tooling, but suffice to say that you should of course be using stylelint and PostCSS with your Sass. With stylelint, you can programmatically enforce BEM syntax in your components, prevent rule nesting, and do lots of other things. I recently wrote an article about configuring stylelint.

Closing thoughts

Many backend developers and designers I’ve worked with also like this layered class-based approach because it empowers them. Changing a few atomic class attributes in markup is far easier and faster than refactoring tangled style sheets. On the other hand, if the markup contains too many atomic classes, you might be giving too much freedom to markup authors. Make sure to keep the UI consistent. That’s why you’re doing Style Guide Driven Development, right?

Before adding anything new to the codebase, do yourself and your team a favor and ask yourself the following questions:

• Does this style exist already? If yes, can I reuse it and maybe abstract it into a utility?
• If this style doesn’t exist yet, what should the new class do? Does it belong to layout, component, state or utility domain? Or is it just a hook for JavaScript, without styling? If it’s none of these, fall back to global HTML elements.

The goal here is to use methodical approach, to reduce ad hoc decision-making.

In this post I’ve talked a lot about components. In many ways, components, modifiers and functional utilities are the meat of the matter of reusable and scalable CSS. It’s important to keep in mind though that component-based design doesn’t always mean that all the CSS should live in the dedicated CSS file for that component (most of it should though). A composed HTML component can include classes from different layers as long as it’s very clear what each class does (because you have a self-documenting naming convention described in this post and shown in the basic example snippet). Go compose!

Partial credits

I’m listing here just a few epic articles. You can find many more in my frontend-dev-bookmarks.

• About HTML semantics and front-end architecture
• CSS Architecture
• Against CSS in JS
• Contextual Styling
• The Role of Utility Classes in Scalable CSS
• Battling BEM

I took the time to read the excellent rules documentation and added stylelint setup for Sass files in my webpack-es6-sass-setup. Configuration includes all the available rules but I’ve turned off the ones that I don’t currently need. I use BEM, so I’ve added stylelint-selector-bem-pattern plugin as well. It’s a bit of a challenge to get the regular expression patterns right, so that part needs some tweaking to allow selectors like this: .main-component__status.is-active. Here’s my .stylelintrc configuration file. Initial configuration for stylelint takes some time but it’s totally worth it!

Many articles and books have been published on this topic. Over the years, I’ve collected some of these testing tools in a Markdown file for a quick reference for myself. I thought I’d share it, so I’ve created a new GitHub repository for Accessibility Testing Tools. I hope you find this list useful!

Work

Most of 2015, I worked in a small and highly skilled team at Podio/Citrix building Beagle, a tool for agencies for creating and reusing proposals. It was a good opportunity to learn about product design/development and work with a modern web stack, and establish a good architecture around it with React, Flux, ES6, BEM, node and webpack. I created a modular Style Guide for the product as well which really helped in maintaining a consistent UI.

Towards the end of the year the future of the product became unclear so I felt a change was necessary. So I quit Podio in October, and in November joined Bownty, a Danish startup providing online to offline deal curation service in hundreds of cities in multiple countries. As Lead Front-End Developer, I’m responsible for modernizing their front-end stack and related tooling, making the site responsive, and making the case for usability and accessibility as we obviously want to provide a good experience to as many consumers as possible. A good work atmosphere, solid business model, and a chance to work on many different areas with new tech with great colleagues make Bownty a great place, so I’m quite excited about it!

Side projects

Outside work hours, I’ve spent time with a number of small side projects and starter templates, mostly on GitHub. These include setups for jspm/systemjs, ES6/Babel, React, Sass, webpack, ES6/Babel, Sass, and React unit tests with Mocha, jsdom, unexpected and SinonJS. Nothing ground-breaking, compiled from different sources around the community, but helpful in getting hands-on with new stuff. I’m maintaining my front-end dev bookmarks as well, and reading a lot.

Conferences

During 2015, I attended three web conferences in Europe: ReactConf Europe in Paris, HybridConf in Dublin and ColdFront in Copenhagen. Good content and food for thought in all of them. Looking forward to meeting new inspiring people at conferences (and elsewhere!) in 2016.

Mobile photography

I’ve been using Flickr since 2007, but this year I finally joined Instagram and VSCO too. These services are a lot of fun to use (but it’s sometimes hard to choose between those filters and not overuse them).

With that, bring on 2016!