This morning I attended ICONS, an event to kickstart the new term of Communication and Multimedia Design, which is a course given in Amsterdam. The event was for students, but they invited others to tag along. So I did. Three speakers shared their views on what I can only paraphrase as: to do something that matters.

Marrije Schaake (eend) explained how not to lose your job in digital to robots. Robots will find it most challenging to take over jobs that require creativity, humanity and leadership. So, a good way to keep your job is to focus on making digital products more human. One needs human skills for that. One needs empathy: the skill to put yourself in someone else’s shoes. So that you can solve their problem. The good thing, Marrije told us, is that we can train our empathy skills: you can interview people to find out about their problems and study them in their natural habitat (like the practice of ethology). Find out what it is they want to do, what impediments they have and what they would not want to happen. This way, it gets easier to find real solutions to solve real problems. Problems that matter.

Johan Huijkman (Q42) talked about digital accessibility. He showed lots of examples of actual users that benefit from accessibility optimisations. And he explained that those users are everywhere and that they could be you (now or at an older age). He demonstrated how important it is to do the basics (according to Derek Featherstone, 80% of accessibility issues can be resolved by keyboard testing and proper markup), to work together, to test with real users and to keep things straightforward and usable (to avoid cognitive overload). By designing inclusively, we can make our digital products matter for people.

The multi-award-winning Astrid Poot (Familie van Fonk) taught us how to be successful, and showed the students that the common cliches about being successful as a digital creative person make no sense at all. You don’t need to be a man, overly rational, extremely confident, focused, disruptive or good looking to be extremely successful. Being professional is about other things, do something that matters. Why launch a new brand of tonic water if you can help children visit art museums or prepare for going to the hospital?

This idea of making stuff that matters is something I have been thinking about for a while. So many good designers and developers work on products that solve problems of big corporations, not of society. I don’t have much against big corporations, we probably need them, but using technology to improve people’s lives seems like the best way to spend our time. Whether that’s for a government or some big corporation, or with a trendy design or fancy framework, those questions are secondary, I think.

What a cool event, and what a great way for CMD students to start their year! I hope they were as inspired as I was, and employ the critical intuitions during their term.

---

Originally posted as ICONS: work on stuff that matters on Hidde's blog.

Reply via email

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