Last week, for roughly one hour each day, I participated in the Accessibility Design Drive, organised by Stanford University and Mozilla to make Firefox more inclusive by collaborating in diverse teams. It was a fun thing to be part of, and great to learn from others!

The people who joined this were a very varied bunch, over 100 in total. There were lots of people from the States and India, but also a number from Europe and elsewhere. Some had impairments, some were accessibility practitioners and some were both. A lot of students joined, too!

They grouped us into teams by time zone, and during the week, some of us were moved around to other teams, so that we could meet and work with more different people. We were working in a decentralised design process, with as its goal the inclusion of more perspectives in the design process.

Time-wise it was challenging. Many of us, myself included, had to squeeze the time into our after work hours, and the one hour wasn’t always enough.

What did we do?

Identify roadblocks

On the first day, we got some links for reading and got to know our fellow team members. The first team exercise was to figure out what kind of roadblocks each of us (or people close to use) experienced when accessing the web.

I read How people with disabilities use the web for inspiration.

Find patterns

The day after, our team had become slightly bigger by this point, we were asked to identify patterns from our observations from the day before.

Think of solutions

The third day, I was moved to another team by now, was all about thinking what we could do about the problems we had identified. And mainly, how could something in Firefox help solve the problems. So the question, really, would be: ‘what can a browser to improve accessibility?’

I found it difficult to come up with many solutions and decided to ask some friends, as well as Twitter:

If you could add a feature to a browser to improve accessibility to the web for people, what would it be? #a11y

(Me, on Twitter)

Lots of great responses came in, a couple I liked in particular:

• auto fix color accessibility issues (Bob)
• allow for styling of form elements like radio buttons, checkboxes and selects (Karl and Anneke)
• make it easy and obvious for users to change the appearance of a site to personal preferences (Alistair)

Prototype

On the fourth day, we were asked to choose three ideas and turn them into a storyboard, which, I learned, is an unpolished visual representation of how an interface idea could work in the real world. We started by describing the approach in steps, as a sequence of actions.

Test

The fifth and last day was all about testing. We were asked to communicate our thoughts to someone from their target audience, ask them about their thoughts, learn from this and then refine. In our team, this was the day we failed to do the main thing and did not test with users because we were time constrained. We did work on fine tuning the descriptions of our most important ideas.

Problems that browsers could solve

I’m a lazy front-end developer and happy with anything I don’t need to build myself. I’ll gladly leave things to the browser. Browsers are much better than I could ever be at interoperability, ensuring keyboard access and providing information to platform accessibility APIs. Over the past week, I realised there are even more things the browsers could improve for users regarding accessibility.

One thing I noticed in the discussions we had in our team, is that some accessibility issues follow from poor decision making by people who make websites. Browsers could theoretically resolve many of those. Examples: too little color contrast (browser could autocorrect), removal of focus outlines (browser could let the user override) and too much motion (the latter has been resolved with a media query for reduced motion).

Problems people have with forms could be solved by browsers, too. What if they provided native methods to style form elements like select and radio/checkbox inputs? Developers currently resort to non-native ways, which are not necessarily the most accessible, hence making forms harder to use for some users.

The above suggestions may be nothing more than public daydreaming, but I think it’s awesome that browser makers like Mozilla are so serious about accessibility. I am looking forward to seeing some feature ideas from this Accessibility Design Sprint make it into Firefox.

---

Originally posted as Accessibility Design Drive on Hidde's blog.

Reply via email

Last Friday, De Volkskrant exposed how much trouble the Dutch tax office has had in recent years to build software and manage its IT projects. Below I’ve listed the four main things they lack according to the article.

The responsible State Secretary, Eric Wiebes, admitted publicly that IT is “the tax office’s Achilles’ heel”. The report goes into the tax office’s 600 plus (!) IT systems and the estimated 750 million euros of tax that isn’t collected due to outdated technology. That is just sad!

They based some of the story on internal review documents, and interviewed a contractor, who gave details of a number of things many developers will recognise as serious red flags.

So, what did they lack, what should they have done differently? I thought I’d summarise some findings on this blog. Note that these might come across as common sense if you work for a fairly modern digital company.

The article in De Volkskrant, 18 August 2017

Take small steps

Some managers at the Tax Office preferred a rather traditional way of working: to build a fully featured product at once. All or nothing.

