Forem: Nothing

5 code improvements you can apply today to make your website more accessible

René Stalder — Fri, 04 Jan 2019 15:37:56 +0000

If there is a component in web development that is too often treated as an option only (if at all), it’s accessibility. Companies want business value out of it but don’t see a benefit; developers have either never heard of accessibility for the web or think that they can’t apply accessibility in their company due to lack of time.

In my experience, accessibility for websites and web applications is 80% writing standard compliant HTML markup with progressive enhancement in mind and 20% content improvements.

The 80% should be doable by every front-end developer with fundamental knowledge in HTML, CSS and JavaScript. This is about semantics, using the right HTML elements, applying correct keyboard focus order and so on. A big part of this work can automatically be tested with tools like aXe (the same engine that powers Google’s Lighthouse accessibility tests).

The last 20% — and that’s why I call it content improvements — is a lot of “accessibility by usability”. It’s less technical and more about how you provide the content of your website so that everyone understands it. This is about providing additional hints for screen readers, subtitles in videos, making content readable in high contrast mode or replacing PDFs with web pages (or replacing them with accessible PDFs).

And, of course, design is also a big part of web accessibility. In this post, I want to show developers five code improvements they can apply today to make their website more accessible.

Disclaimer: I might link to various chapters of the Accessibility Developer Guide in this post. Not because the company I’m working for is contributing to the guide but because it provides a more detailed explanation of the materials in this post that are actually tested, verified and kept up-to-date. They are also much easier to understand compared to the official WCAG specification.

Before we begin: Fundamental mindset about HTML and CSS

It’s important that you approach HTML and CSS separate. It’s totally fine to use an <a> element in code and then style it like a button. Your HTML markup should make sense on its own, without the styling. That’s why libraries like Twitter’s Bootstrap provide classes for various typographic choices in addition to the default element styling. I recommend using classes as much as possible over type selector styling. Your life will be much easier later on, I promise.

Twitter’s Bootstrap provides additional classes to elements other than H1 to H6 with the exact same styles.

Nr. 1 — Fix general code semantics

Semantics refers to the meaning of a piece of code. MDN — which is my favorite source to look up various features of the web platform — has a very good description of what it means for HTML, CSS and JavaScript to be “semantic” (I recommend to quickly read through the referenced page).

The most frequent case of wrong semantics I’ve come across on websites and applications — especially when frameworks like React, Vue.js or Angular are used — is the misuse of <div> elements for everything.

Here’s a short list of cases to check on your website or application:

Titles are wrapped in H1 to H6 tags. That doesn’t mean every title needs to be a heading element. Think of writing a text document e.g. in Microsoft Word. When would you style a line of text as a title? When would you make something bold? Just be aware that people using screen readers love to use the H1 to H6 tags to jump around your content. By contrast, boldness of a text, even when marked with a <strong> tag, doesn’t have any influence on how the screen reader accesses and reads your content.
Lists , no matter if it’s a list of navigation items or a list like this one here, are defined as unordered lists, ordered lists or description lists. Make sure there is no list with only one element. For example, if your navigation can have only one element in any circumstances, remove the list wrappers. Lists with only one element can be confusing to people using screen readers.
Interactive elements are either anchors (<a>), buttons (<button>) or form elements (e.g. <input>, <select>). If you find things like click handlers on elements like a <div>, that element most likely should be one of the elements above.
Use the HTML5 section elements in combination with ARIA landmarks to mark content. Not all have an effect on screen readers but some have. See the referenced page for a good explanation and how to implement.

That’s for sure not all you can do, but these are the most common cases of wrong semantics I’ve found in accessibility testings. A more detailed explanation with examples can be found in the Accessibility Developer Guide.

Nr. 2 — Fix your title structure

Even if you have all your titles wrapped in correct H1 to H6 elements, that doesn’t automatically mean that they are used correctly.

Check that there are no heading level gaps: e.g. a <h2> has to follow a <h1>, a <h3> has to follow a <h2> and so on. For example, if you find a lonely <h5>, no <h4> but only <h3> elements, something’s wrong. So you would rewrite your <h5> to a <h4>.

There is a bookmarklet that helps you to find these problems.

h123 bookmarklet output for gov.uk

Reminder: The visual representation of an element can be different from its HTML element. You can style a <h5> like a <h4> by adding a CSS class. And that’s what you should do in the case described above.

Nr. 3 — Add hidden titles to the structure to mark site sections for screen readers

This improvement belongs to the 20% mentioned at the beginning of this post: This is not something an automatic testing suite will tell you. These are the additional content improvements you either tackle based on feedback from manual testings or by gut feeling. And with gut feeling I mean:

What’s obvious when the website is visually represented but not so obvious when looking at the HTML markup.