The alternative to this approach is to build a simple, minimum viable product first and then extend that with relatively small features when and if they are needed. It is the de facto standard for software development and what all modern, successful companies do in some way or another.

There is a difference in the two approaches from a management point of view: the modern approach requires active involvement, decision making and taking responsibility. When new stuff is added feature by feature, someone, whether it be a project manager or product owner, needs to know what the features are and take bold decisions about priorities. It also takes honesty and putting yourself in a vulnerable position: you’re sharing your work more often and give people the chance to comment. For the greater good!

Distribute responsibilities

The article also gives details of how management repeatedly made uninformed decisions. Tax Office managers ‘made decisions about IT without any technical insight’, which lead to non-vulnerable systems being replaced unnecessarily, and critically vulnerable systems being left without a replacement. ‘Often, the directors didn’t know for which part of the new technology they were responsible’, an external auditor said. Another issue is that no one seemed to know what systems were for and how they were supposed to save money.

In big IT projects, I think it is not inherently bad if management is not aware of all the technicalities involved. This stuff can easily get complex. It’s not uncommon in technical meetings that a majority of the room does not understand what is being discussed (sadly, this really happens). Because of that, people can say nothing and make it sound like something. Given all that, management, if not technically inclined themselves, should have themselves informed by other people who understand the full, technical picture.

Test early, test often

Software wasn’t regularly tested with reality (as in: the IT reality wasn’t checked with the real world reality). There was hardly any contact between the developers and the case workers that were the intended audience for the software. Nobody kept an eye on whether the systems being built did what they thought they would do.

As an organisation that produces software, if you don’t regularly test your stuff for bugs, with users, for accessibility, for security or with reality… you are just being overly confident — delusional, perhaps. Pride goes before destruction, and haughtiness before a fall. Software needs to be tested, and this needs to be done as early and often as possible. This is to verify that stuff does what it should do, and also that stuff still does what it used to do.

Work together

Another thing the article goes into is that the more traditional members of the team were less prone to come into work, they worked from home most days, some came in only once every fortnight, for meetings. From an employee point of view, this might sound like a fantastic benefits package. But to be fair, if it leads to bad software that you are partly responsible for, I’m not so sure I would go for it.

Communication (with team members, with management, with clients) is arguably the most important skill in modern software development. This is not impossible when working from home, with the right A/V and good internet speed you can do your dailies from a distance. However, especially in large and complex organisations, it is essential to be on site regularly, to make it easy to verify assumptions.

Conclusion

The above principles are extremely common in almost all modern and mature digital organisations. Companies like Amazon, Google and my bank seem to effortlessly produce interfaces that are easy to use, have few bugs and are able to disrupt people’s lives in a way that is often so positive. I think aspects like taking small steps, distributing responsibilities, testing early and working together help these companies to have success.

The Dutch Tax Office has a long way to go, but I am really hoping it will manage to shift into this direction, too. In the meantime, I try to be vigilant of the above symptoms when they occur at the projects I work on. I am also curious to hear if you have worked in any organisations that had problems like these, and if so, how you tried to solve them.

---

Originally posted as Small steps on Hidde's blog.

Reply via email

Yesterday I attended the Inclusive Design and Accessibility meetup (“idea11y”) in Rotterdam. The central theme of the evening, I think, was that accessible technology has the unique ability to enable people.

Last night’s meetup marked the first anniversary of idea11y (congrats!), it has been running regularly since the first one. Recently, I have been attending regularly, too. These meetups are always full of interesting content from different perspectives.

First, UX designer Dean Birkett (of AssistiveWare) talked about undertaking usability testing for the products his company makes: products that enable people with impairments. He specifically explained products that enable people to communicate. The users of these products are people who can not or no longer talk, some literate, some illiterate. He showed examples of people using their tools for anything from editing movies in Final Cut Pro to simply saying ‘I love you’ to their loves ones. He talked about the challenges of usability testing: he did a lot of that remote, and sometimes they involved the user’s support network. Main takeaways: don’t let people tell you that you can’t do usability tests, there are always ways; and do tests your products with users, as it is their problems you’re trying to solve.

The second speaker was Bob Offereins (of Microsoft), who talked about what he calls “Inclusive Life Design”: it is all about looking at people around us in terms of impedements rather than impairments. They’re really two labels for one thing: an impairment mostly sounds like an impossibility, ‘impedement’ makes one think of something that can be overcome, it’s a much more positive label. Bob shared his story: at a younger age he was diagnosed with an eye disease, which meant at the time he was labelled by the authorities and people around him. He explained how important it is to believe in the power of people, and encouraged us to believe in our own power, be unafraid of making mistakes and open to new ideas. Which in his case meant: don’t believe in boundaries or labels put onto you by others, think in possibilities! Very inspiring.

Dean showed how his company’s technology enables people, Bob explained how we can enable ourselves (and others) by being open minded and believing in what we can do. Some great food for thought!

---

Originally posted as Enabling people with accessible technology and positive thinking on Hidde's blog.

Reply via email

When assessing how accessible your website or app is, auditors will likely want to look at whole pages. But perhaps most of what you are working on is individual components. I mean, this is how lots of companies work nowadays. Can pattern libraries be tested for accessibility? And if so, what do we test? In this post I will address those questions and look at accessibility testing in different levels of pattern library driven development.

Note that this post is mostly about whether it can be done, as opposed to how, which is a subject all of itself. I may do a post about that later.

A pattern is a reusable piece of your user interface, also known as component or module. It often documents the UI design and is made of code that runs in the browser. Examples of patterns: buttons, messages, accordions, headers, sliders, breadcrumbs and tooltips. A pattern library is a collection of such patterns and slightly more than that. As Alla Kholmotova says in her upcoming book Design systems, it is “a tool to capture, collect and share design patterns and guidelines for their usage.”

With our interface separated into building blocks, it would be great if we can do our accessibility testing pattern by pattern, too. Can we? Well, yes and no.

Let’s start with the bad news. To be able to say something about how accessible your whole site is, you need to assess whole pages, WCAG2 says:

2. Full pages: Conformance (and conformance level) is for full Web page(s) only, and cannot be achieved if part of a Web page is excluded.

But there’s good news, too: there are heaps of accessibility issues that can be spotted on a pattern level, or criteria that can be marked as sufficiently met. Let’s look at how that would work.

What auditors test your site for

When deciding whether something is easy to access for as many people as possible, auditors will make sure four things are the case. They’ll want your site to be:

• Perceivable
• Operable
• Understandable
• Robust

In WCAG2, the accessibility guidelines, there is a number of criteria categorised under each of these main principles. Knowing those criteria is a great way to learn about making more accessible interfaces. There are quite a few. The actual spec is a good place to read about them and it is also the official norm. There is also the WebAIM checklist, which has slightly more developer-friendly wording and (opinionated) recommendations on how to meet the criteria — it’s a great resource!

Although you cannot formally claim your site’s WCAG2 conformance based on audits of just its components, as we’ve seen above, you can look at many of the criteria on a component level. This can have advantages in comparison with testing whole pages.

Patterns as isolated test cases

At the Patterns Day conference last month, Rachel Andrew mentioned something interesting about patterns. She said that working with reusable interface components, where each one has its own page, made her realise that those work quite well as isolated test cases. I feel this also goes for some accessibility tests: there is a number of criteria where isolation aids testing.

Component-specific guidance is available

Not only can isolating patterns be useful in the testing phase, there is also lots of documentation for accessibility-proofing components specifically. WAI ARIA Authoring Practices describes of common patterns how to get them accessible, with examples of keyboard operability and what should happen to focus. There is also Heydon Pickering’s Inclusive Components Club, which describes in detail what optimisations can be made and how they help whom.

Individual patterns

Let’s look at some things that can be tested when looking just at individual patterns. In order to avoid this to become too high level, I will give some suggested questions for specific, real-world-ish use cases.

Collapsible (“Show/hide”)

• Is it visually clear where the focus is? (Focus visible)
• Is information about the state of the collapsible exposed to the accessibility tree?
• Is there enough colour contrast between background and foreground? (Contrast minimum)
• Can the collapsible be expanded using a keyboard only? (All functionality operable through keyboard interface)

Form field

• Does the field have a label? (Provide descriptive labels)
• Is the label properly associated with the input?
• Does the icon that appears next to the input when there’s an error have a text alternative? (Provide text alternatives for non-text content)
• Are error messages conveyed to assistive technology (Identify and describe errors)?

Video player

• Is it easy and clear how to stop the video?
• Is there a way to display transcripts and include captions? (Provide alternatives to time-based media)
• Can the video player controls be used with just a keyboard? (Make all functionality available from a keyboard)