The meaning of hidden titles is titles that are not visible by eye but can be accessed by a screen reader. This means adding titles like “Main site navigation”, “Language switcher” and “Site footer” to your content.

Taking again the example of gov.uk like in Nr. 2, you’ll see for example a hidden title for the links in the footer.

Part of the h123 bookmarklet output of gov.uk with “Mark visually hidden” option activated. <h2> “Support links” is marked as visually hidden.

Screenshot of the footer of gov.uk, showing that the <h2> for “Support links” is visually hidden.

The section about headings in the Accessibility Developer Guide covers this quite well.

Hint: You and I might not agree about using multiple

to improve accessibility, as gov.uk proofs that you can mostly follow the HTML specification without any accessibility concerns. I for one use the approach of one
and I would recommend this to follow best practice in all projects.

Nr. 4 — Fix your forms

There are more things that can go wrong with forms than I initially thought, before I dove into accessibility. This is not mentioned in Nr. 1 of this post as it’s not only about semantics. There are a few additional things that have to be done to make forms, especially the validations, accessible.

Check that every input, select or text area has a label: If it doesn’t have a <label>, what a form field is about is most likely invisible to screen reader users. You can either wrap the form field into the <label> tag, which is valid, but for more flexibility I recommend using the for attribute to make the connection to a form field via the ID.
Mark required fields with the required attribute : This makes it obvious to screen readers that the field is required.
Connect inline validation errors and other hints with aria-describedby : Assuming you show errors just below the form field that contains the mistake, the screen reader doesn’t read the error message when having focus on the field. For this, you need to connect the most likely <p> tag containing the error message with the form field by adding an aria-describedby to the form field linking to the ID of the error message. A detailed description can be found in the Accessibility Developer Guide.

There are a lot more improvements to forms you probably want to do, but they can also get more complex.

Nr. 5 — Fix keyboard focus visibility and order

This is easy to test. Open your website or application and navigate through it without using the mouse (Tabulator key, Shift+Tabular and arrows are your friends, but there are more).

Do you always see where you currently are? Can you focus all interactive elements? Does the order make sense to you?

Fixes you can apply:

Change source order of elements: Default keyboard focus relies on HTML source order. So there can be cases where you want to correct the order in your code and then visually change the order with CSS so it fits in your design. This is totally valid as long as the focus doesn’t make huge jumps from left to right or from top to bottom and back, which can be very confusing.
Change the default focus style to something more visible: Browsers implement the default focus style very differently. Some browsers show a blue outline when an element is focused. That’s okay on a white background but not on a blue background. Some browsers like Firefox only show a dashed/dotted line around focused elements which is barely visible. Never rely on the default focus style. Create your own. For the latest browsers, there is now even a modifier for keyboard-only focus, so you can make a difference between focusing via mouse click and keyboard.
Use native HTML elements over customization: For example, if you want to have custom styles for your radio buttons, use the <input type=“radio”> element and overwrite the styles e.g. by visually hiding the input and keeping the label in place with a “fake” styling for the input.

Custom focus style for form fields on gov.uk

Conclusion

Basic accessibility on a website or application isn’t that difficult to achieve. The more modern your UX and design becomes, the more effort is needed to make it accessible, for example when you go with SPA solutions like React, Vue.js or Angular.

These five fixes are only a few of many you can do, but you should be able to apply them in a couple of hours and already make a big difference.

If you’re interested in more in-depth knowledge about how to make your websites and applications accessible, I’ve got some links for you:

Accessibility Developer Guide A guide mostly for front-end developers on how to build and test websites for accessibility. Includes much practical knowledge from real world testings.
Inclusive Components A blog about building accessible components.
WCAG The de facto standard for web accessibility.
A List Apart, topic accessibility Many useful resources about accessibility.

If you have questions regarding accessibility, feel free to contact me at rey@nothing.ch.

Design Systems: Maintaining design with Pattern Libraries

René Stalder — Thu, 18 Oct 2018 06:50:15 +0000

The web is an incredible platform for building software: You can access a ton of information from nearly everywhere and it gives developers a big range to build nearly everything — from simple static websites to 3D games. You might be surprised, but one of the most challenging parts of maintaining software is keeping design and code synchronised with each other. In this post, I want to highlight how we use pattern libraries to maintain a smooth workflow between design and code while developing medium to large web applications.

The term “Design System” is more trending than ever. Since Google’s Material Design and several other big companies sharing their design system to the public, the debate around how design is maintained opened up all over the internet. If you never heard of the term, here’s a good article that explains what a design system is. In short:

Design systems is a design guide that benefits software, communications, people, and businesses.

One important part of design systems are so-called pattern libraries. While a design system defines a whole design in terms of animation and motion design, content principles, accessibility and information architecture — including the pattern library — the pattern library alone defines the components of a design system and how they are connected.

In this way, pattern libraries help to isolate individual elements of a design while providing a platform to keep an overview of all parts. This is crucial in keeping a design consistent over time. For instance: In a web application, a pattern library is a set of HTML elements with corresponding styles and functionality — one of them might be a confirmation dialog that closes when pressing the “Continue” button.

The dialog component in the Material Style guide.

Four reasons to use pattern libraries

Let’s look at four reasons why pattern libraries are an important of design systems and will help you with your project.

1. Consistency

Pattern libraries might not be worth the investment for small, individual websites. But for web applications that will grow over time and have to be maintained during several years, a pattern library helps to keep the design consistent. Moreover, it provides the needed overview over what parts of the design are available in code form and prevent developers repeating themselves and losing time and focus.

2. Handling dependencies

A pattern library helps the developer think about the isolation of individual parts of a website. In this way, unneeded dependencies can be prevented. One of the most common mistakes in styling web applications is that new features start to borrow code of other features. In a later stage of extending or changing the web application this often leads to problems by unintentionally changing or breaking parts of the application.

3. Build once, apply everywhere

A common rule for a pattern library is to keep it tech-agnostic. This means that no matter what framework or tool you’re using to build the web application, the pattern library is kept in a raw format whenever possible — e.g. HTML, CSS and JavaScript.

A raw pattern library can easily be applied to whatever tech stack is used to build the final web application. For example, if you decide to switch the tech stack at a later stage to improve performance or maintainability, you’ll need less time to apply the design to the new stack because you don’t have to rewrite all the parts for the new stack. Additionally, making the pattern library tech agnostic helps developers which aren’t directly working on front-end. They can easily apply the design to other systems without needing to dig into all parts of the front-end code.

4. Provide designers a platform to test

Pattern libraries provide an easy way for designers to test whether the coded design is aligned with their concept or not. The reason is that it delivers a simple platform that isolates and displays the finished components — either individually or in combination with other elements and components. Last but not least it can also be used as a solution for automatic testing of individual components outside of the final web application.

The biggest mistake that happens within design systems and pattern libraries probably is that they aren’t maintained.

Looking at a concrete example

At Nothing Interactive, we’ve built several pattern libraries over the last couple of years. One of the biggest so far was used for the user interface we designed and developed for Klett und Balmer Verlag. Klett und Balmer Verlag is one of the biggest educational publishing companies operating in Switzerland. They provide books for schools and individuals. Together with H2G Internetagentur , who were responsible for the back-ends, we redesigned the existing experience and are currently working on implementing the new design. Let’s see how we made use of a pattern librar y.

First of all, their web services are split up into three individual platforms. All together, they comprise klett.ch:

Web shop : Provides all the products to buy.
User section : User settings and options.
Web site : Information and articles.

All those sections might use different technologies in the background. Additionally, they connect to different data sources and are managed by different people. But they have one thing in common: They all belong to the Klett und Balmer Verlag and therefore share many aspects of the design. Designing and developing the new user interface without actually providing any back-end logic created several implicit requirements:

Provide the front-end in a form which the back-end developers can easily apply to their stack.
Maintain a single code source for the user interface.
Allow easy integration into the back-end system when changes are made to the UI.

The last requirement is an especially tricky one when you want to use a tech-agnostic approach. Let’s see how we managed it.

The tools: Zeplin + Pattern Lab

In a first step the designers prepared their design to be provided via Zeplin, an online service that allows to synchronise the design source files with a little helper tool installed on the computer. The screens and components the designer created — for instance in Sketch — are then visible online and allow the developer to interact with them; e.g. by copying out CSS styles or see measurements of specific elements.

The transformation to code is then done by the developers. They build the components and specific patterns in HTML, CSS and JavaScript by using a pattern library tool. There are plenty of options to create pattern libraries. However, many of them restrict the developers to specific rules: for instance a given folder structure or a templating engine that has to be used.

Years ago we decided to use Pattern Lab, a tool which helps with the creation of pattern libraries for the web. Pattern Lab is brought to life by Brian Muenzenmeyer, Evan Lovely, Brad Frost, and a team of amazing developers from around the world. It’s one of the longest existing solutions. So you can trust that it’s very well tested for productive use.

Another good thing about Pattern Lab is: It gives us a lot of freedom on how we want to structure and build our pattern libraries. Different templating engines like Mustache and Twig are provided and it will allow Handelbars in the future.

At the same time, the back-end team of H2G Internetagentur decided to work with Symfony. Luckily, some of the dependencies, most importantly the CMS of the website, are working well with Twig. This made the decision easy to use the Twig edition of Pattern Lab and try to build components that can — in the best case — be directly used in the Symfony environment.

From static design to dynamic code: We use Sketch for creating the design and Zeplin as bridge between designers and developers.