Assuming your final page only has pattern libary markup, CSS and JS, all of the above things will yield the same test result in isolation and when used in a page. This is what makes them suitable to test on a component level.

I think for most components, there’s a whole lot of accessibility criteria that can be tested. There is also a number of things where we need whole pages, and in some cases, whole pages with the real data. So let’s look at those next.

Whole pages

Some criteria can only be tested in the context of a full page. Some examples:

Headings

• Are no heading levels skipped?

IDs

• Do skip links refer to existing IDs? (Have a mechanism to bypass blocks of content that are repeated on multiple pages
• Are there no duplicate IDs in the page?

Tab order

• Can we tab through the page and does tabbing make sense?

Whole pages with real data

Lastly, there are also some aspects that can only be tested when pages are composed and they have real content in them. For instance:

Language

• Is the language comprehensible?
• Is it identified which language the page is in? (and, if different: parts of the page) (Make sure human language is programatically identifyable)

Video player

• Are all the people in the video identified in the transcript?
• Do the captions appear at the correct times?

Alternative content

• Can I find out what’s happening in that graph without seeing it?
• Does the alt attribute of that image describe what’s in the image (if it is not decorative)?

TL;DR

Although claiming a site meets the WCAG2 criteria has to be based on research of full pages, there are lots of things you can figure out and tackle while working on components with mock data. Above, I have given some examples of such things. I’ve also shown some examples of criteria that would require full and/or finished pages to be properly assessed.

As always, your mileage may vary! I would recommend checking the components you have against the WCAG2 criteria to see which ones can be checked on component level and which require full pages. Hopefully, the examples give an idea of what kind of things can be tested on which level, and when to run (automatic) accessibility tooling through patterns or full pages.

---

Originally posted as Testing the accessibility of pattern libraries on Hidde's blog.

Reply via email

Ever since the Grid Layout spec review workshop in Amsterdam last year, I’ve been wanting to try this stuff out on a real project, in a real browser. Now that the spec is rapidly gaining browser support, I thought this blog would be a good place to practice with it. I’ve jotted down some of my findings and thoughts.

So, it is really happening! Earlier this year, most major browsers shipped Grid Layout into their browsers in one month. It was awesome, never has a major new CSS feature been adopted this fast across browsers.

Before, we recreated grids with tables, floats and flexible boxes. For some developers, frameworks were helpful when trying to do that on scale. With grid, those things are no longer needed. Grid is great, because, contrary to older grid systems that use CSS to come to layouts, CSS Grid Layout is the lay-out system.

So why would you not use it? A fallback lay-out will either cost lots of time and limit your creativity, or look different from your grid-based lay-out, the most important question to ask here is: can you live with the “websites do not need to look exactly the same in every browser” philosophy? This philosophy has become more and more popular. It was always a wise strategy, but the multi-device world kind of forced us into it. Which is good, I think. There are already lots of viewports and lots of different ways to access the same structured content. For this website, it was an easy choice to make, because it’s only my own website. For client websites, it’s a developers role to look at which compromises are worth making.

Good places to learn more about Grid Layout are the spec and the examples, blog posts, tweets and presentations by Jen Simmons’ and Rachel Andrew, they have both done way more interesting stuff wit Grid Layout than you can find in this post (I mean, Monopoly, Mondriaan and more). Rachel has a full workshop on CSS Grid Layout.

The Grid on this site as viewed through Firefox’ Dev Tools

My implementation

These are some things I found interesting when I worked on this website’s Grid Layout implementation:

A lot less markup

Markup-wise, I have mostly been removing things. I had containers in place for layout reasons, most of those are gone now. The reason: when you define a grid on an element X, the things you can lay out on the grid are the direct children of X. If those are container elements, you’re placing containers onto the grid. This can be useful if you want to group things (make divisions, if you like), but often you want to lay the content itself out against your grid lines. In that case, best remove containers, or use display: contents, which lets elements behave as if the container that wraps them does not exist (little browser support at the time of writing).

Numbered and named grid lines

With Grid Layout, you can name your ‘tracks’ (areas formed of multiple rows/columns), but also the lines that surround them. I did not name all my lines, but I did name the ones surrounding my main content area. Named lines are very helpful: they make the grid-*-start/grid-*-end declarations much easier to read.

The body as the grid

I declared my grid on the body element, because I figured that I wanted to align everything that is in the body onto the grid. On more complex websites, I think grids could work well for just one component/composition, for example an overview of products.

Grouping starts/ends

Not all grid locations are unique. In fact, I found that I ended up aligning a lot of the items to similar places, so I grouped them by location. Many appear in my ‘main content’ column, others are elsewhere. For locations other than main, I used the line numbers to declare where the content should go.

.page-title,
.page-meta,
.entry-content,
.bio {
 grid-column-start: main-content-start;
 grid-column-end: main-content-end;
}

.comments, 
.about {
 grid-column-start: 2;
 grid-column-end: main-content-end;
}

Above I set the title, meta info, entry content and bio to appear in my main-content column (lines on either side are identified with -start and -end, respectively). Then I set the comments section to start after the first column (so on the second grid line) and to end where the main-content column ends.

Larger grid gaps on larger screens

For larger screens, I’ve decided to increase the grid-gap, so that my content can make more use of the available space. I found too much increase made things look weird, so I have only gone from 1em (on small screens, where I don’t use grids) to 2em and then to 4em. In layouts that are more exciting than this one, I can imagine changing these values can have more dramatic effects.

A low-fi fallback

My fallback is a very simple and plain lay-out, focused on having readable content. Anyone who comes to the fallback should have no problem to read posts, find out about me or my background or get to my contact details. But they will not always see the optimal lay-out for their screen (in my case, this goes for users with a screen width larger than 50em). The percentage of people seeing the lay-out as intended will grow over time.

Width of main content based on characters

My main content area uses the ch unit for sizing: depending on your viewport you will see about 50, 60 or even 70 characters on a line. Typographer Robert Bringhurst recommends 45 to 75 characters in his classic Elements of typographic style, and suggests increasing leading (line-height) with line length. This is trivial in CSS if you use unitless line-heights: they grow with the font-size.

Still quite specific

Grid allows you to not be specific and let the browser decide stuff for you. For instance, you can leave the sizes of the grid as well as placement onto the grid to the browser. The Grid Layout spec opens with an example of a game board that makes use of all available space, using just fractions and auto values.

There are other functions too, like the minmax() that lets you declare minimum and maximum sizes, leaving everything else for the browser to figure out.

In the grid on this site, I have still been quite specific about sizes, as one of my main components is a blog entry, and I wanted to base its width on an amount of characters per line.

Where to define how content flows

As you can see above, I’ve grouped things together that are unrelated, for the sole reason that their position on the grid is the same. It still feels a bit odd to be doing this, but it works well for me and for this blog.

I’m not sure how it would work on Big Websites where components can appear anywhere. Some could probably decide on fixed templates where the template name (this could be a classname on the body) determines the page’s positioning of items (.page--dashboard, .page-product, page--insurance-detail).

Other sites will require more flexibility. Maybe on those, you could determine the grid-column-start/grid-column-end values somewhere in the CMS, which would then generate an inline style (or maybe CSS-in-JS could help (?)).

Websites do not need to look exactly the same across breakpoints

With Grid Layout, not only can your website look quite different depending on Grid support, you can also choose to have completely different layouts across breakpoints. This way, you can really make sure your content has the right widths so that it is easy to read and navigate. And you can make those choices differently depending on the screen size that is available.

Previously, layout was quite intertwined with the structure of HTML documents and the classnames within them. With Grid, structure is still important, probably more important, but in a different way. Content still flows in the order of your HTML document, but you no longer need to depend on HTML to do things like laying two items out next to each other.

Conclusion

I’ve had fun experimenting with Grid Layout on this website and look forward to making use of its features in other projects. Stuff like min-content and named grid areas look incredibly useful. I also look forward to letting more stuff be automatically handled by the grid algorithms that browsers now ship with. And to use all the alignment stuff that came to CSS with flexbox and is available in Grid too. Oh, the possibilities!

I hope to see many more websites adopting grid layouts (ones that look more interesting than this one) and documenting their findings. As Jen Simmons said: this truly is a revolution in graphic design on the web. Lots to explore!

Further reading:

• CSS Grid 1.0, the official spec by Tab Atkins, Elika J. Etemad and others
• Grid by Example by Rachel Andrew
• Learn CSS Grids by Jen Simmons
• Getting to know CSS Grid Layout by Chris Wright
• Playing with CSS grids by Marco Barbosa

---

Originally posted as This website now uses Grid Layout on Hidde's blog.

Reply via email