It’s true that this combination doesn’t fully realise the ideal of a tech-agnostic build of the pattern library. But it very much improves the already mentioned third requirement of the specific project for Klett und Balmer Verlag. Most importantly, it solves problems which occur during updates and requires the back-end developers to make changes on the markup. This again allows us to fix issues directly and apply that code to the test environment without further code interaction of the back-end developers.

Build the pattern library: From the smallest to the biggest piece

While the creators of Pattern Lab often refer to atomic design, we decided to use a similar, but slightly different approach. We separated our code into the following sections:

Components : A single component like a button or a form field. It can also combine be combined with other components like a dialog containing buttons.
Patterns : These are specific use cases where multiple components are combined e.g. a login form, header navigation or the footer.
Templates/Layouts : Once we combine different patterns like the navigation, the site header and the site footer we get a template. In our case, we used different templates for the shop and the website.
Theme : Applying brand specific definitions like colours and fonts. In this layer, we mostly overwrite variables that are used in components and patterns. Without this layer, the components and patterns still work, but have a generic look.

See the different sections in action.

Last but not least we have a so-called utility section in our pattern library. This mostly contains examples for shared JavaScript interactions like expanding and collapsing an element. It also contains CSS classes for accessibility.

Once we’re set up like this, we’re able to build our components — disregarding some additional compiling tasks like TypeScript and PostCSS. I won’t go into too much detail here. Basically, we’re able to build our components by adding a Twig template file, a CSS file, a markdown file for documentation and a JSON file for example data. This delivers a nice and easy to use HTML documentation that can be shared with designers and other developers.

Delivering the pattern library to partners and customers

Pattern Lab generates an HTML output which can be used to explore and test components. The good part is that it generates raw HTML. Thus, the whole documentation can be zipped and sent to other parties without any need of setting up a server to use it. In our case, we still host the built version of the pattern library on a test environment while delivering the documentation in a ZIP with every release at the same time.

This was also an important part within this particular project. Remember, we decided early on to use Twig. This would help the back-end developers to directly use the components. Luckily, this worked out very well in the end. What we then delivered to the back-end developers was:

The raw Twig files from our source code
Processed and minified CSS and JavaScript
The Pattern Lab build documentation as a ZIP file

Be aware that in all other cases where we use Pattern Lab, we build the components with Mustache and only deliver the documentation and processed assets. That’s because we usually assume that the developer applies markup and CSS classes as given in the documentation. Hence, this project is an exception.

Pattern Lab: A living documentation.

Maintenance: Pattern library first

The biggest mistake that happens within design systems and pattern libraries probably is that they aren’t maintained. This also happened to some of our own pattern libraries. However, this is quite common in the wild.

In fact, the pattern library brings another bridge into the game. Before, you had to bridge the gap between design and code. Once you use a pattern library you have to connect the design, the pattern library and the final code base that applies the design via the pattern library. This also applies to the most well-known design systems like Material Design. If Google changes the rules and you want to follow them strictly, you have to apply the changes from the design system manually.

For instance, Airbnb ensured the health of their code by making the developed design system the single source of truth. The starting point for any change in the design is the code base. They developed tools that allow you to import the code into the design software and make the maintenance of design files redundant.

Unfortunately, we’re not at that point yet at Nothing. The best we can do is to make sure that there are no UI changes applied to the final software which aren’t included in the pattern library. This is difficult, especially when everything has to go fast and a bug has to be resolved. But it’s a requirement for a long lasting consistent design.

A pattern library can grow fast and get big: We prefix actual documentation output with example-* to enable more flexibility on how and what we output in the documentation.

Conclusion

Is it worth investing into a roundtrip for building a pattern library? If you strive to keep your design consistent and maintainable for a longer time, definitively. A pattern library gives you the tools to keep an overview of your design. And it keeps everything in a sustainable place, no matter what technical evolution your final application goes through in the future. It separates UI and logic further from each other. This produces the positive side effect that you hand developers who are more capable of doing styling an isolated environment to play — without having to dig into frameworks and other technologies.

If you want to see our work in action, you can check out our current boilerplate that we use to kickstart our projects on GitHub.

Forem: Nothing

5 code improvements you can apply today to make your website more accessible

Before we begin: Fundamental mindset about HTML and CSS

Nr. 1 — Fix general code semantics

Nr. 2 — Fix your title structure

Nr. 3 — Add hidden titles to the structure to mark site sections for screen readers

Nr. 4 — Fix your forms

Nr. 5 — Fix keyboard focus visibility and order

Conclusion

Design Systems: Maintaining design with Pattern Libraries

Four reasons to use pattern libraries

Looking at a concrete example

The tools: Zeplin + Pattern Lab

Build the pattern library: From the smallest to the biggest piece

Delivering the pattern library to partners and customers

Maintenance: Pattern library first

Conclusion

Further reading