Hidde's blog

Styleguides for better front-ends

2013-11-18T00:00:00Z

I just read Anna Debenham’s pocket guide to front-end styleguides. With only 69 pages, it is a concise guide to what (front-end) style guides are and how to use them.

It explains what style guides are (used) for, goes into different kinds of style guides used specifically on the web, describes what elements a web style guide can consist of, considers some of the main benefits of style guides on the web, gives some examples of good web style guides and finally looks into what the future for style guides might be.

Anna describes many different types of style guides for the web, such as style tiles, pattern portfolio’s and pattern primers. The main idea with all of those is that they come into being before page lay-out. They describe visual styles of page components, from which full pages can be construed later on in the design process.

The cover of Anna’s Pocket Guide

Style guides for better front-ends

Style guides can be very helpful for those pursuing to build better front-ends (and who isn’t?).

You don’t know which HTML the CMS or future versions of the CMS will spit out, and even if you do, the designer might not have styled them. If you include all generally used HTML in your style guide, you can make sure all of those are properly styled and tested across different platforms and devices.
Creating a front-end style guide will help find inconsistencies between components’ designs, and therefore help avoid inconsistencies in the underlying CSS.
Making a front-end style guide helps thinking even more component-like, which according to some is good. Components are not tied to a specific space in a page layout. That is helpful as much of today’s web design is for multiple screens.
The style guide can be used to show all involved in the project what kinds of content (can) exist in their website.

I have used simple style guide and pattern primers in projects before, and plan to do even more so after reading Anna’s short book.

Originally posted as Styleguides for better front-ends on Hidde's blog.

[email protected]?subject=Reply%20to:%20Styleguides for better front-ends">Reply via email

World Usability Day in Bristol

2013-11-19T00:00:00Z

Last week, the World Usability Day Bristol was hosted in MShed, a building that is home to Bristol’s city museum with the same name.

The view from MShed

World Usability Day 2013 happened in lots of cities all over the world. This local edition was organised by Nomensa, a digital agency based in Bristol. The conference featured speakers discussing a variety of subjects, including interaction design, accessibility, dark patterns and the possible future of the web. It was well organised: the venue had a great view of Bristol, lunch, scones and tea were all taken care of and all of tickets were very affordable.

My focus here will be on three talks that I particularly liked, about practical abstraction, the BBC’s super accessible olympics website, creating cross channel user experiences.

Dan Klyn: practical abstraction

In his talk, Dan Klyn focused on architecture, rather than design or usability. He tried to connect ancient Roman architecture principles to modern information architecture principles.

In Roman architecture the triad of firmitatis, utilitatis and venustatis were considered the main principles of architecture. Roughly translated, they correspond to strength (or firmness), commodity (or utility) and beauty, respectively.

In Roman architecture the triad of firmitatis, utilitatis and venustatis were considered the main principles of architecture.

Different architects in history can be said to adhere to different equations of those three principles. Buildings that were designed by the American architect Frank Lloyd Wright often had leaking roofs, they lacked firmitatis, but they were both useful and beautiful. A software example: Apple’s first release of Apple Maps for iOS tended to show people plainly wrong directions, but its use could easily be seen and it looked beautiful.

There are also examples of two properties giving rise to a third. The architect Johnson was famous for designing buildings that were strong and beautiful buildings, and therefore functional. One could say their utility derived from those former two properties. The German architect Gropius, the founder of Bauhaus, designed buildings that were strong as well as useful, and therefore beautiful. One could say its beauty derived from those former two properties. An example of this from software design is Craiglist: its beauty is in the combination of its strength and utility. Rather than having one property derive from the combination of the others, one could also ‘add’ one of the properties to a combination of the others. Gumtree is an example of this: it is strong and useful, and a visual design layer has been added to that, as a third property.

Other principles from architecture that we might want to apply to web design: order, arrangement, proportion, symmetry, appropriateness and budget-friendliness.

Alistair Duggin: the BBC’s accessible olympics website

Accessibility was a high priority in building BBC’s website for the London 2012 olympics. Front-end developer Alistair Duggin shared some of his experiences working on this huge website.

The BBC aimed to deliver content about the Olympics to as many channels as possible, such as tv, radio and internet. On the internet, the BBC aims for a high degree of accessibility. “The BBC is paid for by everyone and therefore must be accessible to everyone, otherwise the BBC is not the BBC.”, said Michael Grade, Director General BBC 2004-6.

The BBC is paid for by everyone and therefore must be accessible to everyone, otherwise the BBC is not the BBC.

The website was built around a sports ontology: athletes connected to countries and events, events connected to a ventue and sport. All of these ontology items had their own pages, so there were pages for all of the 10000 athletes, 205 countries, 36 sports, 304 medal winning events and 30 venues, and they were all interconnected.

Making something accessible is not as easy as it sounds. An extra complication was that all the templates had to be right when the site was put in use, which was when the Olympics started. During the Olympics itself, there was a code freeze (except for very urgent bug fixes).

The website was a great succes: it was viewed by 37 million UK browsers (57 globally). Many have viewed it on mobile (9.2 million mobile browsers, 12 million requests for video from mobile devices, 34% of all daily browsing by mobile).

These things helped making the BBC’s London 2012 site more accessible:

usage of a front-end style guide, to keep code consistent (more consistency is better for users)
front-end was built component-based; a component could generally drop in most parts of most pages
progressive enhancement was used: pages were built in ‘layers’, so that the basic content was accessible to anyone
content was added in logical order, alt text added to images that needed it, tables had captions, abbreviations had their full text in the code
in the HTML the team used: the HTML5 doctype, lang-attribute, skip-links, a unique <title> and <h1> and WAI-ARIA landmark roles, hierarchical heading structure, no duplicate links, alt text if they would not duplicate, links that were sensible outside their context, correctly coded forms and tables
in CSS, the team was careful not to implement barriers with CSS; display:none was only used when strictly needed, focus-styles were defined, outline:0 and !important were avoided, colour contrast was checked and the lay-outs were checked without JS and images
*in JavaScript, the team used feature detection, generated only valid HTML, updated state labels such as ‘open’ and ‘close’ appropriately, made all content accessible via keyboard and took care not to add keyboard traps
WAI-ARIA was used as an enhancement for those users with devices that support it, for example to keep users informed, manage focus, implement keyboard controls and provide hidden instructions

Andrea Resmini: cross channel experiences

Andrea Resmini talked about how websites have gotten more deeply integrated in our world, and cross channel services.

The difference between multi channel services and cross channel services is that the former serves A, serves B and serves C, whilst the latter includes A, B and C.

Computing used to be bound to a very specific time and place, e.g. a computer would not follow you. Today, cyberspace is very deeply integrated into the world around us. It has become much like a layer.

In a city we are said to ‘know’, we have a mental map of that city. In the first few days in a new city, we are able to create such a mental map. Now with digital products, this is not much different. A digital product like Facebook is much like a city that we have a mental map of. Their app on our phone is part of this, and so are the friends we know to be online in its chat service.

The architecture of information spaces comes down to the information architecture of places.

We ‘know’ a place, because we know specific characteristics of it. Those characteristics make up our memory of the place. If we want to create a cross channel experience that is easy to navigate, we should concentrate on creating characteristics. The architecture of information spaces comes down to the information architecture of places.

Recommended reading: Manovich, The language of new media

Originally posted as World Usability Day in Bristol on Hidde's blog.

[email protected]?subject=Reply%20to:%20World Usability Day in Bristol">Reply via email

Mark Boulton's grid system design workshop

2013-11-27T00:00:00Z

On November 27th, I attended Mark Boulton’s workshop about designing grid systems. It took place in Cardiff, UK, on the day before Handheld conference.

In the first half of the workshop, Mark taught us the basics of grid design theory. In the second half, we were put to work and made our own grid-based design.

Mark emphasised that the design of (the grid of) a website should be a system. He said humans are pattern-recognisable machines, that humans recognise order. Grid systems can help create such order. Hence the workshop name: it was about grid systems.

First of, Mark went through some history of grid design and type design in general. Grids have existed long before the web. Very long ago, the decorative type in books had already some kind of system, but things really started with the Swiss graphic design in the 1960s.

Odd columns can create tension and balance.

Grid systems, Mark said, are most obvious in long form editorials, such as newspapers or magazines. In those places they make the content easier to read. In a lot of print work, odd columns prevail. Print designers do this to create tension and balance. It can ‘unsettle the eye’. In web design, even columns are often used.

One grid does not fit all, in contrary. If a grid doesn’t work for your content then you need to change the grid, that’s ok. Creating a good grid takes a lot playing around with the content you have available. This is why Mark feels grid frameworks that you have just downloaded from the web (like Bootstrap or the older 960 grid solutins) often don’t work.

Types of grids

Mark explained different types of grids: columnar, hierarchical, modular, baseline and compound grids.

columnar grids can be subdivided into regular and irregular grids. UX designers use the term ‘swim lanes’ for groups of grid columns that form one big column. There can be different ratios in between the columns
modular grids are hard to do on the web as height in browsers and devices is difficult to work with (and perhaps not desirable)
baseline grids are most often used to prevent ghosting (the effect that happens in books if the text on the page behind the page you’re reading does not have the same baseline). On the web, there is no ghosting, and using a baseline grid can start to dictate undesirable line-heights. See Mark’s “Incremental Leading“ about this.

Avoid too many columns, it makes the grid less powerful.

The main point of grids is that it can make different pages that use it feel like ‘one system’. The more columns a grid has, the less power it has to come across as one system. Mark recommended to avoid too many columns.

Terminology

Mark also explained some of the basic terminoloy in grid design. A grid designer needs to know what margins, gutters, modules (or ‘units’), columns, hanging lines, offsetting and fields are.

On hanging lines

Good typesetting, Mark mentioned, is like good conversations, or if you like, a good talk. A good talk makes use of pauses, inflections, etc. Something like a pause in a talk is very fragile, it is hard to say when it is ‘just right’. Hanging lines can make typography better like pauses can make talks better, Mark argued.

On gutters

If your gutter is small, you can add a line to it. Newspapers sometimes do this. On the web, if you put a 1px line in your gutter, it can be useful to have a gutter with an odd width (so that the line plus surrounding whitespace are an even number). Sometimes gutters are defined by the padding within the module. Mark mentioned that this approach can require more mark-up, I have not yet done the comparison myself.

On DNA of grids

For years, web designers and web developers have come up with solutions to create grids on the web, a famous one being 960. According to Mark, grid systems like 960 are too limiting. Also, they have their own “DNA”. If many sites use the grid system, all of those sites end up having the same DNA. That threatens original web design.

Designing a grid system

In a lot of graphic design, the design is tied to the page size, Mark called this ‘knowable space’. On the web, there are no book-like pages and thus no page size, no dimensions that you can be sure of. Yes, grid systems for the web are hard.

We should design content out, not canvas in.

For that reason, Mark argues we should design content out, not canvas in. See also his “A Richer Canvas” article from 2011. This means you use your content to derive a canvas from, rather than start with a canvas and lay-out your content on it.

During the workshop, Mark explained three steps to designing content out:

Find the knowable, fixed content sizes
If there aren’t any, make some up
Use them to design your grid

Grids are a system, as Mark said in the beginning. He mentioned three ways to ensure this basic principle:

Relate everything back to the module
Use repeated ratios
Bind the content to the grid

Putting it into practice

The second part of the workshop day, we were put to work. We were given the choice between four projects, or could work on our own side project. The goal was to create a grid system. Mark gave us individual feedback and reviewed some of the projects in front of the class. This was of great help to those who had worked on them, but not much less for the rest of the group.

Mark Boulton’s workshop was very useful, and had a perfect mix of theory and practice.

Originally posted as Mark Boulton's grid system design workshop on Hidde's blog.

[email protected]?subject=Reply%20to:%20Mark Boulton's grid system design workshop">Reply via email

Handheld 2013: the web's structure, expectations and data poetry

2013-11-28T00:00:00Z

In this post I’m going to go through some highlights of Handheld 2013, which started of with the Welsh anthem being played on an electric guitar.

The conference

Generally, I much enjoyed Handheld. If I’m right, it was meant for people who make things for handheld devices. This year, it seemed, the speakers were mostly talking about the web. Which is good, and important. I can imagine some people missed talks about app development, but I didn’t.

A common theme of this year’s Handheld was communication with clients. These days, to make sure our sites work on a big range of devices, most web designers have started using responsive web design (RWD) in some way or another. With RWD, the uncertainty of what a web design is going to look like has become more apparent than ever. It was always the case that websites could not look the same in every browser, but now that we attempt to optimise for more than just a few desktop browsers, we have to come up with ways to explain this to our clients. This is a lot about building trust, confidence and that sort of thing, in addition to crafting great designs.

Having just recovered from co-organising my own conference , I may have had a biased view here, but there were some things I did not like about the practical side of things, including the waiting at registration and the somewhat too visible sponsor involvement.

Some talks I loved

The long web

Jeremy Keith talked about the web, a medium which he clearly loves (and who doesn’t?) He loves it for reasons such as its backwards compatible design, allowing for websites to be built in layers of structure, style and functionality. He also loves it for its URL system, providing a great and multi-purpose way for developers to make content available.

The biggest change in working on the web recently must have been the ‘mobile first’ paradigm, or ’content first’. According to Jeremy, you could work URL first, so that you start thinking about how to address the content before you even think about navigation. A clever way he mentioned to create a website from content is to break it into bits of content, components. Creating a library of components can help a lot. Jeremy created Pattern Primer as a handy way to show patterns and their HTML. And there is of course Anna Debenham’s book on style guides.

Content first also works through in code. You could put the content as (one of) the first thing(s) in your code, and the navigation at the very end.

Jeremy pleaded for progressive enhancement and rightly so. It almost ‘follows’ from working starting with (structured) content first. Progressive enhancement is often thought of being there for users that ‘have their JavaScript turned of‘. Although it does probably help those people, progressive enhancement has more to it. It helps anticipating those things that you did not expect, like a bug in one of your JavaScript files. It is about dealing with technology failing, rather than it not being supported.

Do not outsource your [website’s] performance to a third party.

A great example Jeremy mentioned is that of the social sharing button thingies that many sites use these days. The social media sites often offer those as a <script>-element that they ask you to drop in the middle of a page. Now if you imagine a Twitter widget in the middle of a page: if a user in China opens that page, it may stop loading when it gets to the Twitter widget, because Twitter is blocked in China so its script is never found. Your website’s speed is its most important UX feature, Jeremy warned, “do not outsource your performance to a third party.”

How to call your client an idiot without being fired

Andy Clarke’s talk was about how to communicate about design with clients.

We should avoid setting the wrong expectations

Old-fashioned ways of wireframing and design comps is that they might cause us to set the wrong expectations. When a client is shown a wireframe that already has some basic lay-out, as wireframes often do, they might expect the visual design to look like that lay-out. If the client is shown static design comps, they may assume that the final website will look exactly like them on any browser or device ever used.

What we design, Andy says, is not how we design, but how we communicate our designs. It does not matter which tool you like to create designs, as long as you make sure you set the right expectations.

According to Andy, the waterfall method is one of the main causes to problems related to expectations. To be able to set expectations right, we should start working in agile teams. That way, designers, developers and clients work together. In the process, everyone involved will know what is being worked on, and big surprises at the end are avoided. Working together, team members will feel more accountable.

To improve the way we design websites, we could improve the way we ask for our client’s feedback. If they work alongside designers and developers, we already avoided ‘the big reveal’. There are some other ways to improve the feedback process. At Andy’s company, they try to make it easier to control the feedback conversation, by insisting on face-to-face feedback, not allowing feedback by phone or email. They also try to control the environment in which the design is presented, by making sure everyone who can decide about it is in the meeting. They also find it important to leave their personality at the door: it is about the integrity of the design, not about that of the person who made it or gives feedback about it.

Data poetry

Brendan Dawes had a great talk about data. Now data can have two appearances, Brendan showed. There is the ‘raw’ format of just plain csv of JSON files in a text editor. They look boring and do not invite people to interact with them. They don’t look sexy. But when using data as an input for graphic design, it can come to life. Data represented in a graphical way can show give us new insights. It can help us see connections that we would not have noticed in the csv, although technically they were in there.

Data needs poetry

In his talk, Brendan showed heaps of examples of cool things he had done with data, including many new ways of representing data that was already there. These examples really nderlined his point that data ultimately comes to life when it is put in a graphical form. “Data needs poetry,” Brendan concluded.

And more…

And there were other talks I did not mention.

Syd Lawrence opened up with an entertaining live show, which involved people texting details to a phone number that were later used for playing ‘Guess who?’.

Ling Valentine argued that for information-rich web sites like her own it makes sense to stay away from responsive web design and use a simple, yet annoying mobile page to get people to your desktop site asap.

The prophet of web standards Jeffrey Zeldman gave his ‘ten commandments of web design’, often using his own A List Apart as an example. He loves the web as much as Jeremy does.

Mark Boulton explained how as a designer of RWD projects, you have to worry about content as it is such an integral part of what the design is made of. He illustrated this with stories about some projects he did, like Al Jazeera, CERN, UCL and World Skills London.

Jon Hicks talked about the pros and cons of icon fonts and showed how to make one. He also briefly discussed some alternatives to using icon fonts, like SVG sprites.

Eddie Machado made the Handheld site and explained how. I found he brought a lot of tools in that, imho, he could have done without (eg Sass for icon fonts), and ‘dirty’ tricks like </code>-elements inside a <div> instead of a <video> so that he could conditionally load them in a video.

There were not only talks at Handheld. There was also Bruce singing web standard classics such as ‘Like a rounded corner’ and a new (?) song callde ‘Living standard’, and Aral who announced the next phase of his Project Prometheus, now known as Indie.

Handheld conference was a great and varied day. There will be no Handheld next year, but the organisers have plans for another event. I’m going to keep an eye on this.

Originally posted as Handheld 2013: the web's structure, expectations and data poetry on Hidde's blog.

[email protected]?subject=Reply%20to:%20Handheld 2013: the web's structure, expectations and data poetry">Reply via email

Unobtrusive icons

2014-01-07T00:00:00Z

In this article, I describe a way to add icons to descriptive links, and one that makes icons by themselves more accessible.

Icons are often employed to provide a visual description of an action. In some recent projects, I have treated such descriptive icons as merely enhancements of descriptive text. Because surely, text that describes some action is a basic yet functional substitute for an icon that describes that same action.

Icons preceding descriptive links

For example: an RSS link. In its most basic form, it would be:

<a href="http://site.com/feed" class="icon icon-rss">RSS</a>

The link with just the word ‘RSS’ is sufficient, it does the job of pointing the user to the RSS feed. Or the finely tuned searchbot, a browser plug-in that looks for RSS feeds or even a screenreader.

In its enhanced form, it would have a super sharp, retina proof vector icon in front of it.

Now, as we already made sure everyone is pointed to the RSS feed in a basic way, we have already included almost everyone, we can apply the enhancement to only the browsers that understand it.

The icon would be a character from an icon font. Let’s add the character with a pseudo element in CSS:

.icon-rss:before {
 content: 'foo'; /* character in your icon font, preferably 
one from Unicode's private use areas */
}

Icons with descriptive fallbacks

Sometimes, a web interface uses an icon by itself, without a label. In this case, it does not come with a useful descriptive text out-of-the-box. Adding it with generated content would exclude users whose browsers don’t understand :before or :after.

Support for generated content can be detected by Modernizr. Taking advantage of the class Modernizr adds, we could show or hide descriptive alternatives for generated content.

<span class="generatedcontent-alt">Enlarge text</span>

.generatedcontent .generatedcontent-alt {
  position: absolute; 
  overflow: hidden; 
  clip: rect(0 0 0 0); 
  height: 1px; 
  width: 1px; 
  margin: -1px; 
  padding: 0; 
  border: 0; 
}

This will “visually” hide the alternative in the case it is no longer needed, when generated content support has been detected by Modernizr.

Another example:

<a href="printversion.html" class="icon icon-print">
  <span class="generatedcontent-alt">Print</span>
</a>

The text ‘Print’ is no longer needed if the print icon is there. If generated content is not supported, the text provides an acceptable alternative.

Text as the most basic alternative

Icons have great advantages, and can help users finding their way around a website. But there will be cases in which the icons don’t work, for example if your web font fails, generated content is not supported or your user only processes text (e.g. Googlebot or a blind user).

With text, you can be sure you reach almost all web users. This makes it the ideal alternative, that is always good to have it in place, even if you (visually) hide it from most users.

Originally posted as Unobtrusive icons on Hidde's blog.

[email protected]?subject=Reply%20to:%20Unobtrusive icons">Reply via email

Meeting the TAG

2014-01-08T00:00:00Z

When Bruce Lawson tweeted about an opportunity to meet the TAG, I managed, at the last minute, to get a ticket and joined a room full of very smart people discussing some technical aspects of the web medium.

Although Bruce and Jeremy have already written a much better summary of this fascinating evening, I will share my thoughts nonetheless.

The TAG?

‘TAG’ is an abbreviation of ‘Technical Architecture Group’. They are a special working group within the W3C, overseeing which web standards are developed and thinking about the general direction of the web.

The meeting

The meeting took place in the form of a Q&A session at the Google Campus in London, followed by beers. The atmophere was good, the TAG members interesting and the audience interested.

Archeology

When I entered the room, sorry I was late, there was a discussion about which design principles the TAG has. The web and its possibilities have extended tremendously over the past years, and the main concern of the TAG is making sure that the capabilities of the web ‘platform’ are well documented. Many things a web browser needs to do are not formally described by a spec, but nonetheless, they need doing. Those who put web standards together have to do some sort of ‘archeology’ into what browsers do to find consensus.

DRM

Then, someone asked a question about a drm. An extension of HTML, agreed upon by the W3C, provides APIs ‘to control playback of protected content’. It has been called unethical and bad for the web. In response to the question, the TAG pointed out that they are merely responsible for technical architecture, not for policy. However, individual TAG members did respond. Anne van Kesteren said he personally thinks DRM does not work and is bad for the web. Tim Berners-Lee, after explaining DRM is already in a lot of things that almost all of us use, pointed out the DRM issue is not simple and goes much beyond just technical problems. Many little procedures that make the web work and resulted in its popularity have a social aspect as well as a technical aspect. Someone in the audience noted that the technical DRM discussion ought to be preceded by another, about how, as a society, we want to value content creators. Because surely, we all want to read great books and watch interesting films, and no one would deny the makers of these things to do it for free. I agreed, this discussion has implications beyond tech.

Web Components

In the HTML5 spec, a number of new elements were introduced. Commonly used classnames, like header, footer and section had gotten there own element. When those new HTML5 elements were introduced, they appeared to have been carefully chosen, to make sure the standard remained simple yet effective. With Web Components, it will be possible for developers to use any element they like. Then, asked Jeremy Keith, with some irony, ‘what do we need standards bodies for?’ Now of course it is still good to standardise commonly used elements. Web Components are not meant to create your own <div>-like elements, although you can. They are meant to create the kind of elements that have extra features, like <input type="range">. For standard elements, the browser has APIs to ‘do’ those features. If you make them with a web component, you provide the API yourself, with JavaScript. Then, if some web components become very common, the W3C may decide standardise them, so that they can be used declaratively. In the future, commonly used Components and their JS APIs could be standardised and become part of browsers, just like commonly used classnames were standardised as elements. Now the web is being used more and more as a platform, some developers serve empty <body> elements with a lot of JS. With Web Components, they can serve <body> elements containing meaningful custom elements.

URLs

As the very last question, Andrew Betts brought up an issue that he had with the web product he works on. He felt it was not always possible to represent what was on the page with its URL. One concern he mentioned is that context is not always taken into account. In his organisation, some teams wanted to have different content in different contexts, and there is nothing in URLs that can help specify which context is currently used. The assumption of different web contexts have been argued to be wrong , but Andrew’s case was interesting and lead to the TAG’s final conclusion: ‘we all love URLs!’

Originally posted as Meeting the TAG on Hidde's blog.

[email protected]?subject=Reply%20to:%20Meeting the TAG">Reply via email

Embedded video in responsive lay-outs

2014-02-05T00:00:00Z

Many videos on the web are hosted at third parties and included through an <iframe>. This can be a problem for flexible width sites, as an <iframe> with 100% width will not automatically have a height that respects the aspect ratio of the embedded content.

Forcing an aspect ratio-respecting height

The embedded content will, it its simplest form, be like:

<iframe/>

The width of the video can be adjusted to the width of its container or viewport by setting a width: 100% to the <iframe>, Because the width is not set on the video element itself, as it can be with inline <img> or <video> elements, the browser doesn’t know what the height should be, as there can be any number of elements in your <iframe>.

Let’s wrap the <iframe> in its own container.

<div class="embed-holder">
  <iframe/>
</div>

The embed-holder will be positioned relatively, so that it flows with the page. Its max-width will be 100% and its overflow will be set to hidden. We add a padding-top to the container to reserve some space for the YouTube player.

Now comes the trick¹: the embed-holder will get a padding-bottom of 56.25%. Using a percentage for the padding forces a height that is relative to the width of the element. If we want the embed to stick to the aspect ratio of 16:9, we need to express that ratio as 100:x. We can calculate that by dividing 100 by 16, then multiplying the answer with 9.

Let’s for now assume videos in the ratio of 16:9. Using the following CSS, .embed-holder will have the correct aspect ratio in any container or viewport.

.embed-holder {
  max-width: 100%;
  overflow: hidden;
  padding-top: 30px;
  padding-bottom: 56.25%; /* ensuring 16:9 aspect ratio; 
use 75% for a 4:3 ratio */
}

<p>The last step is to fit the video into the container.</p>

```css
.embed-holder iframe {
  position: absolute;
  left: 0;
  top: 0;
  width: 100%;
  height: 100%;
}

The .embed-holder acts as the positioning context for the <iframe>. The width and height will be that of .embed-holder, so it will have the correct ratio.

Extra step for WordPress users

If you want to do this in WordPress, one extra step is required.

By default, WordPress creates embeds from any URLs to video services like YouTube and Vimeo. Rightfully, it does not add an extra wrapping element to your code, which is what we need in this particular situation.

To do this, simply add a filter² to the embedding function in your functions.php :

add_filter('embed_oembed_html', 'wrap_embedded_els', 99, 4);
function wrap_embedded_els($html, $url, $attr, $post_id) {
  return '<div class="embed-holder">' . $html . '</div>';
}

This wraps the WordPress-generated embeds into a container, to which the above CSS can be applied.

Please note: this wraps all embeds, including some you may not want to apply a different aspect ratio to, such as SoundCloud.

Notes

¹ This is not my own idea, it has been explained by others. Original idea by Thierry Koblentz on A List Apart (May 2009)

² Function via cubecolour , who also made a WordPress plugin to add both the CSS and the filter)

Originally posted as Embedded video in responsive lay-outs on Hidde's blog.

[email protected]?subject=Reply%20to:%20Embedded video in responsive lay-outs">Reply via email

State of the Browser 2014

2014-04-27T00:00:00Z

At State of the Browser in London, a one day event in Conway Hall, organised by the London Web Standards team, eight speakers talked about recent developments in the web and web browsers. Topics included Service Workers, performance, responsive images, web ‘apps’ and new CSS features for responsive web design.

These are my notes of the day.

Fernando Campo & Borja Salguero – Firefox OS: not only promises

In their talk, Fernando and Borja of Telefónica’s Firefox OS team discussed what they have been working on and what their priorities are in terms of new features.

They said the phone is slow, as they focused first on getting it launched and focus now on making it better. It also has few apps, missing features and is hard to debug, but the team is working hard on making it better, faster and stronger.

Recent improvements

What they’ve been doing in the last half year to improve Firefox OS:

There is an app manager which can be used from Firefox nightly. It helps to check the manifest file amongst other things. There is also a simulator, debugger (which works with either the simulator or a real device if you have one) and profiler (with which you can profile actions).
In addition to that, two new measuring tools were launched that can help Firefox OS devs to improve performance: Datazilla and Eideticker (with which you can analyse ‘real’ fps)
They have also introduced more APIs.

Ideas behind Firefox OS

Firefox OS is a project to push the web forward

Firefox OS, Borja explained, is really a project to push the web forward. To do this, Mozilla/Telefónica work together with a lot of partners. One improvement they want to achieve is the exchange of information between apps. Their solution for this is “Inter App Communication”, which helps apps ‘talk to each other’.

In the newest version, your phone will not be a thing you install apps on, it will be more like a browser. Because that is what Mozilla is good at, making browsers. The OS that doesn’t require you to install apps, completely changes the way we work with devices.

More is coming from the makers of Firefox OS, including FirefoxAccounts, your settings in the cloud, and project ‘Loop’ that employs WebRTC to let users call for free. There is also Project ‘Mulet’, which allows developers to do all things related to Firefox OS from the browser.

If we want to know more, Borja explained, there is a lot of documentation available on the Mozilla Developer Network, including screencasts.

At the end of the year new 25 USD devices will be introduced, with all the power of the web, aiming to open the web to people that could previously not afford devices with the same acces to the web.

Andreas Bovens – Intro to @viewport & other new Responsive Web Design CSS features

Andreas discussed some of the lesser known features for responsive web design that are in browsers already, but not used so much yet.

First, Andreas showed the various different browsers that Opera currently offers. There are Chromium-based browsers for Android, Opera Mini based on Presto and the experimental UX of Coast for iOS.

He then discussed four CSS features that are ideal in responsive design.

1. @viewports

The web started off fluid, there was hardly any way to do fixed layouts. Then table layouts came in and fixed CSS widths. Some years later, liquid layout made a comeback, using percentages, max-widths and min-widths. Then, along the lines of the fluid trend, came responsive web design, employing use of media queries and encouring thinking more about different devices. It is now an established way of working.

Karl Gernstner introduced the notion of ‘design programme‘, a set of rules for constructing a range of visual solutions. See also: Lupton, Thinking with type; Kerstner, Programme entwerfen.

Two technologies make RWD possible: media queries and the meta viewport tag. Media queries allow developers to apply CSS rules conditionally, the meta viewport tag allows setting the zoom level (most browsers ‘zoom out’ to display legacy, non-mobile-optimised ). With the meta viewport tag in a page, media queries work as intended.

The whole zooming out to the page width thing started in mobile Safari, and they added the meta viewport tag to allow developers to circumvent the zooming. Soon after, it got implemented in most other modern browsers.

Not a standard

A bad thing about the meta viewport tag: it was not a standard, so people started confusing syntax, e.g. adding semicolons instead of commas (eventually both ended up being supported). As there was no standard, edge cases are now handled different by each browser. Some features are not supported everywhere, e.g. user-scalable=no, so you’re never sure whether things will work or not. Android added target-densitydpi, which Opera also added. Internet Explorer implemented device-width as 320px as that was the original iPhone width. Safari zooms in 1.333% in landscape mode, which could be avoid by (their propriety) initial-scale:1 rule. Then Apple came up with minimal-ui properties. Anyway, end of rant, Opera decided to write a spec for viewport.

To standardise the things the viewport meta element did, Opera wrote @viewport as a CSS spec. Settings that you can set with the meta element can now be set in CSS. [Sidenote Yoav Weiss added to his talk: if you use @viewport in CSS, set it an inline <style> -element, as otherwise it will mess with things, including responsive images].

Example:

@viewport {
  width: auto;
}

In some senses @viewport is better than the original meta tag, and for sure it is better documented as it is a standard.

If you want to try it out now, you turn it on in Opera or Chrome flags and you can play with it. Currently, it would be advisable to use both as support for @viewport has hardly landed in browsers.

2. Resolution media queries

When devices with higher pixel densities came about, they started interpreting 1px in CSS as 2px on the device, for example iPhone 4 interpreted 1 CSS-pixel as 4 device-pixels. This makes fonts and vector graphics look very pretty, but can make bitmap graphics look blurry.

Resolution media queries can use ‘dots per px’ units (dppx).

Example:

@media (screen and min-resolution: 2dppx) {
  .thing {
    background-size: 50%; 
  }
}

@media (screen and min-resolution: 3dppx) {
  .thing {
    background-size: 33.33%; 
  }
}

<p>This technique is similar to <code>device-pixel-ratio</code> that works in some browsers, except this one is standardised. It is in some browsers, and not behind flags so can be used today (but it is not available everywhere yet). </p>

<h3>3. object-fit</h3>

<p>New <span class="caps">CSS</span> rules: </p>


```css
object-fit: fill;

object-fit: contain;

object-fit: cover; 
overflow: hidden;

These features are very useful to make small adjustments to images. They were already possible on background images, but not on inline images.

4. Viewport percentage widths/heights

Units: vw, vh, vmin, vmax

Think of your canvas as a 100 by 100 units, then vw and vh are those units, e.g. 50vw would be half of the width of your canvas.

Opera was heavily involved in all four, both at spec level and implementation level.

Ruth John – Browsers at play

Ruth builds interactive prototypes at 02. At State of the Browser, she showed some great things she built.

VJ’ing with CSS Animations and WebAudio API

When she was at uni, Ruth used to be a VJ. Recently, she thought, with all the cool things now possible in the web (CSS animations, WebAudio API), can I recreate the visuals of those days in the browser?

Ruth showed various demoes, including one that heavily used the Web Audio API (recommended reading: O’Reilly’s book on this subject). It allows you to control volume, create sound and analyse sound. The latter, Ruth used to create graphics that responded to changes in a music file.

With getUserMedia, microphone input can be analysed in JavaScript, using the Web Audio API. Ruth showed a cool demo in which graphics responded to her voice.

Demoes online: dancing.rumyra.com/shake-n-track dancing.rumyra.com/vibrate

Jake Archibald – Network connectivity: optional

The web is in a state where developers do dirty tricks to get you to go to download their native apps. “Why is that, why are mobile apps still preferred to the web versions?”, Jake asked.

Some reasons:

availability offline
server push
background synchronisation
geo fencing
payments
performance
‘app presence’

The web is really exciting, said Jake, as people are currently working on implementation of all of the above.

To improve performance, the 300ms double tap delay was removed from Chrome and Opera (soon to be removed in Firefox), for whenever a screen is small and the device-width meta tag is used.

To improve presence, so that the app can be in start menus, home screens, status bars, etc, the app manifest spec is being written at the moment, describing a way to have a json file with properties of apps, to make all the different <meta> elements that are currently used to do the same, obsolete.

Service workers

To improve offline availability, service workers are coming! There was, of course, AppCache. It tried to create shortcuts for a destination it didn’t know, it was hard to know what to expect from it and its API was too complicated.

We should treat online as a progressive enhancement to offline, and work ‘offline first’. That way, cached content is shown first, whilst making a request to the network for fresh content. When that network request fails, the cached content will still be there; if it succeeds, there will be fresh content.

Service Workers are reactive, not predictive, as AppCache was. It will try stuff and see what happens. The advantage of that is: if the thing it tried does not work, fallbacks can be added, making it very suitable for progressive enhancement.

What the web can do vs what apps can do

Native app developers can do everything, the web can sometimes feel like a massive can’t. Packaged apps are not the solution, they are interim, until the web has improved and become better. Native will always be better on their platform, the web will not win on that front. But it will win in being more accessible and much more widely available.

Martin Beeby – High-performance web platform

Martin Beeby, developer evangelist for Microsoft’s Internet Explorer, explained how to improve performance of websites, and what to keep in mind when building for Internet Explorer 11.

Things limiting speed on the web are bandwidth, latency and data plans.

Perceived performance is the most important to optimise. An important part of this is the use of memory. Inefficient use of memory can be a problem for performance, but also for the user’s hard drive life expectancy. Most of the memory websites take up is taken up by images.

Power consumption is something to think about as well, as it is about the user’s battery.

New website: status.modern.ie to give community more insight in what features the IE team considers supporting, as well as what’s already built in.

Microsoft built two tools to measure performance: the F12 dev tools, in IE10 and more even in IE11 this has improved a lot. There is also the Windows Performance Toolkit, which can be used to measure any app on Windows.

Performance improvements that can be made:

One of the most important performance optimisations are in images: often images for mobile do not have the right size and this can take a long time (not only downloading the images, but also image decoding).
Defer script execution: put scripts in the footer, or, if you put them in the top, add the async/defer attributes.
Reduce number of frameworks: not only because they would have to be downloaded, but also because they have to be garbage collected
To fix items don’t add timers or events, they fire at the wrong timing or too often (e.g. scroll), use requestAnimationFrame (fires whenever the browser is ready to paint the screen, and can therefore be a lot smoother than something that fires each time the user scrolls)
use CSS animations, not JS animations where possible
use JPG instead of PNG where possible, JPGs have a huge performance benefit
keep in mind: download size vs memory size. Memory size needed to store an image is often bigger than the image download size: width * height * 4, roughly. Copying an image from memory to gpu can relatively take quite a lot of time. In IE11, JPGs are hardware accelerated.
when you develop on mobile, use a ‘low end first’ approach.

Yoav Weiss – Brace yourselves – responsive images are coming

Responsive images is to ‘efficiently load propertly dimensionsed images that fit the pages design’. My main concern is with performance here, we cannot be developing websites for 550$ smartphones only.

vs srcset

<picture> was thought up by the responsive images working group, Hixie of WHATWG did not like it and added, without much public discussion, the srcset idea. Two years later, both will be implemented.

Tab Atkins came up with src-n, apparently over a bottle of wine. It was great for discussion, this time amongst browser vendors, which was good. Then, the original picture syntax was redefined, with a new proposal that can make everyone happy. Now the Responsive Images Community Group and WHATWG are working on it together.

Yoav is implementing it in Blink, Mozilla are also working on implementing it it. Should be there in a couple of months.

picture 2.0

Usecase 1: bigger images for high resolution devices / the ‘retina’ use case

<picture>
  <source media=”mq” srcset=”/path”>
  <img/>
</picture>

There can be multiple <source> elements, the srcset attribute can have more than one image.

In Chrome, the srcset attribute works on <img> elements today.

Use case 2: art direction, in case you need multiple images to be properly cropped for different layout)
Use case 3: mime type fallbacks (jpgr, webp, jpeg2000 are formats that only work in some browsers, they would need a fallback)

An image element is always required, otherwise the picture will not display.

The `sizes` attribute, variable widths

Use case 4: variable width images

‘Picture is a magical span, nothing more’ said Tab Atkins. You should not try to style it using CSS.

When looking up what ‘w’ means, look at the picture spec, as the ‘old’ syntax is quite different.

If you want to play with <picture> and srcset today, there is a polyfill available: Picturefill 2.0 was released by the Filament Group, it is officially spec compliant.

Dan Donald – What it means to be flexible

Dan Donald explored what it means to build websites in a flexible manner.

Responsive web design is a recipe for managing and constraining the fluidity of the web. It is a recipe in the sense that it leads to a lot of improvements to the web, like responsive images.

An example of flexibility: the nature of breakpoints. They are a tool to describe change. Are we designing for content or devices? One can use device-oriented breakpoints, but they make the assumption that we can rely on devices having the same widths. Another option is content oriented breakpoints.

When using device breakpoints, we get a conflict with the universality principle of the web. There’s little to no correlation between viewport width alone and devices.

We have a breakpoint purpose mash-up. We work in a world of assumption, but what do we really know? E.g., the user agent string we get on the service side, is full of lie.

An important concept within building flexible pages, is the ‘element media query’. It does not currently exist in a standardised form or in browser implementation, but that did not stop various developers from building their own JavaScript solutions. Dan showed us his.

Chris Heilmann – Open web apps

Chris talked about the open web, and about what Firefox OS can mean within the context of the open web.

Open Web Apps: manifest file that says what your app is/does. Apps are a better form factor for devices (then URLs).

What makes a good app? Why do people download a calculator app, rather than typing their calculation into an online tool like Google?

focused (it is full screen)
mobile (it works offline)
contained (you can delete the icon to delete the app, you can send it as one thing)
integrated (it works together with the OS and has hardware access)
it is responsive and fast

Can all of the things that make apps great be done in HTML?

A great app does one thing and do that one thing well. Simplicity is what makes app so popular.

Service workers is the most important thing at the moment, offline viewing is a very important thing that needs to be solved.

Go low in your testing, do not test on too fast connections, as the web is universal and it would be bad preventing people with low bandwidth connections from accessing your website.

Everyone with an FTP connection and text editor can work on Open Web Apps, not just rich kids in Sillicon Valley that can pay 99 dollars and buy the newest devices to test on. That’s not the web!

Q&A

Throughout the day, attendees could ask questions via Twitter and to the organisers. After the last talk, Daniel Appelquist confronted the speakers with some of the questions that were asked.

(Answers are based on my notes, and should not be considered to be literally what the panelists said).

Q: How will HTTP2 change any of the thinking about responsive web design thinking?

With HTTP2, combining all your JS into one file will become an anti pattern […] the same goes for sprited images

Jake: HTTP2 will turn a lot of good practices into bad practices, for example, starting a new request would be less of a deal. Combining all your JS into one file will become an anti pattern, lots of small files will work much better. The same goes for sprited images.

Yoav: Today, the browser has to download everything to get started, which today is good because it saves HTTP requests, but if that is no longer needed, it will be better to have many small files.

Andreas: I agree, best practices like sprites will have to be rethought. This will mostly be an education problem, we will have to ‘unevangelise’.

Chris: Most people use build processes nowadays, and an advantage of that problems like this can be solved by adjusting those tools. These things are already abstractions, so we only need to adjust the abstractions.

Q: How can we be a web industry that women don’t feel alieniated in?

Martin: All I can do is not be a dick, that is the only thing I can have control over.

Ruth: It is an issue. I have been lucky, as in most places where I worked, people weren’t dicks. I think it is mostly a social problem. I’ve had sexism and it isn’t nice, but there are worse problems in this world.

Chris: Sites like Codebabes are blatant trolling, they’re not much more than a clickbait. We are not going to solve social problems on the internet by clickbaits. We should not give them a lot of attention in tweets.

Ruth: listen to ‘the science of the sexes’ podcast, it is a great resource.

Q: Everyone keeps talking about “the web platform“, what is a platform and should we want the web to be a “platform”?

Chris: The web is an opportunity for people to publish on, it is a way to spread information in a world wide manner. It is a set of technologies.

Andreas: It is just a matter of naming. We have called it ‘web standards’, and later internally at Opera we called it ‘the web stack’. Some use the word ‘HTML5’, maybe ‘platform’ is a better term for it all. Whether it means something deeper than that, I’m not sure.

Q: How can we make the web platform a better platform for games?

Ruth: That’s a really good question, but very difficult to answer. We already have things that are amazing at games, like Xbox and Playstation. I think we need to build a lot more to show what is possible. The Audio API and Vibration API i talked about seem great for games.

Martin: we [at Microsoft] go to lots of game developers, at big companies, but also indie game developers. I don’t know much about game development, it is a very different world. Interesting is what is happening with WebGL, not just for games but for parallel computing in general, it it has implications for lots of things outside gaming as well. It is very complicated though, hard to learn.

Chris: It is a different world, like native vs web. Gaming is a speed test, if we can get games running on web technology, we can learn from it for other applications of the web.

Q: How will Web Components change the way we work on the web?

Chris: Web Components are an amazing opportunity, they allow us to write proper widgets on the web. Whatever HTML you were missing, you can now actually write and publish yourself. It allows for widgets that are running with the browser and not against it. They becomes part of the browser. Jake had a talk about a tabs component some years ago, that is one to watch again. [I think Chris meant Jake’s talk ‘Reusable code: for good and for awesome’ at Fronteers 2010. Video / transcript and slides

Jake: Web Components are an important part of the extensible web. For someone new to HTML, it was weird that

and looked different — CSS helped to explain why this is. Developer tools in modern browsers to this with things like performance waterfalls. Service Workers does a similar things to help understand the network. Web Components will help to show why things render the way they do. Libraries like jQuery UI that change a <div> into a widget will no longer be needed, you could just have a new element doing a widget.

Yoav: I’m slightly worried about performance of Web Components, for example in terms of blocking rendering. The browser has to download the import and files within that file and files within that file. We have to make sure it will not become the next @import of CSS.

Q: What is the future state of deep linking from web apps? And into web apps?

Barjo: Haida does that for Firefox OS, it will make the flow more natural for the user, linking will feel more natural like it is in the native OS already.

Jake: We can’t lose the URL.

Andreas: I agree. URLs are the power of the web and an advantage of the web over native apps. The web can link to apps, but URLs can also be used to link from an app to the web.

Conclusion

I’ve had a great day in London, and enjoyed this very affordable conference a lot. There was plenty to learn and it is exciting to know that a lot of the stuff presented today, will be in browsers in the not too distant future.

Thanks Krijn and Mathias for pointing me at spelling errors in previous drafts of this post.

Originally posted as State of the Browser 2014 on Hidde's blog.

[email protected]?subject=Reply%20to:%20State of the Browser 2014">Reply via email

Keeping it simple

2014-05-08T00:00:00Z

When trying to improve front-end skills, we should improve our knowledge of HTML, CSS and JavaScript first and our knowledge of specific tools later.

Most of the web is written in three simple yet powerful languages: HTML, CSS and JavaScript. Terminology in job ads and portfolios comprises a lot more: LESS, Sass, grunt, Foundation, Bootstrap, jQuery and the like. They are mentioned alongside the big three, but they really are quite different. The former are the foundation of the web, the latter are ‘just’ tools to do stuff with them. Tools that have their merits, surely. But the only thing that constrains how effective one can use front-end tooling, is how effective one can use HTML, CSS and JavaScript.

An example: CSS preprocessors, like Sass en LESS. They can be incredibly useful and powerful tools for writing CSS, but they require knowledge of how box models, positioning, inheritance and specificity work. Limited understanding of these things can makes things worse if applied through a preprocessor (for instance, unintended nesting). Preprocessors provide power, but it is a kind of power that should be used wisely.

Bower is another example: it can help manage dependencies, and makes it very easy to add new dependencies. This may sound like an advantage, but it makes it too easy to bloat a codebase and complicate a project too soon. Whilst it was easy to add a CSS library through Bower, it is now hard to manage <button> styles as the CSS library does overly specific styling that is hard to override.

Tools like preprocessors and package managers have their merits, but to become a better front-end developer, one should focus on HTML, CSS and JavaScript.

Originally posted as Keeping it simple on Hidde's blog.

[email protected]?subject=Reply%20to:%20Keeping it simple">Reply via email

Museums Get Mobile!

2014-05-17T00:00:00Z

“Museums Get Mobile!” was a one day event on designing mobile experiences, aimed at managers, curators and consultants in the cultural sector. It was organised by the UK Museums Computer Group in MShed, Bristol.

The day kicked off with a welcome from the organisers and a short talk from the sponsor, about the advantages of apps. This was followed by the first keynote: Clearleft’s Andy Budd.

Andy Budd – Responsive design is easy

Andy Budd started off by claiming that responsive design is actually quite easy, quickly adding ‘as long as you have been paying attention’.

He took us through the various stages of the history of web design, going for flexible to fixed to flexible and responsive. He showed the very first web page, that was just text, had no CSS and was therefore already responsive. It could be accessed from any kind if device. This is no accident, as the web was envisioned with universality as its underlying principle. Paraphrasing Tim Berners-Lee, it should be accessible from any kind of hardware that can connect to the internet. Along came designers, and they messed it up. Designers have been breaking responsiveness by placing content in fixed width containers.

Embrace the flexibility of the web

There have always been voices that we should embrace the flexibility of the web, most notably John Allsopp in his [classic] article A Dao of Web Design: “we should embrace the fact that the web doesnt have the same constraints [as print], and design for its flexibility”.

Just like people thought tableless CSS sites would never become the norm, some people still think responsive design never will. Andy emphasised responsive design definitely is the future, as it is the most sensible thing to do.

Andy briefly discussed apps versus websites, and was in favour of the web, arguing from statistics. The chance someone will visit your website is much higher than that someone will go through the whole process of finding, downloading and installing your app, especially if they rarely ever visit. Secondly, a problem with apps is that there are a lot of different ecosystems: iOS, Android, Windows Phone, Blackberry, and so on.

Responsive web design can be regarded as a logical next step in the history of web design. There were fluid sites, then fixed sites designed for fixed widths, then half fluid sites and now fully fluid and adaptive sites that are meant to work everywhere.

It started to be used in personal projects first, and quickly made its way into commercial sites, The Boston Globe being one of the first. A great example of a responsive museum website is that of the Rijksmuseum [see also the case study of the new Rijksmuseum website at Fronteers 2013.

Being such a logical next step, for front-end developers, responsive design is not so hard, especially if you have been paying attention to things like fluid design. If you haven’t, it may snuck on you. Learning responsive design from scratch is probably hard and scary, as there is a lot involved.

Organisations have to make their sites responsive. “Wait and see” is not a great strategy, your competitors will get ahead of you. “It’s hard” is not a valid argument. Yes, it will take extra time (and budget), in our [Clearleft’s] experience about 10% more. But if 50% of your visitors visit from mobile, which is likely to be the statistic in 2014, is spending 10% more to reach 50% more people really so bad? Why spend 100% of the money on 50% of the people that access your site? As a museum, you would not discriminate against sex or race, why discriminate mobile users?

Responsive design is not designing three versions for mobile, tablet and desktop respectively. It is a way to pour your content in as many as possible ‘glasses’ (Andy visualised content as water, and devices as glasses). Responsive design demands you understand your content.

Our job is not to dictate design, it is to hint design

In responsive design, never think of devices, think of breakpoints instead: optimise where the layout breaks, not where a specific device is used. You have no control over what devices a visitor uses to access your website, what browser they have, what font size they set. Our job is not to dictate design, it is to hint design.

In a responsive design process, developers and designers should work closely together and talk to each other.

Responsive retro-fitting, the process of making an existing website responsive, does not work well, as it fails to address content problems and does not have the benefits of starting with mobile first. Companies like the Guardian started with a responsive mobile site from scratch, built next to the existing site. It was initially only shown on mobile devices, whilst it was being optimised for bigger screens. It is planned to replace the existing site sometime this year.

Mobile first is a very useful conception to think of, as it can helps focusing attention. There is less space available, so it forces content, marketing and design people to prioritise.

Jeremy Keith would hate me for saying this, but I prefer tablet first, it is a nice midground. You start from a tablet version, them scale up a bit for larger screens and scale down a bit for smaller screens. We are currently taking this approach working with a client.

There are still a lot of issues to resolve with responsive design, an important one being how to deal with images. yay for <picture>

The question shouldn’t be, “when should I make my site responsive?”, it should be “when can I make my site responsive?”

Q: How do you deal with people within the organisation that are convinced they need an app?
A: Mobile apps are part of a healthy ecosystem, but responsive web design is a sensible and logical approach to take. Irregular visitors of your museum will not take the hassle of searching for and installing your app, fans of the museum may like app. You don’t need to talk your boss out of apps, but you should be doing responsive web design as a default.

Ask for forgiveness, not permission

Q: How to ask for budget to do responsive design?
A: Use statistics. Personally, I prefer to ask for forgiveness, not permission. In the project description, don’t make a big deal about it being responsive, maybe call it “has to work on a variety of devices”. That is just very sensible, no one can argue against that. And then when it launches and happens to work across lots of devices, everyone is happy.

Designing for changing museum audiences in-gallery and online

Ivan Teage

Ivan Teage of the Natural History Museum (NHM) explained how the NHM’s approach to mobile caters for the basic needs of visitors.

NHM offers WiFi, which is activated through a splash page that comes up when users try to connect. On this page, NHM can get the visitor’s attention. Analytics are used to see what people are doing and test different content.

NHM research shows 77% of visitors have a smart phone. Many have a tablet, but they don’t bring it to the museum. Before visiting, 1 in 3 visitors research their visit on their phone.

Nearly 10% of the visitors, uses the WiFi, making it a big hit, especially since no efforts were made to promote it. Most use it not to find information related to the museum, but for Facebook.

In 2014, on average, websites will have more mobile visits than desktop visits

As Andy said before, in 2014, on average websites will have more mobile visits than desktop visits. The website of the NHM currently hovers around 44%. There is also a notable difference between pages, some pages are much more popular on mobile, others on desktop.

One of the great challenges NHM faces is that there are a lot of different priorities within the organisation, some “nondigital”.

Frankly green + webb

The biggest aspect in mobile is the organisation. There is a lot of making things for mobile just for the sake of making things for mobile, those are the most challenging projects to work on.

Some regard mobile as a tool. Working on mobile, people tend to focus on choosing tools first, rather than on the actual project. Maybe because it is not very physical, mobile is often called “an experience”.

Let’s look at defining what we have to design before we choose the tool to design it with.

For a specialist (…) it can be heart-breaking to be asked to summarise something in three sentences

For a specialist, for example, a curator who studied 15 years on a subject, it can be heart-breaking to be asked to summarise something in three sentences, they would probably prefer more detail.

Digital services often exist of more than just a website. As they often involve with physical services as well, [like a physical box office in the case of a museum], there are lots and lots of people involved in any given project. It will be hard to get them on the same line, or in the same meeting room.

Two tools to deal with this complexity:

a digital services manifesto, a set of shared objective like the one GDS released, can be a great tool to push a project in an organisation
a visitor journey, an outline of every step a visitor can be involved in, to try to understand what the whole experience is like. There are a lot of examples of visitor maps on the internet, from companies like Lego and Starbucks.

Léonie Watson

Léonie Watson talked about accessibility (on the web).

Accessibility is not boring, we can creative visually exciting and creative experiences that are accessible. It is not difficult, it is no rocket science, but there may be unfamiliarity.

Accessibility is usability for all of us.

Everybody benefits from accessibility

Who benefits:

You do. You can make your content available to more people, you open it up to a larger audience, which makes a great feal of sense.
We do (us being people with disabilities, like sight, hearing, learning, cognitive).
Everybody does. The real minority in the world, are just regular people. People surfing the internet wearing glasses or with a hangover, or people who are tired, because their young kids kept them up all night.

There are accessibility guidelines that make sure we can find out what to do, and help to make things testible. BBC recently launched their Mobile Accessbiblity Guidelines.

There is accessibility testing. Some things can be automated, but putting your content in front of people with disabilities will likely be more effective.

There is also legislation. In some countries more than others. In the UK, there is the Equality Act. It does not have any requirements for accessibility, it only says “digital services have to be accessible”, it doesn’t specify to which standard.

Accessibility does generally cost a little bit more. If your people are good and used to accessible best practices, they can do optimisations at no extra cost. But if you want to do testing, which you probably should, it can cost more than other usability testing, for example transport costs.

Retrofitting accessibility is probably just as hard as retrofitting responsive design

It is best to ‘do’ accessibility throughout all stages of the projects. Keep an eye on it as the project goes. It works with waterfall and agile. Test as often as possible, fix as quickly as possible. It is easier and perhaps cheaper to fix things in early versions than it is in live sites. Retrofitting accessibility is probably just as hard as retrofitting responsive design, which Andy discussed. It will cost much more and probably achieves less.

Accessibility is forever, not just for launch. Keep an eye on accessibility after the project goes live, maybe monthly or yearly.

Andy Budd: Five to six years ago, developers were very involved with accessibility, do you think that is decreasing now?
Léonie: Yes, it does get lost in the buzz sometimes, but there are still a lot of efforts and generally the situation is quite good.

Making responsive design a reality: accessibility and content strategies and commissioning content strategies

Andrew Lewis – thinking holistically about mobile-responsive services

Andrew Lewis of the Victoria & Albert museum discussed how they think about responsive web design. A responsive web service is one that adjusts content to your audience.

V&A did a responsive retrofit in 2012.

Responsive design is not about technology, it really is about social behaviour.

Situations in which people use their phone:

preplanning a visit
visual diary
comfy sofa time

Mobile users and tablet users are often the same people. The V&A website optimises for different contexts, orientations and screen sizes.

Dan Goodwin – Collaborative discovery: commissioning a big web project when you’re not sure what you want

Dan Goodwin, UX Director at Bristol-and Cornwall based agency fffunction, talked about kicking off a big web project.

It is difficult to choose the right agency for the job. A traditional commissioning approach could include asking within your network, send out request for proposals, asking agencies to come up with quotes.

But an important thing to note is: in the process of building a website, requirements are going to change. That is a given. The problem with the traditional commissioning approach is that nobody really knows 100% what’s needed.

Working on the Bristol Museums websites, fffunction did a collaborative discovery phase, to make sure all the different requirements were analysed and looked into.

They did a stakeholder workshop, a get together with a selected number of shareholders, getting them to put post it notes on the wall, with things like target audience, principles, content ideas and potential features. It gave a great insight into the scope of the project and what needed addressing. They also did user interviews, which helped testing their assumptions.

During the Q&A, some pros and cons of working agile were discussed. Working with flexible requirements is one thing, agreeing to or getting permission for flexible pricing another.

Shelley Mannion – Learning from mobile experiences in museums

Shelley Mannion from the British Museum showed how (people) interacted with various kinds of devices and experiences within the British Museum.

Contrary to other speakers before, Shelley did have some good experience with apps. Some webbased, some native.

In statistics of the British Museum website, mobile has also grown a lot. It increases reasonably quickly, but not as fast as the first graph showed.

In her talk, Shelley challenged some common assumptions, like “It has to be the latest device”, this really depends on the device you are using. Another assumption she challenged: “the bigger the screen, the more people can stand around it” . They found the maximum seems to be about 3-4 people around a screen, regardless of how big the screen is.

Shelley showed a couple of very interesting examples of projects in which visitors interact with exhibitions. Imagery, videos and URLs will be in the slides, but they were unavailable at the time of writing.

Conclusion

Some important takeaways of the day were that mobile is here to stay, that it will be bigger than desktop in 2014, and it would be ideal to make things universally accessible, embrace the flexibility of the web and have a flexible workflow. It became clear that those things can be difficult and scary, but they will be beneficial in the long run. Some solutions were discussed: more research —into visitors/users as well as into the project scope—, better teams in which designers, developers and content people work well together and always keep challenging your assumptions.

Originally posted as Museums Get Mobile! on Hidde's blog.

[email protected]?subject=Reply%20to:%20Museums Get Mobile!">Reply via email

Responsive Day Out 2 - the squishening

2014-06-29T00:00:00Z

Last year I experienced Responsive Day Out through its audio podcast (RSS), this year I decided to buy a ticket and travel from Bristol to Brighton for the real thing. It was a varied day, with room for aspects like design, business, information architecture and even CSS specs.

The day was structured in three blocks of three speakers talking for 20 minutes, plus one block of Ethan Marcotte, who came up with the term ‘responsive web design’. The event’s social media hash tag, #beepcheeks, was named after him.

Part 1: Stephen Hay, Sally Jenkinson and Ida Aalen

In the first session, Stephen Hay introduced us to the method of ’sculpting text’, Sally Jenkinson discussed aspects of responsive web design beyond just designing for different screen widths and Ida Aalen shared her experience working on a large responsive project for the Norwegian cancer association.

Sculpting text

Stephen Hay explained that text is what underlies the web. Structured text, to be more precise. Structured text is portable, it can stay the same regardless of which device you use to access a web page. It exposes inappropriate and irrelevant content more easily than a full fledged web design comp would. Web designers have been designing containers to fill with text for ages, so that text would be the last step in their project work flows. But if text is the most portable, shouldn’t we really start with text first? Stephen argued we should.

Increase screen size, until you feel the layout breaks, at which point you add a breakpoint

The method of sculpting text, Stephen explained, consists in adding layers of CSS rules to structured text. It can start with styling text on a small width, a ‘single column grid’ if you will. Start simple. To structured text on a narrow screen you can do things like colour, typography, spacing, et cetera first. Then you increase screen size, until you feel the layout breaks, at which point you can add a breakpoint. You can then introduce things like columns. Sketching is helpful when trying to come up with solutions for larger screen widths.

Sculpting text first and coming up with a canvas later in the process, rather than designing a canvas to put content in afterwards, will help designers understand what they are designing. As a methodology, it helps us cope with the multi device world they design for, Stephen argued.

A more in-depth discussion of responsive design workflow, can be found in Stephen’s book with the same name, which I recommend reading, or have a look at his slides.

Responsive planning

Sally Jenkinson emphasised that responsive design is not only about designing for multiple screen widths, it is also about being very good at planning, not being afraid to experiment and making the right choices.

Our choices have great impact

The choices web designers and developers face, Sally argued, can have large philosophical and ethical impact. A developer often makes choices that impact what a user experiences. This can include ‘invisible requirements’, like progressive enhancement. The decision to make a website ask for a user’s location, may feel awkward or unnecessarily invade their privacy, especially if the app does not evidently require location.

Sometimes we should make choices or do things that aren’t part of our job descriptions. Planners can try out new technologies, rather than solving problems with solutions that we happen to be used to. Choices should not be about what is beneficial to us as designers, developers or businesses, they should be made with the bigger picture in mind. It is about end users ultimately, we should avoid ‘narcissistic web design’, Sally advocated. And we should avoid making choices that invade our users’ privacy.

The core model

Ida Aalen described the ‘core model’ for information architecture, and spelled out how it benefited her team when working on the website for the Norwegian Cancer Society (lang=no). (Slides)

In information architecture, which is a lot about users navigating, it is important to note users will often not (want to) navigate your site. They often just look at one page, coming in following a Google search or a link on Facebook.

Core pages serve both business and user needs

Ida talked about the overlap between business needs and user needs. Some pages only serve one of the two, some serve both. Those are core content pages. An example she discussed is a page about lung cancer: it serves business goals (informing people, sharing knowledge) as well as user needs (getting to know more about symptoms, prevention and treatments). From core content pages, one can think about pages that precede it, and those that can lead a user to elsewhere. The core content is the same on all pages, regardless of device used.

For the Cancer Society, a lot of time was spent on mobile. Ida shared some data on usage. Users visiting with small screens spent roughly the same amount of time on the site as those with large screens. Conversion rates did not differ much between screen sizes used, so it was worthwhile to spend time on designing for all screens.

Part 2: Rachel Andrew, Dan Donald and Inayaili de León Persson

In the second session, Rachel Andrew talked about the CSS Grid Layout Spec, Dan Donald considered the flexible web and Inayaili de León Persson shared her experience of making ubuntu.com responsive.

CSS Grid Layout

Rachel Andrew discussed the new CSS Grid Layout spec. Since it was originally proposed by Microsoft and used in IE10, it evolved a lot.

Rachel discussed different ways of defining grids in CSS, using Grid Layout. There is line based positioning, and the use of grid area names, also known as ‘defining grids in ascii art’. For components you specify in which areas they should be displayed. Then, on the wrapper they are in, you define where those areas are. To see how it works, have a look at her code examples or her blogpost about the subject.

She also explained how grid layout differs from flexbox: whereas the former is most suitable for full page layout, the latter works best for smaller UI components.

The flexible web and element queries

Dan Donald talked about building for a flexible web. In particular, he talked about flexible components using element queries.

Element queries are media queries that respond not on a document level, but on a component or element level.

Element queries are media queries that respond not on a document level, but on a component or element level. Currently, they exist mostly as a concept, i.e. there is no standard with browser support. Nevertheless, it is possible to use the concept in web pages today. Dan explained how he did so in a project for BBC, using data attributes to specify queries, a bit of JavaScript to make them more flexible and, of course, CSS to define what to do at breakpoints.

Realistic responsive design

Inayaili de Léon Persson showed us what she learned when working on the responsive version of Ubuntu.com. At the time, the team did not have the luxuries of starting from scratch, or working on it full time. The mark-up and content had to stay the same, and the team had to squeeze the project in between their other duties.

Inayaili explained that when making a site responsive, it is often not only about just that, there are many priorities, goals and needs. The team behind Ubuntu.com benefited from buying some of the most used devices, using Basecamp to document as much as they could and making clever use of stuff others had done, inside and outside the organisation.

An interesting step in the process that Inayaili described was the writing of ‘responsive rules’, like ‘Content that is divided in half or thirds should convert into single column when it becomes too narrow’. See also Setting the rules in the series Making Ubuntu responsive on the Ubuntu site.

Part 3: Oliver Reichenstein, Kirsty Burgoine and Stephanie Rieger

In the third session, Oliver Reichenstein proposed a better way of structuring websites, which his company recently employed for The Guardian, Kirsty Burgoine shared how her responsive web design process developed and Stephanie Rieger dived into new media queries.

The container model

Oliver Reichenstein explained that making information easy to find for users is hard. Most information architecture starts from the homepage down, with lots of diverging branches. These kind of trees can be very sturdy. Home pages and sidebars are often full of stuff, because of politics.

The alternative [to sturdy information architecture] is the container model

Oliver Reichenstein explains the container model (photo by Marc Thiele)

The alternative is the container model: have containers with specific content and decide where to put them. Containers are full width and horizontal, pages can have a series of containers stacked up.¹ Containers are self sufficient and can appear anywhere. On a news site, a container can be a world cup section, or a top news section. The article is a container, the comment section is a container. Container based design is without columns, but you can put content next to each other, if the content is comparable, for example a top sport section next to top politics.

The container model is to avoid pages where lots of unrelated bits of information are placed next to each other, just because there is a sidebar that can be filled with content. Responsive design or mobile first forces us to have priorities. We should stick to those priorities when working up to larger screens. If you work up from mobile to larger screen, you should still not put lots of random content to fill up space.

Oliver’s company Information Architects helped newspaper The Guardian implementing the container system on their new site, which is currently in beta. But the model is not only useful on news sites, it works for e-commerce and corporate sites, too, Oliver stressed.

¹ Blogpost about the container model at The Guardian

Responsive deliverables

Kirsty Burgoine shared various approaches her business tried when making responsive websites. She also discussed the importance of trust.

All approaches shared that the website was going to be responsive. The first approach was not telling the client, and surprising them with the fact that the website worked on mobile. It resulted in happy clients, but it had a steep learning curve and caused unbilled time. The second approach was to tell them about responsive design, but not to promise anything. The good thing was that her workflow could stay roughly the same. The downside, that it required a lot of trust from clients. The third approach was to dive straight into code, and do HTML early. It made Kirsty happy as a developer, but clients would have hardly any deliverables. The client would have to have trust, without seeing what was being done.

The fourth and final approach was a very practical one. It embraced the chaos that making responsive websites can be. There were lots of different deliverables, or in lieu of them, sharing of ideas. Regular meetings were held to make sure the client was still on board.

The future of CSS media queries

Stephanie Rieger went into some of the new media queries that are being discussed.

There are proposals and drafts for media queries based on user’s JavaScript support, light level, the kind or lack of pointer, ability to hover, screen’s update frequency and overflowing capabilities.

Stephanie also discussed additional media queries that she thought could be useful, including one to see what language a device can use (Chinese interfaces need less space for words then Western ones, as less characters are needed).

Another interesting thought Stephanie shared was that of a browser built-in navigation system, that would just expose the page’s nav items via a control that is best for the device. For example, a phone could have a built-in hamburger icon to open it, a Google Glass could have a speech command to request it.

Part 4: @beep

The last talk of the day was delivered by Ethan Marcotte, who gave the idea of designing flexible web pages its thoughtful name. His talk, which I was lucky enough to see him do at CSS Day earlier this month, was about being lazy. Or, as I would rephrase it: keeping things simple. According to Ethan, being lazy is the only response to the increasingly complex web we work on, with its multitude of devices, connection speeds and interaction models.

He showed some ideas for being lazy about lay-out: the padding trick and nth-child for infinite grids with relatively simple CSS. He also discussed frameworks. On the web they are often too descriptive, too ‘heavy’. In a broader sense, there are examples of great ‘frameworks’: Disney’s 12 principles of animation (video), the Whitney museum with its logo that can have infinite variants, all based on one simple rule, and Karl Gernsters idea of set of solutions rather than just solutions.

Ethans talk made a lot of sense to me. The multitude of devices, connection speeds and interaction models is a fact. There are roughly two ways of dealing with this fact: designing a solution for each of them, or designing a few simple rules that automatically deal with all of them. The latter works for Disney or the Whitney museum, and it is sensible to say it will work best for us, working on responsive web design.

Round-up

Throughout the talks it became clear that responsive web design is now just web design. The great variety in devices people view the web with has influenced web design a lot. In a good way. It has lead many of us to do away with assumptions, and begin to build more solid websites. The idea of separating structure, style and behaviour is definitely not new, but seems to have become inevitable at last. It is key to a great responsive workflow. This starts with structured text, as Stephen explained. Responsive web design also lead us to radically change workflow and planning, as Kirsty, Sally and Inayaili discussed. The surge of small devices with browsers forced web makers to think about priorities in content and navigation, as Ida and Oliver discussed. New standards and ideas, like those discussed by Rachel, Dan and Stephanie, will help us cater even better for a multitude of devices, but we should not just use new technologies for the sake of it, like Sally emphasised.

Responsive Day Out 2 was one of my favourite events this year. It was simple: no lunch, no WiFi, no coffee, no after parties, but also: a low price. And admittedly, good coffee or food is never really far away in Brighton anyway. The format, 20-minute talks, worked well. It resulted in a great variety of subjects. There was a good balance of theoretical/conceptual talks and practical case-study like talks.

Originally posted as Responsive Day Out 2 - the squishening on Hidde's blog.

[email protected]?subject=Reply%20to:%20Responsive Day Out 2 - the squishening">Reply via email

Breakpoints based on language

2014-08-05T00:00:00Z

In responsive web design, many of us think of breakpoints as related to the width of lay-outs. But there are other points that can break a website, like language.

Breakpoints: more than just widths and heights

In Responsive Design Workflow, Stephen Hay encourages readers to think about breakpoints regardless of specifics like widths or lay-out. Stephen says breakpoints are ‘the points when certain aspects of a website or web application change depending on specified conditions’ (RDW, page 92). This definition includes lay-out, but it also leaves room for many other aspects to be breakpoints.

Thinking of breakpoints in this more abstract way, they can be added for any change of condition. Width-based breakpoints optimise for width conditions. If a lay-out breaks on wide screens, a breakpoint is added. There can be breakpoints for conditions like ‘JavaScript is available’ and ‘JavaScript is not available’; some websites break without JavaScript. Certain aspects can be implemented differently to accommodate this: a form that gives validation feedback as you tab through it, versus a form that is able to show such information , but only after submission to the server.

Between the conditions ‘screen is greyscale’ and ‘screen is full colour’ is another breakpoint. Maybe they require different logos.

Breakpoints based on language

Recently, I worked on a project for Transition前進樂團, a Bristol-based band that performs in Taiwan and China. They recently launched their first all Chinese album. Naturally, they needed their website to support both languages. We explored the option of building separate sites in Chinese and English. But the cool thing about the band is that they are English, but sing in Chinese. Bilinguality is an essential part of their identity. Showing the two languages side by side would probably work ok, especially since the two languages look quite different. We decided to give it a go.

The Transition前進樂團 website has two languages side by side

HTML allows for language attributes, so that authors can define in which language content is written. Most people add one to the <html> element. The attribute can be useful for browsers, search engines and screen readers. For example, it can help a browsers suggest “This page is in Chinese. Can we translate this page to English for you?”, or help a screen reader decide to use a Chinese voice.

This website uses:

<html lang="en">

In the Transition site, pages contain both English and Chinese. I added lang="en" to the HTML element, and lang="zh-TW" to all bits of Chinese content. Content that is not in the page’s main language can be a breakpoint, especially if it’s in a non-Western language. Chinese text is much easier to read if it is aligned justified. Likewise, right-to-left reading language may require optimisations too.

Language breakpoints in CSS

If the Chinese content is in elements with the correct language attribute, they can be styled with simple CSS. There are no language media queries, but there is something that works just as well: attribute selectors.

Let’s say content in the default language is marked up like this:

<div class="content-part"></div>

And styled like this:

.content-part {
  text-align: left;
  color: black;
}

The Chinese text is marked up the same, but with a lang attribute:

<div class="content-part" lang="zh-TW"></div>

For the Chinese bits, we would like the text to appear justified. And in purple, because we can. Chinese characters are all the same width, so justified alignment can make them more readable. We can do this by adding [lang|=zh] to the style rule. This applies to all content parts with a language attribute that starts with zh, i.e. all different kinds of Chinese.

.content-part[lang|=zh] {
  text-align: justify;
  color: purple;
}

Other options

There is also the :lang() selector, which can be used to apply style rules to content in a specific language. Differences:

It does not only (?) look at the language attribute, it can also uses browser technology to decide what language content is in. Depending on the situation, this may be useful.
It does not accept regular expressions, so in the case of Chinese, it does not let you write the rule for all different kinds of Chinese (zh-TW, zh-CN)

Alternatively, one could also add classnames to content in a different language, and use those to style. See also: Styling using language attributes by the W3C.

Conclusion

Like screen width conditions, language conditions can be adapted to with simple CSS rules. This is what makes the web such a great medium: if your document is well structured, there are a lot things you can do depending on specific conditions. Really, this is just progressive enhancement.

Originally posted as Breakpoints based on language on Hidde's blog.

[email protected]?subject=Reply%20to:%20Breakpoints based on language">Reply via email

Review: the Mobile Web Handbook

2014-09-18T00:00:00Z

Peter-Paul Koch, famous for PPK on JavaScript, Quirksmode.org and more recently as a co-organiser of various Amsterdam-based web conferences just released his new book: the Mobile Web Handbook, published by Smashing Magazine.

! I have read the book on a recent train trip from Bristol to Brighton. It is 227 pages and beautifully illustrated.

Websites have been developed for more than one screen for a few years now. This inevitably followed from the rise of lots of different screen sizes. New phones, phablets, tablets, laptops and desktops with excellent and not so excellent browsers have come out and users simply started using those to visit our websites. As a response to the explosion of screen widths in our browser statistics, website owners could do nothing but adapt. Websites had to work on mobile.

Why we (still) need a handbook for mobile

By now, most of us have worked on websites made for lots of different screens. There are heaps of talks and articles out there to help. But development for mobile is complex, and untangling this complexity is important. The pixels, viewports and touch events that are discussed in the Mobile Web Handbook may be things we already use every day, but it is incredibly useful to see the concepts explained and annotated by someone with a lot of experience in testing browsers and mobile devices.

The book

The book starts with an introduction of the mobile world, which goes into things like market shares, OSes, stats (and how to interpret them) and strategies of device vendors, operators and browser makers. It gives a lot of useful background information, essential stuff to understanding the mobile world. More context of the mobile world is given throughout the book, for example in the chapter about (the politics of) Android.

After this first chapter the book goes into the more technical aspects of mobile development: from browsers and viewports to pseudo class selectors in CSS and touch/pointer events in JavaScript.

Towards the end of the book, a chapter is devoted to acquiring devices, with some useful hints as to which devices (not) to buy. This chapter, I found, is easier to read than to bring in practice. The argument for having real devices to test on is clear to me, but spending a hundred pounds every month on new devices would not work for me. As a freelancer, I prefer to use a combination of my own real devices, an Open Device Lab (like the Bristol ODL) and even emulators.

Last but not least, the last chapter is about the future of mobile web development, and contains various predictions on what to expect next.

Buy this book

If you’re not sure what the differences are between the visual viewport and the layout viewport, or between device pixels and CSS pixels, you have to read this book! The same goes if you would like to have better insight in the mobile landscape and the politics of (mobile-related) web standards. The ebook is available for direct download, and it seems that hard copies are going to be shipped sometime this month.

Originally posted as Review: the Mobile Web Handbook on Hidde's blog.

[email protected]?subject=Reply%20to:%20Review: the Mobile Web Handbook">Reply via email

Collaborate 2014: designing with empathy for all

2014-11-14T00:00:00Z

At the lovely St George’s, Bristol-based UX agency Nomensa organised Collaborate, a one day conference about user experience and (interaction) design.

Nick Finck – The nuances of UX

Nick Finck started off with his talk “The Nuances of UX”. He focused on what he regards as the four things that make up a good user experience: details, simplification, process and research and showed various examples of each.

Details

Details like the background colour of a placeholder for an image that is going to be loaded or a descriptive diagram component staying in position when changing the thing it describes, can be great details that improve the UX in a way users would only notice when it is taken out.

Simplification

It is important to keep asking ourselves whether we really need whichever things we want to add to a web page. But we should not over-simplify, as that can lead us to miss important details, the work still needs to be done.

Process

Most of our processes are feature-driven, our world is driven by version numbers. Features and version numbers, though great for marketing, rarely they are a means to improve the user experience.

Research

It is important to look at how people use products. Making things merely understandable and usable is great, but we also need to focus on making them “bring joy and excitement, pleasure and fun, and, yes, beauty” as Don Norman said.

Technology is moving so fast that what we thought was a solution for our business no longer is a couple of years later. The most important variable is, as Charles Darwin found, adaptability.

David Peter Simon – Representing information across channels

One of my favourite talks of the day was the one by David Peter Simon about the future of information architecture and portable content. He emphasised the importance of structured content first, a concept well introduced in Mark Boulton’s article Structure First. Content Always.

David Peter Simon showed the significance of structured content with examples from the ecosystem Amazon Kindle, the create-once-publish-everywhere approach of NPR and the structured content of Facebook stories.

As I talked to a content editor during one of the breaks, I found “structured content” is quite a technical term. The difference between plain text content and structured content is that it is not just text, it has things like headings, emphasised words, links, images and lists. A job ad is usually not just plain text: it can be structured into bits like a job title, a location, a salary indication, a ‘apply before’ date, et cetera. A recipe will have things like a list of ingredients, a photo of the end result and a list of steps to follow. These are all things you could in principle display in a different colour of size, they signify different bits of content.

Structured content is the most portable thing of a website. A job ad will always have a job title, a location, etc, whether it is displayed on a phone, a desktop computer or even a smart watch.

An interesting example David Peter Simon showed was that of Facebook. Facebook, he said, “is the first service that can be used by anyone from very young to very old, because it has succeeded in structuring information in such a way that a mental model of the information is created so that it can be familiarised with, regardless of where it is displayed. It no longer requires cognitive load to recognise the content.”

Thinking about responsive web design can be misleading as it often means thinking about (code) techniques. Thinking about mobile can be misleading as it often means thinking about a specific set of devices we want to support. Thinking about structured content does not have such problems, and therefore it is a perfect first step to create truly device agnostic experiences.

Some links about (structured) content:

Future-ready content by Sara Wachter-Boettcher on A List Apart
Sculpting text (slides of Stephen Hay’s talk at Responsive Day Out)

Joshua Marshall – Empathy as a core feature

Joshua talked about what is one of the biggest miracles of the past few years: GOV.UK! Until earlier this year he was Head of Accessibility at the Government Digital Service, the UK government department tasked with ‘leading the digital transformation of government ’.

After describing how the GDS and the new GOV.UK came about, Joshua discussed the place of accessibility in the project and on the web in general. Accessibility, he said, is about making it work for everyone. GOV.UK had 1.2 billion page views in the first year, that are a lot of people to annoying if it is not working right.

Accessibility guidelines in the GDS Service Manual

An important part of enforcing things work for everyone is established by the Design Principles, which emphasises user needs. It explicitly lists things like making it simple to use and inclusive. There is also the Service Manual, which has a brilliant part about accessibility, very useful for those working on any website, not just government.

The earlier you introduce accessibility in the project, the easier it becomes. In multidisciplinary teams, accessibility can be made the responsibility of each person in the team. With lots of semantics in the HTML standard and beyond (WAI-ARIA), accessibility is part of a modern web stack; old-fashioned looking websites do not follow from it, on the contrary.

Design like you give a damn. A more accessible website is better at enabling users to do what they need to do. It is not about you, it is about what you empower your users to achieve. Focusing on simplicity, usability and accessible UX makes everything better for every one of your users.

UX and accessibility both have empathy as their core value, so they should work together more.

Simon Norris – Digital first: a philosophy

The last speaker before lunch was Simon Norris, who doubled as the MC of the event. He discussed his concept of “Digital First” in three acts: past, present and future.

Simon started off by giving us an overview of major events in the history of the world wide web. Most of these events only took place in the past few decades, great to realise. He then went on to the now and discussed the importance of the ‘in between’. Some UX practitioners tend to think of UX as if it were as series of screens or wireframes, which makes us forget to think about the in between, which, arguably, is more important. He then discussed the future of UX, in which he discussed interesting concepts around ecology, arguing they cannot be designed, only shaped.

Maya Middlemiss – The users’ experience of user experience

Maya Middlemiss, managing director of a company that specialises in recruiting respondents for usability research, shared some insights of this interesting and often less discussed part of usability.

To recruit people to come into a user testing session can be anything from quite easy to very tricky, Maya said. It gets easier if it is for a well known brand and they agree to have their name disclosed to potential candidates, and it gets quite hard if it is for specialised products, especially if it is with regards to finance, as people are often more suspicious answering questions. On the test day, giving respondents simple refreshments, a glass of water or a sandwich, can help a great deal in making them feel welcome and comfortable.

Maya shared various videos of respondents that had experienced a user testing session, and were happy to share what their experience was like.

Dan Healy – Making things totes emosh and dead amaze: engaging millennials online

Next up was Dan Healy, who works as a user researcher at Nationwide building society. In his job he does a lot of research into marketing for millennials, or young adults. In his very energetic talk, he shared some insights.

There are lots of young people in the UK, and so far banks hardly pay attention to them in terms of marketing, usually focusing on their parents instead. Of Nationwide’s 16 million customers, 1.95 million are younger than 18, this is a group twice the size of Bristol’s population, too large to ignore.

An important lesson, said Dan, is not to try and speak young people’s language, that can only go miserably wrong. Instead, be scientific about it and use tools to measure readability of text. On some occasions, a couple of difficult word can make a whole page difficult to understand for (young) readers. Improving such text can improve the site for everyone, not just young people. Don’t underestimate the impact small (copy) changes can make on cognitive load of a text.

Ben Bywater – user research: from full fat to lean

Ben Bywater works at MixRadio, formerly Nokia Music and talked about user research. He had interviewed tens of user researchers to find out where they worked (client-side or agency-side) and how much experience they had in the field.

Ben encouraged us to be more pragmatic, calling pragmatism ‘the sweet spot between insight and resource’. It seems throughout the years the amount of time available for user research has declined, but user researchers have more influence on the end result. The best method to be more pragmatic is to do user testing. It can also be better do adapt more: agencies coaching in-house UX at clients. Increasing input can be good too, by establishing long term communities of users. Lastly Ben discussed measuring UX more, by using data analytics to measure the effectiveness of UX changes.

Thomas Wendt – the broken worldview of experience design

Building on the philosophical foundations of the German philosopher/phenomenologist Martin Heidegger, Thomas Wendt spoke about what he calls “Design for Da-sein”.

Phenomenology can be regarded as the study of human experience. “Dasein” is a Heideggerian term that means something along the lines of an individual’s mode of being in the world.

UX designers often assume users think rationally about their actions, but there can be a non-direction-ness in their behaviour. Websites like Instagram and Buzzfeed gain from this.

Another assumption is that users think, then act, but often that is not the case, said Thomas. Actually, I think we can see that in e-commerce websites: sometimes it can be easy to trick customers into buying something by using emotionally appealing arguments like ‘most other people also bought this’.

Thomas also talked about the importance of a designer’s intention. It is often portrayed as more important than everything else, but, he said, we should not prioritise it above adaptability, we could do without designer gods!

Main theme: have empathy with users and design like you give damn

One of the recurring themes at Collaborate 2014 was that user experience is very much about having empathy for users and for all users. As a front-end developer this is a large part of my daily job. But as Joshua Marshall said, accessibility is a responsibility that should be shared across everyone in a team, as it should be part of every aspect of a web project. Not just in code, but also in user experience, visual design and, most importantly, well written content.

Originally posted as Collaborate 2014: designing with empathy for all on Hidde's blog.

[email protected]?subject=Reply%20to:%20Collaborate 2014: designing with empathy for all">Reply via email

Review: Responsible Responsive Design

2014-11-21T00:00:00Z

It’s been 4 years since Ethan Marcotte’s seminal A List Apart article, and by now, responsive web design has become a pleonasm. All proper web design is now responsive, and the question is no longer if we do responsive, it is how we do it and why we should do it better or more responsible.

In the past few years, responsive web design has matured from the conceptual idea it once was. It influenced thinking about plenty related, general web design issues. Many have written about the role of structured content, web design software and progressive enhancement. As a front-end developer, I know this was also true for the code side of things. We started putting more thought into how content is delivered (first!), have been finding out which kind of client side detection mechanisms work (and which don’t) and tried to come up with solutions for browser testing.

! The turquoise cover of ‘Responsible Responsive Design’, published by A Book Apart

Sound reasoning and well-explained code examples

So what about the book? I was excited for it to be released, being a fan of all the awesome articles and scripts Scott and the Filament Group have been releasing recently. When the book came out, it was an instant buy, I started reading the same evening.

The most important facets of better responsive websites, according to Scott, are usability, accessibility, sustainability and performance. All four are described in detail in his book, with solid reasoning and handy code suggestions.

‘Responsible Responsive Design’ is a very practical overview of discussions that happened in the past few years, and hands the reader sensible argumentation as per why some responsive strategies are preferable to others. “Finding” breakpoints vs defining them, progressive enhancement vs graceful degradation, ‘web-safe’ gestures vs false assumptions, feature detection vs browser sniffing, FOUT vs FOIT and much more. If technical arguments don’t convince, he also shows examples of big websites that use solutions like Picturefill (Microsoft), responsive source order scripts (The Boston Globe) and Shoestring (Lego).

Secondly, other than explaining why some things are sensible solutions, Scott also explains how to do things with code examples, and walks the reader through the workings of some of the techniques he discusses, like the sizes attribute, cutting the mustard and loadCSS().

Responsible decision making

I found it very useful to read what Scott had to say about why we should do responsive design responsibly. Some benefits of the ‘responsible’ techniques are quite technical in nature, making them difficult to argue for. But they impact people everywhere. Arguing for those people is an important part of being a responsible responsive designer. Things like prioritising loading content over loading the fancy fonts, can be difficult to explain, and Scotts book makes this easier. It is easier to convince management to go for a cutting the mustard type of approach, if you can say that big organisations like the BBC and the Boston Globe do it, too.

Anyway, I can highly recommend ‘Responsible Responsive Design’. If you ever design or build websites, and are unsure whether your responsive strategies are indeed responsible, read this book!

How to get the book

‘Responsible Responsive Design’ is available from A Book Apart.

Originally posted as Review: Responsible Responsive Design on Hidde's blog.

[email protected]?subject=Reply%20to:%20Review: Responsible Responsive Design">Reply via email

Progressive enhancement with handlers and enhancers

2015-04-03T00:00:00Z

Recently I adopted a different way to manage bits of JavaScript in websites I was building. It exercises progressive enhancement (PE) by declaring handler and enhancer functions on HTML elements.

TL;DR: When JavaScript is used to handle user interactions like clicks, or enhance the page by manipulating the DOM, traditionally you’d have JavaScript find that HTML element in your page, and hook some code into it. But what if you’d switch that around, and have the HTML element “tell” JavaScript what function to execute?

How? I declare JavaScript functions on HTML elements. Separating them to functions that happen on click and those that happen on page load, I use two attributes (data-handler and data-enhancer) that both get space-separated function names as their values. Then, with a little bit of JavaScript, I make sure the functions execute when they need to.

Note that this works best for websites for which the mark-up is rendered on the server, to which JavaScript is added as an extra layer. Websites that rely on JavaScript for rendering content will probably have options to do the same within the framework they are built with.

Separating to handlers and enhancers

On many small to medium sized websites, the required JavaScript can be drilled down to two types of usage:

things that need to happen on a click
enhancements after the inital page load

Surely, there are often other events we want to use for triggering JavaScript (scroll, anyone?), but let’s focus on these two types first.

Many simple websites will have both types of script in a single scripts.js file, which is also used to query the nodes interactions need to happen on, and to add click handlers to those nodes.

This year, Krijn and Matijs introduced me to a new way to go about this. It has proven to be a very powerful pattern in some of my recent projects, which is why I’d like to share it here. Credits for the pattern, and for the initialisation functions I will discuss later, go to them.

Including JavaScript functions to the declarative model

The pattern starts from the idea that web pages have three layers to them: structure (HTML), lay-out (CSS) and enhancement (JavaScript). HTML is a declarative language: as an author, you declare what you’d like something to be, and that is what it will be.

Let this be a header, let this be a list item, let this be a block quote.

This is great, browsers can now know that ‘this’ is a list item, and treat it as such. Screenreaders may announce it as a list, your RSS reader or mobile Safari “reader view” can view it as a list, et cetera.

With CSS we declare what things look like:

Let headers be dark blue, let list items have blue bullets and let block quotes render in slightly smaller type.

This works rather well for us, because now we don’t need to think about what will happen if we add another list item. It being a list item, it will have the CSS applied to it, so it will have blue bullets.

The idea I’d like to share here, is that of making JavaScript functions part of this declarative model. If we can declare what something looks like in HTML, why not declare what its behaviour is, too?

Handlers: things that happen on a click

The idea is simple: we introduce a data-handler attribute to all elements that need to trigger function execution. As their value, we add one or more functions name(s) that need(s) to execute on click.

For example, here’s a link:

<a href="#punk-ipa">More about Punk IPA</a>

This is an in-page link to a section that explains more about Punk IPA. It will work regardless of JavaScript, but can be improved with it.

Cooler than linking to a section about Punk IPA, is to have some sort of overlay open, with or without a fancy animation. We add a data-handler attribute:

<a href="#punk-ipa" data-handler="overlay">More about Punk IPA</a>

In the data-handler, the value holds a function name, in this case ‘overlay’. The idea is that the overlay function executes when the link is clicked. Naturally, you would be able to add more than one function name, and separate function names by spaces. This works just like class="foo bar".

Within the function declaration, we will know which element was clicked, so we can access attributes. We can access the href or any data attribute. With that, it can grab the content that’s being linked to, append it into some sort of overlay, and smoothly transition the overlay into the page.

Note that this is similar to doing <a onclick="overlayfunction(); anotherfunction();"> , but with the added benefit that a data-handler only gets meaning once JavaScript is active and running, and that it contains strings like CSS classes, instead of actual JavaScript code. This way, the scripting is separated in the same way as the style rules are.

Also note that is best practice to only add handlers to HTML elements that are made for click behaviour, like <button>s and <a>.

Adding function definitions

In our JavaScript (e.g. an included scripts.js file), we add all functions for click behaviour to one object:

var handlers = {
	'function-name' : function(e) {
		 // This function is executed on click of any element with 
         // 'function-name' in its data-handler attribute.
         // The click event is in 'e', $(this).attr('data-foo') holds the
         // value of data-foo of the element the user clicked on 
    },
    'another-function-name' : function(e) {}
};

Those working in teams could consider making the handler object global. That way functions can have their own files, making collaboration through version control easier.

Adding click handling: one handler to rule them all

If we set all our click-requiring functionality up within data-handler attributes, we only need to attach one click handler to our document. Event delegation can then be used to do stuff to the actual element that is clicked on, even when that actual element did not exist on page load (i.e. was loaded in with AJAX).

This function (jQuery) can be used to handle clicks, then search through the handler functions and apply the ones specified in the data-handler function:

$(function() {
    'use strict';
    // generic click handler
    $(document).on('click', '[data-handler]', function(event) {
        var handler = this.getAttribute('data-handler');
        // honour default behaviour when using modifier keys when clicking
        // for example:
        // cmd + click / ctrl + click opens a link in a new tab
        // shift + click opens a link in a new window
        if (this.tagName === 'A' && (event.metaKey || event.ctrlKey || event.shiftKey)) {
            return;
        }
        if (handlers && typeof handlers[handler] === 'function') {
            handlers[handler].call(this, event);
        }
        else {
            if (window.console && typeof console.log === 'function') {
                console.log('Non-existing handler: "%s" on %o', handler, this);
            }
        }
    });
});

Enhancers: things that happen after page load

We can run functions to enhance elements in a similar way, by adding their function names to a data-enhancer attribute. The corresponding functions go into a enhancers object, just like the handlers object above.

For example, a page element that needs to display tweets. Again, here’s a link:

<a href="https://twitter.com/bbc">Tweets of the BBC</a>

To enhance this link to the BBC’s tweets, we may want to load a widget that displays actual tweets. The function to do that may add some container <div> s, and run some calls to the Twitter API to grab tweets. To trigger this function:

<a href="https://twitter.com/bbc" data-enhancer="twitter-widget">
Tweets of the BBC</a>

To find out whose Twitter widget to display, our function could analyse the URL in the href attribute, or we can add an extra attribute:

<a href="https://twitter.com/bbc" data-enhancer="twitter-widget" 
data-twitter-user="bbc">Tweets of the BBC</a>

Another example: of a large amount of text, we want to hide all but the first paragraph, then add a “Show all” button to show the remainder. The HTML will contain all of the content, and we will hide the remainder with JavaScript.

<section>
    <p>Some text</p>
    <p>Some more text</p>
    <p>Some more text</p>
</section>

To the block of text we add a data-enhancer function that makes sure everything but the first paragraph is hidden, and a “Show all” button is added.

<section data-enhancer="only-show-first-paragraph">
    <p>Some text</p>
    <p>Some more text</p>
    <p>Some more text</p>
</section>

A function named ‘only-show-first-paragraph’ could then take care of removing the content, and adding a button that reveals it (this button could have a data-handler for that behaviour).

Running all enhancements

Assuming all our enhancer functions are in one enhancer object, we can run all enhancers on a page with one function. The function looks for all elements with a data-enhancer attribute, and calls the appropriate functions.

$(function() {
    'use strict';
    // kick off js enhancements
    $('[data-enhancer]').each(function() {
        var enhancer = this.getAttribute('data-enhancer');
        if (enhancers && typeof enhancers[enhancer] === 'function') {
            enhancers[enhancer].call(this);
        }
        else {
            if (window.console && typeof console.log === 'function') {
                console.log('Non-existing enhancer: "%s" on %o', enhancer, this);
            }
        }
    });
});

Wrap-up

So the basic idea is: functions for click behaviour are handlers, and those that happen on page load are enhancers. They are stored in a handlers and enhancers object respectively, and triggered from HTML elements that have data-handler and data-enhancer attributes on them, to declare which functions they need.

In summary:

All functions that need to execute on click (or touch or pointer events), are declared on the HTML element that should trigger the click, in a data-handler attribute
All functions that need to change/enhance stuff on the DOM, are declared on the HTML element they need to change, in a data-enhancer attribute
Two JavaScript functions run through data-handler and data-enhancer attributes respectively, and execute all functions when they are required

Thoughts?

This pattern is not new, similar things have been done by others. Rik Schennink wrote about controlling behaviour before, and his conditioner.js deserves special mention. It is a library that not only manages modules of JavaScript, it also activates them based on responsive breakpoints, something the pattern described here does not do out of the box (it could).

For me and teams I worked in, the above has proven to be a useful way to declare actions and enhancements within pages. It adds maintainability, because it helps keeping functions organised. It also promotes reusability: although new functions can be added for each use, multiple elements can make use of the same function.

The method is not perfect for every project, and it can definitely be improved upon. For example, we could add the function that triggers all data-handler functions to an enhancer ( <html data-enhancer="add-handlers"> ), as it is an enhancement (of the page) by itself. In big projects with many people working on the same codebase, it may be useful to have all functions in separate files and have a globally available handlers object.

Update 07/04/2015: I have opened comments, would love to hear any feedback

Originally posted as Progressive enhancement with handlers and enhancers on Hidde's blog.

[email protected]?subject=Reply%20to:%20Progressive enhancement with handlers and enhancers">Reply via email

On cognitive accessibility

2015-04-04T00:00:00Z

This week I attended my first Accessible Bristol, which was an interesting talk by Alastair Somerville about cognitive accessibility. Slides are available.

Although I had worked on accessible websites before, and seen my bit of cognitive science at university, the combination of accessibility and cognition in one term was new to me. Cognitive accessibility, Alastair described, is the state you reach when something is perceivable, intelligible and actionable by as many people as possible. All three will have to be the case for it to work.

Alastair showed some example projects where he worked on improving cognitive accessibility, including the application of an urban design paradigm called “shared space at Exhibition Road in London.

Making things accessible cognitively, is about personalisation

The impairments we are looking at are things like dyslexia and autism, but also dementia and ageing. Cognitive impairments apply to all users: not only do we all age, situations of cognitive impairment happen to us all. This can be as simple as being in a foreign country, unable to read the menu. For it applies to all of us, cognitive accessibility is about inclusion, Alastair argued.

This is what we should design for, too. Alastair shared these words by Dieter Rams (citation needed):

Indifference towards people and the reality in which they live is actually the one and only cardinal sin in design.

So, in other words, for designers to impose a reality onto your users is a bad thing. All people are different, cognitive impairment differs from person to person. Instead, designers should try to understand the reality the user is in and start from there. Cognitive accessibility, then, Alastair said, is about personalisation. It is about making something work for someone, or for someone’s personal reality, so to say.

Interesting projects in cognitive accessibility

There are many (research) projects in cognitive accessibility going on, Alastair shared some of those:

Eiman Kanjo’s research on emotion in place / redesigning physical space
The W3C Cognitive and Learning Disabilities Accessibility Task Force, and Jamie Knight’s blog posts: part 1 and part 2
Steve Maslin (Schumacher institute, Bristol), works in physical design. His blog post about design for the mind
The US Army is doing really interesting research on a thing called ”responsive data load through emotionally aware devices”

Designing for happiness

Concluding, Alastair described happiness as “well directed attention”, so being happy is when your attention is well directed. Attention is a feature of one’s cognition, hence it is very personal, and personalisation is the strategy to make things more accessible cognitively. This brings us to the equation Alastair ended with: cognitive accessibility = personalisation = design for happiness.

This isn’t an easy thing to do, because if happiness is so personal, the problem, I think, would be that one thing is used by a lot of different persons. How can we keep all happy, personalise for those who need it, yet don’t disturb those who don’t?

Building a website, for example, one can define focus styles. That way keyboard users can keep track of the element currently in focus. Often though, I have worked with designers that would ask me to remove the focus styles, because they also showed up for non-keyboard users, which did not fit in the look and feel they had in mind. The Dieter Rams quote applies to those designers, obviously, but surely I can understand what they want is make a pretty website.

Another website-related example is skip links: they can be very useful for specific people that use them, for others they might feel unnecessary. Many websites only show them when a tab key is pressed, which is a way to make them available to those who need them, yet invisible for those who don’t. An interesting talk I saw about this was by Johan Huijkman of Q42, who has added lots of a11y improvements to Dutch public transport website 9292.nl that were invisible to most, yet available to those in need. Slides available (in Dutch). He too related accessibility to the user’s experience, and called the accessibility layer “invisible” UX.

Making accessibility invisible is not always the best solution: traffic lights that indicate their state with warning sounds, for example, are just out there, offering a useful level of cognition to users that need it. Or subtitles/dubbing added to speech in foreign languages on television: it is made visible/audible to all, including those who do understand the foreign language.

How can we decide which levels of accessibility to add, what to improve, and how to do this? Alastair mentioned various ways, including testing with (cognitively impaired) users. He also mentioned it can help to read personal blogs of those who are cognitively impaired and describe how they interact, whether physically or digitally. In the end, it is all about caring more about the reality your users live in, and less about your own.

Originally posted as On cognitive accessibility on Hidde's blog.

[email protected]?subject=Reply%20to:%20On cognitive accessibility">Reply via email

Switching to HTTPS

2015-04-12T00:00:00Z

From yesterday, this website is only available via HTTPS. In this post I will explain my reasons for making the switch, and how I did it at Webfaction.

HTTP with SSL

HTTPS stands for HyperText Transfer Protocol with Secure Sockets Layer, or HTTP with SSL for short. Data over HTTP is sent as plain text. Data over HTTPS is encrypted before it is sent off, and not decrypted until it arrives at the user.

HTTPS is great and a must-use for websites that deal with sensitive data, e.g. credit card details, because sending such data in plain text would make it trivial to intercept. With HTTPS, the data is encrypted, and thus safe from hackers, at least in theory.

The certificates that are required to serve your website over HTTPS are not expensive (starting at £10 per year), and there are various initiatives that aim at make it easier or free. Let’s encrypt, sponsored by Mozilla and EFF, amongst others, looks promising. What’s more, you used to need a dedicated IP address, but if your server supports SNI, this is no longer required. Note that not all browsers support the latter (notably IE6 and older versions of Android).

Why use it on this website?

“Your website contains just some blog posts”, I hear you say, “so why would you encrypt it?” Even for sites that do not take sensitive data like payment details, there are additional benefits of HTTPS over HTTP. The most important one is content integrity.

Content integrity

The user can be more certain that the content is genuine. On a news website, we want to be sure the news stories were not meddled with. There is quite a number of countries where the state censors the news by default. If in such countries, news websites send their content over plain text, it is much easier for their government to change what is being served, e.g. replace all instances of “war” with “peace”.

I am the last to pretend anyone would want to alter information on my website, but for the sake of argument: even on this website content integrity could be an issue. Serving over HTTPS makes sure that the phone number on my contact page is not replaced by that of someone with malicious intentions.

Preventing ad insertion

Imagine you are on a WiFi hotspot. If the owner of the hotspot wants to earn some extra money, they could insert advertising into websites served via their internet connection (happens). This would not work on websites that are served over HTTPS, hence this website stays the way it was intended to.

Protecting form data

If you want to comment below, I will require your name and email address. Imagine you leave a comment whilst on airport WiFi and someone in the lounge is bored and listens in for e-mail addresses going over the line. They could, if you submit the data over non-secure HTTP. With HTTPS on, we can be more sure that this data goes from you to me, and nowhere else.

Securing my back-end logins

The content on this website is managed by Perch. If I log in to add new content whilst on public WiFi, my (login) data will be encrypted. The same applies when I access my website’s analytics package, Piwik.

Other potential benefits

A personal benefit of serving my site over HTTPS is that I will now be able to experiment with new standards like Service Workers, which is only available for websites served over HTTPS.

Another benefit in the long term, could be if search engines start to prefer sites that are served over HTTPS. Google has said they will. This makes serving over HTTPS more attractive to those interested in a higher search engine ranking. Yes, that’s right, serving your website over HTTPS optimises your SEO in search engines.

How I did it

To get a signed certificate for your domain and serve your content over HTTPS, these are the steps:

Applying for a certificate
Create a key on your web server, use it to generate a Certificate Signing Request (CSR) and give the CSR to a Certification Authority
Uploading the certificate
When the Certification Authority has been able to sign your certificate and has returned it to you, upload the certificate to your server
Installing the certificate
Install the certificate by enabling HTTPS on the server and reloading the server configuration

My host, Webfaction, was able to do the last step for me, so I only had to do the first two steps myself: applying for the certificate and uploading the signed certificate.

Applying for a certificate

Certificates are sold by many different providers, I bought mine at sslcertificaten.nl.

There are various types of certificates, they differ in how much is actually verified. The ones that are only domain name verified seem to be the simplest, I went for one of those. They can be as cheap as ten pounds per year. There are more complex ones that involve more thorough checks and will cost around a hundred pounds. Certificates are for one domain only, unless you buy one with a wildcard. They are more expensive than single domain certificates, but will work for anything.yourdomain.com.

In the purchase process,you will be asked to input a Certificate Signing Request (CSR). The easiest way to generate one, it by opening an SSH session to your webserver in your terminal:

ssh yourserver

Then, create a key (replace ‘domainname’ with any name):

openssl genrsa -out domainname.key 2048

A key file domainname.key is created. Then create the signing request:

openssl req -new -key domainname.key -out domainname.csr

The command prompt will ask you for some information. When asked for a “common name”, enter the domain name that you need the certificate to work on (in my case: hiddedevries.nl).

Then, to copy the CSR, type this:

more domainname.csr

The code will appear in your Terminal window, ready to copy and paste.

Depending on where you buy your certificate, you will have to fill in your information to complete the purchasing process.

In the type of certificate I chose, the only verification step was done with an email from the Certification Authority to admin@mydomain. The e-mail contained a link that I, i.e. the person with access to the domain name’s admin email address, could click to approve the certificate request.

About 15 minutes after approving the certificate request, I was sent my certificate. For the certificate to function, they sent me two other certificates: a root certificate and an intermediate certificate.

Uploading the certificate

Using SFTP, I uploaded my certificate, the root certificate and the intermediate certificate, to the root of my web server.

Installing the certificate

To get the certificate installed, I opened a support ticket at Webfaction, as per their instructions. Fifteen minutes later I received an email stating that the certificate had been installed.

That’s about it

I have little experience of how it works at other hosting providers, but was quite pleased to see how quick it went at mine. Basically, I uploaded the files and got in touch with support, who then did the rest. Whether “the rest” is incredibly painful, or just a few simple steps, I am not sure (instructions for Apache).

Note that once it is setup, you should also make sure your assets (CSS, JavaScript, images) are served over HTTPS. If you use CDNs, use one that supports HTTPS. Likewise, if you use plug-ins that do stuff with URLs, make sure they know about the change (or use relative URLs).

Some further reading/tips about HTTPS:

HTTPS on Wikipedia
It’s time to encrypt the entire internet by Klint Finley
Let’s encrypt
HTTPS Everywhere

But also:

Why HTTPS and SSL are not as secure as you think by Scott Ogrin
Should all web traffic be encrypted? by Jeff Atwood

Originally posted as Switching to HTTPS on Hidde's blog.

[email protected]?subject=Reply%20to:%20Switching to HTTPS">Reply via email

Making our websites even more mobile friendly

2015-04-16T00:00:00Z

From 21 April, Google will start preferring sites it considers “mobile friendly”. The criteria are listed in a blog post and Google provide a tool for web masters to check whether they deem websites eligible for the label.

First, we should define what we are trying to be friendly for here. What’s the ‘mobile’ in ‘mobile friendly’? Is it people on small screen widths, people on the move, people with a slow connection? The latter is interesting, as there are people using their fast home WiFi on a mobile device on the couch or loo. There are also people who access painfully slow hotel WiFi on their laptops.

Assumptions are pretty much useless for making decisions about what someone is doing on your site. Mobile, as argued before by many, is not a context that helps us make design decisions. We’ll accept that for the purpose of this article, and think of mobile as a worst-case scenario that we can implement technical improvements for: people on-the-go, using small devices on non-stable connection speeds.

Great principles to start with

So what are Google’s criteria for mobile friendliness? According to their blog post, they consider a website mobile friendly if it:

Avoids software that is not common on mobile devices, like Flash

Uses text that is readable without zooming

Sizes content to the screen so users don’t have to scroll horizontally or zoom

Places links far enough apart so that the correct one can be easily tapped
(Source)

Websites that stick to these criteria will be much friendlier to mobile users than websites that don’t. Still, do they cover all it gets to be mobile friendly?

It passes heavy websites, too

At Fronteers, we celebrated April Fool’s by announcing, tongue-in-cheek, that we went all Single Page App. We included as many JavaScript libraries into the website as we could, without ever actually making use of them. It made the page much heavier in size. We also wrapped all of our markup in elements, with no actual JavaScript code to fetch and render content. The site became non-functional for users with JavaScript on. External scripts were included in the <head> of the page, so that their requests would block the page from rendering. With JavaScript turned off, the site was usable as usual, with JavaScript on, all the user saw was an animated spinner gif.

All the user saw was an animated spinner gif

Probably not particularly funny, but it showed a problem that many modern websites have: loading content is made dependent on loading JavaScript, and lots of it. This is not user friendly, and certainly not friendly to users on wobbly mobile connections. In our extreme case, the content was made inaccessible. Still, as Krijn Hoetmer pointed out on Twitter this morning, the joke —still live on the page announcing it (view the source) — passed Google’s test for mobile friendliness:

Nope, Google, a media query doesn’t make a site “Mobile-friendly”. Your algo needs some love: google.com/search?q=site:… pic.twitter.com/GPgEfkpKLV

I think he is right, the algorithm could be improved. This is not trivial, because the algorithm has no way to find out if we intended to do anything more than display a spinner. Maybe we really required all the frameworks.

The tweet inspired me to formulate some other criteria that are not currently part of Google’s algorithm, but are essential for mobile friendliness.

Even more friendly mobile sites

There are various additional things we can do:

Minimise resources to reach goals

Slow loading pages are particularly unfriendly to mobile users. Therefore, we should probably:

Be careful with web fonts
Using web fonts instead of native fonts often cause blank text due to font requests (29% of page loads on Chrome for Android displayed blank text). This is even worse for requests on mobile networks as they often travel longer. Possible warning: “Your website’s text was blank for x seconds due to web fonts”
Initially, only load code we absolutely need
On bad mobile connections, every byte counts. Minimising render-blocking code is a great way to be friendlier to mobile users. Tools like Filament’s loadCSS / loadJS and Addy Osmani’s Critical are useful for this. Possible warning: “You have loaded more than 300 lines of JavaScript, is it absolutely needed before content display?”
Don’t load large images on small screens
Possible warning: “Your website shows large images to small screens”

Google has fantastic resources for measuring page speed. Its tool Pagespeed Insights is particularly helpful to determine if you are optimising enough. A reason not to include it in the “mobile friendly” algorithm, is that speed is arguably not a mobile specific issue.

Use enough contrast

If someone wants to read your content in their garden, on the window seat of a moving train or anywhere with plenty of light, they require contrast in the colours used. The same applies to users with low brightness screens, and those with ultramodern, bright screens who turned down their brightness to deal with battery incapacity.

Using grey text on a white background can make content much harder to read on small screens. Added benefit for using plenty of contrast: it is also a good accessibility practice.

Again, this is probably not mobile specific; more contrast helps many others.

Attach our JavaScript handlers to ‘mobile’ events

Peter-Paul Koch dedicated a chapter of his Mobile Web Handbook to touch and pointer events. Most mobile browsers have mouse events for backwards compatibility reasons (MWH, 148), he describes. That is to say, many websites check for mouse clicks in their scripts. Mobile browser makers decided not to wait for all the developers to also check for touch behaviour. So, mobile browser makers implemented a touch version of the mouse click behaviour, so that click events also fired on touch.

Most mobile browsers listen to touch events, like touchstart or gesturechange (iOS). So maybe we could measure mobile friendliness by checking if such events are listened to? This is a tricky one, because a script that only listens to click events can be mobile friendly, because of backwards compatibility.

Depending on the functionality, JavaScript interactions can be improved by making use of mobile specific events. Carousels (if you really need to) are a good example of this: adding some swipe events to your script can make it much more mobile friendly. Or actually, like the two above, it would make it friendlier for all users, including those with non-mobile touch screens.

Even more friendly sites

Page speed, colour contrast and touch events may not be mobile specific, but I would say that goes for all four of Google’s criteria too. Legible text helps all users. Tappable text also helps users of non-mobile touch screens.

If we are talking about improving just for mobile, Google’s criteria are a great start. But we need to work harder to achieve more mobile friendliness. Above, I’ve suggested some other things we should do. Some can be measured, like improving load times and providing enough contrast. These things are friendly to all users, including mobile ones. Other things will have to be decided case by case, like including ‘mobile’ events in JavaScript, but probably also how much of our CSS or JavaScript is critical. As always, it depends.

Originally posted as Making our websites even more mobile friendly on Hidde's blog.

[email protected]?subject=Reply%20to:%20Making our websites even more mobile friendly">Reply via email

Solving problems with CSS

2015-04-20T00:00:00Z

Writing CSS is, much like the rest of web development, about solving problems. There’s an idea for laying out content, the front-end developer comes up with a way to get the content marked up, and she writes some CSS rules to turn the marked up content into the lay-out as it was intended. Simple enough, until we decide to outsource our abstraction needs.

TL;DR: I think there is a tendency to add solutions to code bases before carefully considering the problems they solve. Abstraction and the tooling that make them possible are awesome, but they do not come without some problems.

When going from paper, Photoshop, Illustrator or whatever into the browser, we use HTML, CSS and JavaScript to turn ideas about content, design and behaviour into some sort of system. We solve our problems by making abstractions. We don’t style specific page elements, we style classes of page elements. Some abstract more from there on, and generate HTML with Haml templates, write CSS through Sass or LESS or use CoffeeScript to write JavaScript.

I work at agencies a lot, so in my daily work I see problems solved in lots of different ways. Some choose to enhance their workflow with preprocessors and build tools, some don’t. All fine, many roads lead to Rome. Often, specifics like grids or media query management (apparently that is a thing) are outsourced to a mixin or Sass function. With so many well-documented libraries, plug-ins and frameworks available, there’s a lot of choice.

What tools can do

Libraries like Bourbon for Sass have lots of utilities that are solutions to solve specific problems. Their mixins can do things like:

@linear-gradient($colour,$colour,$fallback,$fallback_colour)

which is transformed into a linear-gradient preceded by a -webkit prefixed version and a fallback background colour. Someone found it would be good to outsource typing the fallback background colour, the prefixed one and then the actual one. So they came up with a solution that involves typing the gradient colours and the fallback colour as arguments of a mixin.

This kind of abstraction is great, because it can ensure all linear-gradient values in the project are composed in the same, consistent way. Magically, it does all our linear gradienting for us. This has many advantages and it has become a common practice in recent years.

So, let’s import all the abstractions into our project! Or shouldn’t we?

Outsourcing automation can do harm

Outsourcing the automation of our CSS code can be harmful, as it introduces new vocabulary, potentially imposes solutions on our codebase that solve problems we may not have, and makes complex rules look deceivably simple.

It introduces a new vocabulary

The first problem is that we are replacing a vocabulary that all front-end developers know (CSS) with one that is specific to our project or a framework. We need to learn a new way to write linear-gradient. And, more importantly, a new way to write all the other CSS properties that the library contains a mixin for (Bourbon comes with 24 at the time of writing). Quite simple syntax in most cases, but it is new nonetheless. Sometimes it looks like its CSS counterpart, but it accepts different arguments. The more mixin frameworks in a project, the more new syntax to learn. Do we want to raise the requirement from ‘know CSS’ to ‘know CSS and the list of project-related functions to generate it’? This can escalate quickly. New vocabulary is potentially harmful, as it requires new team members to learn it.

It solves problems we may not have

A great advantage of abstracting things like linear-gradient into a linear-gradient mixin, is that you only need to make changes once. One change in the abstraction, and all linear-gradients throughout the code will be outputted differently. Whilst this is true, we should not forget to consider which problem this solves. Will we need to reasonably often change our linear-gradient outputs? It is quite unlikely the W3C decides linear-gradient is to be renamed to linear-grodient. And if this were to happen, would I be crazy if I suggested Find and Replace to do this one time change? Should we insist on having abstractions to deal with changes that are unlikely to happen? Admittedly, heavy fluctuation in naming has happened before (looking at you, Flexbox, but I would call this an exception, not something of enough worry to justify an extra abstraction layer.

Doesn’t abstracting the addition of CSS properties like linear-gradient qualify as overengineering?

It makes complex CSS rules look simple

Paraphrasing something I’ve overheard a couple of times in the past year: “if we use this mixin [from a library], our problem is solved automatically”. But if we are honest, there is no such thing.

Imagine a mathematician shows us this example of his add-function: add(5,2). We would need no argument over the internals of the function, to understand it will yield 7 (unless we are Saul Kripke). Adding 5 + 2 yields 7.

Now imagine a front-end developer showing us their grid function: grid(700,10,5,true). As a curious fellow front-end person, I would have lots of questions about the function’s internals: are we floating, inline-blocking, do we use percentages, min-widths, max-widths, which box model have we set, what’s happening?

Until CSS Grids are well supported, we can’t do grids in CSS. Yet we can, we have many ways to organise content grid-wise by using floats, display modes, tables or flexible boxes. Technically they are all ‘hacks’, and they have their issues: floats need clearing, inline-block elements come with spaces, tables aren’t meant for lay-out, etc. There is no good or bad, really. An experienced front-end developer will be able to tell which solution has which impact, and that is an important part of the job.

CSS problems are often solved with clever combinations of CSS properties. Putting these in a black box can make complex things look simple, but it will not make the actual combination of CSS properties being used less complex. The solution will still be the same complex mix of CSS properties. And solving bugs requires knowledge of that mix.

Solve the problem first

When we use a mixin, we abstract the pros and cons of one solution into a thing that can just do its magic once it is included. Every time the problem exists in the project, the same magic is applied to it. Given a nice and general function name is used, we can then adjust what the magic is whenever we like. This is potentially super powerful.

All I’m saying is: I think we add abstractions to our projects too soon, and make things more complex than necessary. We often overengineer CSS solutions. My proposal would be to solve a problem first, then think about whether to abstract the solution and then about whether to use a third-party abstraction. To solve CSS problems, it is much more important to understand the spec and how browsers implemented it, than which abstraction to use (see also Confessions of a CSS expert). An abstraction can be helpful and powerful, but it is just a tool.

Originally posted as Solving problems with CSS on Hidde's blog.

[email protected]?subject=Reply%20to:%20Solving problems with CSS">Reply via email

The web is fast by default, let’s keep it fast

2015-05-18T00:00:00Z

A major web corporation recently started serving simplified versions of websites to load them faster¹. Solving which problem? The slowness of modern websites. I think this slowness is optional, and that it can and should be avoided. The web is fast by default, let’s keep it fast.

Why are websites slow?

There are many best practices for web performance. There are Google’s Pagespeed Insights criteria, like server side compression, browser caching, minification and image optimisation. Yahoo’s list of rules is also still a great resource.

If there is so much knowledge out there on how to make super fast websites, why aren’t many websites super fast? I think the answer is that slowness sneaks into websites, because of decisions made by designers, developers or the business. Despite best intentions, things that look like great ideas in the meeting room, can end up making the website ‘obese’ and therefore slow to end users.² Usually this is not the fault of one person.³ All sorts of decisions can quietly cause seconds of load time to be added:

A designer can include many photos or typefaces, as part of the design strategy and add seconds
A developer can use CSS or JavaScript frameworks that aren’t absolutely necessary and add seconds
A product owner can require social media widgets to be added to increase brand engagement and add seconds

Photos and typefaces can make a website much livelier, frameworks can be incredibly useful in a developer’s workflow and social media widgets have the potential to help users engage. Still, these are all things that can introduce slowness, because they use bytes and requests.

An example: an airline check-in page

To start a check-in, this is the user input KLM needs in step one:

ticket number
flight number

What the check-in page looks like

For brevity, let’s just focus on this first step and see how it is done. What we would expect for us to submit the above details to KLM, is to be presented with a form that displays a field for each. However, at the time of writing, the check-in page of KLM.com presents us with:

151 requests
1.3 MB transferred
lots of images, including photos of Hawaii, London, Rome, palm trees and phone boxes, various KLM logos, icon sprites and even a spacer gif
over 20 JavaScript files

From the looks of it, more bytes are being transferred than absolutely necessary. Let me emphasise, by the way, that this thing is cleverly put together. Lots of optimising was done and we should not forget there are many, many things this business needs this website to do.

On a good connection, it is ready for action within seconds, and provides a fairly smooth UX. On GPRS however, it took me over 30 seconds to see any content, and 1 minute and 30 seconds to get to the form I needed to enter my details in. This excludes mobile network instabilities. On 3G, I measured 6 and 10 seconds respectively.

Is there a different way? I mean… what if we JUST use plain HTML? As a thought experiment, not as a best practice or something we would realistically get signed off.

Constructed with just HTML, the page weighs just over 2kb and takes 0.2 seconds to load on GPRS. This is what it would look like:

Just HTML. Alas, it looks boring, but it is extremely fast

This is the web in its default state, and it is very fast. No added styles or interactions, just HTML. I’m not arguing we should serve plain HTML, but we should realise that everything that is added to this will make the page slower. There is plenty one can add before worrying about slowness: adding a logo, colours and maybe even a custom font can still leave us with a very fast page.

Designing a fast website does not have to be boring at all. As Mark Skinner of cxpartners said, “it’s about being aware of the performance cost of things you add and being deliberate with your choices”.

Performance budgets to the rescue

In a world where speed is the most important aspect of a website, the web can be incredibly fast (plain looking, but incredibly fast). If branding and business needs are taken into account, websites will be slower. As long as everyone involved is aware of that, this is a challenge more than it is a problem.

The key question here, is how much slowness we can find acceptable. Just like a family can set a budget for how much spending they find acceptable, web teams can set a budget for how much slowness we find acceptable. Performance budgets (see Tim Kadlec’s post about this) are a great method for this.

The idea of a performance budget, as Tim explains, is just what it sounds like: ‘you set a “budget” on your page and do not allow the page to exceed that.’ Performance budgets can be based on all kinds of metrics: load time in seconds, or perhaps page size in (kilo)bytes or number of HTTP requests. They make sure everyone is aware of performance, and literally set a limit to slowness.

Agencies like Clearleft and the BBC (‘make the website usable [on GPRS] within 10 seconds’) have shared their experiences with using performance budgets. Advantages of setting a budget, they say, is that it ensures performance is part of the conversation. With the budget, avoiding additions that cause slowness no longer depends on a single developer, it becomes a team’s commitment. With the Grunt plugin it can even be part of the build workflow and out-of-budget additions would, in theory, never make it to production.

Conclusion

The web is not slow by default, but still, many websites have ended up being slow. Apart from the best practices that can often be automated, there are many human decisions that have impact on page speed. A way to make page speed part of the conversation and optimising it part of a website’s requirement, is to set a performance budget.

Update 02/07/2015: Someone pointed me at this page that provides a lighter check-in option

Notes

¹ Or as Benjamin Reid tweeted: ‘Facebook doesn’t think the web is slow. That’s their “legitimate” reason to stop users navigating off facebook.com. It looks better for them to say that rather than “we’re opening external websites in popups so that you don’t leave our website”.’

² As Jason Grigsby said

³ As Maaike said (lang=nl)

Originally posted as The web is fast by default, let’s keep it fast on Hidde's blog.

[email protected]?subject=Reply%20to:%20The web is fast by default, let’s keep it fast">Reply via email

The accessibility tree

2015-05-26T00:00:00Z

At this month’s Accessible Bristol, Léonie Watson talked about improving accessibility by making use of WAI-ARIA in HTML, JavaScript, SVG and Web Components.

The talk started with the distinction between the DOM tree, which I assume all front-end developers will have heard of, and the accessibility tree. Of the accessibility tree, I had a vague idea intuitively, but, to be honest, I did not know it literally exists.

The accessibility tree and the DOM tree are parallel structures. Roughly speaking the accessibility tree is a subset of the DOM tree.
— W3C on tree types

The accessibility tree contains ‘accessibility objects’, which are based on DOM elements. But, and this is the important bit, only on those DOM elements that expose something. Properties, relationships or features are examples of things that DOM elements can expose. Some elements expose something by default, like <button>s, others, like <span> , don’t.

Every time you add HTML to a page, think ‘what does this expose to the accessibility tree?’

This could perhaps lead us to a new approach to building accessible web pages: every time you add HTML to a page, think ‘what does this expose to the accessibility tree?’.

Exposing properties, relationships, features and states to the accessibility tree

An example:

<label for="foo">Label</label>
<input type="checkbox" id="foo" />

In this example, various things are being exposed: the property that ‘Label’ is a label, the relationship that it is a label for the checkbox foo, the feature of checkability and the state of the checkbox (checked or unchecked). All this info is added into the accessibility tree.

Exposing to the accessibility tree benefits your users, and it comes for free with the above HTML elements. It is simply built-in to most browsers, and as a developer, there is no need to add anything else to it.

Non-exposure and how to fix it

There are other elements, like and <div> that are considered neutral in meaning, i.e. they don’t expose anything. With CSS and JavaScript, it is possible to explain what they do, by adding styling and behaviour.

<!-- this is not a good idea -->
<span class="button">I look like a button</span>

With CSS and JavaScript, it can be made to look and behave like a button (and many front-end frameworks do). But these looks and behaviours can only be accessed by some of your users. It does not expose nearly enough. As it is still a <span> element, browsers will assume its meaning is neutral, and nothing is exposed to the accessibility tree.

Léonie explained that this can be fixed by complementing our non-exposing mark-up manually, using role and other ARIA attributes, and the tabindex attribute.

<!-- not great, but at least it exposes to the accessibility tree -->
<span class="button" role="button">I am a bit more button</span>

For more examples of which ARIA attributes exist and how they can be used, I must refer you to elsewhere on the internet — a lot has been written about the subject.

Exposing from SVG

With SVG becoming more and more popular for all kinds of uses, it is good to know that ARIA can be used in SVG. SVG 1.1 does not support it officially, but SVG 2.0, that is being worked on at the moment, will have it built-in.

SVG elements do not have a lot of means to expose what they are in a non-visual way (besides <title> and @), and this can be improved with ARIA labels. Léonie gave some examples, and wrote a blog post about SVG accessibility which I can highly recommend.

Exposing from Web Components

Web Components, without going into too much detail, are custom HTML elements that can be created from JavaScript. For example, if <button> does not suit your use-case, you can create a <my-custom-button> element.

At the moment, there are two ways of new element creation:

an element based on an existing element (i.e. is like , but…). It inherits its properties/roles from the existing element if possible
a completely new element. This inherits no properties/roles, so those will have to be added by developer that creates the element.

The first method was recently nominated to be dropped from the specification (see also Bruce Lawson’s article about why he considers this in violation with HTML’s priority of constituencies, as well as the many comments for both sides of the debate).

Again, like <span> s used as buttons and with SVG, these custom elements, especially those not inherited from existing elements, scream for more properties and relations to be exposed to the accessibility tree. Some more info on how to do that in the Semantics section of the spec.

“Code like you give a damn”

Léonie ended her talk with a positive note: to build accessible websites, there is no need to compromise on functionality or design, as long as you “code like you give a damn”. This showed from her examples: many elements, like <button> expose to the accessibility trees, they come with some free accessibility features. And even if you use elements that do not come with built-in accessibility features, you can still use ARIA to expose useful information about them to the accessibility tree.

Personally, I think the best strategy is to always use elements what they are used for (e.g. I would prefer using a <button type="button"> for a button to using a supplemented with ARIA). In other words: I think it would be best to write meaningful HTML where possible, and resort to ARIA only to improve those things that don’t already have meaning (like SVG, Web Components or even the <span> s outputted by the front-end framework you may be using).

Originally posted as The accessibility tree on Hidde's blog.

[email protected]?subject=Reply%20to:%20The accessibility tree">Reply via email

Responsive day out 3: the final breakpoint

2015-06-20T00:00:00Z

Yesterday I attended the third (and hopefully not final) edition of Responsive Day Out, Clearleft’s one day conference about all things responsive web design.

The talks were very varied this year. There were practical talks about improvements to the web with features like Web Components, Service Workers and flexbox. There were also conceptual talks, which looked at meta issues surrounding responsive web design: how web designers and developers adopt new ways of working or choose not to do so, and how to work together.

Like last year, the conference was hosted by Jeremy Keith, talks were divided into four segments, with three short talks in each segment, followed by a short interview-like discussion.

Jeremy Keith opening Responsive Day Out 3

Part 1: Alice Bartlett, Rachel Shillcock and Alla Kholmatova

In the first segment, Alice Bartlett looked at whether and how we might be able to come up with a business case for accessibility, Rachel Shillcock looked at the relationship between web design and accessibility and Alla Kholmatova did a fantastic talk about (libraries of) patterns and, amongst other things, how to name them.

The business case for accessibility

Coming up with a business case may be a much shorter route to getting everyone on board with accessibility

Alice Bartlett from the Government Digital Service opened with a convincing talk about how to sell accessibility. Designing and building websites accessibly is a no-brainer to web designers and web developers who are convinced by the moral case for accessibility. But to some, that argument won’t cut it. There may be people in your organisation that want to learn more about the return on investment, and instead of trying to make the moral case, coming up with a business case may be ‘a much shorter route’ to getting everyone on board with accessibility, Alice said.

A business case is a document that proves that you have a problem and shows how you can solve it in the most cost effective manner. For accessibility this is hard, as there is not much evidence to show that accessibility solves the problems that we assume it solves. Sites that are accessible may be more maintainable, better for SEO or beneficial to usability, but, said Alice, there is hardly any evidence supporting such claims. See also Karl Groves’ series of blog posts about this, and the conclusion of that series.

Litigation may prove to be a way out: if non-accessibility is something one can be sued for, accessibility may be the result of a strategy avoiding being sued. The problem with that approach, is that whereas the risk of being sued is likely to be substantial for high profile companies, it is unlikely to be big enough to make a case for low profile companies. This should not stop us from making low profile companies’ sites accessible, but it does show that coming up with a business case for accessibility is problematic.

Accessibility and web design

Rachel Shillcock is a web designer and talked about how she integrates accessibility in her web design workflow. She gave practical tips and discussed tools like Lea Verou’s Contrast Ratio for determining WCAG colour compliance, HTML Code Sniffer that checks your front-end code for potential problems in web accessibility guidelines compliance, and tota11y, a similar tool that was recently launched by Khan Academy. Rachel made the moral case for accessibility: she emphasised that accessibility is a responsibility and that improving it can hugely improve your users’ lives.

Pattern libraries and shared language

Alla Kholmatova talked about the pattern library she works on at Future Learn. One of the problems she highlighted, is the boundary between a component being just something on its own, and it having enough similarities to something else to form a shared component. Like in language, interpretations may vary. I may see two separate components, you may see one component and one variation. “Naming is hard”, Alla explained. Visual names like ‘pink button’ are easy, but will quickly become limiting and burdensome (to the project). Functional names may be better, but then you might end up with two components that have different functions, but are visually the same. Higher level functions could be the basis for better names.

Alla emphasised that language is incredibly important here, shared language in particular. Pattern libraries and frameworks for modular design like atomic design and material design are ‘examples of controlled vocabularies’, she said. Naming is the method teams use to establish such frameworks. The framework will be used by the team, therefore the naming should be done by the team that will use it. The language that is established should remain in use to stay ‘alive’ and keep its meaning. Because a name like ‘billboard’, one of Alla’s examples, is quite broad. By using it in daily conversations, it remains meaningful. It made me think of Wittgenstein, who held that language only has meaning in virtue of the group / community it is used in.

Many of their naming conversations […] are done with everyone involved: not just designers or developers, but also content producers and users.

She explained how the team at Future Learn work on their shared language: they have a wall with all the (printed out) bits of design of their website for reference and overview. Many of their naming conversation takes place on Slack, and are done with everyone involved: not just designers or developers, but also content producers and users. They look at terminology of architecture and printing press for inspiration.

Part 2: Peter Gasston, Jason Grigsby and Heydon Pickering

In the second part, Peter Gasston talked about the state of web components, Jason Grigsby explained some of the puzzles of responsive images and Heydon Pickering showed how when viewing CSS as (DOM) pattern matches, clever CSS systems can be built.

Web Components

Peter Gasston gave an overview of Web Components, which provides a way for web developers to create widgets or modular components, that can have their own styles and behaviour (as in: not inherited from the page, but really their own). React and BEM have provided ways to do that with existing tech, Web Components brings it to the browsers.

There are four key modules to Web Components: templates, HTML imports, custom elements and Shadow DOM.

Templates offer a way to declare reusable bits of markup in a element. Works everywhere but IE.
HTML imports lets you import bits of HTML. Major problem: these imports block rendering (the imported file can link to stylesheets or scripts, which will need to be fetched). This may be replaced altogether by ES6 Modules.
Custom elements let you have meaningful markup with custom properties. You create them in JS. The custom element names have a hyphen in them, because standard HTML elements will never have those, so browsers know which ones are custom. ES6 also offers a way to do this, possibly better, ES6 Classes.
Shadow DOM: hide complex markup inside an element. This works by creating a shadow root (createShadowRoot()). Little agreement amongst browser vendors about other features than the createShadowRoot function. Still a lot to be defined.

Custom elements in Web Components bring a lot of responsibility, as they are empty in terms of accessibility, SEO and usability. With standard HTML elements, browsers have those things built in. With custom elements, they become the developer’s responsibility, Peter stressed. Potentially, there will be a lot of badly built Web Components once people start playing with them (like there are a lot of badly built jQuery plug-ins). The Gold Standard Peter mentioned may be a helpful checklist for how to build a Web Component and do it well. Peter also said we should use the UNIX philosophy: ‘every component does one job [and does it really well]’.

Peter said Web Components are good enough to be used now (but not for a business to depend on). He recommended using a library like Polymer for those who want to explore Web Components in more detail.

Responsive images

Jason Grigsby discussed Responsive Images, which has now shipped in most browsers and will work in others (IE and Safari) soon. His talk was about the why of responsive images. It has been designed to serve two use cases: resolution switching (best quality image for each resolution) and art direction (different image in different circumstances).

One of the puzzles around responsive images, Jason explained, is when to add image breakpoints. What dictates when to add an image breakpoint? Art direction might dictate breakpoints; this can be figured out and is mostly a design/art direction concern. Resolution might also dictate breakpoints, but this is much harder to figure out. How do we figure out how many breakpoints to use? In many companies, three breakpoints would to mind (phone-tablet-desktop), but that’s pretty artificial.

The ideal image width is the width it will have as it is displayed on the page. But in many responsive websites, images are sized with a percentage and can have many, many different widths, so often, some bytes will be ‘wasted’. So the question is: what is a sensible jump in file size? Maybe we should use performance budgets to make our choices about image resolutions? Important to note here, is that the larger the image, the larger the potential number of bytes wasted. That means we should have more breakpoints at larger sizes, as at larger sizes, differences are more expensive in bytes.

We can distinguish between methods that tell the browser exactly which image to use when, and methods that let the browser choose what is best. In most cases, Jason recommended, the latter is probably best: we just let the browser figure out which image to use.

Solving problems with CSS selectors

Heydon Pickering looked at making use of some powerful features of CSS (slides). He disagrees with those that say CSS is badly designed and should be recreated in JavaScript (‘pointless’) and showed in his talk how we can use the very design of CSS to our own benefit. CSS is indeed very well designed.

Most grid systems are not grid systems, they are grid prescriptions

Most grid systems out there, Heydon argued, aren’t much of a system. As they are not self-governing, they are more like grid prescriptions. Automatic systems can be done, using the power of CSS. Heydon suggested to look at CSS selectors as pattern matches. Matching containers full of content, we can look at how many bits of content we have, and let the browser come up with the best grid to display our content in. In other words: quantity queries. With nth-child selectors, Heydon showed how we can create a ‘divisibility grid’: looking at what your total amount of columns is divisible by, we can set column widths accordingly.

BEM-like conventions create order and control, but they throw out the baby with the bathwater by not using the cascade. The divisibility grid and quantity queries that Heydon create chaos, one might say, but as he rightly pointed out, this is in fact a ‘controllable chaos’.

Part 3: Jake Archibald, Ruth John and Zoe Mickley Gillenwater

The third segment started off with Jake Archibald, who talked about progressive enhancement in ‘apps’, followed by Ruth John who discussed a number of so-called Web APIs and lastly Zoe Mickley Gillenwater, with a talk about the many uses of flexbox on Booking.com.

Offline first

“A splash screen is an admission of failure”

Jake Archibald looked at progressive enhancement on the web, and showed how progressive enhancement and web apps are a false dichotomy. He emphasised it is indeed a great feature of the web that web pages show content as soon as they can, as opposed to last decade’s native apps, that often show a loading screen until everything you will ever need has loaded. On the web, we don’t need loading screens, yet some web apps have mimicked this behaviour. Jake argued this is a mistake and we can do better: ‘a splash screen is an admission of failure’. On the web, we can actually have users play level 1, even when the rest of the game is still loading in the background.

Jake Archibald making the case for progressive enhancement

Some web app slowness exists because all the required JavaScript is requested as one big lump, with a relatively big file size. Not a huge problem in ideal, fast WiFi situations, but quite a PITA for those with two bars of 3G on the go. Or for those accessing the web on what Jake referred to as Lie-Fi.

People may say all the JavaScript should download first, as it is a ‘web app’, and that this is how ‘web apps’ work, but that will not impress users. We can actually load the essential bits of JavaScript first and others later. Although this will decrease total loading time, it can hugely increase the time to first interaction. This is more important than overall load time: people will likely want to use your thing as soon as possible.

>A Service Worker can be put in place to make sure users can always access the cached version first, even when offline

After the first load, assets can be stored in cache. A Service Worker can be put in place to make sure users can always access the cached version first, even when offline. Whilst the cached version is being displayed, everything else else can be taken care of in the background, you can notify the user when it is ready. I felt this is a bit like offering your restaurant guests a table and some bread and wine, whilst you prepare their starter. You don’t have to let them stand outside until everything is ready, that would get them unnecessarily annoyed.

Service Workers, that allow for taking over the network management of the browser and thus for serving cache/offline first, can be used now. Not because they have support across all browsers ever made, but because they are pretty much an extra layer on top of your existing application. If your browser doesn’t understand this mechanism to get the app served from cache first, that’s okay, it will just be served a fresh version (as it would have been without a Service Worker). If it does, you can save your users from Lie-Fi.

Link: SVG OMG (load it, turn WiFi off, load it again, it still works!)

Web APIs

Ruth John talked us through various different Web APIs, or as she likes to call them: client side web APIs. She showed interesting demoes of Geolocation, which gives access to a user’s location if they give permission, including a ‘watch’ function that can update so that you could build a sat nav application, Web Animation, which offers the animation properties from CSS in JavaScript, the Web Audio API, that lets one manipulate audio amongst other things, and finally the Ambient Light API, that gives us the tools to do useful little improvements for our users.

Flexbox

Zoe Mickley Gillenwater works at hotel booking website Booking.com, which is a hugely flexible website, as it is served in many different languages and on many different screen sizes and browsers.

When designing for the web, Zoe explained, we can used fixed units like px, or relative units, like rem or vw. Relative units can be a useful ‘best guess’, let you be close to an ideal, and work in many different circumstances. Even better than flexible units, is designing without units at all. Flexbox allows you to do exactly this. It lets you tell the browser an element’s starting size and whether it can grow/shrink, and lets the browser figure out the math.

[Flexbox] does responsive lay-outs without media queries

Flexbox, Zoe showed, is great for improving whitespace and wrapping for better coherency in lay-out. It often does this better than floats, inline-block or table-cell, but can (and probably should) be used in conjunction with those, as they provide a usable feedback. It is also great for reordering: with its ‘order’ property, you can achieve visual improvements by setting an element to display in another place than your source order. Lastly, it does responsive lay-outs without media queries, as it will display within your constraints and figure out its ‘breakpoints’ all by itself.

Zoe pointed out that the interesting difference between flexbox and other CSS features, is not really code, but our way of thinking about lay-out. It requires a bit of a mental shift. Responsiveness, Zoe concluded, is not binary, it is a continuum, and flexbox can help making your site more responsive. You can make lots of small minor changes to your site, each of which can make it more flexible. Browsers will make use of those improvements if they understand them, devices will make use of them if they are smaller or bigger than usual (most of them are, but all in different ways).

Part 4: Rosie Campbell, Lyza Gardner and Aaron Gustafson

In the final part, Rosie Campbell looked at the future of web design beyond the screens as we know them, Lyza Gardner pleaded for generalists in the web industry and Aaron Gustafson presented his idea of what we should expect next.

Beyond the screen

Rosie Campbell from the BBC talked us through some of the experiments she was involved with at the BBC Research lab. She noted that screens will only get weirder, and urged us to think about designing for such screens that don’t even exist yet. How? Stay agnostic to underlying hardware, she recommended. And reconsider assumptions: we are used to designing with rectangles, but future screens may be round, or indeed have completely different sizes. We should not be afraid of constraints, but embrace them as they can fuel creativity.

Skillsets

Lyza Gardner talked about how the web designer/developer job has changed in recent years, and what that does to us as people that just try to work in the web industry.

The web used to be much simpler, Lyza explained. In the beginning there was no JavaScript, there were no stylesheets, even images hardly had browser support. These constraints made working on the web interesting. This has changed hugely, as we now have a daily influx of new frameworks, tools and methodologies to learn about, consider adopting and perhaps specialise in. Because there is now so much information about so many different things we can do with the web, working on the web has become quite complex. There is more than anyone can possibly keep up with. This, Lyza said, can make us feel down and unsure.

[Generalists] think and talk about the web with nuance

The web industry celebrates specialists, we adore single subject rock stars, but we should be careful not to dismiss people that don’t specialise, but generalise. Generalists, unlike specialists, cannot show off their specialisms on their CV, and may not be great at fizzbuzz, but they have other things to offer. They can think and talk about the web with nuance. They synthesise and when combining synthesis with their skills, show how valuable they are. When given a problem they have not seen before, they can synthesise and do it. Generalists are beginners over and over again.

We should be generalists, Lyza concluded, we should cultivate wisdom and share it.

Where do we go from here?

The day was concluded by Aaron Gustafson, who looked at what’s next. The A List Apart article Responsive web design, Aaron said, was the first to provide a concrete example of the principles of A Dao of Web Design (speaking of how valuable generalists are…). That article goes into the flexible nature of information on the web. Content created once, accessible anywhere, as it was envisioned by Tim Berners-Lee.

Accessibility is core to the web, and it goes hand in hand with the flexible approach John Allsopp and Ethan Marcotte describe in their articles.

Accessibility is core to the web, and it goes hand in hand with the flexible approach John Allsopp and Ethan Marcotte describe in their articles. Don’t make assumptions about how people want to access your website, just let them access it in any way they want, by providing solid mark-up of well structured content.

Accessible websites have a benefit in the future of the web. There will be more controls and inputs, like gaze and eye/facial tracking. Voice will play a bigger role, too. You may have provided CSS with your content to display it beautifully across devices, but those users using voice will not see that. They will just be listening, so it is of utmost importance that your mark-up is well structured and the source order makes sense. That it is accessible.

Responsive web design, Aaron concluded, is all about accessibility. It is about making things accessible in the best possible way.

Wrap-up

As may have become clear from my notes above, Responsive Day Out 3 was a day full of variety. I had the feeling it could have easily been called Web Day Out, and I guess that makes sense, as responsive web design has naturally grown to be a pleonasm in the past few years.

I found a couple of common themes throughout the talks:

Let the browser figure it out. Throw multiple image types/resolutions at it, and let the browser decide which one to display, as Jason explained. Or like Zoe demonstrated, tell the browser roughly how you want your element to be with flexbox, and let the browser figure out the maths. Give it some relatively simple CSS instructions, and let it grid your content for you, as Heydon did.
Soon, we will be given more responsibilities. As Peter noted, Web Components will let us define our own components, which makes us responsible for setting up their usability and accessibility. Service Workers, as Jake showed, put us in control of network handling, so that we can decide how to handle requests (and respond to them with offline/cached content first). If we use Web Components or Service Workers, we explicitly choose not to let the browser figure it out, and provide our own algorithms.
Responsive web design is all about accessibility. Although it is hard to make a business case for it, accessibility is very important, as it is a core concept of the web, as Aaron mentioned, and, being mostly device-agnostic, our best bet at future proofing content for screens that don’t even exist yet, as Rosie pointed out.
Make things as flexible as you can. Good responsive design makes things very flexible. Flexbox and the non-binary improvements it creates, as Zoe discussed, make sure things work in many places at the same time.

Originally posted as Responsive day out 3: the final breakpoint on Hidde's blog.

[email protected]?subject=Reply%20to:%20Responsive day out 3: the final breakpoint">Reply via email

What kind of Web Components do we need?

2015-07-02T00:00:00Z

Web Components will allow web developers to create their own elements: custom elements. Last week I attended the Web Component panel and accessibility break-out at Edge Conference, and left both sessions full of questions. One was: what kind of custom elements do we need?

The idea of Web Components and specifically their custom elements, is that you no longer depend on the browser to provide you with elements: you can bring your own. Many blog posts about the subject emphasise how exciting this is. Yes, this is exciting new tech. It gives website owners lots of freedom, but also a big responsibility. I think Web Components have their use case for the web at large, but I can’t help but feeling that for many websites, it will be too costly to create and unnecessary to use custom elements.

Existing HTML elements come with benefits

Many of the existing, standardised HTML elements come with semantics, and browsers can do all kinds of smart things with them. Some examples:

The <select> element lets a user pick one option from a list of options. Every browser can decide how to represent this best. My phone shows a fruit machine style thingy, an old-fashioned Windows style selector is shown on old Windows machines, and easy to recognise for users of such machines. A future version of Siri may be able to talk us through the options, in fact, some assistive technology already does this.
The <video> element lets a developer point to a video, or indeed a couple of videos in different formats. The problem of how to play the video is then solved by the browser. Each browser chooses the best video player it can offer, and lets the user watch the video in it.

With existing HTML elements, the browser takes care of a lot of your accessibility, usability and design.

Custom elements come with responsibility

Contrary to most existing elements, a <custom-element> is much like a <div> : it has no meaning to the browser, so browsers have nothing built-in to deal with it. It doesn’t expose to the accessibility tree, has no usability or default appearance. Indeed, this is what a component creator has to take responsibility for themselves:

accessibility / semantics
usability
what it looks like

For each platform.

The Gold Standard gives a great checklist for making Web Components “to be as predictable, flexible, reliable, and useful as the standard HTML elements”.

To increase a component’s accessibility, one could provide meaning through ARIA roles and properties. Or, if we use native elements within our components, we can have our cake and eat it too: when embedding existing elements, you would inherit their benefits. I have not been able to find a definite resource confirming this can be done.

It is probably not easy to create a custom select or date picker that works as well as its native equivalent.

To provide usability, you would have to provide ways to interact with your element for whichever method your user chooses (or is forced to use by personal or indeed corporate circumstances). This is hard, because in most cases, as a website, you do not know a lot about the circumstances under which you are accessed. It is probably not easy to create a custom select or date picker that works as well as its native equivalent.

Design means designing for many different contexts: phones, watches, desktops, etc. And there are probably going to be contexts that we currently don’t know of: a future fridge with a web browser will probably know how to most suitably render a <select>, but it will not know how to deal with your <custom-datepicker> .

Chris Heilmann once said it makes sense to use what already works and build on top of that. I think this applies to custom elements, too. They would only have benefit, if they combine existing elements to bring something we need that does not exist yet.

Does building Web Components sound complex? In the Web Components panel, Google’s Alex Russell noted that “tooling will save you”. Tools can make it much easier to build better Web Components, for example by making them render both on the server and the client for progressive enhancement. But aren’t tools the problem?

Benefits of Web Components

Web Components are not just hard to build well, there are also many benefits to using them.

With Web Components, browsers (will) give website owners the power to bring their own elements. This gives a lot of freedom and is a big addition to the web as a platform. It is innovation we should welcome.

Web Components also bring developers the convenience of style/DOM encapsulation: if you work on a custom element’s CSS, you know it is only going to apply to that component.

Thirdly, a Web Component can be very portable: once you have created a <custom-element> and built all its behaviour and style, you can then use it where you like. As Peter Gasston noted in the EdgeConf Slack channel, “[They take] more effort to build, less effort to use”.

A fourth advantage of Web Components is for search engines: they can potentially start recognising widgets if they are used enough throughout the web, which would improve their search result listings.

An additional benefit of Web Components as a project is that it helps find missing platform APIs (a fascinating project by Domenic Denicola).

What kind of custom elements do we need?

In summary, custom elements can be good for the web as a platform, for developers and potentially for users, too. But building custom elements that are accessible, well-designed and easy to use on all platforms, is not going to be easy, or cheap. So what kind of custom elements do we need?

Building custom elements that are accessible, well-designed and easy to use on all platforms, is not going to be easy, or cheap

Some say custom elements will be a bit like jQuery plug-ins: you need a carousel in your page, but instead of building it yourself, you peruse a third party carousel. You want your content to appear in tabs, so you go and use a third party tabs script. Instead of borrowing someone’s CSS and JS, you borrow their <fancy-carousel> or their <the-ultimate-awesome-tabs> , which have their styles and scripts nicely hidden inside their Shadow DOM. We should take care choosing only properly built ones. Also, we should be careful not to repeat the “just another plugin doing $x” mistakes.

I have the feeling that custom elements make most sense for huge companies that have many different websites and apps that have or should have shared elements. Google, who came up with Web Components, have a search engine, maps, Word processing tools, online storage, a social network, an operating system and many other products. It makes lots of sense for them to want to share many of their controls across their products. And they have plenty of designers and developers available to work on the usability, accessibility and design of such components, so it is more feasible for them to do it well (and even they do not have unlimited time and resources).

The same probably goes for big social network enterprises like Twitter and Facebook. They could create things like a Twitter timeline widget for people to embed in their site. Currently, I advise clients against using those, as they come with privacy and performance issues. If offered as a custom element, these issues might still be there, but now buried away in the Shadow DOM. Instead, offering the data as JSON, as Twitter used to do, would probably be more helpful for developers. But I guess that would add less value for Twitter’s shareholders.

Or perhaps media organisations like the BBC. Their video player seems a huge part of what they do, so they might have time to work on a custom element for it, that plays video exactly in the way they need it. For their own site(s), they have many, or perhaps for people to embed elsewhere.

Web Components could also bring a big benefit to people that create ‘apps’, websites where people go to do stuff, or maybe even games. They might need very specific controls, that do not exist in browsers yet.

How about smaller sites?

I’m not sure about the use case for smaller websites. One of the messages of Web Components seems to be that we can soon control style and behaviour of all the elements. But that’s not the full story: it is also very hard to do it well. I am afraid we will end up with lots of badly built components, if we do not tell the full story. What if web agency clients start asking for cool, custom-designed and custom-behaving components, and the teams tasked with creating them do not have the budget to meet the Gold Standard? Should we instead trust the capabilities of larger, Bootstrap-like projects, and use their components?

What if web agency clients start asking for cool, custom-designed and custom-behaving components, and the teams tasked with creating them do not have the budget to meet the Gold Standard?

Some have suggested Bootstrap and Foundation should start converting their components into Web Components, but I fail to see how that would solve a problem people actually have. It would be interesting to do it as a research type of thing, but to make them the main way to use Bootstrap or Foundation components just feels wrong.

I’m not convinced either, that every company should come up with custom elements for all the things, just because they can. Most elements can be built very well with existing HTML, without costing as much design and development time. I feel many web projects will hardly have a use case for utilising custom elements, or the budget for creating them. They would overcomplicate things. It still feels like eating a 5 course dinner when all you wanted was a salad.

I hope Web Components will get used by those companies that have genuine use cases for which the current set of HTML elements cannot provide. That will help push the web forward, and potentially add new ways of interacting with the platform. We are given the chance to add new elements, before WHATWG, W3C or browser vendors have the time to do so. Or the chance to create elements that would not be suitable to be part of the web standards, yet very useful to one organisation’s strategy. But before that can happen, what we need most is agreement amongst browser vendors.

So, what kind of Web Components do we need? Well-thought-through additions to the existing set of HTML elements, solving problems that aren’t solved by existing elements: yes, please. Many variations on improvements of existing elements like checkboxes and selects? As far as I am concerned, probably not. New elements built without considering accessibility or the huge diversity of browsing contexts? No, thanks.

Update 03/07/2015: Peter Gasston points out on Twitter that a lot of potential value is in the use cases we haven’t thought of yet. This is probably true, I may have to adjust my view when such cases arrive.

Originally posted as What kind of Web Components do we need? on Hidde's blog.

[email protected]?subject=Reply%20to:%20What kind of Web Components do we need?">Reply via email

Offline apps and user intent

2015-07-19T00:00:00Z

The next problem being solved for the web is not having the network: apps that work offline. I think when designing such apps, we should consider user intent, and in particular what a user intends to be available offline.

Web apps that work offline will download themselves into a user’s cache: their assets, their core app code, et cetera (see also: service worker). When the app itself is offlinified, the next choice is: which content should we make available offline? I think we should consider letting our users decide.

My newspaper app lets me download newspapers and requires no further connectivity once the download is completed. As a user, this allows me to download a newspaper to my tablet before I leave home, take a seat in a local train and start reading. Great for commuting. It lets me not worry about the network. In theory, my tablet might have 3G, or could connect to the train’s WiFi system. In reality, that would probably result in me struggling to get any data when the train is in a tunnel, or trying to battle the train WiFi’s registration page. The alternative, downloading the paper on my home WiFi, which I know works, is much better. For this to go smoothly, it is crucial the newspaper app has a ‘download for offline usage’ button.

A music subscription service I use, offers me the ability to have some music available offline. I use this feature a lot. If I need to catch the airport bus, I want to listen to that new album that came out. I know which. If I’m going for a long drive, I might make a playlist to listen to whilst driving in the UK’s beautiful, but not always well-networked country side. I create the playlist at home, and want it to be available on the go. So I think my music app with offline capability should let me choose what to make available offline. Spotify has a toggle that sets playlists to ‘available offline’, but it does not have UI to let a user download specific music (it behaves more or less like a hint). It will decide, based on how much connectivity and storage the device has. This makes sense, as often connectivity and storage are big uncertainties for the developer that builds the app, but it gets in the way of user intent.

Some apps choose to offlinify the last x items (eg a news site), or the content that the user has visited (eg an encyclopedia). The latter is a form of user intent, the former is unrelated to it. Naturally, depending on context, these can be a good strategies, too.

For the news and music player examples, honouring user intent can hugely improve a user’s experience. It may very well be possible to let the app decide what to offlinify when, but maybe your user just wants a particular thing to be offline. Today’s newspaper. Or, for that matter, last Tuesday’s issue, because their grandmother appears in it. This artist’s new album. This episode of that podcast. This A List Apart article.

Technically, it is far from trivial to do for a web app. Without going into too much detail: you don’t know if your user/their browser will have cleared their/its cache, or how much storage they have available.

In summary, I think if our app makes itself available for offline use, we should consider giving our users a choice in which content to make available offline.

Originally posted as Offline apps and user intent on Hidde's blog.

[email protected]?subject=Reply%20to:%20Offline apps and user intent">Reply via email

The role of grid systems in component-based front-end builds

2015-12-08T00:00:00Z

Grids… for long I have thought they are the trivial bit in front-end development. Many sites do not have much variation in column widths, so to use a ‘grid system’ would be a clear violation of the KISS principle. Now I think complex grid systems can be of great use in component-based front-end builds.

Note that the following may soon be obsolete, when we start describing layout in CSS using CSS Grid Layout (not widely supported at the time of writing)

My view is this: for large websites and organisations, in addition to having a component system, it makes sense to have one agreed-upon, shared-between-projects grid system.

What is a grid system?

By ‘grid system’, in this article, I mean a set of CSS rules written for the purpose of declaring grids in mark-up. These can be hand written, or generated by preprocessors (in which case they can be generated with custom options to fit a project better). Some agencies I worked with have rolled their own. Others use an open source one, such as Bootstrap’s.

Spanning columns through classnames

In this kind of grid system, grids are declared using classnames on HTML elements. Usually classnames are given to each row of columns, and then to each column within that row. A grid has a number of ’virtual’ columns (e.g. 12 or 16). Specific elements span a number of these virtual columns, e.g. a main column could be the first 8 out of 12, then the sidebar could be remaining last 4. In mark-up, classnames of each actual column determine how many virtual columns are spanned.

Complex structures full of features

Grid systems are, more often than not, convoluted structures of code. Not only do they contain percentages for any combination of columns imaginable, they often also have options to ‘skip’ columns, so that an element can start spanning columns after the columns it has skipped. Many also contain percentages per breakpoint, so that you can have different sets of columns per breakpoint. This results in many classnames; time consuming to write, or if generated, buried away in your preprocessor output.

As opposed to the introducing-columns-when-required approach

Note that there are other ways to go about columns and widths in websites. You could just add CSS rules for each grid variation required (eg, you would be done by just writing one for doubles, one for quarters, and perhaps one for three quarters). This is how websites have been built for a long time. I used to prefer this approach — depending on the project, I sometimes still do. It uses a lot less CSS and is very KISS.

How do they fit in component-based front-ends?

The cool thing about component-based front-ends is that none of the component code is committed to specific widths. The width of a component is determined by the container it happens to exist in. Or, if it does not sit in a container, by the window or viewport width.

If your team decides to build pages using a grid system, this is their role: they force what the width is of any components that occur in the page.

To have a super complex grid system, with perhaps more classnames generated than you might actually need, requires clear advantages to be worthwile. The amount of classnames comes with weight: Bootstrap’s default grid system is 8KB (minified). Yet, advantages do exist:

Separation of generic, reusable components and specific, non-reusable widths

You don’t want the development of a new component to involve widths, the width of things will be decided in the context of the page grid and the viewport it exists on. Therefore, a separation between things and their widths makes sense. If the grid is separate, it makes sense to be a powerful (or complex) system that fits many cases, rather than something that is decided case by case.

Great for teams in agencies or organisations

As a team (in an agency or elsewhere), it makes sense to use the same grid system or grid system generator for all projects, with only changes to their setup (eg number of columns, nature of breakpoints). This is not about developer convenience, it is about organisational consistency. You’re making sure all teams in your organisation do the same thing with their widths, just as they do the same thing with their components.

Conclusion

The main benefit of an agreed-upon, shared-between-projects grid system is this. For an organisation, a great level of consistency can be achieved if widths in all of their sites come from one system (just as it helps if components for all of their sites come from one system).

Does that mean I think one grid system will fit all? No, adjustments are probably required sooner or later. That would mean new versions of ‘the grid system’ would get released. All projects within an organisation would be using ‘a’ version of ‘the grid system’. If this happens to be not the most recent version, the project team can decide whether to update to the latest version or not.

Originally posted as The role of grid systems in component-based front-end builds on Hidde's blog.

[email protected]?subject=Reply%20to:%20The role of grid systems in component-based front-end builds">Reply via email

Declaring grid layouts with ‘just’ CSS

2015-12-16T00:00:00Z

CSS Grid Layout has been coming for a long time, browser support seems to be on its way (at last!). This is great news! It means we can soon use ‘just’ CSS to describe our lay-outs. But, arguably, this leaves us with a naming problem.

‘Just CSS’ vs classnames for lay-out

In the current situation, many lay-outs on the web work with a combination of classnames-for-layout-purposes and CSS to go with it. In the future, with CSS Grid Layout, classnames can just declare what a thing is. They then leave it to CSS entirely to describe how the thing is layed out. As Rachel Andrew points out in her recent 24 Ways article, this may mean the end of container, row and col-* type of classnames:

(…) my hope is that it will be the layout frameworks that tie our design to our markup. They have been a necessary placeholder while we waited for a true web layout system, but I believe that in a few years time we’ll be easily able to date a website to circa 2015 by seeing <div class="row"> or <div class="col-md-3"> in the markup.

CSS Grid Layout is awesome, because it would provide web page layout with a separation that the makers of the web always encouraged authors to follow:

HTML is for what it is (structure)
CSS is for what it looks like (style)

But I feel that this leaves us with a problem not easily solved: how can we sensibly sname page areas? In examples of Grid Layout, there is usually a header, main content, sidebar and a footer. In reality, there can be lots of different combinations of column widths. There are usually many variations, possibly more than we could possibly come up with classnames for.

Naming page areas

When using classnames-for-layout-purposes, page areas are defined by presentational classnames that do not require further naming. We just name the components inside the containers, and give their wrappers/containers presentational names to form a grid structure.

If we want to peruse the semantic classnames we have added to page areas to lay things out, we’ll need to give them sensible names. We can then apply grid CSS to each of them (and could do this reusably/automatically by clever preprocessor usage).

My argument is that coming up with such names could prove quite hard: what’s a thing called that has a 35% column and a 65% column, in which the latter column is divided into four? Arguably, names like col-6, or even col-md-6 are easier to work with (and yes, I’ve frowned upon them for long).

Making it easy to work with is probably what we are discussing here. It’s mostly an issue between developers, for the browser or user doesn’t experience what we call things. They can benefit from separation between semantic usages of HTML elements and separation of concerns generally, but classnames aren’t read out by screen readers (like a title attribute), used to construct the accessibility tree (like some attributes are) or linked to by users (like IDs).

Conclusion

So I think there are two views, really. Some will argue we should think of our grid as a system separate from the rest of a site’s front-end, and as a thing that we can leave for months without touching it. In this case, when regarded as a separate thing, presentational grid classnames are seen as okay. Others will say grid-structures should just arise from grid definitions that belong to each semantically classed component. Especially for those, CSS Grid Layout will make it a lot easier to do this.

Originally posted as Declaring grid layouts with ‘just’ CSS on Hidde's blog.

[email protected]?subject=Reply%20to:%20Declaring grid layouts with ‘just’ CSS">Reply via email

Scripts and stylesheets in WordPress sites

2015-12-23T00:00:00Z

WordPress is used by many different audiences. It is used by people who do not know much about code, as well as by experienced programmers¹. Expectations of plug-ins therefore vary.

Some want plug-ins to automatically do everything. If they use a plug-in to integrate their Twitter stream into WordPress, they expect the plug-in to not only pull tweets from the Twitter API, they also want the necessary mark-up and CSS to display tweets in the front-end. Others will only expect a plug-in to do a specific task, leave front-end hooks for developers to output data surrounded by their own mark-up, styled by their own CSS and made interactive with their own scripts.

My ideal WordPress plug-in is of the latter type. I write my own templates (mark-up, stylesheet and scripts). Then, in the mark-up, I simply replace all dummy strings of text with template tags. My ideal Twitter plug-in, for example, would take care of fetching tweets from Twitters API, and it would then expose an API to output tweet data (the tweet itself, its date, its author, avatars etc), allowing a developer to output the relevant strings of text where required.

When I add a new plug-in (or a client requests one to be installed), I have made it a habit to make sure it does not add any CSS or JavaScript (plug-ins can add assets through wp_head() and wp_footer()). If it does, I usually undo the behaviour and add CSS or script to fit within the existing code.

¹ And some experienced programmers will never touch WordPress (different discussion)

Originally posted as Scripts and stylesheets in WordPress sites on Hidde's blog.

[email protected]?subject=Reply%20to:%20Scripts and stylesheets in WordPress sites">Reply via email

JSCS vs JSHint

2016-01-05T00:00:00Z

JSHint helps you enforce code correctness, whereas JSCS helps you enforce a code style.

JSHint is deprecating its code style related features and plans to remove them from the next major releases (see docs). Therefore, it makes sense to use both JSCS and JSHint. (Thanks Alex for pointing me at this)

Originally posted as JSCS vs JSHint on Hidde's blog.

[email protected]?subject=Reply%20to:%20JSCS vs JSHint">Reply via email

The website as an instantiation of your design system

2016-01-19T00:00:00Z

In his talk at Beyond Tellerand last year, web designer Brad Frost talked about the website “as an instantiation of your design system”. I really liked that idea.

Design can be defined by many things: it is a thought process, the result of abstract thinking, something that requires research and a sense of style. From a practical point of view, it can be described in terms of the materials it is made of. Paint, wood, glass, ink… This is slightly different for web design. Web design, in particular, is made of some very specific materials: HTML, CSS, JavaScript, typefaces and images.

Design on the web, more than any other type of design, can be documented in a way that is powered by the materials it is made of. Pattern libraries can do this.

Pattern libraries

A pattern library is a set of components, in which each component can include:

Documentation
Mark-up in HTML (or Twig or Haml or Mustache)
Style in CSS (or Sass or Less or Styles)
Scripts in JavaScript (or Coffee Script)
Images

Each component has at least documentation and mark-up.

The set of components, as a whole, describes the design system that exists in your website. The components, plus perhaps a couple of files like typefaces, a logo and an icon set (although they could be components of their own).

Advantages

The advantages of separating your design system out as front-end components are plentiful:

great reference for all people involved in the project
potentially a better workflow, as there is only one place where common patterns are created
easier to spot and avoid inconsistencies in both design and code (‘Oh wait, we’ve already got a datepicker!’, ‘Actually, we can reuse most of that existing markup for this new button style’)
more testable as everything is abstracted and nicely separated and organised, this makes it easier for a script (or anyone) to test

Zombie style guides

To create a style guide as an overview of your website’s design system and the corresponding code is one thing. To maintain it, is another. In her Fronteers 2015 talk, Anna Debenham referred to a phenomenon known as zombie style guides, style guides that live separate from the web project they power, and are not actively maintained. They are no longer as useful as they were at the start of the project.

To avoid that, a style guide should be what powers your actual website(s), so that your website(s) become instance(s) of your design system.

The website as an instantiation of your design system

This is what Brad Frost suggested in this talk at Beyond Tellerand in Düsseldorf (Video, scroll to 39:00):

“The website is one instantiation of your design system”

I think this brilliant. In the ideal set up, there is a set of components, and then those components are used in places. The set is built, updated, improved, refactored etc separately from the places it is used in. The website, but also a front-end style guide are just examples of places.

Brad quotes Nathan Curtis:

“A style guide is an artifact of design process. A design system is a living, funded product with a roadmap & backlog, serving an ecosystem.”

Copy/pasting mark-up vs “real” instantiation

One way a website could be an instantiation of a design system, is if all markup in the site is copied from the style guide. The copy/paste method is easiest to set up.

A much better and more ideal way, is if the site uses code to grab a copy of the actual markup for a component. This markup could live in its own repository so that it can be modified, refactored and improved. For example:

includeMyComponent('button', { text: "Click here" })

could render as this today:

<span class="button">Click here</span>

and render as this tomorrow, after an update to the component library:

<button class="button">Click here</button>

New mark-up, same include function.

The holy grail, Frost concludes, is a “magical setup” that contains “all the lego bricks of a site”, and if we make a change, anywhere that lego brick is updated, it just magically updates. Like the example above. Ian Feather and his team at Lonely Planet have built a system that can do this, with their API for components.

The front-end style guide

The front-end style guide, like the website, can also be seen as an instantiation of the design system. It is just another place that consumes your organisation’s set of components.

Documentation

There is one important difference though: a front-end style guide should, in my opinion, serve as documentation. So not only should it consume the components themselves, it should consume components with their documentation.

The person who builds a component, will have to write its documentation. This is essential, as a few month’s later, they may have left the team. Or they may still be on it, but have forgotten about what the component was for.

Documentation of a component should explain what it is, what it is used for and what its options/parameters are.

Conclusion

To summarise my thoughts: I think web design is a special type of design as it can be documented with the same materials it is made of: markup, stylesheets, scripts et cetera. This can be done by structuring the design in the form of a system of components. This system can then power both the website and a showcase of documented components. Statically, or, ultimately, dynamically.

For more info on different types of style guides and approaches to building ones that ‘live’, I can recommend watching Anna’s talk at Fronteers and Brad’s talk at Beyond Tellerand:

Anna Debenham – Front-end Style Guides (Fronteers, Amsterdam, 2015, includes transcript so you can read instead of watch)
Brad Frost – Style Guide Best Practices (Beyond Tellerand, Düsseldorf, 2015)

Originally posted as The website as an instantiation of your design system on Hidde's blog.

[email protected]?subject=Reply%20to:%20The website as an instantiation of your design system">Reply via email

Making conference videos more accessible

2016-01-21T00:00:00Z

If conference videos are made more accessible, they can be shared with a wider audience. This is a great way to add value! Most Fronteers 2015 videos are now available with captions and transcripts. In this post I will explain why we did it, how we got our transcripts made and what happened next.

At Fronteers, we have had our videos transcribed in the past 2011, 2012, but it was quite a time-consuming process and we’ve not always been able to find volunteers for it. In recent years, the process has improved a bit, so this year I thought it would be good to have them made again.

What and why

To make a video more accessible, WebAim recommends having both captions and transcripts.

A caption is like a subtitle, but in the same language as the video. It contains whatever is said in the video, and other sounds, such as laughter, applause and description of any music that is played.

A transcript is a textual alternative for audio and video. On the Fronteers site, we use the content of the caption file and display it underneath the video.

Captions and transcripts can benefit:

people with partial or total inability to hear
people for whom the video’s language is not their first
people who do not have time to watch the video, prefer reading it or want to search for a specific thing a speaker said
people watching the video in a noisy environment
your website’s SEO optimisation strategy for search engines1! (really)

Amara via Vimeo

For our transcripts this year, we have been making use of a service called Amara. It is integrated into Vimeo, which makes the process of ordering very convenient (we host our videos there).

We used Amara’s paid service, but, at the time of writing, they also give users access to their editor on Vimeo, so that they can DIY the transcripts. Or you can access the same tool on Amara.org and subtitle videos hosted anywhere (many formats supported). Both are free, but cost more time per transcript.

Amara is bigger than just their Vimeo integration: they are a project of a not-for-profit organisation that aims to ‘build a more open, collaborative world’. In this post I will focus on how to do it with the version built-in to Vimeo.

The process

The Amara service can be used from within Vimeo. The way it works is that, as the uploader, you go to your videos’ settings and under “Purchase Amara professional services”, you click “Purchase”. You then select the language that you require, choose a price tier and enter payment details.

You can also add a comma separated list of technical terms, to make sure the transcript reflects their spelling correctly. As an experiment, I decided to leave this field empty.

Purchase button on Vimeo

After submitting a video for transcription, each one took 3-6 working days to show up. The week after I had ordered them, they kept slowly coming in, giving me the time to check each one (see below). The quality was surprisingly good, with only very few minor corrections needed. This was despite not supplying a list of technical terms.

When we were happy with the transcript, we also uploaded the video to our own website, where we included:

the video (as a , obvs)
the subtitle file as captions (a )
the transcript (which in our case was just the captions file as text)

(Example: Digital governance by Lisa Welchman)

In the front-end outputted by our CMS, Krijn built something nifty to make it so that when you click a sentence in the transcript, the video skips to that part of the talk. Check out the example above to see it in action, it is very cool!

If you want to do something similar, it is good to know that the caption that shows up in Vimeo can be downloaded as a WebVTT file. This is ‘just’ a text file with time stamps and sentences, so it can be opened and updated in a text editor of choice.

QA

In our case, we paid for our transcripts. The results were very good, and almost ready to go live. Just before that, I have gone through a few steps manually for each transcript:

search for [INAUDIBLE] and have a listen to see if it really is inaudible. Sometimes it was added when the speaker said a technical term very fast (gulp.js, console.log())
search for [?, these are words that the transcriber was unsure about. Again, these could be technical terms. If the video is about web development and you’re a web developer, you can likely fix it.
scroll through and gloss over the text

!/_images/vimeo-amara-.jpg(Amara interface on Vimeo)! Amara’s handy interface to check and adjust your captions

Some notes

At the time of buying, Basic, Professional or Full Service captions were priced at $1.70, $2.80 and $3.95 per minute respectively (difference is in how many proofreaders are used), so it is not very cheap. A conference video (45-60 minutes) will cost between $100 and $150.
From the Vimeo interface, you cannot get all languages transcribed. Our conference videos were in English, which was supported. Many of our meetup videos are in Dutch, which is not supported.
I was amazed at how good the transcribers were at getting technical terms right, words like SVGOMG, Sass and JavaScript were spelled and capitalised correctly and consistently so. Ideal for when pedantry does occur within your target audience!
Using Amara’s “Professional” tier, leaving the technical terms field blank still gives great results
We used Casting Words in the past, they work out slightly cheaper and offer integration with FTP and an API (but are not built into Vimeo)

So, that’s it. I hope this helps conference organisers in deciding whether and how to transcribe their conference videos. If you have experience with other services or workflows, please do leave a comment below.

Edit 26/01/2018: unfortunately, it is no longer possible to do the above through Vimeo.

Originally posted as Making conference videos more accessible on Hidde's blog.

[email protected]?subject=Reply%20to:%20Making conference videos more accessible">Reply via email

Turning off Heartbeat in WordPress made my day!

2016-02-08T00:00:00Z

Heartbeat API is a thing built into WordPress that sends a POST request every 15 seconds. It allows for interesting functionalities like revision tracking, but can also dramatically slow things down and even block editors from editing content (if your connection is quite slow).

The “Edit” pages in WordPress use the Heartbeat API to detect connection loss. If they detect you’ve lost your connection, your ‘Update’/‘Publish’ button will get disabled until your connection is back.

Why?

“Connection lost” message on slow connections

When I was working on a WordPress site this week, I accessed the internet through my 3G MiFi, and added a VPN for security (the less glamorous side of working remotely). It resulted in seeing the ‘Connection lost’ message all the time. It would usually appear before I could make any changes, and never disappear. In which case it stopped me from editing content.

! The error message

High CPU usage

Others comment that Heartbeat leads to high CPU usage: imagine having multiple instances of WordPress edit pages open in a browser, each sending its own POST requests every 15 seconds.

Turning Heartbeat off

Only when I just turned the whole thing off, I was able to make changes to my page. Turning Heartbeat off can be done by simply deregistering the script:

add_action( 'init', 'remove_heartbeat');
function remove_heartbeat() {
 wp_deregister_script('heartbeat');
}

(via Aditya Nath Jha

Originally posted as Turning off Heartbeat in WordPress made my day! on Hidde's blog.

[email protected]?subject=Reply%20to:%20Turning off Heartbeat in WordPress made my day!">Reply via email

World IA Day 2016 in Bristol

2016-02-20T00:00:00Z

This weekend I attended World IA Day in Bristol. The event is organised simultaneously in 61 locations across 31 countries. The local one was put together by Nomensa, an awesome Bristol web agency whom I had the pleasure of freelancing with for 3 months last year.

The day offered a variety of talks: some more philosophical, others more practical. The overarching theme of the day was ‘information everywhere, architects everywhere’. Talks focused on what architecture is (and whether ‘architecting’, as Kanye West used it, is indeed a verb). It was about what it means that in the digital age, information can really go everywhere.

Simon Norris - From taxonomy to data and beyond

Simon’s talk gave us an interesting overview of the history of information architecture (IA). According to Simon, four paradigms characterise the development of IA: Classic IA, User-generated IA, Pervasive IA and Inversion. He related each one to a change of context.

First spoken about in the sixties at companies like IBM, the discipline of IA started with the popularisation of the phrase by Richard Saul Wurman, and the publication of the book ‘Information Architecture’ by Morville and Rosenfield, also known as the Polar Bear Book.

Simon considers IA as a ‘sister’ discipline of UX (separately, like chemistry and physics are separate disciplines). One does not supersede the other, they work together. IA is about the blending of the immaterial and the material, Simon said. In this view information itself is completely shapeless, and giving it shape is what IA is about.

Simon discussed these four waves of IA:

Classic IA - Context: the web was quickly becoming the most popular technology ever. Classic IA was about what to equip designers with to make sense of all the information that needs to go on a website. Simon said that for him, Classic IA was about defining taxonomies to aid the design of websites that support human decision making.
User generated IA - Context: the web had become a global phenomenon in many ways, it was bigger than what anyone expected. Another shift happened: User generated IA. It was almost the opposite of Classic IA: it was user orientated not designer orientated. Users were enabled to make their own taxonomies and with that, shape their own experiences. Example: delicio.us (now Delicious), the bookmarking website, lets users save URLs and manage them within taxonomies like tags and categories.
Pervasive IA - Context: people started to use computers everywhere. It was no longer a discrete activity, computing had become ubiquitous, and interaction started happening ‘cross channel’. IA was no longer about labeling and hierarchies, it became about sense making and place making. Resmini and Rosati wrote ‘Pervasive Information Architecture’. IA now had to consider changing and emerging experience across channels.
Inversion - Context: digital is now influencing the physical world. The fourth wave is about ‘inversion’. There is now so much data, ‘big data’, that we could do analysis on, that we are urged to look at information in a completely new way, Simon said.

Simon recommended reading “A brief history of information architecture” by Resmini/Rosati (PDF).

Shaula Zanchi - The world is greater than the sum of its parts

Shaula works in ‘physical’ architecture and talked about how internal information is managed at her company. For each project there is a lot of information that they need to keep track of. One example of information is keeping track of samples used in the architectural process: which they had, where they were, where they came from, et cetera.

They began making sense of their information and the relationships within it through a spreadsheet. Then they started using a database with some PHP, as a kind of Excel plus. They then started adding layout kind of things to what they had, so that it could look and feel more like what they now call Sample Library. It all became part of the bigger intranet project.

A very interesting case study!

Team BBC

The next talk up was by what Simon called “Team BBC”: four smart people involved with the BBC’s information architecture.

Dan Ramsden talked about blending the day’s theme, ‘information everywhere’, with another: ‘uncertainty’. At BBC, he said, they literally have millions of pages online. This is a lot of content and information. The ratio of content producers to designers is roughly 83:1. Projects vary from simple projects with a clear direction and scope to more complex ones, with many uncertainties. Information architecture helps them hugely with these challenges. The most important IA adds to the BBC, Dan concluded, is that by defining a structure, we create meaning.

Luisa Sousa then talked about joining and becoming a User Experience Architect at the BBC. When she first started, she explained, Luisa felt like being in a box where she couldn’t move or see much. On her first project, a new website for GEL, she learned to stop worrying about the word ‘architect’ in her job title, and to start being involved as a problem solver, master of questions, designer and jelly bean eater. From her talk, I understood good information architects are able to put on many hats.

Barry Briggs talked about practical aspects of being a user experience architect. He emphasised how complex IA work can be, as there are many gaps between bits of information. He showed how flow charts can help. Not only do they help verifying IA work with stakeholders, they also help with dividing stakeholdership across different parts of the chart. Letting team members and stake holders be involved with specific parts of the flow chart, also aids working in parallel, Barry explained.

Lastly, Cyrièle Piancastelli talked about advocating for UX at BBC. The best user experience, she explained, enables innovation, is an investment and is essential. The best way for user experience (and perhaps information architecture). At the BBC, as Dan also mentioned, there is lots of good content. When you are already sure about your content, the thing that you can make a difference with is how your present it, said Cyrièle. With good IA, we can make a difference.

Karey Helms - Making the invisible physical

Karey talked about how to make sense of complex data driven systems to design enterprise solutions. She discussed what makes enterprise UX so challenging and what physical prototyping is, and showed us some cool example projects.

One of the major challenges Karey’s company had, is that many of their users are ‘situationally disabled’. Whether they are potentially under stress (healthcare patients) or wearing gloves (when working in a warehouse): they can be in complex situations, and interfaces need to be designed appropriately. I think this goes for users outside enterprise as well: we should always design for circumstances that we are aware or unaware of.

Physical prototyping or model making, Karey explained, is used by her company to identify what ‘core components’ of a project are, to situate things in context and to explore interaction modalities.

Karey showed some great and personal examples:

the ‘party mode’ on her website that corresponds with a Philips Hue light on her desk. Information, she concluded from this project, is emergent, part of an ecosystem and not a fixed modality.
the ‘burrito’ bot: it analyses use of emoji in personal communication between her and her husband, and then reports who the weeks’ best spouse was at the end of each week. From this she found that information has a large role in the design of systems, but also that it has broader implications and varying levels of fidelity.

Ben Scott-Robinson - Making money out of IA

Ben works for Ordnance Survey, Britain’s ‘national mapping agency’. Making maps, he explained, is in its core all about information architecture. His talk was about how OS makes money from IA. The main thing they produce, he said, clarity of information. Detailed information, in their case, used by the likes of governments and telecom providers.

Despite the IA-like activities being at the core of the company, OS’ website was not ‘generating leads’ or selling products very well. This almost lead to the closure of the website, but this did not happen. They decided to work on a new website and have a strong focus on user testing during the process.

Ben explained OS decided to make ‘happiness of users’ a key metric for their definition of success. Their company’s performance would be judged by how happy their users were. There was an big role for NPS (net promotor score), a number that expresses the chance a customer would recommend your company to others. NPS, they decided, equals happiness. When they first started, the NPS was very low, negative even. Then they started using UX processes like paper prototyping and card sorting. They built a new website, showed it to stakeholders. Some departments were unhappy as their bit wasn’t in the main navigation, but this is where the user testing sessions came in handy: there were many a user testing video they were able to show to back up their decision.

Dan Klyn - Everything needs to be actually architected

The last talk of the day was a great Kanye West-inspired keynote by Dan Klyn. A greatly inspiring talk, about whether architecting is a verb (compared with the word ‘designed’, he said, it is about something more fundamental than design). Dan emphasised that architecture is not design. He also talked about the difference between good design and better design, which he said is immeasurable.

Dan Klyn

The reason we don’t call architects something like ‘building designers’, Dan said, is that they operate on a different level, being the level of human agreement. An interesting challenge in IA Dan mentioned is that of the ‘structural integrity of meaning across contexts’: the ‘mess’ that iTunes currently is, is an example of a product where this needs improvement.

Conclusion

I had a great time at World IA Day 2016 and learned a bunch about information, architecture and information architecture! Practical tips about different approaches and working together, but also theoretical ideas about the meaning of information architecture concepts. Also, I should definitely go and read the Polar Bear book.

Originally posted as World IA Day 2016 in Bristol on Hidde's blog.

[email protected]?subject=Reply%20to:%20World IA Day 2016 in Bristol">Reply via email

Cascading and cognitive overhead

2016-02-23T00:00:00Z

When I started out learning to build websites, the web world was just moving from adding style declarations to every single element, to a generalised approach where one small-ish set of rules would apply to all of a website’s pages.

We transitioned from meaningless markup:

<font size="-1">A smaller heading1!</font>

to markup that described an element’s position in the page structure:

<h3>A smaller heading</h3>

This was the magic of CSS: because our markup had meaning, we could contain the style of all the elements in just a small set of rules that would sort of automatically work for new pages.

Styling things that don’t even exist yet

With CSS, you don’t just style that heading, you style the general thing ‘heading’, including the ones on pages that don’t exist yet, with lengths you hadn’t imagined yet.

Preparing for the unexpected is a large part of the art of authoring stylesheets. We don’t know what device a user is going to pick, we don’t need to know, but if it’s got a certain screen width, we can write rules to adapt the lay-out.

Cascade blaming

In modern approaches to CSS, some portray the cascade as a nuisance. In his (well-considered) article about REMs vs EMs (seriously, read it, it is good!), Zell Liew says:

What throws people off is that 1em can take on different values in different parts of the code

Harry Roberts responded to this on Twitter:

This, in a nutshell, is why I hate ems.

So about this ‘taking on different values on different parts of the code’: in any programming language that would be bad, a side effect, a bug, a problem. But for CSS, a declarative language, it is arguably the whole point of it. CSS is made to have a cascade: behaviour that inherits style declarations based on priorities.

I would argue the benefit of CSS is that it does unexpected things. Instead of having to style every heading individually (result: expected behaviour), it will style each heading for us, including the ones that don’t exist yet when we’re writing the style rule (result: unexpected behaviour).

This is something you need to keep in mind when writing stylesheets. Harry replied that the cascading behaviour of ems is ‘cognitive overhead’ that ‘isn’t worth it’. I concur it is cognitively challenging, and education is important (Harry personally does a lot of great CSS education), but so are many things in web development.

Complexity in CSS vs complexity in preprocessors

The benefit of cascading as a cognitively challenging thing: it is clearly defined in specifications.

Many features of the modern day CSS approach, such as custom mixins and functions, are defined by the (very smart) people behind projects like Bootstrap, Bourbon, Inuit et cetera. They, too, bring cognitive overhead, but have only their documentations to refer to for help.

Where the spec-defined complexities have always been explained in the spec, and books by people like Eric Meyer and Andy Clarke, many modern-day complexities in CSS are harder to learn. Arguably, they bring more cognitive overhead.

Originally posted as Cascading and cognitive overhead on Hidde's blog.

[email protected]?subject=Reply%20to:%20Cascading and cognitive overhead">Reply via email

Perf mattered at the Fronteers Spring Conference

2016-04-01T00:00:00Z

On Friday 1 April I attended Fronteers Spring Conference at EYE in Amsterdam. The first of its kind, after 8 two day conferences in autumn. IMHO, this one day spring thing is a fantastic format worth pursuing again!

Fronteers has in recent years always taken place in Tuschinski, an old cinema with a very cool interior, an eclectic mix of styles like art deco and Jugendstil. Cinema equals comfy seats. The cool thing about the new venue, also a cinema, was that most of us had to get on a boat (for five minutes or so) to get there.

The day was all about web performance (hashtag #perfmatters): making websites faster. It was divided into three sections, each with three 20 minute talks: the first on visual performance, the second on performance and accessibility and the last technical performance. Each section ended in a panel discussion with MC, eh, host, Phil Hawksworth. The day was then concluded with a keynote talk about money and the business case for web performance.

Visual performance

Tobias Ahlin started the day off with some great tips for better performing animations (slides). He recommended to only ever animate opacity, transform and translate properties, and suggested the use of pseudo elements to resemble animating other properties. An example: you cannot transition/animate border, but you can add a pseudo element, make it look exactly like a border and transition/animate that instead.

Paul Bakaus discussed the perception of performance. How a person experiences speed, he argued, may be a more important thing than actual, measurable numbers. Long activities, he said, can be memorised as short, and short ones can be memorised as long. He also emphasised how important context is for this: where and how you experience time can also influence what you feel about an interaction taking a certain time.

Bram Stein then talked about web typography, and more in particular the timing of custom font loading (slides). Browsers (and developers) make choices about what to do when your CSS wants to use a font that is not on the user’s system, the main options being FOIT or FOUT. FOIT is the flash of invisible text: a white screen until the requested font has downloaded. FOUT is the flash of unstyled text: rendering content in a fallback font until the requested font is downloaded and available. I could not agree more with him that FOUT is the best strategy: displaying any content at all is more important than displaying it in your font of choice. Web fonts are an enhancement. Bram stressed we should optimise how browsers load fonts with code, as most browser’s defaults are not great. This can be done with prefetch headers, the Font Loading API or its polyfill, Stein’s own Font Face Observer.

Accessibility

Marcy Sutton talked about ensuring accessibility in apps that rely on JavaScript (slides). To get websites to perform well and accessibly, she encouraged us to think about how you impact users (eg those that want or have to interact with their keyboards or assistive tech). This means we should not only focus on the DOM tree, but also on the accessibility tree. In terms of performance, if your app relies on JavaScript to be usable with a keyboard or AT, she stressed, make sure this JavaScript is in the critical path and load it before the rest of your app. She also recommended to prefer native elements above custom ones, as they often come with free accessibility benefits. I feel this is especially important when thinking of Web Components.

Karl Groves said that an important reason that we optimise for performance is because our clients want it and they’ll leave our sites or refrain from buying our stuff if we don’t and our website takes too much time before it becomes accessible. He said research (on physical businesses) showed that up to 83% could indeed leave a business if they had difficulty accessing it, and that this applies to the web. The most important question he said developers should ask is: “What is this thing and what does it do?”. This makes lots of sense, because the answers to those questions will likely remain the same whatever the device/context/user. Like Marcy, Karl mentioned the benefits of using native elements, and he showed an awesome video that compares how ATs make sense of real <select> elements and their jQuery UI counterpart.

Estelle Weyl talked about how responsive web design is not (only) about making it ‘squishy’: with sites getting larger in file size, page weight really matters (slides). An example she showed is that of YouTube Feather, a super light replica of YouTube (100k instead of 1200k) that someone at Google made. She also explained how responsive images save time in both decoding and transferring, and said we should consider our user’s battery lives. Design, Estelle concluded, is not about making it pretty, it is about making it usable and intuitive (and I guess that includes fast).

Technical performance

Yan Zhu went into the speed of TLS: when it was first on the table, people said it should not be deployed as it would be too slow. This is changing, with the likes of Netflix (which accounts for a huge part of bandwidth usage, especially in the US) switching to HTTPS. She said session resumption makes TLS less expensive by saving roundtrips. HTTP2 will also have impact as it allows multiple TLS connections at ones (and all regular supporting browsers will require HTTPS for it). HTTPS has in recent months become much easier to deploy on any site, with the public launch of Let’s Encrypt, which has issued over 1.4 million certificates since its launch, which, in number, makes it one of the largest CAs out there.

Tobias Baldauf showed us some very clever tricks to get better performing images, including those ‘hero’ images that we all love. There were three parts to his proposal: use HTTP2, use progressive JPGs and optimise the ‘scan levels’ in those JPGs. Tobias showed a number of comparisons showing real speed differences between HTTP1.1 and HTTP2, and between progressive JPGs / optimised progressive JPGs and ‘regular’ JPGs. With HTTP2, progressive JPGs and optimised scan levels, he showed, you can get a recognisable image on screen after only 15% of the image has downloaded. Wow.

Fronteers veteran Mathias Bynens blew everyone’s mind by explaining a very different phenomenon related to comparing the timing of downloads: the so-called timing attack (slides). He showed a number of different ways this can be used, but the main idea comes down to making requests to a site you think your victim visited, and use differences in server response times to find out about their status on that site (e.g. that they are logged in, have an account, or even have a certain age).

Round-up

Kristian Sköld ended the day with an interesting keynote about a subject that was hardly discussed in the other talk: money. If you need your organisation’s support for spending time on web performance, you will want to make a business case and discuss money, as that is likely what the management will want to know about. Whatever you do, there should be a business case behind it, Kristian said. If you correlate pageviews/load time statistics with bounce rates, you will likely find that more people bounce if the site takes longer to load. This is a metric marketing/business people can work with and ultimately, approve the budget for. If better performance can shave money off the marketing budget, Kristian explained, making more money available to the IT/web department becomes simple math.

My takeaways:

We should be conscious of and minimise the amount of bytes we send down the wire
Page speed is not just numbers, perception can also be a factor
Fast websites do not have to be insecure: TLS is getting faster (so fast that Netflix is moving to it) and HTTP2 (HTTPS-only in all major browsers) lets us benefit even more from progressive JPGs
Fast websites do not have to be inaccessible: resources that aid accessibility should be part of the critical path and if we use native elements, we get a lot of accessibility for free
Paying attention to the amount of bytes sent to users can also help evil companies to track them

What a fantastic day this was. We learned about keeping file sizes down and minimising bytes sent over the wire, about using the right tools for the right job and about advantages of HTTP2 and HTTPS. There were both specific and general talks about web performance issues, and as many as three accessibility talks. Lots of variety! Well done, team Spring Conference!

Font loading strategies

2016-04-21T00:00:00Z

If one phrase from Bram Stein’s excellent Fronteers Spring Conf talk stuck with me, it was ‘always have a font loading strategy’. The point he made was that if you use custom web fonts in CSS, you should not rely on browser default behaviour, as that will often mean users see white pages with invisible text in case of font loading failure.

In his article ‘Web fonts for president’, Zach Leatherman compares font loading strategies (or, mostly, lack thereof) of the 2016 US election candidates. What a great idea! It’s a very interesting read!

Bram Stein describes how to use his Font Face Observer on his blog.

(I realise this blog currently lacks a font loading strategy, since I recently updated the typeface, I’m working on that)

Originally posted as Font loading strategies on Hidde's blog.

[email protected]?subject=Reply%20to:%20Font loading strategies">Reply via email

Collaborative CSS

2016-05-08T00:00:00Z

In “Meaningful CSS: style like you mean it”, Tim Baxter argues for replacing CSS approaches that heavily rely on classnames with a markup-centric approach. I think adding styling to HTML elements is hugely beneficial, but works best when combined with a class-based approach. We need a bit of both.

In his article, Tim explains that in the past few years, HTML (especially when enriched with ARIA) has become much more expressive. So expressive, that we can throw away class-based approaches to styling. We can just style on HTML elements themselves, he says.

Your team’s standards vs web standards

The challenge in CSS is to find a way to apply the styles you want to the things you want to apply them to. Classes let you give your things any name. Classes are to “[represent] the various classes that the element belongs to”, says the HTML standard. With a ‘class-based approach’, I mean approaches like OOCSS and BEM, that recommend you to define components or objects with just or mostly classnames.

The most-used argument for a class-based approach to CSS is that it makes things easier for teams. Once a team agrees on the preferred nomenclature for a thing, they can consistently use those names within their team.

But consistent standards already exist, in the form of web standards. Why not make those the baseline? Tim Baxter also says this:

if there is any baseline level of knowledge we should expect of all web developers, surely that should be a solid working knowledge of HTML itself, not memorizing arcane class-naming rules

Yes, let’s add styling to HTML where we can! This is wonderful, because web standards for markup were made through a long process of mailing lists, IRC discussions and face to face meetings. They have already gone through the trouble of defining what things are on the web.

Web standards define the difference between inputs for phone numbers and those for email addresses. They define the difference between a definition list and an unordered list. And the difference between quotations and paragraphs.

We need a bit of both

Adding style rules to native HTML elements, and use the power of some of the many attributes HTML comes with, sounds very sensible to me. Because the web standards people have already defined and documented what things mean in HTML, we can just use those semantics and be done with it. This also aids your users. Some of them may be using a screen reader or search engine to access your site.

But there is a problem here. The issue with using ‘just’ HTML to apply CSS, is that HTML is simply not as expressive as the design languages that often underly our web projects. Many web projects contain various instantiations of the same, meaningful HTML elements. In such projects, the meaning cannot come just from the elements themselves.

To be more precise, I think avoiding class-based approaches does not align with how web teams collaborate.

Some examples

Web standards document:

what a form is

Our project’s design language contains:

a newsletter form
a search bar
a contact form
a poll (why not?)

These are all different types of forms, and would often not benefit from sharing style rules. The interaction designer has had user tests done and decided to do labels next to inputs in the contact form, and make the search bar expand when you click it. They’re all forms, but they’re all different.

Web standards document:

what an input with the type ‘submit’ is

Our project’s design language has:

the newsletter signup submit
the search button
the ‘Contact us’ form’s submit
the button to submit your choice in the poll

Again, I think their is much more difference in meaning than we can ever distinguish between with styling just <input type="submit"> .

We can design beyond the list of available HTML elements

If we expect to be able to style just HTML elements, we should only allow designers to design one style for each HTML element. We would just hand them the list of available HTML elements, and they would create a design for each. That would be an insane process to follow. Unrealistic, too. Interaction designers have user journeys to worry about, they need to keep track of the whole picture.

Designers for the web, rightly, design more than just individual HTML elements. This is why, for front-end developers, it makes sense to use classes like .form--newsletter, .form--search or .form--contact. Or, depending on whether they differ a lot, .newsletter, .search-bar and .contact-us.

I have built websites where all the forms look the same, all the tables look the same and all the quotes looks the same. In those projects, they really exist, classnames are mostly unnecessary. Yet, most larger web projects are not like that. They have a lot of variations and for their meaning they cannot rely on HTML elements alone.

We have to be pragmatic about this. We should collaborate on websites that go beyond just what native HTML elements have to offer. Creative combinations of markup can bring our users a great experience. Classes aid creative combinations.

Using classes to draw distinctions

So, I think we need to define blocks with classes, so that we can distinguish between all the different components that are in our project’s design language. There is no harm in adding classes for variations of those blocks, or elements within the blocks. After (a lot) of initial scepticism, I quite like BEM and have seen it work (but as with all best practices, it is good to be critical, the problems they solve may not be your problems).

Classes are essential to do the work we need to do: style websites with a varied design language that creatively uses combinations of HTML elements. But using lots of classes should not stop one from using meaningful markup. CSS experts should always also be markup experts.

Conclusion

I really liked Tim Baxter’s article about styling with HTML elements and attributes, mostly avoiding classnames. It provokes thought and is a welcome alternative to the let’s-add-classes-to-all-the-things consensus. And I agree, adding styling to HTML elements is powerful, as they have inherent meaning that is specified in a standard.

But I think HTML and ARIA are (still) not expressive enough to draw the distinctions our designers draw. Classnames are essential in making such distinctions. The best approach, imho, would be to combine both classes and meaningful markup.

Originally posted as Collaborative CSS on Hidde's blog.

[email protected]?subject=Reply%20to:%20Collaborative CSS">Reply via email

Notes on CSS Grid Layout

2016-05-10T00:00:00Z

In preparation of the Grid Layout Workshop in Amsterdam this Friday, I read the grid spec. I highly recommend doing this.

This specification is a great read, even for those not familiar with reading CSS specs. It first introduces all the concepts with comprehensible examples, and then dives into the syntax in more detail (including diagrams that show exactly which properties can be used how, available shorthand syntaxes and the algorithms used to decide about sizing and alignment).

Why?

“We already have many clever combinations of HTML, CSS and JavaScript to do layout”, I hear you think, “so what do we need Grid Layout for?” All layout mechanisms we have used to date come with specific problems. Floats need clearing, inline-block grid elements need comments to remove spaces and make widths work, and tables misused an HTML element for layout. CSS Grid Layout addresses our layouting problems, and lets us ‘divide available space for layout into columns and rows using a set of predictable sizing behaviors’. Yeah!

New terminology

The grid spec introduces a number of new terms. A grid is a set of lines that divides the grid container. Within the grid container, columns or rows exist between the lines. Columns and rows can both be referred to as grid tracks. On the grid, each cell is called a grid cell. One or more cells can form a grid area, which can be occupied by grid items.

I found it a bit confusing at first to see the difference between grid areas and grid items, but as I understand it, grid items are the bits of content that authors can specify to live in a specific grid area.

More alignment options

Some of the best new CSS properties that were introduced in flexbox, also work on grid containers (justify-items, align-items), grid items: (justify-self, align-self) and the grid itself (justify-content, align-content).

Naming lines and areas

With grid-template-columns and grid-template-rows you can not only specify how much space each grid cell takes up, you can also give the lines surrounding them names. So for a 3 column layout with a width of 25%, 50% and 25% respectively, you do something like:

grid-template-columns: 25% 50% 25%

And if you want to lines surrounding the 50% area, you do:

grid-template-columns: 25% [start-main-area] 50% [end-main-area] 25%

so that you can set a specific bit of content to live in the 50% area between ‘start-main-area’ and ‘end-main-area’.

You can also define names for the areas themselves, using the ASCII art method (if a word appears multiple times, it means it spans multiple columns/rows):

grid-template-areas: "header header header"
                     "main main sidebar";

so that you can set a specific bit of content to live in the ‘header’, ‘main’ area or ‘sidebar’.

fr

The fr unit can be used to define flexible lengths and represents a fraction of the free space in the grid container. I think this is how it relates to auto: if all lengths are set auto, that would be equivalent to them all having 1fr, but if they have different amounts of fr, the fr unit gives more control as they can give some grid tracks more space than others.

Changing visual order

The grid spec frequently talks about the order keyword, which lets you visually change the order of your document (this property also exists in flexbox).

This makes that there are now two different orders to keep in mind:

document order / source order (this is what you see when you view source)
order-modified document order (this is the document order with all the ‘order’ properties in your stylesheet(s) taken into account)

Browsers are supposed to paint in the order-modified document order (this is also good to know for if you’re setting z-index).

The spec emphasises that order will only change your visual order, and not update speech order (for people that have your page read out to them) or navigation order (for people that use keyboards to navigate). Therefore it is important that the source order is sensible (this is an important accessibility concern).

Auto

Lots of things within grids can happen automatically. This is a bit complex to get your head around, but it is rather exciting (if you have not seen it, I can recommend fantasai’s CSS Day talk on defining auto). The good news is: to use grids, you do not need to know how the auto algorithms work, they just do.

With grid properties, you can set your grid exactly how you want it to be (‘explicit grid’). If you forget something or position an element outside of the bounds of your grid, the grid algorithm will create ‘implicit’ grid tracks.

Grids in grids

Grid items can be grids themselves (they are then ‘subgrids’), but this is still being discussed by the CSS Working Group. With display: subgrid, the subgrid would be able to inherit the cols/rows of its parent.

Thoughts

This is exciting! I really look forward to using CSS grids in my daily work.

I do think the transition to actually using the new properties for page layout will come with some problems, especially around giving grid areas names that can be shared across everyone working on the same site, and letting grid areas be occupied by components (as component libraries are the deliverable of many front-end developers these days).

And if that all works, should we give content managers controls to set content to flow in specific columns (perhaps the CMS would show a representation of the grid on various different viewports?).

Originally posted as Notes on CSS Grid Layout on Hidde's blog.

[email protected]?subject=Reply%20to:%20Notes on CSS Grid Layout">Reply via email

ConfConf

2016-05-24T00:00:00Z

A conference about conferences, isn’t that super meta? It is, a bit. Most web conferences aim to bring web people together and inspire them to do better work. ConfConf in Bristol did something similar for those who organise conferences.

Having originally been conceived as a joke between two event organisers, ConfConf became a real thing for the first time last year. It turned out that the event provided real value: with all the knowledge sharing, organisers were able to learn a lot from each other.

This year, the event was held in Bristol, and I attended as part of a group representing Fronteers Conference. The audience was small enough to have group discussions and not need mics, but big enough to have lots of conf-organising experience between them. These are my notes of the day.

The human side of event organisation

Marc Thiele, organiser of the Beyond Tellerand conference in Düsseldorf, gave the first talk. He walked us through his process and the tone of voice he tries to convey.

If one thing stood out from his talk, it is that communication plays a huge role in everything he does. It sets the tone of the event, Marc explained.

He makes a point of being very friendly to every single person involved with his event: attendees (including previous attendees), speakers, suppliers, even the venue staff. Being friendly includes checking in with people, being prepared to patiently answer the same questions over and over and being interested in everyone at the event. This goes a long way. For instance, if you need your A/V to think with you about new ideas, it helps if you get along with them.

Communication is also about being very clear. Marc took us through the various emails he sends to attendees, speakers and others, to make sure everyone has all the information they need.

Getting bums on seats

John Davey, who is responsible for the ‘Reasons to’ conferences, talked about what he does to sell tickets. He recommended selling tickets early, making use of social media (on accounts that matter to your target audience rather than those with huge numbers) and doing so creatively.

John likes people who pull faces and, as his slides confirmed, is quite good at this himself.

He emphasised communication should be provocative (never rude though) and not bland. Creative communication and attention to detail also helps convince potential attendees of the quality they will get.

John gave some tips to increase ticket sales: by setting limits on based on quantity or time, you can create an urgency; you can be loyal to past attendees and email them with a special discount; you can also use the audience of your sponsors for promotion (their coverage/promotion could be more valuable than money).

Panel: all things to all people: striving for the impossible

In the first panel, there were discussions about curating a quality and diverse lineup, single track vs multi track and dealing with criticism.

Some organisers said they think of speaker names first, others think about talk subjects first and then come up with names for each subject. I like content-first, as it makes it much easier to explain to speakers why you want them. This increases your chance of getting speakers to agree to come to your conference.

We also discussed conferences with tracks. Having a single track can sometimes force people to sit in talks they would normally not attend. Marc Thiele said he likes that and tries to play with that. Rachel Andrew recommended that, in multi track conferences, speakers state the experience level at the beginning of their talk, to allow people to leave if the level is not what they were looking for (better for speaker and attendee).

The panel also talked about video: most conference organisers that attended said they had their talks recorded (some said they no longer did for cost reasons). Brief discussion followed on making videos available accessibly. At Fronteers we provide transcripts and captions for all our talks (see my blog post about how we do this).

What do speakers really want?

For her talk, Rachel Andrew did a survey amongst conference speakers and shared her results. She illustrated those brilliantly with personal experiences (she speaks at a lot of events) and gave a huge number of tips. There was a lot more in her talk than I can cover here, but I will try my best.

She talked about how important it is to be clear to speakers. What it is you do, what you expect a speaker to do where, when and for which audience and what you offer in return. Speaking is expensive, especially for those speakers who are freelancers / run a business. If your event makes a profit, you should pay speakers; only if you organise a community event you may get away with not paying.

Another thing Rachel talked about is to be helpful: make sure they have your contact details (and make sure there is always someone on phone duty), have professional audio/video people (‘agressive A/V people are a thing’, Rachel’s survey showed) and try to get post talk feedback to them (best filter it for constructive notes).

Rachel also said all speakers should be treated equally (rockstars and newcomers). That means they require equal pay, but also equal taking care of and being friendly to. If you are going to differentiate, best be extra helpful to newcomers rather than rockstars. If you have newcomers, inexperienced or vulnerable speakers (in any way), covering expenses can make a huge difference: paying their expenses and fees can empower them.

Panel: the future of conferences

In the ‘future of conferences’ panel, we discussed structure, and techy vs creative events.

Thomas van Zuijlen of Fronteers asked whether the “Fronteers model” (2 days of ‘just’ 45 minute talks) is going to die out in favour of newer models like the “responsive day out model” (1 day with sessions of three 20 minute talks followed by a panel discussion). Most of the panel agreed that the old model is likely there to stay, but new structures are interesting and bring in new benefits: more concise talks, easier to cover subjects that are too new to be suitable for a full length talk, etc).

The panel touched on the difference between events about technology and those about creativity. Some noted that the ones about creativity and inspiration are much harder to sell tickets for. One reason for this, the panel concluded, may be that it is easier to get management approval for attending a conference, if it is easier and more tangible what the conference covers (Angular vs creativity).

The conference survival handbook: extreme edition

Cat organises the international Smashing Conference as well as ConfConf itself. Cat’s talk was about a subject that will be familiar to anyone who has organised an event before: conference nightmares. There is so much that could potentially go wrong! Cat talked about known knowns, known unknowns and unknown unknowns.

Known knowns are things that can be planned for, like not running on time, slow registration process, speakers illnesses and poor WiFi. To avoid running off schedule, Cat recommended planning time for getting everyone seated without gaps, factor in welcomes and introductions and being very clear to speakers about how long they are on for. To make registration smoother, she said events should avoid requiring ticket print outs and have one person available to investigate in case someone shows up and their badge is not there. She also mentioned preregistration, which can be good, but requires extra plain badges as people tend to forget theirs on the conference day.

Unknown knowns are things that happen on the day: a speaker oversleeps, someone is angry or rude on Twitter or a complaint is made. The crux of solving such issues is being ready for them when they happen: having people available that can react quickly is important. Cat mentioned at Smashing, she asks speakers to be on site a minimum of 3 times the travel time between hotel and venue.

Unknown unknowns are things that almost never happen: the projector’s bulb blowing (ask A/V staff if they have a spare), power cuts (again, ask venue for their backup plan) or natural disaster (take insurance).

Wrap-up

If there is one thing that I learned from this day, it is that taking care of all the little details, being very friendly and communicating clearly are very important additions to your main conference organising duties. Probably thanks to having had an experienced speaker (hi PPK!) and a very friendly personality (hi Krijn!) amongst our founding organisers, I realised during some of the talks, many of these things have been in the FronteersConf handbooks for years. But I also heard many things we could improve on.

It’s been great to hear from some seasoned organisers and a speaker. And it was very useful to exchange knowledge on the day and in the pub afterwards. ConfConf showed me that there are many types of events, as well as styles of organising. Recommended for all (web) conference organisers!

Originally posted as ConfConf on Hidde's blog.

[email protected]?subject=Reply%20to:%20ConfConf">Reply via email

Reasons to make digital products accessible

2016-06-01T00:00:00Z

Yesterday I attended NCDT, the Dutch conference for digital accessibility. Hundreds of people whose work somehow involves digitally exposing information gathered in Utrecht.

The interesting thing about NCDT, I found, is that many attendees work in roles that require them to organise accessibility within their organisations, having to convince management and stakeholders of accessibility benefits. As a front-end developer, I usually only have to convince designers and interaction people. Convincing the whole of a company seems lots harder!

Here are some reasons for accessibility that I heard on the day, in no particular order.

Because we ought to put users before egoes

The excellent Gerry “top tasks” McGovern could not have said it clearer in his talk: “we measure production, not consumption. If we want digital excellence, we must measure actual use”. Many organisations put out web pages because some employee made the page and is excited about it. They put out web designs, because the designer made something pretty and the team liked it. They contain web copy that their content marketeers think provides value. But your website should not be about your employees, your designers or your content marketeers, it is about the users and what they want. That’s what websites should invest in, McGovern said. The users on your website should be put before the egoes in your organisation. Therefore: always be user testing.

Because it could be illegal not to

Users who cannot access your website, could potentially sue you. Eric Velleman of the Accessibility Foundation explained how. He showed there are currently a number of Dutch laws and regulations that make it illegal for companies to have an inaccessible website. Important to note: in The Netherlands, no one actually got one of those laws to be applied to them by a judge. In America however, judges have ordered large companies to pay sums of money and/or make their website more accessible.

More legislation is coming: an EU wide Directive is being implemented by EU member states. The Netherlands also recently agreed it will ratify the 2006 United Nations Convention on the Rights of Persons with Disabilities. The “College voor de rechten van de mens” was appointed as the regulator for this convention, and this will be where people can go to complain if they cannot access a particular site. At this time, it is not clear what the Dutch authorities will do in terms of fines or sentences. It is unlikely, Velleman said, that companies will get sued for inaccessibility.

Because our organisation has embedded inclusive design

Jonathan Hassell talked about embeddding accessibility throughout organisations (he was the main author of BS 8878, the British standard / code of practice on this subject). He said what’s more important than making accessibility checklists mandatory, is valuing accessibility as an organisation. To do this, the top needs to be on board, training needs to be in place (staff might leave), it should be embedded in company policies and it should be in a process that can be used over and over again.

Having accessibility is embedded in all those different ways, can really make it part of an organisation, which can ensure the organisation makes more accessible products, now and later.

Because there is passion for #a11y at the top

Jake Abma, head of accessibility of a major Dutch bank (the orange one) held a talk about how he got support for his radical idea to embrace digital accessibility practices. It was a truly inspiring story. He convinced his manager to get him 2 hours a week to spend on accessibility, this later became 4 hours, a day and even two days. Later others got time too, and currently, the bank has a dedicated accessibility team. They have their own accessibility guidelines (which is a superset of WCAG and other standards), do lots of accessibility testing and have “accessibility champions” across teams. They ensure doing the accessible thing is part of their process (in scrum terms: it’s in their definition of done). At a bank!

Part of what worked is that there were some people in the top of the hierarchy who had visual impairments: there was a passion for accessibility at the top. Otherwise, to get support for spending time on accessibility, Jake explained, is a matter of small steps. Focus on those people who do like the idea and most importantly, do not give up.

Conclusion

I am just a front-end developer. For me, accessibility is usually about practical things like checking the colours that come in from designers, getting my markup semantics right and providing alternatives (in all kinds of ways).

At NCDT, I saw that it is not just about single team members (“we not me”, said Jon Hassell). This makes sense. Especially for large organisations, there can be a lot of company politics involved, and it is some people’s job to work these politics every day.

Originally posted as Reasons to make digital products accessible on Hidde's blog.

[email protected]?subject=Reply%20to:%20Reasons to make digital products accessible">Reply via email

The internet does forget

2016-06-21T00:00:00Z

Although it may be very exciting to make new things for the web, it’s important to think about archiving what we have made before. This requires one to think about the long term, and about whom we trust with our content.

Last week, Jeremy Keith held a lecture about digital preservation at Amsterdam’s university of applied sciences. This is a write-up of his talk.

Why keep old websites?

“This is for everyone” is the message that appeared behind Tim Berners-Lee, the inventor of the web, when he made a surprise appearance during the London 2012 Olympics ceremony. The web is meant for everyone. It is there not just to consume, but also to create for, Jeremy said.

Geocities used to be where people with hobbies hosted websites to share with the world what they did. Over 30 million of them. Websites about pets, football clubs, fan sites, you name it. From a web designer’s point of view, they were not necessarily the most beautiful or user-friendly websites. But, Jeremy said, “an ugly website that we find ugly today, may be the first website made by the future president of the United States“.

When Geocities shut down, no backup plans were made. We were looking at the removal of over 30 million websites, to be gone forever. This was a threat. It would have been where archeologists of the 2090s would have found what we were up to in the 1990s.

Other than their cultural significance, existing websites can also break the web if they are removed from it. This is because links to them will break.

Luckily, in the case of Geocities, the Web Archive team stood in and managed to save a large part of these websites.

Third parties

If recent history is an indication, trusting your content to third parties only is not a good idea, Jeremy emphasised. Geocities was bought by Yahoo!, so was Tumblr. Many websites that offer to host your content for you are bought by some big internet company at some point. We trust our content to these start-ups. But rarely, when they close, they offer a way to export the data. They do usually thank you for being on their incredible journey.

Indieweb type of solutions can help here: there are tools that let you publish on your own platform as well as on third parties, so that you always have your own content.

Hard work

The good news is that the web, Jeremy said, is actually very suitable for being preserved. Apps you build now will likely not work on devices from 5 years in the future, whereas websites probably will (as long as someone pays the web hosting bill).

The saying “the internet never forgets” is not actually true, Jeremy explained. The internet does forget, a lot of things get deleted and are then gone forever. One has to work hard to keep things online, preferably on their own URLs (to not break the web).

Preserving your websites requires one to think about the long term: you will have to make sure to keep paying your hosting bills, for one thing. But what about when you pass, are there any hosting companies that will let you include hosting fees in your will? Some compelling questions to think about!

Originally posted as The internet does forget on Hidde's blog.

[email protected]?subject=Reply%20to:%20The internet does forget">Reply via email

Progressive Web Apps Dev Summit

2016-06-22T00:00:00Z

This week I had the pleasure of attending the Progressive Web Apps Dev Summit, an event organised by Google in the beautiful city of Amsterdam. These are my takeaways from the event.

The screen was immense

Progressive Web Apps: what and why?

What an ‘app’ is, depends on who you ask. When we are talking about apps on mobile devices, they are usually things with specific capabilities. They help users do things, integrate well with device capabilities, can be opened from a home screen and are able to work full screen and offline. At the moment, apps with all those capabilities are usually not mobile websites, but app store apps.

From a technical perspective, there are only a couple of things that separate mobile websites from app store apps. But in terms of user experience, these differences are enough for people to prefer app store apps to web apps.

To solve this UX gap between native and web, Google came up with the concept of Progressive Web Apps. It’s a set of open web standards that lets developers turn their ‘website’ into a ’web app’, in a progressive manner.

What’s a progressive manner? If your site already functions as a website, by adding stuff to it, it can become more app-like. Browsers that don’t support this ‘stuff’ will get what they already got before. Supporting browsers, however, will get the benefits. As an extra. The idea is that over time, more browsers will fall in the supporting browsers bracket. It is a bit like using rounded corners in CSS, knowing that some browsers will take advantage of it, others will ignore it. Users will likely not notice they are missing out, but will get a better experience if they aren’t.

With progressive web apps, we can ‘earn our space on the home screen’ (Alex Russell), ‘stop blaming being offline on the user’ (Jake Archibald) and ‘give the user a page they can interact with faster‘ (Surma). Whereas native apps are things you go out, buy and download, PWAs are basically an up-sell: you download them by visiting the page, and keep them if you like to.

The summit

Google have been great hosts! They drove us to the venue with a shuttle bus, let us in for free, provided lots of fancy food and drinks throughout the two days and used exciting intro tunes between speakers, who presented on a huge wall-to-wall screen. They really are serious about saving the web in its fight against native apps.

It wasn’t just a Google party though. Google sent lots of their developer relations people, but so did others: there were people from all major browser vendors (except Apple) and they even did talks. There were also folks from businesses that built PWAs, such as the Nigerian online marketplace Konga and the Amsterdam-based Booking.com. This made the whole event much more like an open web standards event than a Google marketing event.

New technologies

Progressive Web Apps is not one technology. It is one name for a set of technologies that you can use to progressively expose app-like qualities to go with your regular website. A marketing term, if you will. There were talks about most of the different technologies.

Service Workers give developers control over the network, by exposing the decision process for network activity to JavaScript. What they effectively do, is to enable reliable performance: apps can now deal with Lie-Fi or offline connections by serving alternatives (for instance, a cached site). Service Workers can make your site work offline first, as you get to decide how the network requests from your app are handled.
The streams and fetch APIs can be used from Service Workers, a good intro to them is Jake Archibald’s blog post or his talk at the dev summit.
In the majority of supporting browsers, HTTPS is an important part of progressive web apps, as a lot of the tech (geolocation, getUserMedia, HTTP/2, push notifications) requires it to work. Emily Schechter explained HTTPS brings three security properties: identity (be sure this site really is this site), confidentiality (be sure about who can read your data) and integrity (be sure that nothing can modify your data). HTTPS used to be hard to set up, expensive and slow. It’s now easy to implement, cheap and fast, Emily showed.
Push Notifications can provide great benefits for users if applied properly. Owen Campbell-Moore discussed do’s and don’ts: good notifications are timely, relevant and precise. He also discussed the flow of asking users for permission to send notifications. It is important to do this at a good time.
By having a manifest file and matching some other criteria, you can now make your app quality for Add to homescreen notifications. What the heuristics are differs per browser / platform. Interestingly, if a user sees ‘Add to homescreen’, they have already downloaded the site. So, as Alex Russell pointed out, the question really means: ‘would you like to keep it?’

Making it better for users

Progressive Web Apps seem to be about making it better for the users, and many of the talks discussed how to do that.

UI performance is important, Paul Lewis talked about using things like will-change and debugging by knowing when your code triggers repaints.
Surma talked about improving network performance by using Service Worker and HTTP/2.
Accessibility is an essential part of delivering a good user experience, as well. Rob Dodson discussed three steps to ensure accessibility: nail the WebAIM WCAG checklist, always be managing focus and provide proper semantics (either with meaningful native elements, or with ARIA). Look at WAI-ARIA best practices.
Daniel Appelquist shared an interesting principle about URLs, “the one web principle”: “content provided by accessing a URI yields a thematically coherent experience when accessed from different devices”. It’s useful for all (not the least users) to let a URL always present the same thing, regardless of which device it is accessed from. See also: responsive web design.

Other browser vendors

The event did not just feature speakers from Google, other browser vendors were invited to the stage as well.

Ben Kelly from Mozilla talked about how they joined the Service Worker effort in 2014, and focused on parts like security, improving the spec, documenting PWA technologies on the Mozilla Developer Network and making the Service Worker Cookbook.
Patrick Kettner shared Microsoft’s perspective. They, too, are very excited about Progressive Web Apps. He also showed how to make a fallback using AppCache (‘it is a douchebag, but it can be a useful fallback’) and talked about IndexedDB and Dexie.js.
Opera’s Andreas Bovens showed that Opera already support lots of PWA features and will support more in the near future. He also talked about UX patterns that relate to Progressive Web Apps, considerations to make, and choices to give to (or hide from) users.
Junkee Song and Daniel Appelquist from Samsung Internet, who make the default browser on Samsung devices (almost 10% market share in Europe) and are a major committer into the Chromium project. They also work on browser experiences for GearVR, Samsung’s virtual reality goggles and try to provide a ‘continuous browsing experience’ between phone and VR.

Examples in the wild

Throughout the two days, we saw some presentations by people who have actually released progressive web apps ‘in the wild’. It was inspiring to see how they made those apps work for their organisation. PWA tech gives developers tools to do stuff, but it will not make your decisions for you (that’s a good thing).

Jesse Yang showed how Booking.com made their confirmation page work offline. They did not tell users, giving the team opportunity to play with it without a lot of risk. They also experimented with ‘Add to homescreen’ and found most people ignored it.
Andreas Bovens mentioned pwa.rocks, a site by Opera that tries to list interesting Progressive Web Apps (pull requests welcome).
The Washington Post made a PWA that downloads lots of text to the user’s cache , to make that available offline, and downloads images later.
The team at Konga, Nigeria’s largest online market place, recently built a PWA using custom web components. They use background sync for analytics, tracking offline events and an offline checkout experience. Major obstacles are making things modular, getting Safari support and the learning curve for new developers.

Concerns

This whole post may sound like everything is peachy, but there are also concerns about Progressive Web Apps.

iOS support is a concern. Apple were invited to the event, but other than Microsoft, Opera, Mozilla and Samsung, they did not attend (because of other commitments, and they really want to attend future events). Their absence was noticeable: they are a large player and we all would have liked to know what they think about these new standards.

And what about the URL? They are an integral part of the web, as it is what people use to point to stuff and share things. However, for apps to get a ‘Add to homescreen’ prompt on Chrome and others, the ‘hide URL bar’ setting is compulsory. In apps that run full screen, URLs cannot be copied. Opera Mobile are experimenting with a gesture that lets you ‘pop out’ of an app, back to the browser, so that users can see, copy and hack URLs. Great idea, I think!

Another matter is the risk of heavy reliance on complex JavaScript. Admittedly, complex JavaScript is not compulsory for something to be a Progressive Web App, but it is what all of the apps demonstrated at the summit were using as their tool of choice. I’m not sure if this concern is a concern with PWAs, or with the let’s-do-it-all-with-JavaScript trend. Service Workers can be added to super simple websites like this blog, too (why not?).

The event was actually great at addressing many of these concerns, and culminated in a panel session moderated by Jeremy Keith (who published the brilliant Regressive Web Apps) .

Panel discussion moderated by Jeremy Keith

The future

Two things are important about PWAs: firstly, they are a set of open web standards, which means all browsers can implement them in somewhat the same way and developers can be fairly sure things will work inter-operably. Secondly, browser vendors seem to be very excited about adding support for these standards, which increases their chance of being a safe bet.

It was exciting to hear about the technologies, and to see that a lot of them already work on a great deal of platforms. Most of the major browser vendors expressed how much they liked the idea, so it is realistic to say support will increase in the short term. This, and the fact that all PWA techniques can be regarded as a ‘progressive enhancement’ (with some leniency as to what that term means), entails that we can build Progressive Web Apps today.

Hopefully, we will do so responsibly. Native apps really only work on their particular platforms. PWAs, in theory, can be built to work universally. For everyone with a web enabled device. This is awesome! Major browser vendors are behind the idea, and I think as developers we should be, too.

To keep this post somewhat concise, I did not do each talk right here. If you’ve had to miss the event, it was recorded and videos are available on YouTube.

Originally posted as Progressive Web Apps Dev Summit on Hidde's blog.

[email protected]?subject=Reply%20to:%20Progressive Web Apps Dev Summit">Reply via email

Some pointers on default cursors

2016-08-06T00:00:00Z

Every so often in a project, the issue comes up of whether cursors on buttons should be ‘the hand’ or default. The spec says they should be default, but many people (myself included, until recently), are unaware. Many designers I’ve worked with want pointer-cursors regardless of what the spec says.

This is the thing: links (<a/>) go to somewhere else, buttons ( <button> s) let users perform actions. The ‘hand’ indicates to a user that their cursor is on a link, which will take them somewhere. And can do so in another tab, copy/paste the link, drag it to another window, et cetera. Other interactive elements on the page (buttons, for example) just get a default cursor. TL;DR: the hand does not mean clickable.

What the standards say

The above is not my personal opinion, it is what the CSS spec says and what all browsers do by default. You can see this when you hover buttons in your OS, or look at the browser buttons to switch tabs. Or on the ‘Search’ button of Google dot com.

Apple’s OS X Human Interface Guidelines also say the ‘hand’ means the content is a URL link.

Microsoft’s guidelines are clear, too:

To avoid confusion, it is imperative not to use the hand pointer for other purposes. For example, command buttons already have a strong affordance, so they don’t need a hand pointer. The hand pointer must mean “this target is a link” and nothing else. (Emphasis theirs)

If we manually add a hand cursor to a button, we suggest to a user that they will be taken elsewhere, while they won’t. We would be breaking an affordance that was put into the web. It’s like taping a sticker that says ”Push me” over a well designed door handle (see also: Don Norman).

Clearly, standards say the hand is just for links. And there’s a great argument to be made to not mess with browser defaults.

Using ‘the hand’ anyway

Many people apply a pointer cursor to their buttons anyway. I have done so, too. I’ve heard many say they add the pointer to improve usability. In addition, Bootstrap and various other CSS frameworks also apply pointer cursors to their button (note that Normalize used to, but recently removed them).

Whether we just did not know about the standard way, or purposefully ignored it to improve things for our users, ‘the hand’ on buttons is somewhat becoming a de facto standard. It is done all over the place, so some users may now expect hand cursors on buttons.

Basically, I think there are now two standards.

There is a further complication: in practice, there is a grey area between buttons and links.

A “Back to top” link is literally a link to the top of the page, but, especially when it animates the user back to the top, it feels like it performs an action, too.
In a tabs component I recently built, each tab is marked up as a link to an area in the page. Visually, clicking it, ‘opens’ a tab. That’s an action, right? But what if you use a modifier key and open it in a new tab? That would also still work.
How about a button that says “Log in”. Sounds like an action, but what if the button is a link and just takes the user to a page where they can login?
What about a button in a <form method="POST" />? You can submit in a new tab, which makes it a bit like a link, but it also submits data, which makes it more like a button that performs an action. Or a form with GET, which should have no side effects at all?

I find that in team discussions, we talk about something being a ‘button’, yet in my HTML, I use the <a /> . Or even the other way around, occasionally.

Conclusion

The question is, does apply the ‘wrong’ cursor really matter? When I asked around on Twitter, some said applying hand cursors wrongly is a non-issue, as it confuses no one and it’s non-hand cursors that cause usability issues.

However much I think existing standards are the best to follow, I guess we have pretty much reached a situation where there are two standards, and either one is okay to use. Especially since things on the modern web are often not clearly a link or a button. Striving for consistency, at least within the same website, is probably the best thing we can do for your users.

Originally posted as Some pointers on default cursors on Hidde's blog.

[email protected]?subject=Reply%20to:%20Some pointers on default cursors">Reply via email

Things I learned at From the Front 2016

2016-09-15T00:00:00Z

This week I visited the 6th From the Front conference in Bologna, which this year was themed The Frontend Guide to Life, The Universe and Everything. It was my second time at the conference, having visited their first in 2012. Great to be back!

Below I share with you my takeaways from two days of From the Front. I have written a summary of each talk, occasionally mixed with personal opinion.

The Frontend Guide to Life, The Universe and Everything

We can develop personally to deal with the enormous amount of change in the 2016 web

Lyza Danger Gardner talked about overchoice, ‘the idea of an overload of choice’. Having worked on the web since the nineties, she already worked on the web when tables were commonly used for layout and CSS was a novelty. Browsers improved very slowly. The complete opposite is now true: browsers take feedback very seriously. New features get added very quickly into the browsers that people use. This also means there is a lot to learn. When Lyza spent 6 weeks in the woods, six weeks without working on web stuff at all, she felt she had to relearn the trade. And this is from someone who has worked on the web for a very long time.

Having the feeling that everyone else is smarter or that it is all just too much and you want to quit the trade altogether, can make individual developers unhappy. “We really want change, yet change is killing us, too”, Lyza said. She explained how she made some personal choices in order to take back responsibility for her own happiness.

Its built-in robustness makes the web great for progressive enhancement

Jeremy Keith shared with us a story of how the web was invented. Its main virtue, he explained, is that it is deliberately dumb: it provides simple mechanisms to transmit packages (TCP/IP), mark up documents (HTML) and declare what they look like (CSS). Beyond these mechanisms, the web does not care. It does not care what you name things, or what protocols you build on top of it. Super powerful, right from the start. It is also designed to be robust; browsers will not throw errors if you forget to close your HTML element or use a CSS property that they do not recognise. Instead, they will parse what they can parse. JavaScript is a bit different, as it will throw errors when you make a syntax error. This difference lets us divide front-end tech in two categories: the resilient and declarative (HTML, CSS) and the fragile and imperative (JavaScript).

Jeremy noted some websites now rely on JavaScript, which is fragile, to display content. He then made a strong argument for progressive enhancement. His strategy is to (1) identify core functionality, (2) build this with the simplest tech and (3) enhance. If you get (1) and (2) right, you can go crazy in step (3) and use tech that does not necessarily have broad browser support, without witholding core functionality from people. Service Workers, WebGL, push notifications, anything! This approach can take more time if you are not used to it, but it is definitely possible, even on large scale corporate websites (some might say they would benefit the most).

We can make non-default things in HTML accessible to more users with ARIA, keyboard support and focus management

Léonie Watson explained how to make our web applications more accessible (slides). The important part is that everything in our web application exposes three things: their accessible name, their role and the state they are in. This is easy for things that already exist in the web platform, like links, buttons and form elements. Browsers already know their names, roles and states. In other words, default HTML elements are already accessible out of of the box.

It gets more complex when we want to use things that don’t exist as such. Tabs, for example. Léonie showed us how to mark up tab links and tab panels in a way that is most usable for users of assistive technologies, and explained how ARIA attributes can help here. She also showed how to build in keyboard support and manage focus.

With radio buttons and checkboxes we can use logic to make HTML emails more interactive

Mark Robbins is an expert in interactive email HTML. He showed some perplexing techniques for making emails interactive. The trick: making extensive use of the ‘states’ that can be styled with CSS. Things like :hover, :active and :focus, but also :checked (a lot of that). By including a number of radio buttons / checkboxes (and nested labels for them), the document can have logic that can be targeted from CSS. For more advanced logic, a ‘punched card’ can be coded in radio buttons and allow for even more complex hiding and showing.

Using the above, Mark created galleries, interactive games, live shopping cards that can even update prices (using CSS counters), form validation, analytics that work by fetching background images based on :checked states and 3D views of products utilising CSS animations on 3D transforms. At the end of his talk, Mark revealed that even his slide deck was built as an HTML email: he had been presenting everything from Apple Mail. Mind. Blown. While Mark was talking I wondered about the accessibility of it all, and later I found his company has posted Accessibility in email and Accessibility in email part II.

All problems can be solved with CSS

Sara Soueidan showed us some of the work she had been doing on the upcoming redesign of Smashing Magazine. First, she talked about SVG and when to use or avoid it. She said that ‘not only should the image be a good candidate for SVG, the SVG should also be a good candidate for the image’: too many shadows/gradients/paths might mean a large file size and make an image less suitable for SVG (and more suitable for PNG). She also talked about scalable type: type can scale with the viewport when using vw/vh units, but then the need for minimum and maximum font sizes arises (font-size: calc(16px + 3vw can help here; 16px will work as your minimum size).

Some absolute highlights of Sara’s talk:

she showed how a seemingly impossible article layout could be done with CSS
she explained how she made whole blocks with links in them clickable while retaining the focus order she intended
she talked us through building custom ordered lists with CSS counters
she showed a method to do better underlines using text-shadow in the same colour as the background-colour.

This talk once more showed how incredibly flexible CSS is if used by smart people: everything is possible.

We should regularly reflect and listen to our gut feeling

Conference organiser Marc Thiele talked about the changes he had made in his life, recently and less recently, and the events in his life that triggered those changes. They lead to many good things, including his first Flashforum conferences years ago, and his current Düsseldorf/Berlin based conferences about the web in general. He explained that it is important to make time to reflect on the past and encourages the audience not to be afraid to make changes.

Apprenticeships can be a great thing for the web

Dan Mall ended the first day with a talk that strongly encouraged us to start an apprenticeship program within our companies. He shared his experiences with doing so in his own company. Apprenticeships encourage the best form of learning, he emphasised. They don’t just teach things you can learn in a school, they also teach people how to be a professional, act with customers and sell their services. They can decrease the gap between the best of our industry and people who have an interest in joining our industry. To take an apprentice does not have to be expensive or time consuming, Dan’s personal experience showed. Averages from 10 apprenticeships his company hosted, show a cost of about $7000 and a time investment of about 36 hours per apprentice (over a period of 9 months).

We can improve perceived performance by reducing passive phase waiting time

In his talk about the psychology of performance, Denys Mishunov said research showed that people who have to wait too long for specific things on your site, may end up disliking your entire brand for it. Reducing this waiting time and improving performance is not just about numbers, it is about experience as well. Denys discussed two phases in waiting, which he referred to as the active phase and the passive phase. Active waiting is waiting while your brain is still busy with other stuff, passive waiting is just waiting. A wait with an idle brain is perceived as a longer wait. Naturally, active waiting is a lot less frustrating, so a way to improve perceived performance is to make the passive phase shorter (even if that makes the active phase longer). In code, Denys explained, this can be done by taking advantage of resource hints (dns-prefetch, preconnect, prefetch, prerender and preload). In interaction design, it can be done by letting people do stuff while they wait, for example adding meta info to a photo that’s currently uploading.

Serving over HTTP/2 may the best thing you can do now to increase your site’s performance

Patrick Hamann explained to us why it would make sense from a performance point of view to start serving your websites over HTTP/2, given that we have already done other performance optimisations. Slow websites are often slow because of latency, and HTTP/2 fixes a large part of that. The major inefficiency of HTTP/1.1 is ‘head of line blocking’. HTTP/2 fixes this with its ‘multiplexing’ approach: bits of data that are called ‘streams’, of which multiple can go over one (!) TCP connection. A stream carries messages that are made up of frames, like its header and its actual data. Frames are binary, as opposed to data sent as plain text in HTTP/1.1. The advantage of that is that they can interleave, the disadvantage is that they are no longer human-readable. Streams can also have weights attached to them, and with HPACK their headers can be stored in referencable IDs so that they don’t need to be endlessly repeated. Special PUSH_PROMISE can inform the browser about resources it is going to send, saving requests.

To start using HTTP/2 you need HTTPS (Let’s Encrypt helps here) and a server that can handle HTTP/2 (many servers can now) and use its features. If you use CDNs, you also need to make sure they can do HTTP/2. Support is really getting there, and that means HTTP/2 is pretty much ready for adoption.

Voice User Interfaces are coming

Ben Sauer talked about user interfaces that are controlled by voice (VUI). Systems like Amazon Echo, Apple’s Siri and Microsoft’s Cortana. These companies are currently all heavily investing in voice technology and computers that are all around you all the time (‘ubiquitous computing’). They are also trying to normalise voice interactions, by showing their tech in social contexts, making it a lot less weird to be talking to your computer. With voice interfaces, Ben explained, apps will become more plain, or possibly invisible. The brand will likely be less invisible, too: if you ask your voice-based assistent what the name of a song is, you won’t go into a branded app interface, and you don’t need to know it uses the Shazam brand for it.

VUI still needs a lot of work, as it is not so good at large amounts of input, dealing with natural breaks in speech and working out fuzzier tasks. And then there is privacy, a huge issue in my opinion: a lot of VUI requires a microphone to be always listening (and this would be great for your ex or the police to listen in, too).

Your design system will thrive when you group modules by function and get their naming right

Alla Kholmatova did not try to convince us to come up with design systems for our sites, as every site already has one (paraphrasing her). A lot of her talk was about how to make it work better, through documentation and cross discipline collaboration. Integral to Alla’s approach is separation by function (not form): you try to figure out which things on your site have the same functional role, and group those together. Naming is incredibly important when working on the design of a site as a team: once something has a name and can be found under that name in a pattern library, it becomes a thing, it ‘comes into existence’ .

Alla shared five tips with us:

Give your modules names that relate to the system, not to a specific page. Functional names (related to what something does) usually work better.
You’ll likely have some modules that are generic and others that are specific. Let their naming reflect this. It’s okay if a specific thing is at some point changed to be a generic thing or vice versa.
Name things collaboratively and make a point of always referring to the things by the names you’ve given them. This takes effort, but it is very helpful.
Use names with personality, as they tend to stick better. You can use metaphors borrowed from other industries, or even from films. If names are not remembered by team members, you risk duplicate modules being created. Good names inspire other names, Alla said, and before you know it a family of names starts to grow.
If it’s hard to come up with a name for a module, this may be a sign that there’s something not right about the module, you may need to go back to the drawing board.

Another interesting thing Alla shared is that at Future Learn, spacing in modules is part of their design system. They distinguish between types of modules: spacious, regular and ‘cosy’.

Finally, Alla recommended reading How to make sense of any mess by Abby Covert, and looking at the Visual Loudness Scale that Tom Osborne wrote about.

CSS Modules is a JS powered CSS pipeline that addresses concerns with the CSS language

Hugo Giraudel explained what CSS Modules are: a JS powered CSS pipeline that gives CSS namespacing, amongst other things. “CSS is broken”, Hugo said, because it has a global namespace, does not come with dependency management and has no mechanism to share configurations. CSS Modules lets you have all three, and can be plugged into various JS pipelines. Definitely a fascinating concept! It’s easiest to set up with Webpack, but can be used in Browserify or even Gulp. Hugo made a solid case for CSS Modules, however I personally strongly disagree with his premise: that CSS is broken and needs fixing. I admit CSS does not check all boxes that programming languages do, but I think that is because CSS is not a programming language (probably something for another blogpost).

Visual regression testing is most helpful when used on isolated components

Varya Stepanova showed us her approach to visual regression testing, the process of keeping track of visual differences between versions of your application. Instead of automatically testing whole pages, Varya said it is a lot more helpful to test isolated components. She demoed the Gulp plugin she built to do isolated visual regression testing. It uses PhantomJS to take screenshots (see on GitHub). Varya also explained the business value of having a component library with automated visual regression tests on each component: it makes the UI more stable and ultimately lets teams work faster.

If we want to do the good thing, we need to design features on websites with empathy

The last talk of day 2 was by Beth Dean. She shared her fascinating employment history with us, and explained how all these different things she did made her realise the importance of considering emotions in web design. “A lot of people live in a world that is not designed for them”, she said. Ill-considered design choices can give individual users of your site a terrible experience, for example when you send Mother’s Day marketing to someone who’s mother recently passed away. Part of the solution to this problem is to ensure that design teams are very diverse (in age, gender, ethnicity, etc). In addition, it is important for designers to be aware of any privilege they may have, and to have an attitude of empathy towards users.

Originally posted as Things I learned at From the Front 2016 on Hidde's blog.

[email protected]?subject=Reply%20to:%20Things I learned at From the Front 2016">Reply via email

Review: Inclusive Design Patterns

2016-09-21T00:00:00Z

This week Heydon Pickerings’ Inclusive Design Patterns came out. As I was quite fond of his previous work, I insta-bought the ebook version (hard copy will be available from October).

The book does not (only) show you how to write front-end code in an accessible manner, it teaches you how to think like an inclusive designer. That is, a designer that considers the widest range of people possible. Heydon does go into the code involved, but that is mostly in support of the inclusive thinking he advocates.

It’s all about making things work for people

The book shows why creating accessible websites is not a ’bureaucratic box-ticking’ exercise (IDP, 121). It’s not just a matter of slapping on the right ARIA attributes, it is all about envisioning what would give people the best way to experience your site. Designing the best way for people to use your thing. If ARIA helps with that, fine. However, Heydon warns, never fix something with JS and ARIA if it could be done with HTML and CSS.

Inclusive design, says Heydon, has this as its object: ‘the user’s ability to actually get things done’ (IDP, 121; emphasis his). Throughout the book, it becomes apparent that making a product accessible is not a matter of always doing X or always doing Y. You have to always consider (and then test) what works best, has wide browser support and gives the best results.

Inclusive Design Patterns is full of interesting things, like how to use Schema to make search results for your site more accessible, what screen readers voices say and how to tweak that, and giving users feedback on form input with live regions. It contains many real world examples, like filter widgets and ‘Load more’ interactions. Clever ways of making things work. There really is something to be learned for everyone in this book. Highly recommended! (Buy the ebook)

Originally posted as Review: Inclusive Design Patterns on Hidde's blog.

[email protected]?subject=Reply%20to:%20Review: Inclusive Design Patterns">Reply via email

Leaving the Fronteers board: what happened

2016-12-01T00:00:00Z

This week I resigned from the Fronteers board. I tweeted about it earlier, but didn’t express myself as carefully as I would have liked to do. In this post I hope to explain things properly.

TL;DR: Fronteers members democratically voted to hire an external company ran by two former conference team members to take care of the logistics of its conference organisation. Personally it made sense for me to leave the board as a consequence. I think Fronteers has a bright future, and the decisions made can help make Fronteers more professional, and possibly more fair, as less pressure will be put on volunteers that spend too much time on Fronteers.

Also, there should be no confusion over this: this was a perfectly reasonable proposal, which was accepted by a majority of the Fronteers members who came out to vote. Personally, I feel the decision is bad for Fronteers as an organisation that is multi-faceted: meet-ups, workshops, conferences, a job board and lots of community outreach. It puts the conference and its organisers first by making that facet a paid job, and is bad for the other facets. I suspect less volunteers will be likely to choose and spend a lot of time on Fronteers for free. In a year’s time, I think Fronteers should probably review what today’s decision meant for all of these facets.

The discussion was one between people with good intentions and people with good intentions. People who love Fronteers and people who love Fronteers.

My tweet

I tweeted this:

Yesterday I resigned from the @fronteers board after members voted in favour of a proposal that lets some volunteers charge for their work.

This tweet was phrased harsher than I intended. I did not mean any nastiness, but can see that it came across as such. I really should have used different words.

What happened is that people, who were previously volunteers, left the conference team. At the same time they put a proposal forward to Fronteers members, that offered conference organising services through their company. Where I said volunteers would get paid, the nuance is that the company of former volunteers would get paid.

I want to clarify that all of this happened through a fair member consultation in which all members were able to vote. There was no nepotism.

I was planning to leave at some point anyway, as it is almost 10 years ago since I first volunteered for Fronteers (at the first conference). I’ve been involved with most aspects of Fronteers since: more conferences, workshops, marketing, meetups, the board, finances, partnerships, et cetera. The situation brought me to do that a bit earlier and a bit more abrupt.

What happened at the members meeting

Fronteers members voted to hire an external company to take care of the logistics of its conference organisation.

The problem being solved

Fronteers can take a lot of its volunteers’ time. Some volunteers have literally spent 1-3 days a week, for years, working on stuff like the yearly conference. Evenings, weekends, but also lots of day time. Freelancers amongst them had to balance this with their client’s time and had to give up billable time to work on Fronteers tasks. Employees amongst them required lenience from their employers. This has been the case for years and is far from ideal.

It has taken me a lot of time to see the above as a problem, as it all seemed so natural. I also realised that it was in fact a problem that affected me, too. Evenings, weekends, day time. Life/Fronteers balance is important, and it is up to individuals to make sure they make that balance.

The arguments in favour

The proposed solution was ready to execute as it was well defined, with plenty of room for Fronteers to negotiate whatever boundaries necessary.
The members who brought the proposal into vote had done years of volunteer work for Fronteers. To hire their company made perfect sense: they had experience specifically with Fronteers Conference, spent years organising it for free and contributed a lot to what it is now.
They did a fair proposal: their ballpark figures constituted a price that would be hard to get on the market, many commercial conference organisers cost a lot more.
If Fronteers were to hire a company to help with logistics, that company could be held responsible and accountable for various aspects.
Fronteers already outsourced tasks to third parties, such as catering, WiFi and flight booking
Finally, someone recognised The Problem and tried to do something about it.

The arguments against

The proposed solution only solved The Problem for some members. Others also spent evenings, weekends and day time.
This would be weird for Fronteers volunteers that have to work together with the supplier (weirder than working with a caterer, hotels or venues).
I suspected the proposed supplier would be hard to separate from the people behind the company, as they were former conference team members.
Fronteers Conference is the product of years of volunteer effort. Can anyone ever earn any money from that? (This argument regards the caterers, hotels, travel agents etc as fundamentally different third parties, as they are not ran by former volunteers, which is both snarky to even mention and pretty much the case)
I suspected this would completely change how Fronteers works and possibly cause volunteers to leave.

One last point is that others in Fronteers history who have also faced The Problem, are not going to be paid for their past efforts (this includes those who made this proposal). But this makes sense: none of these people acted as a separate supplier, and applying the new rules to volunteers retroactively would be overdoing it.

To get around of some of my concerns, I co-signed Arjan’s proposal which asked the board to investigate the intricacies around paying all active Fronteers volunteers (financially, legally, ethically, etc), i.e. those who spend a lot of time on Fronteers. If all active people were paid, there would be less weirdness. Unpaid people could still remain, and could feel happy to do a lot less work.

My personal context

To give you an idea of where I’m coming from, I would like to share some of my Fronteers history (feel free to skip ahead to the next section). After I was approached to volunteer at the first conference in 2008, I continued volunteering for every single conference until 2013. In the first few years I was a ‘runner’, in the last years I joined the actual team. I was given responsibilities like sponsorship, volunteers, marketing, visual design, speaker curation and even had the honour to be the chair in my last year.

I also took on other tasks within Fronteers: I briefly chaired the marketing and workshops teams, and after I joined the board in 2014, I became treasurer in 2015. The last year was one of my heaviest: I helped Fronteers transition to a new bookkeeper, organised the preparation of two sets of accounts (2014 and 2015), restarted the workshops team and organised four workshops, helped organising four meetups and kept in touch with various organisations for our new front-end community support program.

I’ve very much enjoyed (most of) this. I made many friends, had fun, learned loads and met many friendly Fronteers fans who appreciated the stuff Fronteers did for the community. Yet it did cost me a lot of time. Evenings, weekends, day time.

I resigned from the board immediately after the vote. I had spent about a week contemplating doing this in case of a vote in favour of the proposal. The reason? I accept the decision, but assumed the proposal would take time to work out, and foresaw a backlash that would take the board’s attention for a while. I decided that I did not want to spend my free time on dealing with the situation. I was looking forward to spending the last year of my 3 year board term organising workshops, meetups, community support and possibly the new website. The acceptance of both proposals radically changed the board’s priorities, and I could not see myself stay yet ignore that. I saw an early end as the best way to solve my Fronteers/life balance.

What now?

Both the proposal to hire a supplier and the proposal to investigate paying Fronteers volunteers were accepted at the members meeting. The vote happened and this is now the direction in which Fronteers is moving. The board and others (like Peter-Paul Koch) have constructively started thinking about how to carry out the proposals. This will be a complex task, because there are a lot of questions about the details and conditions.

The 2017 conference will be fine too. It’s going to be the tenth year of Fronteers! The idea is that a team of volunteers will be erected to organise the conference, and that they will be in charge of contracting Eventstack (and any details concerning that contract).

Personally, I committed to keep carrying out my treasurer tasks until the end of the year, including making sure the accounts for 2016 are prepared and transferring all I know to my successor. I will also continue chairing workshop team, and hope to organise many more workshops in the new year. After, I hope to get some new hobbies.

Update: from 1 April I have left the workshop team, I am now no longer involved with organising things for Fronteers

Originally posted as Leaving the Fronteers board: what happened on Hidde's blog.

[email protected]?subject=Reply%20to:%20Leaving the Fronteers board: what happened">Reply via email

On initialising JavaScript from markup

2017-01-10T00:00:00Z

In Don’t initialise JavaScript automagically, Adam Silver argues that we should not rely on markup to trigger bits of JavaScript. I disagree with the advice he gives, and think markup is great place to trigger behaviour. Where else?

A quick disclaimer up front: I believe that when it comes to how to trigger JavaScript, there is no good or bad. There is personal preference though, and mine is a markup-based approach.

In this post I will go into three of Adam’s concerns with that approach. They are about what behaviour is being triggered, how many times and whether hiding complexity is a problem. His post does not go into any non-markup-based initialisation methods, so I can only guess what such methods would involve.

What you’re triggering

With markup to trigger behaviour, Adam explains, it is harder to know what you’re initialising. I think this depends on how your declare the behaviour. Enforcing a solid naming approach is essential here.

This is an approach I like:

<a href="#section1" 
   data-handler="open-in-overlay">
Section 1</a>

Let’s assume a website consistently uses the data-handler attribute (see my earlier post about handlers), with as its value a verb that corresponds to a function name. In the codebase for that website, it will be trivial to see what you are initialising.

In the example, the initialised JavaScript will open a thing called “Section 1” in an overlay. The function name is pretty much self-documenting, and it will live wherever your team decided functions to live.

Another approach is the syntax ConditionerJS uses:

<a href="http://maps.google.com/?ll=51.741,3.822"
   data-module="ui/Map"
   data-conditions="media:{(min-width:40em)} and element:{was visible}"> ... </a>

Conditioner (it’s frizz-free) does not use verbs as a naming convention, but expects module names in a data-module attribute. All modules use the same convention for declaring they exist. Again, there is no confusion as to which behaviour is being triggered.

In the above examples agreed upon data attributes are used to declare behaviour. The reason why I think they are intuitive, is that they look very similar to standard HTML. Take this link:

<a href="#section1" 
   title="Section">
Section</a>

We could see this as a ‘link’ module, that has two options set in its attributes: href tells the browser where it needs to take the user, title sets up which text to display in a tooltip when the user hovers a link.

Or this image:

<img src="temple.jpg" alt="Four monks in front of a temple" />

This ‘image’ module comes with two settings: src tells the browser where the image is, alt can be used by browsers to display to users if fetching the image fails. With srcset and sizes, even more attributes are available to trigger behaviour.

In summary: custom attributes are great to declare custom behaviour, because HTML already has lots of native attributes that declare native behaviour. This doesn’t mean we’re doing behaviour in HTML: we’re doing behaviour in JavaScript, and are merely using the markup to declare the nature and conditions of this behaviour.

How many times you’re triggering

When you trigger JavaScript for each occurrence of classname or attribute, you do not know how many times you are triggering it, says Adam.

Correct, but is this a problem? This phenomenon is quite common in other parts of our work. In a component based approach to markup, you also don’t know how many times a heading or a <p> is going to be on a given page. In CSS, you also style elements without knowing on which pages they will exist (or not), or how many times.

Hiding complexity

[Defining behaviour in markup] is magical. […] Automagical loops obfuscate complexity. They make things appear simple when they’re not.

It’s unfair to markup-based initialisation concepts to label them ‘magical’, as if that is something we should at all times avoid. The label makes it sound like there is a simpler and more sensical alternative, but is there?

We are always going to be applying script to DOM elements, whether we define where scripts run in the scripts themselves, or in the markup they apply to. Neither is more or less magical.

Besides, if using classes or attributes to trigger behaviour is magical, is using classes to trigger CSS also magical?

For example:

h2 { color: red; }

Your browser ‘automagically’ applies a red colour to all the headings. Its algorithms for this are hidden away. That’s good. We can declare a colour, without knowing exactly how our declaration is going to be applied. This is very powerful. It is this simplicity that has helped so many people publish great stuff on the web.

The same goes for my HTML examples earlier. The fact that link title tooltips and alt texts are just attributes, makes them easier to use. The fact that the browser’s logic to ‘use’ them is obfuscated is a benefit, if anything.

Abstracting the complexities of initialisation away also helps to keep code DRY. There is one method for initialisation, which is testable and maintainable. Everything else is just suitable function names declared on well-structured HTML, which themselves are also testable and maintainable.

Conclusion

I think defining behaviour in markup is absolutely fine, and it is probably one of the most powerful ways to define behaviour out there. Looping through elements with specific attributes helps developers write DRY, maintainable and testable JavaScript code. Not looping through elements would do away with most of those advantages, without any clear wins.

There is something magical about how DOM structures work together with the styles and scripts that are applied to them, but that will always be the case, regardless of where our initialisation happens. I would be interested to see examples of approaches that do not use markup to infer what behaviour a script needs to apply where, but until then, I’ll be more than happy to use some of the above methods.

Originally posted as On initialising JavaScript from markup on Hidde's blog.

[email protected]?subject=Reply%20to:%20On initialising JavaScript from markup">Reply via email

Using JavaScript to trap focus in an element

2017-01-29T00:00:00Z

For information on how to accessibly implement the components I’m working on, I often refer to WAI-ARIA Authoring Practices specification. One thing this spec sometimes recommends, is to trap focus in an element, for example in a modal dialog while it is open. In this post I will show how to implement this.

Some history

In the early days of the web, web pages used to be very simple: there was lots of text, and there were links to other pages. Easy to navigate with a mouse, easy to navigate with a keyboard.

The modern web is much more interactive. We now have ‘rich internet applications’. Elements appear and disappear on click, scroll or even form validation. Overlays, carousels, AJAX… most of these have ‘custom’ behaviour. Therefore we cannot always rely on the browser’s built-in interactions to ensure user experience. We go beyond default browser behaviour, so the duty to fix any gaps in user experience is on us.

One common method of ‘fixing’ the user’s experience, is by carefully shifting focus around with JavaScript. The browser does this for us in common situations, for example when tabbing between links, when clicking form labels or when following anchor links. In less browser-predictable situations, we will have to do it ourselves.

When to trap focus

Trapping focus is a behaviour we usually want when there is modality in a page. Components that could have been pages of their own, such as overlays and dialog boxes. When such components are active, the rest of the page is usually blurred and the user is only allowed to interact with our component.

Not all users can see the visual website, so we will also need to make it work non-visually. The idea is that if for part of the site we prevent clicks, we should also prevent focus.

Some examples of when to trap focus:

user opens a modal in which they can pick a seat on their flight, with a semitransparent layer underneath it
user tries to submit a form that could not be validated, and is shown an error message; they can only choose ‘OK’ and cannot interact with the rest of the page
user opens a huge navigation menu, the background behind the navigation is blurred (“Categorie kiezen” at Hema.nl)

In these cases we would like to trap focus in the modal, alert or navigation menu, until they are closed (at which point we want to undo the trapping and return focus to the element that instantiated the modal).

Requirements

We need these two things to be the case during our trap:

When a user presses TAB, the next focusable element receives focus. If this element is outside our component, focus should be set to the first focusable element in the component.
When a user presses SHIFT TAB, the previous focusable element receives focus. If this element is outside our component, focus should be set to the last focusable element in the component.

Implementation

In order to implement the above behaviour on a given element, we need to get a list of the focusable elements within it, and save the first and last one in variables.

In the following, I assume the element we trap focus in is stored in a variable called element .

Get focusable elements

In JavaScript we can figure out if elements are focusable, for example by checking if they either are interactive elements or have tabindex .

This gives a list of common elements that are focusable:

var focusableEls = element.querySelectorAll('a[href]:not([disabled]), button:not([disabled]), textarea:not([disabled]), input[type="text"]:not([disabled]), input[type="radio"]:not([disabled]), input[type="checkbox"]:not([disabled]), select:not([disabled])');

This is an example list of common elements; there are many more focusable elements. Note that it is useful to exclude disabled elements here.

Save first and last focusable element

This is a way to get the first and last focusable elements within an element :

var firstFocusableEl = focusableEls[0];  
var lastFocusableEl = focusableEls[focusableEls.length - 1];

We can later compare these to document.activeElement , which contains the element in our page that currently has focus.

Listen to `keydown`

Next, we can listen to keydown events happening within the element , check whether they were TAB or SHIFT TAB and then apply logic if the first or last focusable element had focus.

var KEYCODE_TAB = 9;

element.addEventListener('keydown', function(e) {
  if (e.key === 'Tab' || e.keyCode === KEYCODE_TAB) {
    if ( e.shiftKey ) /* shift + tab */ {
      if (document.activeElement === firstFocusableEl) {
        lastFocusableEl.focus();
        e.preventDefault();
      }
    } else /* tab */ {
      if (document.activeElement === lastFocusableEl) {
        firstFocusableEl.focus();
        e.preventDefault();
      }
    }
  }
});

Alternatively, you can add the event listener to the first and last items. I like the above approach, as with one listener, there is only one to undo later.

Putting it all together

With some minor changes, this is my final trapFocus() function:

function trapFocus(element) {
  var focusableEls = element.querySelectorAll('a[href]:not([disabled]), button:not([disabled]), textarea:not([disabled]), input[type="text"]:not([disabled]), input[type="radio"]:not([disabled]), input[type="checkbox"]:not([disabled]), select:not([disabled])');
  var firstFocusableEl = focusableEls[0];  
  var lastFocusableEl = focusableEls[focusableEls.length - 1];
  var KEYCODE_TAB = 9;

  element.addEventListener('keydown', function(e) {
    var isTabPressed = (e.key === 'Tab' || e.keyCode === KEYCODE_TAB);

    if (!isTabPressed) { 
      return; 
    }

    if ( e.shiftKey ) /* shift + tab */ {
      if (document.activeElement === firstFocusableEl) {
        lastFocusableEl.focus();
          e.preventDefault();
        }
      } else /* tab */ {
      if (document.activeElement === lastFocusableEl) {
        firstFocusableEl.focus();
          e.preventDefault();
        }
      }
  });
}

In this function, we have moved the check for tab to its own variable (thanks Job), so that we can stop function execution right there.

The importance of web standards and design for accessibility

2017-02-21T00:00:00Z

Yesterday I attended the Inclusive Design and Accessibility meetup (“idea11y”) at De Voorhoede in Amsterdam, which was about development tools, graphic design and, the surprise act, the accessibility of React apps.

Florian Beijers, who currently interns at Microsoft, talked about his experience using text editors. He showed us popular editors like Sublime Text and Atom, and how they are impossible to use for him as a blind user. Some just read out BLANK BLANK BLANK, due to bugs in the underlying framework (Electron, in Atom’s case). It was easy for us all to conclude that the products had not looked into accessibility much. During the talk and Q&A two questions arised: why does this happen, and how hard is it to make products accessible? The why, Florian said, seems to be a combination of lack of knowledge and lack of education, which then also causes accessibility bugs to be deprioritised. If you don’t know that your designs or your code places a burden on some of your users, why make improvements? Then the how. According to Florian, adhering to standards can help a great deal in making things accessible. An example is labeling: if you do not use the standard way of labeling controls in your application, your user’s accessibility tools will not understand them.

Design consultant Agnieszka Czajkowska talked about accessibility from a design point of view. She emphasised that good design can help a great deal in removing barriers for some of your users. To come to good design, she said, it is important to include users early on, do accessibility by default and avoid treating it as an optional feature. This is something I personally see a lot in projects: specific user stories or backlog items for accessibility (‘as a user, I want all the things to be accessible’). It doesn’t work like that, every task should include doing it accessibly. In the Q&A, the discussion moved towards flexibility of interfaces. Some people need more contrast or larger fonts. If an interface is flexible enough, they can use their browser settings to do this. Agnieszka said this comes down to giving users agency: make sure your interface allows for rather than hinders user preferences. In her talk, she showed a practical example of this: on a site she used, text overlapped with other text when she set a larger font size. With responsive design, it is perfectly possible to avoid this.

De Voorhoede’s Jasper Moelker stepped in at the last minute to do a lightning talk that he had done before for the ReactNL conference. In the talk, he used examples from the React docs and showed how they performed in three browsers: Chrome (a modern browser), Opera mini (a proxy browser) and Lynx (a text browser). Sadly, most of the examples worked great in Chrome, hardly in Opera mini and not at all in Lynx. He then showed how to rewrite the examples by using semantic HTML. Basic markup 101 like pairing labels with inputs and wrapping form controls in form elements helped a great deal and made some of the examples work in all three browsers. Takeaway: semantic markup is extremely important. It is a great strategy to ensure your application is understood by the largest amount of browsers/devices possible. Again, as Florian also concluded, following existing standards helps a great deal. Another strategy Jasper recommended is to choose ‘mount nodes’ wisely: some turn their whole body into one big React app, which does nothing without React. Instead, you could turn specific parts of your page into mini React apps, and have the rest of the page contain sensible defaults. The latter likely deals more gracefully with failures.

This was my first idea11y meetup, and I have had a great evening. Many thanks to the organisers for putting this event up and De Voorhoede for their hospitality. I am looking forward to attending again!

Originally posted as The importance of web standards and design for accessibility on Hidde's blog.

[email protected]?subject=Reply%20to:%20The importance of web standards and design for accessibility">Reply via email

Perfwizardry

2017-03-09T00:00:00Z

When Harry Roberts tweeted he would be free to give a workshop in The Netherlands this week, Joël approached Xebia and Fronteers and made it happen. Almost 20 of us gathered in the Wibautstraat in Amsterdam and spent a whole day getting all nerdy about web performance.

Harry told us all about how to sell performance, how (and what) to measure and which tools to use. And of course, how to fix the problems you measure. He also went in to how all of this is impacted by HTTP/2 and Service Workers (spoiler: turn them off when performance testing). The workshop came with plenty of theory, which I liked, as it helped understand how things work in practice. We ended by scrutinising a number of actual websites using the things we learned.

Please find some of my notes below.

Selling performance

When trying to sell performance to others in your company, tune the message towards the audience. With performance, it is easy to get all excited about all the technical stuff, especially as a developer. Concurrent downloads in HTTP/2 may interest your audience less than the forecast of paying less for bandwidth.
Use stats. If your company does not keep them, you can also refer to stats of others, WPOstats is great.
Your users may have capped data plans, they may be in an area with poor network conditions. Think of the next billion internet users, they may not have fast iPhones and great WiFi. See also What does my website cost and Web World Wide.

What to measure

Testing on your own device with your own network helps and it is easy, but it is nowhere near as valuable as Real User Monitoring (RUM). There are services that help with this, such as SpeedCurve and Pingdom. Google Analytics also provides some rudimentary RUM tools.
Beware of metrics such as page weight, number of requests and fully loaded. It depends on your situation if and how those apply to your performance strategy.
Perceived performance is better to focus on, although it is harder to measure. Many automated tools require thorough evaluation. Human judgment is essential.
Speed Index is a good metric to focus on. It is a ‘user-centric measurement’: the number is based on visual completeness of a page.
You can use Speed Index’s median as a metric in Web Page Test by adding ?medianMetric=SpeedIndex at the end of your Web Page Test url.

The network and requests

TCP/IP comes with head of line blocking: if one of the packages fails to come through, the server will request it again and hold up other packages in the meantime.
The network is hostile, assume it will work against you.
Beware of the difference between latency and bandwidth. Latency is how fast a certain path can be travelled, bandwidth is how much we can carry on our journey. Compare it with a motorway: latency is how fast we can drive, bandwidth is how many lanes are available for us to use.
The Connection: Keep-Alive header will leave a connection open for other transfers to happen, preventing new connections (with new DNS looksups, handshakes, etc) having to start all the time.
High Performance Browser Networking by Ilya Grigorik is a great book and it is available online for free. It is very technical, the mobile section is especially great.
Avoid redirects, they waste your user’s time. This is especially true on mobile, where requests are even more fragile.
Beware of whether your URLs have a trailing slash. If you are not precise about where you link to, you can cause redirects to happen. For example, if your ‘About’ page is on yoursite.com/about/, you link to yoursite.com/about and you’ve set up a redirect, you can save your user from this by just linking to the right path in the first place.
Elimate 404s, as they are not cached (this is a feature).
Make use of cache, do not rely on it.
Use compression, for example gzip.
Concatenate your files to circumvent the HTTP’s limit on concurrent downloads (stop doing this when using HTTP/2).

Resource hints to increase performance

In which was likely the most exciting section of the workshop, Harry went into resource hints: DNS Prefetch, Preconnect, Prefetch and Prerender. Web performance hero Steve Souders talked about these concepts at his Fronteers 2013 talk “Pre-browsing”. Browser support for resource hints has improved massively since.

If you use both dns-prefetch and preconnect, set the preconnect header first, the browser will then skip over the dns-prefetch header as it will have already prefetched the DNS.
Long request chains are expensive: this is what happens when you include a CSS file, which imports another, which then requests a font, etc. The browser will only know about the font when it has parsed the second CSS file. With the preload you can tell the browser to preload assets, so that it already has them when the second CSS file requests them.

Anti patterns

Avoid Base64 encoding as it has little repetition and therefore gzips badly.
Don’t use domain sharding (the practice of using different domains to allow for more concurrent downloads) for any assets that are critical to your site, such as your (critical) CSS.
Many of today’s best practices are HTTP/1.1 oriented. When you start serving over HTTP/2, beware some may become anti patterns.

The future

If you serve over HTTP/2, you can benefit from multiplexing and concurrency (download all assets at the same time), improved caching, much smaller headers and Server Push, which lets the server send files the user did not yet request
Service Workers can speed up things tremendously as you can use them to have more granular control over what you serve from where.

Although I was familiar with most of the concepts covered, I did pick up lots of things that I did not know about. There were also practical examples, and Harry explained everything with lots of patience and at just the right speed. If Harry is coming to your town with his performance workshop, I would recommend coming along.

Originally posted as Perfwizardry on Hidde's blog.

[email protected]?subject=Reply%20to:%20Perfwizardry">Reply via email

My last day at Fronteers

2017-03-31T00:00:00Z

So… tomorrow is the end of me volunteering at Fronteers. As of then, I am no longer part of Fronteers’ workshop team. With that, I am officially no longer volunteering at Fronteers. Time for a round-up!

Front-what?

Fronteers is the professional association for front-end developers in The Netherlands. It has about 500 paying members. Some of those volunteer to put up conferences, workshops, meetups, a job board and a Slack community. It was founded in 2007 by PPK, Arjan and Tom and has grown and changed in many ways since.

In this post I will look back at my volunteering for Fronteers, and share some things that I learned.

The cool thing about Fronteers is that it is an organisation that is bigger than its individual volunteers. Although it often heavily depends on the spare time of specific people, stuff can go on. Even when people leave and new people come in. Fronteers history shows this is not always easy and not every detail survives. Often, new, awesome details come into existence, too. Progress happens.

Round-up

For those who find it interesting, I’d like to share a bit of my history at Fronteers. With my apologies for what is sort of blowing my own trumpet – quitting after all those years is quite a big deal to me.

I volunteered at six conferences (2008-2013), of which I was in the organising team of three, one as the chair. I was able to add a few new things to the mix, like subject-first speaker selection and a practical case studies session.
I organised meetups about the semantic web (with SETUP), healthcare and online news (with Lable), RequireJS and MVC (with VPRO), Progressive Web Apps (with Dan and Bran), accessibility (with Thomas and Michiel) and music (with Thomas and Michiel)
I was involved with about 12 workshops (some in 2012, some in 2016/2017), including one about CSS with one of the inventors of CSS
I had two sets of accounts prepared as treasurer and transitioned us away from the accountants that did not deliver many of their promises (it was quite the chase)
I worked on getting 61 of our conference videos captioned (with Krijn and Janita)
I chaired the marketing team from 2011 to 2013 (and was team member from 2008), which produced legendary pens, notebooks, promotional slides, as well as BEERS with the Fronteers logo on

More recently, in August last year I revived the workshops team. With the support of Rachid and Sharon back then, joined by Tim later, we managed to put up a one day workshop every month from September (with one cancelled). This is still happening, with the April one sold out and an exciting one for May in the pipeline (soon to be announced). I found it a lot of fun to be involved with this. It’s all volunteer work, but you get to spend the association’s money on good teachers to provide affordable workshops for all. What’s not to like?

I learned things

I’ve really enjoyed doing all of these things! My feelings about my recent stint at the workshops team is a general theme in most of the things I’ve been able to do at Fronteers. It is an organisation with international connections (and goodwill), money to pay for activities that aim to improve front-end development, and an endless stream of ideas waiting to make it into reality.

Working for Fronteers I learned a lot, although hardly about front-end development.

I learned, for example, that you can try getting things done by yourself, but working together with people who complement you makes it a lot easier.

I discovered that work in an association like Fronteers involves a lot of politics. It takes time to convince people of your ideas, and to learn who needs to be convinced most (this can be the oppposite of what you expected). This takes patience.

On the subject of politics: at times, there would be different ideas at how to go ahead. If we would be working together at a large business, strict hierarchy would have dictated the decision making process. With a group of volunteers that all put lots of love (and time) into their work, debates can be more heated. At these times it is extremely important to look at the bigger picture, because the heat is usually only within the team. Outsiders, or attendees, will likely just see an awesome conference, meetup or workshop.

I found it’s so hard to get it right (we often did not), and that sometimes the best ideas come in hindsight.

I learned to live with not realising ideas, because of time constraints. I tried setting up a system to manage contacts between Fronteers and the outside world, organise more meetups outside of Amsterdam, redesign all of the website with Krijn (we even had one of the best Dutch agencies on board to help), present the financial budget in a way that is less boring and organise meetups specifically to bring volunteers together to work on organising shared activities. Time was a constraint.

I also learned that me being personally delighted about a subject or speaker would not guarantee lots of attendees for an event. Especially in the week before Sinterklaas.

Or that it is important in volunteering to learn to say ‘no’ before it is too late. This helps with focus, and with being able to meet promises and expectations.

I’ve gotten to know this fantastic feeling that goes with putting on something that people enjoy to attend, whether it be workshops, meet-ups or conferences.

Thanks and goodbye

I’m very grateful to Krijn and Arjan for inspiring me to start volunteering at Fronteers, and to PPK, Tom, Sander and Jaco for trusting me to organise things within the professional association they chaired. They were always encouraging as well as very forgiving and patient with regards to my mistakes.

I should also thank all other volunteers that I had the pleasure of working with, many of whom who have become friends. You know who you are.

I’m going to be focusing on other things now, and become a consumer of Fronteers activities. It has truly been a blast!

Originally posted as My last day at Fronteers on Hidde's blog.

[email protected]?subject=Reply%20to:%20My last day at Fronteers">Reply via email

How to make inline error messages accessible

2017-04-04T00:00:00Z

On one of my projects I am helping a governmental organisation to take their application forms to the web. They are mostly very complex forms (for reasons). We do our best to help people fill out the forms correctly and identify incorrect input to them where we can. In this post I will go into some ways to do this accessibly.

Commonly, when an error occurs, an error message is inserted into the page. If you want to do this accessibly, some things to look at are identifying errors as errors, notifying the (screenreader) user of new content and describing what happened in clear language. Below, I will go into how you can improve things in those three areas.

As per WCAG 3.3.1 Error Identification, this is what we need to do:

If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text.

Yes, we can script it

Before we go into identifying validity and error messages, a little note about using JavaScript.

In the old days, a form submit would just trigger the same page to reload, now with error messages where applicable. In 2017, this is still a good practice, but it can be hugely enhanced by preventing the submit and displaying errors client side. And why wait until the submit? You could insert an error message as soon as a user tabs out of a field.

Shouldn’t accessible forms avoid JavaScript? No, on the contrary. They can use JavaScript to inform users about errors as they occur. Combined with a server side approach, this can give us the best of both worlds.

Needless to say: using good old HTML elements is key to your forms to be successful. In this post I go into some ARIA techniques, but always keep in mind that the first rule of ARIA is to not use ARIA. Paraphrasing, this rule means that if you can do it with HTML, don’t use ARIA. The exception to this for things that are not available in HTML. Whether error messages getting injected into the page fall under that umbrella is a case of ‘it depends’. There is the native Constraint Validation API, but it is problematic in many ways (see PPK’s 3 part article on form validation), so in this article I am assuming we are rolling our own validation with JavaScript.

Indicating a field has invalid input

When you detect a field is invalid, you can apply the aria-invalid attribute to it. Then, make sure your scripts are watching the relevant field, so that you can remove the attribute once it no longer applies.

If you were using native HTML form validation, you could style invalid input using the :invalid pseudo class. If your JavaScript is determining what’s valid our not and the aria-invalid attribute is added/removed appropriately, it provides a convenient way of indicating invalid input:

[aria-invalid] { border-color: red; border-right: 5px; }

(Codepen)

Adding and removing the aria-invalid attribute also helps users of screen readers recognise they are on an invalid field. Fields with the attribute are read out as being invalid in JAWS, NVDA and VoiceOver.

Conveying that an error message appeared

When your script has detected input of a field is not valid, it inserts an error message into the page. Make sure it is easy to see that this is an error message, for example by using a combination of colors, an icon and/or borders. It also helps if you indicate that it is an error by prefixing the actual message with ‘Error: ’.

To make sure our error messages are read out to users with screen readers, we need to ensure the accessibility tree is notified of the newly inserted content.

There are two ways that are roughly equivalent, both making use of ARIA attributes: live regions (aria-live) and role=alert (avoid using both at the same time). They turn an HTML element into a live region, which means that a screenreader will read out changes to that element. A change could be that something is appended to the element. Note that for this to work, the element itself has to be present in the DOM on page load. Live regions or role=alert work in VoiceOver and most versions of JAWS and NVDA.

In the implementation I describe below, this would be the flow:

User makes mistake in field 1, tabs to field 2
Script detects mistake, reads out that field 1 is incorrect (or conveys it through big red error message appearing)
Meanwhile, user is in field 2 and can decide to go back and fix, or continue and fix later

Live region

To turn an HTML element into a live region, add aria-live to it. There are various modes, depending on whether you want updates to be read out immediately or not. In our case, we do want that, and will use aria-live="assertive" :

<div aria-live="assertive">
<!-- insert error messages here -->
</div>

If we are watching for fields to become incorrect, it makes sense to apply the same functionality in reverse. If the field is changed and input is now valid, we can remove the errors. We need our live region to be aware of both addition and removal of error messages. With aria-relevant we can set it up to do exactly this:

<div aria-live="assertive" aria-relevant="additions removals">
<!-- insert error messages here -->
</div>

(Codepen with live region examples)

If we want to control whether we need the whole region to be read out, we can use aria-atomic . If it is set to true, the whole live region will be read out if anything changes. It defaults to true. It depends on your situation which setting fits best. If your error messages are displayed in a question-specific live region, this might make sense. If error messages for the whole form live in one live region, it may be a bit too much.

`role=alert`

Instead of manually setting up a live region, you can also give the error are a role=alert :

<div role="alert">
<!-- insert error messages here -->
</div>

This turns it into an assertive live region automatically, with aria-atomic set to true.

Focus management

When inserting a new error message

There is no need to do anything with focus after you have inserted an error message. When you insert it as the user tabs to the next field, they will likely have focused the next field. Intercepting TAB to steal their focus and bring it back to the error message would result in an unexpected experience for the user. I would consider this an anti-pattern.

When preventing submit, because there are still errors

If you have prevented submit, because there are still errors on the page, it could be useful to send focus to a list of errors that you have prepared at the start of the form. Bonus points if each item on that list is a link to the invalid item, to make it easier to correct.

Note that if you use this approach, it may conflict with your assertive live regions, as they will get read out before your list of errors. It may be better in this case to choose between the two approaches.

Language

The above is a quite technical approach that optimises the situation for screenreader users. Another accessibility feature that can be optimised and will improve things for all of your users is the use of language.

Whether your form is complex or simple, make sure your error messages are easy to understand. Use clear and concise language. Be helpful in explaining what is wrong and how it can be fixed. This aids the user to complete the form as smoothly as possible.

In summary

In this post, I have discussed three ideas to improve the accessibility of dynamically added error messages:

identify a field as being currently invalid with the aria-invalid attribute
notify the user when a new error message has appeared, by inserting them into a live region / role=alert
always make sure you explain what went wrong and how to fix it in clear and concise language

Any feedback is welcome!

Originally posted as How to make inline error messages accessible on Hidde's blog.

[email protected]?subject=Reply%20to:%20How to make inline error messages accessible">Reply via email

On hiding content

2017-04-11T00:00:00Z

Sometimes you want parts of your page to be invisible. For example, because all of your application is on a single page. The hidden attribute in the HTML standard is made for this. In this post I will explain how the attribute works, how it differs from [aria-hidden] and how it relates to just hiding with CSS.

What it is

This may be somewhat superfluous, but let’s start with looking at what ‘hidden’ means. Other than ‘not visible’, it also indicates that an element is not relevant.

For modern websites, think of “not relevant” as no longer relevant, or not yet relevant. There’s a thing in your HTML structure, it is not in view and users cannot do anything with it. It just sits there, waiting to be consumed by some script.

How the hiding works

There is a part of the HTML spec that recommends what browsers should include in their built-in stylesheets. For elements with the hidden atribute, it prescribes using display: none. Interestingly, this means hidden elements are treated the same as elements like head, script and title: not displayed (not usually, anyway).

Most browsers do this, but it takes little effort to set it explicitly in your CSS:

[hidden] { display: none; }

It then works not only in browsers that have the above lines in their built-in stylesheet, but also in all others (that understand attribute selectors). I would recommend doing this. By default, most browsers also set elements with hidden="false" to display: none, so when something should no longer be hidden, best just remove the attribute, rather than changing its value.

`aria-hidden` vs `hidden`

There is also a aria-hidden attribute. It differs in default behaviour: an element with aria-hidden is hidden from (just) screen readers, an element with hidden is hidden from all modalities, including screen readers.

Their default visibility seems to be the only difference, as both attributes will take the element out of the accessibility tree.

If you want nobody to be able to interact with a part of your page, I would recommend using the hidden attribute. This also follows the first rule of ARIA: “Don’t use ARIA if there is a native HTML alternative”. In any case, best don’t use both at the same time, as that approach is known to cause conflicts.

Hiding with attributes vs hiding with CSS

Is invisibility not just a visual thing, you might wonder? Why bother with an attribute if all the browser does is use CSS anyway?

In addition to it being a visual thing, hidden content is also a semantic thing. It describes not just what something looks like, it describes the thing’s meaning within the page structure. Therefore, it still makes sense to use the attribute over the styling.

More information

Marcy Sutton did a great screencast showing different ways of hiding content including a demo of how they play out in screenreaders
The hidden attribute in the HTML spec. See also the part about the inert attribute and how it differs from hidden.
Steve Faulker’s hidden content test results

Originally posted as On hiding content on Hidde's blog.

[email protected]?subject=Reply%20to:%20On hiding content">Reply via email

Mom-jokes as part of corporate culture

2017-04-20T00:00:00Z

Dutch retail giant Coolblue showed the world this week that they have a new meeting room, named ‘Your Mom’. They explained in a blog post how this name sets the stage for all sorts of mom-jokes. I think this is not really OK.

The tweet

Personal context versus corporate culture

Before I continue: I am just commenting as a member of the tech community on a situation in a company that does a lot of recruitment in the tech community. Why do I do this as I don’t even work there? What’s my business here? In all modesty, I am just a developer that would like the tech community to be inclusive. I am trying to figure out which things get in the way of this (and how).

The problem, I think, is not with jokes or even inappropriate jokes. Fun is fine! Have fun at work. Banter. As a person, between you and other people. Cross the line, or choose not to. Be as politically correct as you like, I guess. Be childish if you like. Your jokes reflect on your person, they get you in trouble (or don’t). Person-to-person gives context for judging whether lines are being crossed. Unless you are in higher management, on a stage, in public: your jokes likely don’t harm that much.

If you are a company (or manage/represent one), this is different. Companies should be wary of jokes that have sexual aspects in them, because their language creates a corporate culture. You can see this in the example: they’ve painted a mom joke onto a meeting room, their corporate blog explains why this is funny. It has gone from a joke between people who work there, to a joke that is part of the company’s culture.

What’s wrong with a mom-jokes culture

If a joke that crosses the line is on a wall and on a corporate blog, it no longer reflects on one person. Leaving taste out of this discussion, there are problems with getting your corporate culture wrong: it is not good for recruitment, it is not good for your employees and it is not good for the tech industry.

For recruitment

In terms of recruitment, you will likely change the set of people you can pick from. Maybe you will get to pick from more people who like mom-jokes (and, sure, they could be excellent at their work), but you will likely also miss out on people who see them as a red flag. Especially in tech, and especially in the light of recent scandals. You will end up with a less diverse company. Diversity is a good thing (there’s loads written about this elsewhere; the recent film Hidden Figures illustrates how diversity got NASA into space).

For employees

A mom-jokes culture can make the environment less welcoming and possibly less safe for your employees. If you have an issue you’d like to report to HR, let’s say with regards to something horrible like harassment, can you still be sure it is going to be taken seriously? The HR department being part of the management of a company that has mom-jokes in its corporate culture seriously changes this. If one colleague made an inappropriate comment, you can report to the company. If the company itself makes inappropriate comments part of its DNA, where can you go?

For the tech industry

This is the one where my worries are probably most appropriate, as I don’t recruit or work for the company, but I do work in tech: a tech giant with a mom-joke culture makes the tech industry look less professional. It makes the tech industry look less attractive to a diverse group of people. Like I said above, diversity is a good thing. The industry should be cautious not to miss out.

Conclusion

I have nothing against jokes, but as an industry I think we owe it to ourselves to make sure that inappropriate jokes don’t become part of company cultures, as this can harm those companies as well as the tech industry as a whole.

Mom-jokes get in the way of diversity, by attracting people who like such jokes, and repelling those who don’t. This isn’t necessary. There is so much fun to be had in the world without such side effects, we really can do better!

Originally posted as Mom-jokes as part of corporate culture on Hidde's blog.

[email protected]?subject=Reply%20to:%20Mom-jokes as part of corporate culture">Reply via email

Book tip: Turing’s vision

2017-04-21T00:00:00Z

When I visited New York last year, I picked up a copy of Chris Bernhardt’s book Turing’s Vision: The Birth of Computer Science, which dissects one of Alan Turing’s most interesting papers. I’ve been recommending it to various people since, so I thought I would write about it here.

The book

The book aims to explain a number of complex ideas from computer science and mathematics to the general public. “The reader doesn’t have to understand much mathematics — high school provides enough”, Bernhardt explains.

Personally, I’ve had to skip over bits and pieces, but generally, I’ve found it quite accessible. It takes us back to the historical and philosophical basis for many concepts that are still there in modern-day programming: encoding, regular expressions, Lambda calculus, recursive functions, functions that break on certain input, arrays…

On computable numbers

Turing is well known for his leading role in decrypting messages from the German’s Enigma devices for the allied forces, a history recently turned into a film worth watching. He also came up with the Imitation Game thought experiment to tell humans and computers apart, now known as the ‘Turing test’ (and familiar to all internet users as CAPTCHAs). This book does not focus on those things.

The paper central to this book is called ‘On computable numbers, with an application to the Entscheidungsproblem’. Entscheidungsproblem is German for ‘decision problem’: it is the question whether we can write algorithms that can decide if certain mathematical statements are true or false. The problem was defined by Hilbert, one of the biggest mathematicians of his time. He thought such algorithms did exist. The book goes into various examples of decision problems.

Turing wanted to prove Hilbert wrong. To do this, Turing had to define what an algorithm was; he explained this by breaking complex calculations down into simpler parts. He also defined the very concept of computation, using the concept of ‘Universal Machines’, machines that, he proved, can compute anything that is computable. In 1936, this was all still as theoretical as it gets. We have modern computers now; at the time a computer was the job title of a person hired to do calculations.

Conclusion

Turing’s Vision is quite theoretical, but it is a great read for people who are interested in the early days of computing. It’s a good mix of mathematics, philosophy and computer science, and helps to understand in detail the paper that started it all.

Want to hear more about this book? There’s an interview with the writer (mp3, 8MB).

Originally posted as Book tip: Turing’s vision on Hidde's blog.

[email protected]?subject=Reply%20to:%20Book tip: Turing’s vision">Reply via email

Where focus goes when following in page links

2017-04-24T00:00:00Z

Today I learned about the sequential focus navigation starting point, which helps browsers decide what to do with focus when you link to content that is not focusable.

Finding out which element has focus

In a given web page, there can only be one thing that ‘has focus’. As most working with focus management problably know, this is how to find it (roughly speaking):

document.activeElement

(Type this into your Dev Tools’ console or console.log it from scripts).

When you tab through a page and check document.activeElement in between each tab, you will see it is always set to the thing that has focus.

Similarly, if you build a custom widget with JavaScript and manually shift focus, you can use the above to verify that focus has shifted the way you expected. If that thing is in view, you should also see the focus outline visually (assuming you have not set outline to none).

What happens when you follow an in page link

This is what I mean by an in page link mechanism:

<a href="#the-hague">The Hague</a>
<!-- lots of HTML -->
<div id="the-hague">
  <h2>Our stores in The Hague</h2>
  <p>We have two stores in The Hague, one is at De Passage</p>.
</div>

(view on Codepen)

When you follow the link to “The Hague”, focus does not shift to the “The Hague” div, as the console will tell you after activating that link:

> document.activeElement
< <body></body>

Focus was moved to body, not to div#the-hague. The reason is that div#the-hague is not a focusable element (divs, by default, are not), so the browser returns focus elsewhere, in this case the body.

The focus navigation starting point

Something interesting happens with the above example in some browsers. When you TAB after following the link, it does go to the next focusable thing from div#the-hague.

I wasn’t sure what was going on, so I asked on A11Y Slackers, where Alice pointed me at the following. There is a browser feature called the sequential focus navigation starting point, which is a position in the document from which the browser decides where to go when the user presses TAB or SHIFT TAB.

What happened after activating the link in my example is that, though the focus did not move, the focus navigation starting point did.

I’ve made a Codepen to illustrate the above, and the situations in which the linked content have implicit and explicit tabindex.

Other ways of shifting the focus navigation starting point

Browsers don’t just shift this navigation starting point when you following internal links. The spec also recommends browsers to do this when users click somewhere in the document.

Browser support

Not all browsers support the sequential focus navigation starting point. In my tests, it worked in Opera, Chrome and Firefox, but not in Internet Explorer 11 or Edge.

How to customise a file upload control

2017-05-02T00:00:00Z

If your website lets users upload files, you have probably compared the default file upload control with custom solutions. In this article I will show you can have both, using a method that uses the default input, but looks completely custom.

The default file upload

This is a default file upload:

<input type="file" id="file-upload" />
<label for="file-upload">Upload a file</label>

It is one of those HTML elements that has a lot of usability and accessibility built in.

To name a few things that you get for free when using the native <input type=file> :

it can show the file name of the upload file
it can be used with just a keyboard
on phones, it will let your user take a photo or choose to select files from specific apps
on desktop browsers, it will let your user browse the file system
it can be set to allow multiple files to be selected
it can distinguish between file types with its optional accept attribute
it exposes a useful files DOM attribute for usage in your scripts (as well as a slightly less useful value)
it integrates with your browser’s built in error mechanism

File input that matches your brand

Something you probably don’t get for free is a smooth integration with your brand’s design guidelines. They might prescribe buttons to be blue or rounded corners everywhere.

The HTML example above related the input with a corresponding label. I used corresponding for and id attributes, but wrapping the input inside a label works just as well.

In all browsers, you will find that you don’t actually have to click the input to activate it: clicking the label will do. Because of this, the trick, which I learned from Krijn, is simple: hide the <input/> and style the <label> .

Hide the input

You want to hide the input, but do that in a way that screenreaders don’t assume it does not exist. The method for hiding is to make it ‘visually’ hidden, but not actually hidden to assistive technologies.

This is one way:

input[type="file"] { 
  opacity: 0; /* make transparent */
  z-index: -1; /* move under anything else */
  position: absolute; /* don't let it take up space */
}

There are various different approaches to this, the important thing is that the method does not render the input unusable (as visibility: hidden would, for example), or move it off screen (as left: -9999em would), as that would move any native error messages off screen as well.

Style the label

Now, only the label is visible and you can style it however you like. You can make it look like a button, add background gradients, drop shadows, whatever your heart desires.

Add focus styles

It would be good to add the focus styles that your input had to the label. You can select this in CSS as follows:

input[type="file"]:focus + label {
  outline: 2px solid;  /* example focus style */
}

TL;DR

To make a custom file upload control, use a standard file upload and label, then visually hide the input and style the label.

Update: On Twitter, Phil pointed out that if you use the above example, users can’t see the file name of what they’ve uploaded. This is a great point; in my own implementation I’ve used some JavaScript to access the input’s files property onchange of the input, which I then inserted into the page if it had changed (I’ve created a Codepen to show how to do this)

Originally posted as How to customise a file upload control on Hidde's blog.

[email protected]?subject=Reply%20to:%20How to customise a file upload control">Reply via email

Accessibly labelling interactive elements

2017-05-05T00:00:00Z

All interactive elements should have accessible names, says the W3C about using ARIA. They can also have descriptions. Names and descriptions can help your users figure out which elements they are interacting with, and what they are for. In this post I will explain implicit and explicit labelling methods and discuss how to future-proof your labels.

Accessibility tree

Besides a DOM tree, browsers build an accessibility tree when they render pages. It contains all interactive elements, so that it is easier for assistive technology (AT) to expose a page and its controls to their users. Being aware of how your markup influences the accessibility tree helps a great deal in making your app work for those users.

Interactive elements are things like links, buttons, form inputs and <details> with a <summary> and <audio> with a controls attribute.

An accessibility tree contains accessible objects, which can have these name-related properties:

accessible name
accessible description

The properties that result in an accessible name are often called label, this is why from the next section I will be calling them labels.

Name vs description

Both the accessible name and the description can provide text alternatives for interactive elements. The difference between the two is that the description is more detailed than the name, and that it is additional, where a name is essential. Generally, it is more useful to provide a name and no description rather than the other way around.

Inspecting the tree

If you want to look at the accessible objects in pages you are building, install the Accessibility Dev Tools in Chrome. With those turned on, go to a website of choice, inspect an element and look at the properties under the Accessibility tab. If you’re on Windows, aViewer lets you browse what accessibility APIs of multiple browsers are exposing.

Labelling with standard HTML

Most of the time, browsers can compute these things from your HTML structure. To make this work, just use standard HTML conventions. With those, your accessible names and descriptions are implicitly exposed.

Labels

This structure, for example, uses a <label>:

<label for="element-1">Phone number</label>
<input type="tel" id="element-1" />

The browser infers the accessible name for the input from the label, so no extra work is required, the input will appear in the accessibility tree with a sensible name.

You can also label an interactive element without rendering the label on screen, with a title attribute:

<audio src="great-song.mp3" title="Great song" controls></audio>

‘Great song’ will be used as this audio fragment’s accessible name, so a user trying to figure out what this audio file is, will be presented with a label.

Descriptions

There are various native ways to associate a description with an element, for example:

a <legend> in a <fieldset>
a <caption> in a <table>

None of the above are interactive elements, though. This is because for interactive elements, there is no implicit method to add a description without ARIA.

Labelling with ARIA

For some elements there are no labelling methods that use standard HTML. The <label> element, to name one, is just there for form controls. WAI-ARIA allows for more explicit association of labels, with these two properties: aria-labelledby and aria-describedby .

Labels

With the aria-labelledby attribute, you can use another element as the label for your interactive element. This is for cases where no native labelling method is available.

The value of aria-labelledby should be the ID of the element that labels it. You can even add multiple IDs (separated with spaces). Use with care, as in many cases this would cause the label to be unhelpfully long.

Example:

<h2 id="label-lasagna">Lasagna recipe</h2>
<p>To make this lasagna, just follow these 
10 simple steps! <a href="/posts/name-change" 
aria-labelledby="label-lasagna">Read more</a></p>

“Read more” is not a useful label, as you can imagine what would happen if this component is repeated a couple of times on a given page. A screenreader user tabbing through the links on the page would just hear:

Link Read more Link Read more Link Read more

As the title above the text, I have chosen something that would work well as a label for the link text. I’ve associated it with aria-labelledby . In many screenreaders, a user that tabs over the link will hear ‘Link Lasagna recipe’ instead of ‘Read more’ (PowerMapper have comprehensively tested this technique).

Another example:

<h3 id="label-song-4">4: It never entered my mind</h3>
<p>The fourth song, “It Never Entered My Mind” is a show tune from the 1940 Rodgers and Hart musical Higher and Higher (1940), where it was introduced by Shirley Ross. The Miles Davis recording was used in the movies Runaway Bride (1999) and the Lenny Bruce biopic Lenny (1974).</p>
<audio src="4-mind.mp3" controls aria-labelledby="label-song-4">

This exposes ‘4: It never entered my mind’ as the accessible name of our audio fragment. When a user tabs onto the audio button, a screenreader should read out the title (this is in theory; in practice, support for aria-labelledby on <audio> is actually quite bad).

If, for some reason, your label is not visible on screen and you want to add it for screenreaders only, you can also use aria-label with the actual label text as its value. I would not recommend this in most cases — if a label is helpful, why only show it to some of your users?

Descriptions

The aria-describedby lets you associate an element with another element as its description.

Example:

<input type="checkbox" id="accept-terms" aria-describedby="small-print" />
<label for="accept-terms">Accept our terms</label>
<p id="small-print">Note that upon accepting our terms, you also agree to us calling you with offers for beautiful kitchens, mortgage plans and magazine subscriptions.</p>

The small print text will display, but by associating it with aria-describedby you make it easy for assistive technologies to provide a description for the input to their users.

This can help screenreader users that are tabbing through the form, to make a better choice about whether to accept the terms.

Future-proofing labels and descriptions

Arguably, the best labels and descriptions are the ones that are up to date. The ones that have been added properly and provide useful, sensible text, explaining what a control is for.

This is harder than it may sound. As Mark Pilgrim concludes in his post about longdesc, a theoretical solution does not necessarily provide ease of use to your users. He cites statistics that say that “less than 1% of images that provide a longdesc attribute are actually useful”. Wow!

Risk of breakage

One way less useful labels can make their way into your product, is because of human error or even unintended sloppiness. By yourself, by another team member, by a team member 3 years from now. A developer could add the proper associations now, only for someone later in the process to break it unintentionally.

Maybe one of the content editors forgot that a heading was associated as a button’s label, and changes it into something that no longer labels it. Or it could be that a developer isn’t aware of the latest aria-* attributes and breaks something. Note that such breakages can happen without anyone noticing.

Avoiding breakage

An approach to get most out of your labels in the long run: make sure the labels and descriptions can be seen by everyone on your product team and by all of your users. It then happens where everyone can see it, which helps fixing any breakage as it happens.

Another thing that can help is to have a component based approach. In a component, you would usually associate variables rather than actual values (i.e. aria-labelledby="" instead of aria-labelledby="might-forget-this-is-here" .)

Lastly, I would recommend making sure the labelling approach is addressed in documentation and that all testers / reviewers in your team(s) are aware of what the attributes do, so that they can spot any issues before they go live.

In conclusion

To help all users make sense of your page, ensure all interactive elements are properly labeled and have descriptions where appropriate. There are several native techniques to do this, as well as ARIA attributes.

To associate labels with interactive elements, always prefer native methods as they will have the best browser support and there is most chance your users and other developers are familiar with them. If native labelling really is not possible, use aria-labelledby (if label is rendered on screen) or aria-label (if label is not rendered on screen). To associate descriptions with interactive elements, use aria-describedby .

I, Daniel Blake

2017-05-24T00:00:00Z

In what was a truly inspiring afternoon at the client last week, we watched the English film I, Daniel Blake. It is about a carpenter of nearly the pension age, who applies for income support following a heart attack.

The client is a semi-government organisation that builds software for citizens to manage income support applications online. When I first watched I, Daniel Blake when it came out in November last year, I was moved, but also inspired. This film was about the very thing we were working on, and there was so much to be learned from it.

The plot of the film, which won the Palme d’Or at Cannes in 2016, is fairly simple (spoilers ahead). Mr Blake wants to apply for income support, as his doctor has told him he should not work. For some reason, his application gets denied. A mountain of bureaucracy follows soon after. The staff tell him he could appeal, but as an appeal could take months, they recommend him to apply for job seekers’ allowance instead. He does so, but is then asked to prepare a CV and apply for jobs, which he ends up getting offered but cannot take because of the aforementioned doctor’s advice. Mr Blake patiently jumps through all the hoops the system forces upon him, until the point he does not want to take it anymore.

Stills from the film

People as numbers

In the film, Mr. Blake often tells staff he engages with about his heart condition. He’s the example of a perfectly reasonable person. Yet he finds they ignore what he says, and are only willing to look at what the system says about him (which is: ‘application denied’).

The film shows a bureaucratic system that regards people as applicants, service users or ‘clients’: like numbers. I don’t think that is inherently good or bad. All software that deals with people represents them as fields in a database. I guess this aids efficiency: if all people are in a database, it is easier to make estimates, identify people and their details, et cetera. This only turns into a problem when people are also reduced to numbers. If the number are the only thing the system is interested in.

What happens to Daniel Blake is an example of the latter. Was he treated humanly, a heart attack and a doctor’s recommendation would be plenty of indication for the system to just give him the income support he applied for. Now that he is treated only as a number, the system forces him to jump through hoops needlessly.

Human judgment

Services that used to be mostly physical are transforming to their mostly digital equivalents. Although I am just a front-end developer, I am often involved in teams that realise such transformations. Most of my work revolves around trying to make interfaces easier to use and being inclusive to all who need to use them. I, Daniel Blake was a good reminder that those ambitions can still leave people frustrated.

However user-friendly we try to make our interfaces, a digital service is not going to help everybody. Sometimes the best interface is an actual human being that helps people. Machine judgment is great and efficient, but the system needs human judgment. Equipped with appropriate authorisations, humans trump digital services: the very person sending Mr. Blake to a cv workshop could have just authorised his income support (and gotten on with the next applicant – now that’s efficiency). To help him skip the hoop-jumping.

It was fantastic to get the chance to watch this film with colleagues, and I can’t recommend it enough to peers who work on digital services (government or otherwise). I’ve heard some say it is overly dramatic. It may be, but I found it realistic and close to reality, too. Looking forward to hearing what others think about it!

Originally posted as I, Daniel Blake on Hidde's blog.

[email protected]?subject=Reply%20to:%20I, Daniel Blake">Reply via email

ICONS: five questions about screen readers

2017-06-02T00:00:00Z

This week I attended the last ICONS meetup of this academic year, which had as its speaker Léonie Watson. She shared five questions related to screen readers.

ICONS is an event organised by the design department of the Hogeschool van Amsterdam. They invite (web) design related speakers, as well as students and people working in the web industry, so that they can meet each other and learn stuff. Awesome! I took some notes of Léonie’s talk, please find them below.

Léonie Watson in Amsterdam

Five questions

Who

Some might think screen readers are just used by blind people. Léonie explained they have a broader audience: people with impairments in the autistic spectrum use them (screen readers provide a way to navigate information with less distraction) and people with some forms of dyslexia (as listening may be easier for them than reading). In the future, many others may use audio to navigate information: think about digital assistents like Siri and Cortana, or voice interfaces in the car.

What

A screen reader, Léonie explained, ‘translates on-screen content into synthetic speech’. Some can also do braille, but equipment for this can be costly. They are available on most platforms, including mobile platforms. Some are free (NVDA, VoiceOver), others can be quite expensive (JAWS). They don’t read the whole page as if it were plain text (as they used to do in the old days), they interpret a page structure and let their users benefit from shortcuts. For instance, a screen reader user could navigate through just headings, or press the ‘read next paragraph’ shortcut.

Where

Most of the interpretation for screen readers happens on the OS level. Things in the OS expose their role, name and state, and through platform level accessibility APIs, this information is referred to the screen reader. There exist accessibility mappings between the OS and the browser. Note that browsers don’t always support all accessibility features: they sometimes support a new web platform feature, without also accessibility supporting it. Which means:

(…) it is usable by people who rely on assistive technology, without developers having to supplement with ARIA or other additional workarounds.

(source: HTML5 Accessibility, a website that holds information on accessibility support in browsers)

When

In the browser, an accessibility tree is generated based on information in the DOM tree. This process basically means that the browser is figuring out what the role, name and state of things are, and puts them in a tree. Screenreaders use platform APIs to access information in this tree, and then make all the shortcuts possible for their users.

A quick note on this: as a front-end developer, you can directly influence what information gets exposed by making sure you use a semantic HTML structure and get your labelling right (see also: Accessibly labelling interactive elements). States are harder, but there are native HTML attributes available for this (i.e. hidden and open, as well as ARIA polyfills).

Why

Then, the last question: why? This was mostly aimed at designers and developers making websites: why would they support screen reader users? Léonie gave lots of reasons: it feels good, it’s fun to work on something others enjoy using (isn’t that why we add subtle animations, choose good looking and nicely readable fonts, make our stuff load fast etc). Secondly, it is a professional responsibility to ensure what you make is usable. Thirdly: as a designer or developer, you have a choice (as opposed to the users that rely on screen readers to access your product).

These five questions are certainly something to think about when you are making websites that are used by people who rely on screen readers. And that’s very likely to be every website or web application.

It was a pleasure, as always, to hear Léonie talk about using screen readers and share her knowledge. Thanks to the HvA for setting up this event!

Originally posted as ICONS: five questions about screen readers on Hidde's blog.

[email protected]?subject=Reply%20to:%20ICONS: five questions about screen readers">Reply via email

Browser API Special and CSS Day

2017-06-16T00:00:00Z

This week, the 5th edition of the yearly CSS Day took place. It was preceded this year by something called Browser API Special: a full day about JavaScript APIs.

I’ve done a quick writeup below, with some of my takeaways and some things I thought were quite brilliant. If you’re interested in more of CSS Day, the organisers have announced there will be another edition next year, updates for which are available through the newsletter. If you want to experience more of this year’s edition, there will be videos!

Access to almost everything through JavaScript

The general theme of Browser API Special was that browsers are starting to expose so much stuff via JavaScript. Animation, virtual reality, payments… more and more is made available through useful (and some less useful, see below) DOM APIs.

The day started with Rachel Nabors, who explained how CSS transitions, CSS animations and SVG animation standard SMIL are now combined into one Web Animations API. This API provides a bunch of methods to let us animate stuff on the web more efficiently. Her examples were helpfully based around Alice in Wonderland. This made the code examples much easier to understand (cake.animate() instead of foo.animate()).

Then Peter-Paul Koch counselled us (PDF) on the usefulness of :valid/:invalid in CSS and the Constraints Validation API. The latter is a standard that, in theory, lets us offload the logic of dealing with form validation and requiredness onto the browser. It and the CSS pseudo classes contain some helpful stuff, but there are issues with timing (errors on keypress or submit, where blur would make more sense), customisability (can’t change what the error message is) and stylability (can’t style error messages).

Philip Walton then went into how to polyfill stuff in CSS, or in other words: add custom functionality to it. Wait, wut, extending CSS via JavaScript? Yes! Suppose you would like to have a random() function in CSS that you could use within calc(), what would you need to do to make it work? Browsers let us access the CSS Object Model, but using that to then try and replicate cascading and media queries and what not after the browser has already evaluated all its stuff raises the question: why doesn’t the browser help us a bit here? Houdini has a set of low-level JavaScript APIs that let us access the stuff browsers do when parsing CSS (paint, layout, parsers, etc), which is awesome as it lets us interact with our custom functionality right in the browser dev tools.

Ruth John showed us that websites that are enhanced with audio aren’t always an awful thing: wonderful experiences can be made with it as long as we’re considerate and subtle. She also showed what the code looks like to interact with fragments of audio. From creating a new AudioContext to using that to do all sorts of wonderful things. You can use Web Audio API to create your own sounds or do so with the help of MIDI devices. Very inspiring!

Ada Rose Edwards asked us all to put on the VR headsets that had been handed out during the breaks, and showed us some cool demos of WebVR. There was even one that had ourselves in it, which was an interesting experience. At some point it had 178 of us logged in at the same time.

Mike Taylor shared all sorts of weird things that are now in browsers and probably will be in browsers for the foreseeable time, for all kinds of weird and usually historic reasons. He explained it is good if functions don’t have all sorts of side effects, and that window.showModalDialog does. How stuff gets capitalised is complex and various mistakes have slipped into browsers regarding this. Vendor prefixes can be hard to get out of browsers once they are no longer needed.

Patrick Kettner went into Progressive Web Apps and kind of showed how turning your app into one can benefit your app’s potential: it can show up in the Windows app store (as Bing indexes PWAs and can automatically add them into the store if you want that), and lets you access platform APIs for things like Bluetooth and media keys from the browser.

Chris Wilson, who was the first to implement CSS in a browser (way back), talked about both managing credentials of users (and ways to make that easier for users) and the Web Payments API. This lets the browser be aware of a user’s payment methods and allow users to pay from their browser. Lots of food for thought, i.e. what sort of new payment providers will come up, and will it be useful if the Dutch iDeal system hooks into this (I think it already works very well on mobile, but this may vary per bank)?

There was so much stuff in today’s talks that, had you asked me five years ago, I would have thought could only be done in native apps. Native apps have traditionally been able to do more with hardware than web apps, but that seems to have rapidly changed. This is a good time to be a web developer.

The history, current state and future of CSS

Day two had everything in it from the history to the future of CSS. Generally speaking, I was very pleased to see into how much detail many of the speakers went. As someone who writes CSS almost daily, I benefit a lot from its simplicity. A lot of things happen automatically and ‘just’ work. To make that possible, specifications and browsers do tend to get quite complex and detailed. CSS Day 2017 was a great chance to learn more about those details, and will likely help me get even more out of CSS.

CSS-inventors Bert Bos and Håkon Wium Lie opened the day. I had seen both talk before, but never in the same room. They used their session to reflect on stylesheets: what would they have done differently, what are they happy with? The syntax, absolute positioning, collapsing margins and scrollbars were some things the two would have liked to have a second chance at.

Bert and Håkon looking at the first proposal for “Cascading HTML stylesheets”. “HTML” was dropped from the name, as there were other markup languages around and stylesheets seemed fit for those, too.

An interesting aspect in the discussion: CSS was meant for documents, which is what Bert and Håkon had a history in, as opposed to UIs. There has been talk about a second language to do UI styles. An example of a difference: documents benefit from collapsing margins and text flowing the way it does, but that kind of stuff can get frustrate styling UIs.

Another fascinating topic was that they would have loved CSS to consider wholes rather than parts. In order for something like ‘make all p’s display in italics’ to work, an alghoritms can do this thing by thing. In order for something like grid to work, an alghorithm needs to consider the whole (sub)tree and place stuff.

A general theme I took from Bert and Håkon’s discussion was that so much effort was put into keeping CSS as simple as possible. Stuff like the cascade: it was put in so that authors can write a lot less CSS. Food for thought!

After this magnificent opening, Rachel Andrew talked to us about CSS Grids. I loved how the talk really went into the nitty gritty, and I have lots to look up at home: blockification and inlinification for example, and the difference between outer and inner display types. Rachel also went into why subgrid is not happening (yet) and what makes it hard to replicate with other CSS properties. She also explained how CSS Grid’s writing mode awareness impacts its syntax. Lastly, a great tip she gave: if you’re confused about what your Grid is doing: try and use longhand syntax to make debugging easier.

After the break, Mark Boulton gave us an introduction in grid design for the web. After a bit of graphic design history, and making the argument against just using 12-column grids for everything (hello Bootstrap!), he explained a grid design method: start with a constraint, base units on that constraint and then create a grid based on those units. All of this, he emphasised, fits the best order to grid design: start with content and base a grid around that, not the other way around.

Jen Simmons talked about Writing Modes in CSS: a standard that lets us build websites with content in all modern (spoken) languages, whether they are written horizontally or vertically, left to right or right to left. There are major differences here in languages: Arabic (rtl), Mongolian (vertical, ltr) and Han-based languages (vertical, rtl or horizontal, ltr). Inline direction and block direction are important aspects in understanding Writing Modes (check the spec for details). If you’ve switched writing modes (with lang and dir attributes), the browser will then do its stuff (create space for elements; apply cursors, etc) with the correct writing mode in mind.

Jen Simmons with her slide that shows examples of ‘logical properties’ in CSS: rather than ‘left’ and ‘right’, ‘start’ and ‘end’ are more meaningful as they are direction-agnostic.

Variables may be a thing most CSS developers know from preprocessors, but they have become a (well-supported) thing in CSS. With --foo: bar we can set custom properties, and Gregor Adams showed some amazing examples of what can be done with that. A supports table where properties were updated within @supports queries so that they only got the true value when the feature is supported (this works because they are scoped), as well as an actual working calculator. Awesome stuff!

The author of many modern CSS specs, Tab Atkins, was in today to tell us all about Houdini, which is a set of JavaScript APIs (and some CSS stuff) that makes CSS extendible by its users. If the community goes ‘we’d like masonry in CSS’ or ‘can we have a random() function?’, it will soon be able to add those things to CSS themselves, using JavaScript. His talk contained near future stuff like methods to register custom properties, as well as new things that are yet to be finalised, like custom units and custom paint functionality. And then there was stuff that really does not (yet) exist: a CSS.parseRule() method so that we don’t have to reimplement all stuff browsers do with CSS in our own JS libraries, custom functions and custom @- rules.

Tab Atkins introducing what could be quite a simple way to define custom functions in CSS (does not exist yet)

The last block of talks started with CSS-Tricks and CodePen founder Chris Coyier. In a talk full of questionable pop music, but also many tasteful examples, he showed us best practices for making a fan site for our favourite band. Four properties were central to his talk: shape-outside, offset-path, clip-path and d. He demoed how they can help making a lyrics page have more interesting visual effects. All four are awesome properties well worth checking out, but d stood out to me: its value is a path() function that lets you override a path in an svg. I had no idea this sort of stuff could be done!

Closing this wonderful day was Stephen Hay. He talked about various things that people with bad intentions can do to exploit security issues caused by bad (but also good) CSS. Who would have thought that using classnames could lead to vulnerabilities? Some stuff is luckily no longer possible, like adding JavaScript into the url() method of CSS backgrounds and looking into a user’s browsing history with getComputedStyle on visited links. Stephen also discussed dark patterns, like unsubscribe flows that lure you into resubscribing.

I’ve had a blast! After having worked as conference staff for the first 4 editions, this year I had the honour to work on the design part of CSS Day, doing poster, slide and badge designs with silly CSS jokes on. I was happy (almost) all of it worked out well. And that I got to watch all the talks!

The talks were just fantastic. There are a lot of specs and APIs that I will have to read up on, but I’ve also learned plenty of practical stuff to use at work straight after this weekend. It was awesome to see how much effort spec writers and browser makers put into making stuff easier and simpler for both end users and web developers. They also do more complex stuff: Houdini comes to mind. Although that might not be fair: Houdini will help people extend CSS, and although the extending itself may be complex for people who normally write CSS, making use of extensions can be made very simple. Just like existing CSS properties and functionalities.

For those who have missed this year’s edition, as I said before, there will be a UX Special and CSS Day next year: 14-15 June 2018 is the date to save!

Originally posted as Browser API Special and CSS Day on Hidde's blog.

[email protected]?subject=Reply%20to:%20Browser API Special and CSS Day">Reply via email

Pseudo classes vs pseudo elements

2017-06-22T00:00:00Z

Something I thought I knew, but found out this week that I did not: the exact difference between pseudo classes and pseudo elements in CSS.

Pseudo classes let you style an element based on its state, says MDN (:checked, :valid, :disabled). This also implicates that they refer to an existing element: something that is already in the DOM available to style.

As a rule of thumb, what a pseudo class offers, you could have achieved with a classname. Not that that would be very practical – for most pseudo classes you would need to detect some stuff with JavaScript to work out the state and add that class; so yay CSS for providing this!

Pseudo elements let you style things that are not actually elements. They can be parts of existing elements (::first-letter, ::first-line), including parts that exist temporarily (::selection). Generated content also falls within the pseudo elements bracket (::before, ::after).

Rachel Andrew said it beautifully at CSS Day 2017: “The more I know about CSS, the more I realise I don’t know” (photo: Bernardo Baquero)

Thanks Krijn for pointing me to this.

Originally posted as Pseudo classes vs pseudo elements on Hidde's blog.

[email protected]?subject=Reply%20to:%20Pseudo classes vs pseudo elements">Reply via email

Coherence, Lego and how naming things is hard: Patterns Day 2017

2017-07-01T00:00:00Z

Pretty much all of my projects in recent years have involved pattern libraries: setting them up, promoting their usage and coding actual patterns. So when Jeremy Keith of Clearleft announced he would host a Patterns Day, I bought a ticket instantly. A full day of design system nerdery sounded like a great thing to travel to Brighton for. And it was definitely worthwile…

Pattern libraries can be hard to get right: not only do you need to gather patterns and put them in a library, you’ll likely also want to avoid code repetition, make sure they integrate with your application code, get others in your organisation to care for and use the library and find a way to make the distinct modules you’ve created form one sensible whole. Patterns Day conference covered all of these subjects and more.

Audio of the day is available as podcast on Huffduffer, videos have also been recorded and will probably follow soon.

The talks

The conference had a fantastic start with Laura Elizabeth, who talked about selling design systems. She said they are great as they ensure consistency, shared vocabulary and understanding of the medium for less technical people. They also have problems: keeping them maintained is hard, they are a lot of work (often underestimated), and there is a chance they won’t be worth the investment. Laura explained that making the case for design systems can be a two step process: first, find a common pain, then gather data. According to her, a pattern library works when the need for it is equal to or larger than the effort require to build it (and that effort is usually huge). My main takeaway from this talk was: if you want to do well at selling your pattern library, be aware of potential shortcomings and gather data to support your claims.

The second talk of the day was by Ellen de Vries (we’re not related, not as far as I know anyway). Her talk was lots more theoretical and went into what it means for a system to be coherent. One way to improve coherence, and this is something we can learn from architecture, is to look at more than just the parts and consider the usage of our designs by people and the larger world around the design (when a performance area is designed for a park, the designer could consider what the charge for attending concerts should be). A story in books or films can be defined as personal experience in space over time. A story in books is a more fragmented experience: content guidelines can help users make more sense.

After the break, Sareh Heidari took the stage. She works at BBC News and told us about both their design language (GEL) and their approach to CSS architecture (Grandstand). Turning things into a pattern helps avoiding the repetition of CSS. Grandstand has namespaced objects and utilities, but also mixins to aid localising typography and grids. These mixins effectively turn direction-dependent properties into direction-agnostic ones, so that one rule can be used in generation of stylesheets for both left-to-right and right-to-left languages. Sarah also emphasised how important communication is, if you want to keep your codebase lightweight (challenge those who want to add new variations, they might not be absolutely necessary).

Sareh Heidari explaining mixins for localisation

In the next talk, Rachel Andrew discussed two bits of software I use almost daily: Fractal (a component library tool) and Perch (the CMS this website runs on). She recommended making your pattern library the single source of truth for UI styles (as the Perch one is for Perch’s UI), and choosing a pattern library approach that makes renaming trivial (as Fractal does) so that you don’t need to worry too much about naming. A pattern page is like a reduced test case, Rachel said, and they’re great for experimenting in isolation. I had never thought of it like that, but realised that is certainly something I use pattern pages as.

Rachel Andrew showing Perch’s Fractal instance

After the lunch break, Alice Bartlett talked about the Financial Times’ Origami pattern library, specificly about what’s next when you’ve built your actual library. She explained templating is ok for a specific stack, but hard (impossible?) to do right if your organisation has multiple stacks. No templating at all is likely a bad idea that causes duplication and makes simple changes like classnames hard. Serving CSS/JS is easy if you serve everything always (can work if your site is not too complex), but separation can be done. Origami has a repo for each individual pattern so that projects that use it can use just what they need (or include just that from the Origami CDN if they don’t want to bother with asset management). Rule for all of this: choose the simplest for the job (the best tooling is no tooling!). Alice also went into non-technical aspects of pattern library success in big organisations: have fantastic documentation, put effort in making sure people in your organisation are aware the pattern library exists (so: do marketing, basically) and have a support channel and incident reports.

Jina Anne did something completely different and read a story to us, which was beautifully illustrated on the slides that complemented it. I’l have to refer you to the videos for this.

Paul Robert Lloyd let us look at the bigger picture, with some interesting examples from architecture. He asked a number of thought-provoking questions about how our choices are informed: is there room for irrationality when our design systems embrace mathematical precision, do the tools we use dictate our approach to design systems (like Photoshop’s ’New File‘ screen asking for dimensions), does culture affect our decisions and do we serve the interests of the organisation we work for or those of the people affected by our work?

The last talk of the day was by Alla Kholmatova, who has spent years researching design systems and how companies use them. For her forthcoming book, she interviewed style guide people from various large companies. Her talk was about three aspects where design system implementations can differ: strictness, modularity and organisation. The first is about how strictly the system is enforced: are there rules that no one can differentiate from and strict processes for new pattern addition? Or is the system quite loose, and do you rely on your people’s familiarity with the design principles and allow for flexible and expertimental use of those? Modularity then: do you stictly separate everything into modules (high investment, but potentially cost saving in the long term) or is it acceptable to produce designs that are quite specific (and potentially easier to build, but harder to scale)? And lastly, organisation: is it centralised or distributed? Is there one team that creates and vets everything (more reliable, but potential bottleneck), or can people across all teams contribute (more autonomy, but potentially dilutes creative direction)? These three aspects provide a great way to think about what kind of design system works for your organisation. With examples from AirBnB to TED, Alla showed that different companies make different choices on these scales, and she recommended us to make our own choices: ’the right design system is probably not someone else’s design system‘, she concluded.

Alla Kholmatova: the right system for you is not someone else’s system

Takeaways

These are some of my takeaways and things I felt recurred across the different talks:

Moving from a static page comp approach to working on pattern libraries can completely change our way of thinking about making websites. A pattern page as an isolated test case is one of those things.
Wholes are just as important as parts: it’s great we spend time on isolated components, but the end user experiences however they’ve ended up being used together, it is important not to lose sight of that.
There are many complex solutions (like static asset APIs, versioning, templating to serve multiple stacks), but your organisation’s problems may not require them. Keep it simple if you can, introduce more complex solutions if your research shows you have to.
Marketing your pattern library is a thing, especially in bigger organisations. People can also build web products using their own code or Bootstrap. It’s unlikely for others to promote your pattern library, so if you want it to be success you’ll have to put your sales hat on.
We aren’t the first people to solve these kind of problems: architects (of buildings) have long worked with modules and wrote at length about making them work in wholes.

In his closing remarks, Jeremy asked if he should do another Patterns Day next year. For what it’s worth, I would love to attend another one! There’s lots more to discuss and a year later, more of our shared problems will have likely been solved by people. I would love to hear more about, for instance, how to test for accessibility in a pattern library world.

I’m looking forward to bringing some of the stuff I learned into practice when coming back to work next week!

Originally posted as Coherence, Lego and how naming things is hard: Patterns Day 2017 on Hidde's blog.

[email protected]?subject=Reply%20to:%20Coherence, Lego and how naming things is hard: Patterns Day 2017">Reply via email

Did CSS get more complicated since the late nineties?

2017-07-03T00:00:00Z

The first hour of CSS Day 2017 was truly memorable, as the very inventors of the language took the stage. They brought back memories of the early days of CSS. It was the year 1994. There were lots of documents and they needed styling.

One of the things that stood out for me was their discussion of what they wanted CSS to be: as simple as possible. This is a thing today’s CSS language still resembles. Want something to have a red color? something { color: red; } is all you need. But while the language itself is simple, the structures we build with it today are often not.

Really, ‘simple’ is not a qualification suitable for the CSS codebases I have worked on in the recent past. The same might go for you. Near the end of the session, someone mentioned Internet Explorer has a maximum of 6000 or so CSS rules allowed (4095, actually). Bos and Lie wondered whether anyone would need that many rules. With some embarrassment, I’ll admit that I once worked for a large Dutch consumer brand where we encountered this maximum, and ended up splitting our stylesheet into two separate stylesheets.

Screenshot of the proposal for Cascading HTML Style Sheets

Simplicity was a core design principle

From the early mailing lists and the proposal of Cascading HTML Style Sheets to Håkon Wium Lie’s PhD thesis about stylesheets, which reads as a detailed account of CSS’s genesis: there is quite a bit of information on the web about how CSS was designed. Keeping it simple was a core principle. It continued to be — from the early days and the first implementations in the late nineties until current developments now.

Authors can specify as much or little as they want

CSS authors can use the language to just set a font and line height for a document and leave it at that, or they can completely change the appearance of it. The cascade ensures this: even if no rules are applied by the CSS author, there is still the browser stylesheet or even user stylesheet to provide hints as to what the page should look like. Yes, the cascade is a principle that provides simplicity, not complexity.

It is not a programming language by design

CSS is a declarative language on purpose. It could have been a Turing-complete programming language, which would have been more powerful, but bad for simplicity: difficult to read and expensive to maintain. As Bert Bos mentioned in the session: ‘we wanted it to be so simple that everyone would be able to use it’.

They are agnostic as to which medium they are used for

From the early days, CSS has had @media constraints, so that authors could write different CSS rules for media like print and screen. All optional; if not specified, the rules would apply to all. They came up with ways to specify which medium some style rules are for, but most importantly, they thought about the applicability of the language outside the medium they were looking at then.

It is stream-based

Browsers can do progressive rendering, which means they show the document incrementally, while it is still downloading. It was important for CSS not to break that principle, which is the reason CSS is “stream-based” (as opposed to being a transformation language, which would allow more features, but also increase complexity).

To summarise: CSS itself was kept simple, and it was designed to support unknown as well as existing stuff (and to not break that). It is non-intrusive, which I think is a characteristic that is hard to find in complex systems.

What has changed since?

So, let’s look at what makes modern CSS complicated. With modern, I mean after the late nineties. I think there are a couple of things.

Websites have become more than documents

CSS was made to style documents. At the time, they were things like a long Word document — think academic papers, reports and the like. Early CSS features aided those kind of documents: there was generated chapter and section numbering, ability to style the first line and page margins.

Although we still call web pages documents, (I mean, who doesn’t document.querySelectorAll ?), they are often more than that. We now have loads more websites where you do stuff, rather than just read things: from transferring money to booking travel.

Tooling

I think hardly anyone still writes CSS by hand, I mean, in a .css file. I do it on some sites that I run myself, but it’s been a long time since I’ve seen it in my client’s codebases.

Often, the reason is that CSS is written per component, with different files, and tooling is used to combine them into one file (@import would be too many HTTP requests). Other reasons are variables and mixins that are used with the goal of DRYer code (the latter, I think, can be quite problematic).

Graphic design for the web professionalised

Early web pages often hadn’t a dedicated or professional designer. Most modern websites do. There are specialised teams caring in detail for branding and user experience, and this demands a careful approach to writing CSS. Front-end development teams adjusted their practice, they sometimes agree upon a systematic approach to classnames. They often prefix classnames with the project name (for this site, I could start all classnames with hv-). Some companies distinguish between objects and utilities and prefix those (hv-o-thing, hv-u-thing). Also, they have agreed on mostly using classnames as selectors, not IDs or tags. Attribute selectors are controversial in some companies (I personally love them).

Control over content and markup

CSS has always been able to work on unknown markup, but things have gotten more complicated in the sense that more content is now user generated, content changes faster (i.e. on news websites) and more markup has been abstracted by powerful and complex CMSes.

Component based architecture

Lots of companies have switched to a component-based approach, where they design and build components that can then be put together in whichever way they see fit. For CSS, this means that elements can be inside different parts of the DOM tree. This is why many CSS authors that work on component libraries choose to create different ‘scopes’ (in classnames, with something like BEM).

Although things have changed, the basic idea is still that values/properties apply to things, and as an author, that’s the only thing you need to worry about. You don’t have to have build steps and you still don’t have to specify how styling, including complex grids, should be computed. You don’t even have to specify what everything looks like, as there are defaults and your own settings cascade. However, if you want to have build steps or have more fine-grained control, you can! Houdini will provide the latter, while keeping the basic ideas of CSS, like the cascade and media constraints, for you to use.

I think lots has changed since the early nineties, but not really things that touch on how we apply CSS to structured markup.

Today

Most of the early-day thinking about CSS still applies today (and is still very much there in more recent additions to CSS specs). That is kind of amazing to me, because it is over 20 years old. In the world history, that does not seem like much. But looking at what kind of devices and browsers existed then, it is quite astonishing.

I like to believe that the simplicity of CSS as a language is one of the reasons that it still works so well. Efforts to componentise CSS (to get programmatic scope) and bring CSS into JS can bring huge benefits and make things more manageable. But they definitely also increase complexity. Increasing complexity is a choice, and in the early days, the web community chose simplicity over complexity. They had good reasons for that choice, and it is a choice that has served many for over 20 years.

Modern websites are different and so are our coding practices, but in the grand scheme of things, not a lot has changed. If we are to willingly increase complexity of our CSS code with shiny new tools, that’s fine, and CSS is quite suitable to build tooling on top of. But, we should have good reasons for introducing complexity (and definitely read more about CSS’s making of).

Originally posted as Did CSS get more complicated since the late nineties? on Hidde's blog.

[email protected]?subject=Reply%20to:%20Did CSS get more complicated since the late nineties?">Reply via email

Professional developers

2017-07-10T00:00:00Z

The other day I watched a talk in which the speaker criticised PPK for trying to come up with a definition of a ‘real developer’. Many people have said it is ridiculous to frame developers with words like that. The wording is probably inapt. But is there much inherently wrong with setting standards for what a real/good/professional/sufficient way to exercise our trade is? In this post I will look into that question.

For me personally, ‘real’ feels ok to use in the context it was used in, but then I am not a native speaker of the English language and I only know some connotations of the adverb. Obviously, its opposite is ‘fake’, which isn’t a nice thing to call anyone. I think the intended meaning of ‘real’ in that particular talk is similar to ‘professional developer’, which is the word I will use here, hopefully not being overly controversial.

We need diversity! With ‘our industry’s diversity needs’, I mean that a large part of us web developers, myself included, think it is very important that the web industry welcomes all, should strive to be as diverse as possible and possibly have mechanisms in place to ensure it is very attractive for newcomers to join the industry.

The web is for everyone

The amazing thing about the web is, it is for everyone. This is a phrase that applies to having a place on the web, as well as working on websites. Nobody should be stopped from running their own Vengaboys fan page, or their website with hiking tips in Seoul. Or with their search engine, or their social medium, although those arguably do require some legal framework to operate in. My point is: you don’t need anyone’s permission. Everyone can make and have a website.

The web technology community should also be a welcome environment to everyone. Everyone should be welcome to contribute stuff, no matter whether you’ve played with Service Workers or CSS animations on your Vengaboys fan page or while working for Facebook.

At the London 2012 Olympics opening ceremony, Tim Berners-Lee tweeted “This is for everyone”. The letters simultaneously showed on the big screen. Source: Telegraph / PA.

Are standards acceptable sometimes?

However, if someone is a web developer and is doing paid web development work, I don’t think it is unreasonable to have some expectations. If a web developer is working on the system that lets me download my bank statements, a system that lets me apply for a new parking permit at the local council or a system that shows me the latest news, I think they should know what they are doing.

This is because I want to make sure my bank information is transferred securely, my parking application is treated confidentially, my news site is not hacked and filled up with fake news, and my public television’s live TV thing streams fast and in HD.

Critical websites should be:

secure with data
accessible
fast
solid

So, everyone can do stuff on the web, by all means. But if they’re doing this professionally, especially on society critical systems, we can expect them to have a certain skill level.

Other industries do have standards

What if someone said:

that dentist is not a professional dentist, as she does not know what the side effects of her anaesthetics are
that pizza chef is not a professional pizza chef, as he buys ready-made dough
that accountant is not a real accountant, as he is unaware of the legal obligations that are involved with running a Limited company
that mortgage advisor is not a real mortgage advisor, as she does not know the implications of a 5 year fixed interest rate as compared to a 10 year fixed interest rate

Would the above statements be offensive or scare new people from the respective industries? I beg to differ, I don’t think they are.

Note that when I say dentist, pizza chef, accountant or mortgage advisor, I am talking about those who do it as their profession and charge their clients for their services. Needless to say, all of those people could have interns or apprentices for whom it is absolutely fine to not know all the tricks of the trade.

But which standards?

Who knows what ‘knowing what you’re doing‘ means? What’s the industry body that prescribes what the good and the right is? I think this is a question that is extremely hard to answer, especially for the web, as there are many ways to do things. But let’s not give up there, at least not for this thought experiment.

Let’s look at some other industries first. Pizza makers, dentists, accountants and financial advisors all have industry bodies that decide for the whole industry what’s right and what’s wrong.

Pizza makers have the Associazione Verace Pizza Napoletana, and I quote:

Its mission is to promote and protect in Italy and worldwide the “true Neapolitan pizza“ (“verace pizza napoletana“)

Accountants have the body of Chartered Accountants:

Chartered Accountants were the first accountants to form a professional accounting body, initially established in Scotland in 1854. The Edinburgh Society of Accountants (1854), the Glasgow Institute of Accountants and Actuaries (1854) and the Aberdeen Society of Accountants (1867) were each granted a royal charter almost from their inception.

Now I’m not saying a member of a royal family needs to get any say in this, I just want to point out that for other industries it is quite acceptable to have some form of standard.

Lawyers in The Netherlands have to go on courses yearly and if they do not show up or fail to collect all the credits the bar prescribes, they could lose their license.

I think it would be okay to have expectations of professional developers, and looking at other industries, there are ways to establish them. Web technology changes a lot, and there are many specialisations, but the same goes for law and accountancy.

How to do this for front-end developers?

Who should do this and how they should go about it? Can a team of, say, 5 people just come in and make a list of requirements that will be taken seriously by the community? Are basic HTML, CSS and JavaScript like the tomato sauce for pizza chefs, or is it understanding of MVC and two-way data binding? These questions are beyond the scope of this article, but they are certainly difficult problems that would have to be solved. I think we can all agree it will be a huge challenge for the web industry to find people as well as ways to establish standards for professional exercise of our trade.

In conclusion, I think having certain expectations of developers that build critical systems seems sensible. If we want to have high quality things on the web (in terms of security, performance, accessibility, etc), having standards could help. When it comes to critical systems like banks, government and news, we even should!

As I said above: the web is for everyone, it is relatively easy to start making stuff for it and I don’t think that should ever change. For most websites.

Originally posted as Professional developers on Hidde's blog.

[email protected]?subject=Reply%20to:%20Professional developers">Reply via email

This website now uses Grid Layout

2017-07-11T00:00:00Z

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!

Testing the accessibility of pattern libraries

2017-07-13T00:00:00Z

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.

[email protected]?subject=Reply%20to:%20Testing the accessibility of pattern libraries">Reply via email

Enabling people with accessible technology and positive thinking

2017-07-21T00:00:00Z

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.

[email protected]?subject=Reply%20to:%20Enabling people with accessible technology and positive thinking">Reply via email

Small steps

2017-08-21T00:00:00Z

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.

[email protected]?subject=Reply%20to:%20Small steps">Reply via email

Accessibility Design Drive

2017-09-04T00:00:00Z

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.

[email protected]?subject=Reply%20to:%20Accessibility Design Drive">Reply via email

ICONS: work on stuff that matters

2017-09-05T00:00:00Z

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.

[email protected]?subject=Reply%20to:%20ICONS: work on stuff that matters">Reply via email

Brique: a conference about challenging reality

2017-09-28T00:00:00Z

This week I attended Brique, a design conference by the lovely people of Fabrique in Rotterdam’s Kunsthal. It felt like a Dutch dConstruct for designers, like Creative Mornings meets This Happened. I had a great day!

The programme was extremely well-curated, with a great variety of talks, but an overlapping theme as well. Every talk approached the subject of reality. Some were about how to experience it, through inquiry, investigative journalism or photography. Others talked about how to shape reality to tell a story, with animation, graphs, VR or even classic cars. And then there were talks about how to change reality for the greater good, to decrease income gaps and make solar power work.

Photo credit: Fabrique on Twitter (original)

Stop motion filmmaker Rogier Wieland showed some of his work and the process it involves. He makes animation films, mostly with stop motion. The attention to detail was nothing more than impressive, and it shows in the result. It did seem like a lot of work, but lots of fun too (see also the photos on their website.

Philosopher Bas Haring talked about the daily life curiosity that brings him so much: when he encounters something he just does not understand, he investigates the thing. Whether it is the history of the Panama Channel, the economy or why someone would claim that homosexuality is not natural. This attitude of inquiry often brings him to more questions and answers. Interestingly, it also inspired him to write multiple popular philosophy books.

Jeffre Jackson explained that asking ‘seriously?’ is his “standard mode”. Reality isn’t always what it seems, he said, and part of why is that we don’t know everything. We need to inquire, ask questions and realise we don’t know everything. Withhold judgment, he advised. Throughout his talk, he referenced the humanist Michel de Montaigne, whom he said “would have loved the web”. Great stuff! Still in doubt whether I should get Montaigne’s essays.

Ionica Smeets, mathematician and professor in explaining scientific research to the world. She talked about the fascinating subject of a language used by experts talking to non-experts. She explained that one way to make sure your word usage is accessible is to ask the people you talk to for a summary of what you’ve just said. It might appear they misunderstood. Or filled in blanks wrongly. She also showed how graphs can be extremely misleading, and how some use them to tell stories their way.

Storyteller Steye Hallema did the first VR talk that overwhelmed me, mostly because of the meaningful examples. I had seen VR talks at tech conferences before, Steye’s talk had a different angle: he talked about what kind of stories can be told with VR and how. VR, he said, is a bit like extracting consciousness from your brain and passing it around the room. He showed us how VR was applied to swap genders, make a music video, and experience a peep show. VR is hard, he said, from which I concluded: only use it when it improves how the story is told. He showed many examples where VR adds a new level and lets the public experience stories in ways that aren’t possible in traditional film.

Lawyer Aernoud Bourdrez enlightened us about conflict resolution. He talked about Shapiro’s five emotional aspects: appreciation, affiliation, autonomy, status and role, and ensuring to cover them all in every negotiation move. He also showed how to use this to obtain art, with some entertaining examples, such as how he managed to get the original x-rays of a car that is stuck in the Jackass’ Ryan Dunn’s buttocks.

Martijn Kieft of tv programme Tegenlicht told us how his tv programme looks at things that aren’t typically in the news, but have a huge impact with how they shape the world. Some of these things are very abstract, such as the process of creating money or negotiating for disinvestment in companies that harm the earth. For something to make the news, it requires images, but one needs creativity to find imagery if your subject is an abstract process.

Architect Kristian Koreman talked about how his team challenge reality with the projects they do. They don’t always do projects because clients ask for them, they sometimes give unsolicited advice. I like the idea of that. He showed how they helped the city of New York with a project around gentrification – quite a problem here, but a much bigger problem there. They studied differences between poor and rich and tried to come up with ways to challenge that reality.

Photographer Otto Snoek talked about his Europa project: he left his home city of Rotterdam to travel Europe and photograph people there. With his photos rotating in the background, he shared his thoughts about photography, Rotterdam and the world, and read three short stories.

Closing the day was the technologist, designer and philosopher Koert van Mensvoort. He showed some product designs to make us think about the future of our society: new technological possibilities arise, but are we comfortable with what can be achieved? He showed us the ‘speculative products’ he developed to start a discussion, and different kinds of in vitro meat products, some real and some imagined. He also talked about what ‘nature’ is, and argued the traditional definition should be widened to include hard to control human-made systems (such as financial markets and the internet). And that we should have the ambition for technology to become part of our nature, rather than just to the job they were invented for. More about how technology becomes part of nature in this TED Talk Koert gave.

Originally posted as Brique: a conference about challenging reality on Hidde's blog.

[email protected]?subject=Reply%20to:%20Brique: a conference about challenging reality">Reply via email

On recruiting for specific technologies

2017-10-12T00:00:00Z

I recently had a conversation with a recruiter that went more or less like this:

He: Are you available for a project?
Me: What kind of project?
He: I have one React project and one Angular project

In my head, I have trouble classifying projects in terms of the specific front-end frameworks that power them. We’re using technology, sure, but what are we using it for?

My ideal client knows the answer to the latter question and leaves implementation mainly to the team. The longer I’ve worked as a front-end developer, the more I’ve realised that specific technologies don’t matter that much, especially in projects that run for more than a couple of months.

Anyone can learn how to operate a gearbox or figure out how to reverse in a specific type of car. But where are we driving to? Ok, silly metaphor, but hopefully it gets my point across. We’re putting stuff on the people’s screens. It’s mostly about what and making stuff that matters, but those are (mostly) not front-end things.

Front-end wise, I think these things are probably key:

are we making a fast website, i.e. do we optimise assets and avoid sending unnecessary bytes to the client?
are we making a usable website, i.e. have we provided ease of use, rather than confronting our users with problems resulting from our complex business logic?
are we making a website that doesn’t exclude people, i.e. do we have all users in mind when hiding and showing content and is our interface keyboard accessible?

I don’t want to be all millennial and display overly unrealistic idealism, but these things seem quite basic to me. Why strive for less? Of course, in actual interviews, it would be interesting to gloss over technologies to use to reach those goals, but I can’t see how filtering for them works as a recruitment strategy.

In order to find good people to solve your development problems, problem-solving and people skills are probably going to help much more than previous experience with specific tricks of the trade.

Originally posted as On recruiting for specific technologies on Hidde's blog.

[email protected]?subject=Reply%20to:%20On recruiting for specific technologies">Reply via email

Web Components as compositions of native elements

2017-10-19T00:00:00Z

I wrote a post about Web Components about two years ago, wondering what kind we would need, if any. More companies have recently started adopting web components. I’m starting to get more excited about them, and think they can be very helpful to encapsulate compositions of elements.

Please note: this isn’t a recommendation for ‘switching to Web Components’, at the time of writing browser support is weak and the ‘components without libraries’ is not reality yet. I’m only exploring the theoretical argument.

We have all the elements we need…

At university, I learned something about Conway’s Game of Life: it can do super complex things with only four simple rules. It has been used to implement things as spectacular as Boolean logic, a clock and a Turing Machine. Similarly, I have always thought the small set of existing HTML tags is enough to build interfaces suitable for anything. From your local grocer to rocket science (for most websites, with some exceptions). We have all the elements we need.

Glider Gun in Game of Life (source)

To have the capability of creating one’s own elements seemed like fun to me, but unnecessarily complicated. At first sight, it seemed puzzling to me: how many companies are there with the resources to implement Web Components and implement them well (fast, usable and accessible)? Two problems still stand out to me: the need for polyfilling and the fact that going custom means having to provide custom usability and accessibility.

Web Components require polyfilling

To get Web Components working in most browsers, we need to use some sort of polyfill or framework. This puts our problems on users. Maybe they don’t have a fantastic connection or a brand new device. To put it bluntly, they might now experience issues they would not have had to experience if it weren’t for our custom element usage.

Custom makes usability and accessibility harder

Custom elements are custom, so browsers and device don’t ‘know’ what they are for. This means:

they can’t provide a perfect UI that seamlessly matches the platform (as they do for native elements like select), which could result in reduced usability
they can’t give assistive technology information about semantics, which could result in reduced accessibility

When the (Shadow) elements inside a web component are native elements, part of this problem goes away, as for those native elements, browsers would likely have perfect UIs and good exposure to assistive technologies.

…but we don’t have all the compositions of elements

Maybe providing new “primitive” HTML elements isn’t the point of Web Components. Although the basic building blocks are there, we often combine basic elements. We combine them to create our own things, our own components, patterns, modules or widgets. We may have all the required elements, we don’t have all the required compositions of elements.

Components are often that: compositions of existing elements, complemented with JavaScript and CSS to make a New Thing. The question is: do we want to encapsulate our New Things, so that they are actual, separate things?

We do this without Web Components, too. In front-end pattern libraries, each pattern often has its own folder, its own CSS file and its own scripts. In React or Vue, developers often blend markup, style and behaviour together in one piece of JavaScript.

A web standards way to compositions of elements

In recent years, the web standard gods have worked on lots of new stuff that allow developers to have more access to and influence on the web platform. And more control. Numerous new APIs have been released to give developers access to stuff that only the OS could access, like location and Bluetooth, and to stuff that only browsers could access, like stylesheets and the network. Getting access to the set of elements that exist, and being able to extend that, makes sense in that bigger picture.

Web Components provide a component model to web standards, so that we can stop using complex tools. Yup, less or no external tooling is part of the argument for web components.

With components that are part of web standards, we need less reliance on frameworks, says Alex Russell in his post Bedrock:

We observed that most of what the current libraries and frameworks are doing is just trying to create their own “widgets” and that most of these new UI controls had a semantic they’d like to describe in a pretty high-level way, an implementation for drawing the current state, and the need to parent other widgets or live in a hierarchy of widgets.

In that 2012 (!) article, he observes that creating widgets becomes the core of what modern web development looks like:

Let that picture sink in: at 180KB of JS on average, script isn’t some helper that gives meaning to pages in the breech, it is the meaning of the page. Dress it up all you like, but that’s where this is going.

So, creation of components, widgets, modules, reusable patterns for user interfaces on the web is commonplace — most web teams do it in some way or another. Frameworks provide ways to do this, but Web Components provide a standardised way to do this. See also: Web Components, the long way.

The bright side

I think the decision to go all Web Components shouldn’t be taken lightly, as many organisations may not have the problems they solve, but there are definitely upsides to them. The future for web components is looking quite bright.

Accessibility

Native elements do a great job at having accessibility built in, i.e. if you use a select you can be quite sure most of your users will be able to select stuff with them, even if they use assistive technologies to access your site, even if they have colour blindness. At the point of usage, you don’t need to worry (much) about how accessible it will be.

If you build your own component now, you will likely use some JavaScript to make accessibility provisions. There’s some risk they get lost when being copy/pasted. With Web Components, those provisions are not in the markup, they are an integral part of the component. They will be there every time you use the component’s terse syntax.

Even better, if the Accessibility Object Model becomes a thing in browsers and Web Components are better implemented, we can set accessibility properties and states directly in JavaScript.

Real encapsulation

With custom elements, you can have scope in HTML and CSS, not just in JavaScript.

IMHO, this is a solution for a problem that is not a problem, but I realise people disagree about this. The advantage of this solution is that you never need to worry about where you use a component, as it will have exactly the styles you’ve applied to it. Personally, I will probably still take advantage of CSS’s cascade.

Conclusion

And that’s what I’d like to end this with: the pre web component web is not going to go anywhere. If your website is not extremely complicated, it still makes lots of sense to just write HTML, CSS and JavaScript, keep things simple and stay away from custom elements and Shadow DOM. Peruse that cascade, do some simple DOM scripting, leverage all that built-in usability and accessibility, and be done with it.

If you have quite a complex codebase that is componentised through a framework like React, it would make sense to look at Web Components, the web standards way to build encapsulated components. In the future, when they are supported across the board. That isn’t the case at this time, so for now, they are still just theoretical awesomeness.

Update 24 October: removed parts that suggested I was recommending Web Component usage today; added a note at the top to clarify.

Originally posted as Web Components as compositions of native elements on Hidde's blog.

[email protected]?subject=Reply%20to:%20Web Components as compositions of native elements">Reply via email

New challenges

2017-10-23T00:00:00Z

This month is my last at Wigo4IT, and I’m excited to start new projects at Mozilla and the Dutch Ministry of Internal Affairs.

Leaving Wigo4IT

For years, I’ve wanted to work on front-end code for the public sector, inspired by the awesome user-centered design work that the Government Digital Service (GDS) have done in the UK. While I lived there, I wasn’t in London, the closest I got to the GDS was working for Nomensa and sitting near a team that did a GDS project.

Back in the Netherlands, I was quite excited when Informaat, a user experience agency, approached me and asked me for a project they did for local government. Long story short: I spent a bit of last year and a large part of this year contracting for them at Wigo4IT. Wigo4IT is a cooperation of the four largest Dutch municipalities, who work together on software related to social welfare.

I worked on a portal where people can apply for income support. The role of our front-end team was to build a responsive component library that can be used to create WCAG 2.0 compliant pages. The project was full of challenges related to web forms, front-end pattern libraries and theming. It was also a lot of fun to advocate for accessibility as part of the project, and my first time to have the JAWS screen reader software available to test on. I learned a lot about differences between the public and private sector, on many levels.

New challenges

Mozilla

As of next month, I will join Mozilla for a couple of months as a freelance front-end developer. I will be working for the Participation Systems team, the team that has as its goal to make it easier and more effective to contribute to Mozilla projects for all. I am incredibly excited (and slightly scared) about getting the chance to work with some brilliant minds.

Government

I have also recently started to work on two projects for the Dutch Ministry of the Interior and Kingdom Relations together with Atticus: one to apply a redesign to a set of government data related websites, and another one related to accessibility guidelines conformance statements. I love this, because this is the Ministry where a lot of the official Dutch accessibility information and guidelines are published.

CSS Workshops

Lastly, this year I will also be giving my first workshop (organised by Fronteers). Two times, in fact. It’s going to be about modern CSS Layout, including flexbox and CSS Grid Layout. I hope I’ll convince the attendees that those who haven’t yet can now safely abandon Bootstrap for layout, and that we can have lots of fun exploring and using new layout-related properties and thinking.

Originally posted as New challenges on Hidde's blog.

[email protected]?subject=Reply%20to:%20New challenges">Reply via email

The web is ready for great graphic design

2017-11-29T00:00:00Z

There was a time when front-end developers would frown upon (former) print designers that designed for the web. At their usage of ‘perfect’ yet unrealistic content, and their creative ideas that were impossible to build with web tech. If this frowning since has scared print designers away from web design, I hope that they return in 2018. New CSS possibilities are ending the unrealistic content problem and the generic layout problem. It’s a great time to build layouts in CSS!

Problems solved

The unrealistic content problem

It is now not as common, but I’ve still seen it happen in the past few years. A designer presents a design. The content lines up beautifully, because it is picked to fit perfectly. Headlines that only ever need one line, that sort of thing. It can result in beautiful and balanced visual design. But it doesn’t take many years of front-end experience to know that such designs risk breakage as soon as the template is hooked up to a CMS. The content is updated, and boom, it no longer fits. With new or real content, either the design loses some of its tidiness, or the CMS is set up to force character constraints on content. That leaves the design tidy, but the content inflexible.

When content for one of the blocks changes, it will not be trivial to line up

Most of these problems have to do with keeping things the same height and doing advanced alignment. These are both requirements that are super easy to do on paper and in design software. Easy to do when making a static comp. I guess. But CSS never had tools for doing this flexibly and with unknown content (table layout excepted).

In the CSS Layout workshop I ran for Fronteers last week, I tried to emphasise that recent updates to CSS mean that the above is soon (or now, actually) no longer an issue. CSS Grid Layout (and flexbox, to some extent) will let us have our cake and eat it, too. We can make things line up or be the same height in a whim, regardless of content. We get flexible units like ch and fr that make it easier to line things up in a way that was always quite sensible, but never quite feasible. Unrealistic content, then, is less of a problem, as we have actual alignment options, rather than CSS trickery.

The defensive design problem

Every so often, contracting for agencies, the designer of a new website would come to me and ask ‘What kind of layout framework are you using? What’s the grid, are we doing Bootstrap or Foundation?’ Sometimes the agency had already listed one of these as a requirement during recruitment. I often found that the in-house developers were used to dictating these kinds of things. Lucky bastards! The reason is probably practical: when producing website after website, it makes sense for a team to start optimising things and have one way of doing grids. When working with contractors, it is useful if that one way is a broadly used open source framework. But it also seems oddly out of order: it can be a lot like solving problems before you have them.

The thing with CSS layout frameworks is that there is a fixed amount of stuff they can do. The things that are generic enough to make it into the framework. They speed up things, and are super helpful for prototyping and even creating production sites. But they don’t just create a generic way of working. They also create a generic look of websites. I’m not the first to conclude that.

Defensively designed websites tend to look the same

Web design with CSS frameworks in mind is, I think, to design defensively. The approach gives a lot of certainty about whether something can be built, which leads to happiness throughout the team, including product owners.

2018 may be the year that we no longer need to design defensively. Because Grid Layout is here. By ‘here’, I mean in our users’ browsers. In The Netherlands, on average 85% of users use browsers with full or partial (IE11) Grid Layout support.

With CSS Grid Layout, we no longer need frameworks, CSS now is the framework. This is great, we can now solve problems when we have them. With something that is a web standard.

New challenges

There are new challenges, too. The stuff Grid (and flexbox, to some extent) does, can be unexpected to those who have not mastered the spec. That’s probably most of us. They have documented Grid’s behaviour exceptionally well there, but it is perhaps only in real life designs that we will get a feeling of how it all works. For instance, what autoplacement does and how to leverage features like minmax and min-content to get our designs exactly how we want them.

Letting it go

Grid Layout has a lot of ‘leave it to the browser’ kinds of settings. Rather than ‘make this thing 400px wide’, you set things like ‘make it fit roughly between 40 and 60 characters’. More than ever, it is clear that CSS isn’t about exactly specifying what we want.

John Allsopp famously discussed this in A Dao of Web Design, over 17 years ago. He talks about “to suggest the appearance of a page, not to control the appearance of a page”. For this, he says we need to let “go of control”:

It is the nature of the web to be flexible, and it should be our role as designers and developers to embrace this flexibility, and produce pages which, by being flexible, are accessible to all. The journey begins by letting go of control, and becoming flexible.

(Emphasis mine).

“Letting go of control” is about letting the browser decide based on our hints. Browsers are good at this. They have all the knowledge: what device they’re running on, how much space is available, what fonts are available, which settings the user has set, et cetera. But it isn’t necessarily something all web teams like to do, I found.

Communicating flexibility

Even if we as CSS developers have mastered the spec, we still need to be able to communicate and explain the consequences of our code to designers, product owners and stakeholders. This is key. It requires us to explain stuff to the rest of our team. Results that struck us as unexpected will likely strike them even more.

Historically, we’ve seen a lot of website owners like the idea of their websites looking exactly the same everywhere. But it is now clear to most that this is no longer feasible. The case for flexibility has become lots stronger in our current multi-device reality. The internet is on so many devices: fridges, cars and watches with browsers now exist. This reality has powered the responsive design argument, and think it can power the flexible layout argument, too.

Conclusion

So, yes, the web is ready for great graphic design. The flexibility it was invented with has recently flourished with the surge of responsive web design. We now have CSS layout methods that let us embrace flexibility and they have good browser support. Cool experiments are done with CSS Grid Layout.

The case for using flexible layout methods will require clear communication between front-end developers and the rest of the team, as well as in-depth knowledge of these new lay-out tools. But I think we can do this. We’ve done it before with responsive web design, and we can do it again!

Originally posted as The web is ready for great graphic design on Hidde's blog.

[email protected]?subject=Reply%20to:%20The web is ready for great graphic design">Reply via email

What to use Grid Layout for? Some ideas.

2017-12-06T00:00:00Z

If you have learned how to use Grid Layout, you might wonder what to use it for. In this post, I will give some use cases where I think Grid will excel.

In the last two weeks I gave two workshops on CSS layout techniques. Heavily inspired by Jen Simmons’s remarkable Grid Layout experiments, I picked three posters that Wim Crouwel designed. Crouwel is a graphic designer that has been making use of grids for a long time, including for all the characters in his New Alphabet typeface. His work is iconic and I was quite excited to see some of it could easily be built for the web using CSS Grid Layout.

I liked how working on non-real world examples played out, as the focus was really on applying all those different properties, rather than writing production-ready code. Old posters are great to try this stuff out on.

After the workshop, Michael asked me what we can use Grid Layout for in the real world, if not for recreating iconic posters from the history of graphic design. I talked to others about this and found various people weren’t sure what to use Grid Layout for in actual websites for clients.

I’m sure we can use it for a lot more than recreating old posters. There definitely are good use cases, so I thought I would make a list of where I believe Grid can help us create cool stuff.

Use cases

To show what’s on offer

Grids are perfect for showcasing things, inspire visitors, communicate to them what kind of stuff we have on offer, in a very broad way.

We can do these things with old-school layout methods. However, using CSS Grids they can look more exciting, it is trivial to make some things appear more prominently than others and it is easier to have the browser deal cleverly and responsively with content differences.

For an online supermarket: a listing of products with prices, reduced prices, product names
For a library: a page with reviews of the five books that have recently come out and have great reviews.
For an airport: an overview of the tax-free shopping available
For a railway company: a selection of exciting holiday destinations, weekends away, day trips

These are all listing pages that want to inspire people to find stuff, whether it be groceries or books. They can benefit from things only Grid offers.

For one-pagers with a lot of different sections

Many front-end developers will have had to code them if they worked on marketing sites in the past five years: one-page websites in which every section is quite different. They often have lively designs. Lots of differences between sections makes it hard to code systematically.

With Grid Layout you can keep the markup of these sections nice and plain and choose a sensible and consistent source order, while still allowing yourself to go wild creatively on each section.

To display a schedule

We can use grids to display information about what’s happening at a given event, conference. Note that proper markup will be extra important here, as for accessibility reasons we want to make sure the content makes sense without its Grid Layout.

For embedded layouts that fill the entire screen

If you’re building an interface that is supposed to go full screen on some physical product, Grid Layout might be quite a helpful way to distribute space.

A while ago, I built an interface for a Dutch department store that would be used by the cashier when you pay. It had things like your products on and stuff about loyalty card usage. This kind of interface runs full screen in some sort of embedded browser.

Some use cases:

your digital tv interface
the self-check-in screen in an airport
the screen you see when you return books at the library
a screen that shows information on the next train

With a grid that is based on viewport units (vw/vh) and/or fractions, space distribution and alignment may get a lot easier. (I have to admit, in my case the screen ran a browser that was almost identical to IE7 and the system’s output gave me only tables to work with).

The Grid Layout Spec has an example of a game that always fits on your screen. The required markup/CSS is ridiculously little.

An example

Imagine we have a grid with cards in it for a supermarket’s weekly offers.

All offers take one spot in the grid using autoplacement. However, some offers are more prominent, and we could make them use two rows:

.offer {
    // regular offer code goes her
}
.offer--prominent {
    grid-row: span 2;
}

I don’t work at a supermarket’s marketing department, so my knowledge of its possible marketing strategies is lacking, but maybe there are other offers. Perhaps one that will expire after this week. This is people’s last chance, so we make it use three columns and two rows.

.offer--last-chance {
    grid-row: span 2;
    grid-column: span 3;
}

This is stuff that is trivial in a Grid Layout and impossible to do so easily and flexibly using traditional methods like display: inline-block;. For those of us who have used floats, inline-block and even tables to do lay-out, using Grid Layout may be a bit of a mental shift. I suspect this applies a lot less to people who learn CSS layout today, as they will start in a reality where the new stuff already exists.

Conclusion

There are plenty of uses cases where Grid Layout would be a sensible implementation choice. I have listed some examples above, but I am sure there are more — please leave a comment or tweet if you have found other ideas.

Originally posted as What to use Grid Layout for? Some ideas. on Hidde's blog.

[email protected]?subject=Reply%20to:%20What to use Grid Layout for? Some ideas.">Reply via email

#yallhands

2017-12-17T00:00:00Z

Last week I was at Mozilla’s All Hands in Austin, Texas (hence the hashtag). All Hands is an all company event where the people who work for Mozilla come together in one city. Staff, but also prominent volunteers, contributors and community leaders. It’s all about sharing experiences and meeting people.

It was my first All Hands, and the first time for me to meet any of the people I have worked with for the past six-ish weeks. The week went by faster than I could have imagined. I had been warned for this. Beforehand, I had heard great things about the event, but, wow, it was incredible! So many people met, so many productive sessions had, so many stickers acquired and various American foods tried.

Throughout the week I was in many meetings in various settings with colleagues from Open Innovation, as well as with the IT department whom we collaborate with for identity and access management work (the IAM project). We made plans, shared ideas, talked about planning and discussed our processes. Tons of things that are easier to do in person. For me personally, it was great to learn that and how our daily work fits in the broader Open Innovation and Mozilla goals.

Below, I’ve provided a couple of links to projects and ideas for y’all.

Plenaries

A plenary session opened the week, featuring most of the people leading Mozilla, including CEO Chris Beard and Executive Chairwoman Mitchell Baker. There was a lot to celebrate about 2017 for Mozilla. The launch of Firefox Quantum which had been years in the making, projects like Common Voice that want to facilitate machine learning of voices for all, the programming language Rust that gained a lot of momentum and an MDN that is supported by all major browser vendors. All these initiatives are means to support Mozilla’s mission: to have a web that puts people first and empowers, rather than one that facilitates harassment, walled gardens, fake news and digital exclusion. Sillicon Valley isn’t necessarily society’s friend. These are things that need fixing. Katharina Borchert explained that, as these fixes need an answer that goes beyond technology, Mozilla has set up a policy team. Mozilla focuses on five issues in particular.

“Even mainstream media are noticing”

Throughout the week I learned about lots of different projects that clearly work towards this mission. I picked up lots of dots and it was great to see how well they all connected. For example, later in the day, I attended the Mozilla Foundation’s plenary session. Some of the Mozilla fellows presented their work on things like Net Neutrality, the Internet Health Report and privacy. All things that help fix what’s currently broken on the web.

Electives

On Wednesday afternoon I attend various electives: sessions open to anyone, focused on a specific subject. There was a lot of good stuff to choose from, I ended up going to the ones about the Photon Design System, WHATWG and a design system approach to Mozilla’s websites.

Photon Design System

Photon is the design system used by the people who build Firefox. It was created because browser engineers and designers wanted it, to make it easier to have the same look and feel across the browser, on all the platforms it works on. Currently it is ‘just’ a website that documents the design choices, but the team are looking in turning the style guide into a living style guide. In a fun post-it note exercise we looked at the pros and cons of Design Tokens. They are design decisions abstracted into JSON files, so that they can be reused. In CSS or Sass, but also in design software like Sketch. This setup can create an application agnostic approach to documenting design, because the tokens are easily shareable between platforms and people.

It was fun to think about Design Tokens

WHATWG

At the session of standards community WHATWG, I learned about their recent changes to dealing with intellectual property rights and what they mean for contributing. The new IPR agreement and way of working was developed together with all major browser vendors: Apple, Google, Microsoft and Mozilla. They all have representatives in the Steering Group. Spec contributors of all of those companies now contribute to the Living Standard/WHATWG-version of specs like HTML, rather than the W3C version (as GitHub activity shows). The session was quite positive and people seemed eager to work together with others including W3C, and minimise confusion for developers and browser implementors.

From wagile to agile with mozilla.org

Craig Cook, front-end developer at mozilla.org held an elective about design systems. Mozilla has hundreds of websites, some quite old and some brand new. Many of those have been developed in a process that started as agile but quickly became waterfall, something he ironically referred to as wagile. Design systems can help here, because if multiple sites make use of one design system, it is only that system that needs updating rather than individual sites. That would really offer the flexibility in process that wagile lacked. Other than process it will likely improve user experience, as human brains are good at pattern recognition, having reusable patterns leverages that. As someone who works on some Mozilla sites now and in 2018, I look forward to seeing the design system flourish.

Lightning talks

I also attended a number of lightning talks. Some facts from those:

you can have sourcemaps for Web Assembly (wasm) compiled Rust code in the browser, which can make wasm debugging as straightforward as JavaScript debugging
user testing showed that action-oriented users of MDN are better served with a live preview CSS editor.
the RNNoise project teaches computers to reduce noise with recurrent neural networks
incremental Rust compilation is coming, which will make things a lot faster
Web of Things is a horizontal stack and open source approach to Internet of Things, for which Mozilla submitted the Web Things API spec
there is talk about a Rust-powered version of Ember
Common Voice aims to create an open source data set that can be used by anyony who wants to teach machines about recognising voices; it has collected as much as 500 hours worth of speech data

CSS editor in MDN

This week has given me a lot of energy, despite the inevitable shortage of sleep. It has been a lot of fun to be part of this. It was refreshing to meet this super global community, with different countries and cultures represented. I am looking forward to Q1 of 2018, and the work that lies ahead. Because executing things is even more fun than planning them!

Originally posted as #yallhands on Hidde's blog.

[email protected]?subject=Reply%20to:%20#yallhands">Reply via email

2017 in review

2017-12-29T00:00:00Z

Inspired by Nienke, I’d like to share some of my highlights and learnings of 2017.

Highlights

Projects

2017 was the first full year working via my Dutch company, after I had hiddedevries.nl Limited struck off the English companies registry as part of my personal Brexit. The Dutch company was there since January 2007. It’s been over ten years now, but it feels so much shorter.

This year, I really, really wanted to focus on work with social impact (in government, culture or non-profit). How millennial! But really. In a world that is more and more powered by technology, choosing what kind of technology to work on and which people benefit from that technology seemed super important. This was not easy per se. If I’m honest, as a contractor, the kind of work I can do largely depends on what kind of projects I am approached for. Recruiters usually laughed when I mentioned my preference. But I feel it would be sad if all the bright minds of our industry helped some webshop create a better checkout flow and sell more tvs, if we could have helped citizens get the support they need. I tried being proactive, but luck and chance were probably as important. Anyway, I got to do some pretty impactful projects this year.

At Wigo4IT I worked on a web page where people can apply for income support from their local government (for the cities of Amsterdam, Rotterdam, Utrecht and The Hague)
At Logius I worked on a website where Dutch governmental organisations can generate an accessibility statement
At KOOP I worked on the redesign of various data-heavy websites, like overheid.nl and wetten.nl
For Web Conferences Amsterdam, I worked on visual design for the CSS Day and PhoneGap Day EU conferences (building upon Stephen’s designs)
I made various small changes to websites of Xander Publishers, Trio42, Stichting Piet de Vries and others
I joined Mozilla’s Open Innovation team as a contractor, and my contract was extended until far into 2018

Conferences and events

I have attended a couple of conferences this year:

CSS Day, which this year was a two day event about CSS and Browser APIs (write-up)
PhoneGap Day EU
Brique, a design conference by Fabrique
Patterns Day, about pattern libraries (write-up)
Fronteers 2017, its tenth edition and the first where I had no responsibilities whatsoever, great catching up with people
the year opening of Communication & Multimedia Design in Amsterdam, which I thought had a ‘work on stuff that matters’ theme to it (write-up)
Web Accessibility Live (which has no website, but it was great to see Job and Bruce speak)

Speaking

This year I also stepped out of my comfort zone and did my first public speaking, thanks to Niels and Léonie for encouraging me.

I talked about hiding content (slides) and the basics of accessibility (slides, video), at meetups.
At Fronteers Jam Session, I did an even shorter version of my talk about hiding content
At Inclusive Design 24, I spoke about the argument for accessibility from philosophical ethics (slides, video)
For Fronteers, I hosted two workshops about CSS Layout, which, to my own surprise, sold out. It’s awesome to see so many people excited about new lay-out techniques

Also to my own surprise, I thoroughly enjoyed preparing and giving talks. So much, that I would love to do more in 2018. Nothing much planned so far, but the CSS Layout workshop is running again and there may be another workshop in the first half of 2018.

Writing

On this blog I published 32 posts, some longer than others, some more interesting than others. There were also many posts that did not make it past the Draft stage, I guess that will always be the case. Writing can take up a lot of time, but I can recommend it to everyone working in the web field. It helps understand stuff better, can expose what you don’t know yet and also just to align thoughts.

These are some of the most read:

Volunteering

On April 1st this year I stopped volunteering at Fronteers, after over 8 years. It’s been a lot of fun and I learned a lot, yet it felt very good to step down.

The decision has given me a lot of free time, which was good. But I couldn’t really help myself and did organise a small event with Sharon: a film screening of Hanzi the movie, its European premiere. Responses were great, some people even suggested we could do a monthly design documentary meetup in Rotterdam. That would be very cool.

Things I learned

Finally, some random things I learned:

In two projects I was involved in we had official WCAG 2.0 audits, it was great to get feedback on our accessibility efforts. Before the auditor came I had done all I could to be 100% compliant, but they found several issues anyway, most of which we were able to resolve, others we could use as leverage to convince people of different prioritisation. Because accessibility is, as many things, team work.
I presented a couple of sprint review demos. It was fun to try and explain our technical projects to an audience with various less technical people in it. I learned to switch quickly between more and less technical narratives.
Remote working can be tiresome, especially working across time zones. I’ve had to force myself to do some non work things in my days to balance stuff out. Knowing when to ignore notifications late at night is acceptable and also key.
I wrote a lot of vanilla JavaScript, I owe a lot this year’s progress to Matijs, his patience is A+
Learned loads about how big organisations manage projects and how to be political about getting accessibility to be a priority. For example: be nothing but positive and constructive in meetings (this is a skill I’ve had to get much better at). I owe a lot of this year’s progress in that part of work to Jeroen. who is very good at this stuff
It’s been good to plan for holidays. However much it might seem like they’re not necessary, they absolutely are.

Some resolutions for the next year:

More reading of books and newspapers, less looking at my phone
More public speaking if I can
Better time management
Help other people get started with a personal blog like this one (get in touch if you need proofreading/advice)

I am looking forward to 2018. Happy new year!

Originally posted as 2017 in review on Hidde's blog.

[email protected]?subject=Reply%20to:%202017 in review">Reply via email

Form events when submitting with keyboard

2018-01-11T00:00:00Z

The other day I was building a form, and I was surprised how event firing works when you press ENTER on the keyboard.

When you’re on a form field in most browsers, pressing ENTER on the keyboard triggers the browser to submit the form. This is called implicit submission (thanks Tim). I suspected pressing ENTER would cause a submit event to be fired on the form, but it is more nuanced than that.

‘ENTER’ submits the form, even if it contains no submit button. If the form does contain one or more submit buttons:

pressing ENTER results in a click event on the submit button of the form
when the submit button is clicked, it submits the form, which triggers a submit event on the form

In the above, “the submit button” is the first submit button that exists in your form, the HTML spec calls this the form’s default button.

What surprised me, is that functions that listen to the click event on your default button, run before the form’s submit event is fired. Running event.preventDefault() on the form’s submit event will not stop that click handler from running (thanks Matijs for helping me figure this out).

Originally posted as Form events when submitting with keyboard on Hidde's blog.

[email protected]?subject=Reply%20to:%20Form events when submitting with keyboard">Reply via email

My ideal newspaper app is not very smart

2018-01-12T00:00:00Z

For about 6 years, I have mostly stopped reading my daily paper physically, unless sipping lattes in a coffee shop. I used its app instead. In those years, they released various updates, and these updates got me thinking about what I want from a newspaper app.

My app-based news consumption was somewhat of a necessity. I was abroad and kiosks abroad very rarely sell Dutch dailies. I’ve since really come to like reading digitally, and it also saves paper and sending screenshots to friends is useful.

My ideal

Ideally, the app just downloads a PDF and lets me browse through that page by page. A screen that has all pages would be useful, too, so that it is easy to jump to that one cartoon that I know will be on the last page. Yup, that doesn’t contain links and isn’t easily updated, and it doesn’t peruse some of the unique features of the web platform. It’s boring, simple and not very smart. To read articles you even need to zoom in, as the text is not HTML, it’s not responsive, it’s literally a PDF (it does contain plain text for users who need or prefer this).

Two things I like about the PDF-style newspaper reader: first, it looks like the newspaper everyone else buys from the kiosk, second, this formatting is the one a editing team of smart people have chosen over the course of their night. Up until moments before the thing really needs to go to press, they can still tweak things. After that time, that’s it: the paper of that day.

The good thing about producing one paper a day rather than a continuous stream of news is that the daily deadline forces decisions about what’s most important. Even if that means the occassional ‘when this went to press, we only knew 80% of the election results’. I can live with that. It is good for my sanity to take in one thing a day rather than continuous streams of news.

I like artificial intelligence, but for some things human judgment clearly wins. Let alghorithms calculate my fastest route to work or what the best way is to distribute food droppings in a war zone. For news, I think intentional prioritisation and placement in the page are best left to humans.

Their innovations

Two things De Persgroep have added to their Volkskrant app:

ads that take over the whole screen
animated page switch

I probably don’t need to explain what’s underwhelming about the addition of ads. This doesn’t belong here.

An animated page switch is cool, it keeps the interface fresh, but my tablet is too old to do the animation, causing it to freeze for a few seconds halfway an animation.

Both the ads and the animation slowed down the app considerably. This meant that, over the years, my digital paper became harder to read. That is remarkable for what is essentially a PDF reader.

What I’m not looking forward to

What I’m mostly concerned about is that my news will be displayed like it is on the newspaper’s website. This is great when one wants to see the latest news at a glance, but, with the bath water, it would throw away the daily carefuly curated prioritisation that news physical papers offer.

With CSS Grid Layout, the kind of layouts that are mostly unique to newspapers, are now possible in browsers. But until the process of filling a web based newspaper grid becomes a process similar to filling the physical paper with content, and I think having one daily thing that doesn’t change (much; small updates could be useful), I’m hoping the PDF-viewer version will stay on offer. Otherwise I would likely switch back to paper.

Originally posted as My ideal newspaper app is not very smart on Hidde's blog.

[email protected]?subject=Reply%20to:%20My ideal newspaper app is not very smart">Reply via email

Making password managers play ball with your login form

2018-01-13T00:00:00Z

Secure passwords are long and unique. Therefore, remembering them all is impossible for most human beings. Hence the popularity of password managers. If you’re building a login form, these are some tips to improve the experience for password manager users.

With ‘playing ball’ in this post, I mean that password managers recognise your login form and let you use their features on your fields. Things like password generation, offering to save credentials for a host name and filling in the password for you in a secure way. Ideally, password managers work in both of these cases: on first time visit (when they offer to store credentials) and on recurring visits (when they let you use stored credentials).

1Password recognises it has a pair of credentials for this site

Password managers come with all sorts of heuristics to detect username and password fields. Yet, they sometimes still fail to recognise them. For this reason, Firefox’s password manager complements its heuristics with a recipe system, where users can describe specific instructions for specific hosts. I believe some password managers have hard-coded field recognition for popular websites in order to make them work.

You might think, isn’t recognising my fields the job of a password manager? Isn’t this their problem? I have good news. Mostly, yes. Password managers are built to work with all login forms that follow best practices. Doing nothing special is an option. It will often give you a form that performs well across password managers. But if things don’t play out, this post may contain some pointers to look at.

Last Pass playing ball

Security considerations

Password managers that automatically fill in credentials can be prone to coffeeshop hacker attacks (over HTTP) , as shown by Silver, Jana et al in their paper Password Managers: Attacks and Defenses (pdf). They also provided a number of measures that password managers can take to prevent this, including only allowing filling in passwords after user interaction.

There is also a risk of leaking password information to third party scripts. The article explains actions against this include having the login form on a separate domain, ad blockers, and disabling autofilling altogether (as Safari will do by default). At the same time, more transparency could be provided with browser warnings or permission requests before autofilling.

Use standard HTML form practices

Make sure your form fields are in a <form> element that has an action and a method attribute defined on it.

Another think to look for, is that input elements are associated with a label through their ID (with for) or by being wrapped in one.

Using the right input type can also help: type="text" or type="email" for the username / email address, and type="password" for the password.

The `autocomplete` attribute

The autocomplete attribute on your username and password inputs can help password managers or browsers figure out what your fields are for. Actual autocompleting, as mentioned above, could be a security risk, if it is done by password managers on page load, rather than after user interaction, or if it happens on pages where protocol or host name are off.

Major browsers ignore autocomplete=”off”, some do this specifically for username and password fields, as they deem it more secure than users using very easy-to-remember passwords.

Google recommend using autocomplete attributes, and their advantages also appear in the spec (yes, there’s a spec!):

The autocomplete attribute offers a declarative mechanism by which websites can work with user agents to improve the latter’s ability to detect and fill sign-in forms by marking specific fields as “username” or “password”, and user agents implement a wide variety of detection heuristics to work with websites which haven’t taken the time to provide this detail in markup.

(Source: Credential Management spec)

For usernames

For the username field, you can add autocomplete="username".

For passwords

For new passwords, for example during account creation or in a password reset process, it’s autocomplete="new-password". For current passwords, for example in a login form, it’s autocomplete="current-password".

No funny stuff

Both 1Password and LastPass have various recommendations related to unexpected behaviour. Well-built login screens:

try to stay away from dynamically adding and removing fields
don’t regularly change names or IDs (or, worse, populate them dynamically)
have the form on the page on first render from the server
avoid method=GET and XHR requests for logging in (it can work, but it is harder)
use the placeholder attribute as it is intended
steer clear from mimicking a password field with a regular field so that you can do things like showing the last character

The message here is: keep it as simple as you can. This helps both users and password managers.

Multi-page login forms

Multi-page login forms can make sense, for example if there are different login options based on the type of user. With this kind of login pages, some password managers, including LastPass, may not play ball. I’ve found that LastPass will not work on first time visits, when your password field is hidden or in a hidden element (more on the hidden attribute). In others, including 1Password and the built-in managers of Chrome and Firefox, this problem does not exist.

In my situation, ‘pages’ were just divs on the same page, with only one of them not hidden. That caused LastPass to not do its first time visits thing. I consider this a bug in LastPass, or overly enthusiastic heuristics at the very least. I found out that if I used something like opacity: 0; it did not fail. This would cause a weird user experience, as opacity only visually hides elements, leaving them available to access by keyboard or Assistive Technologies (AT). Sometimes, and in this case, accessibility is about making something inaccessible to all, at the same time (i.e. when temporary hiding certain screens in a flow).

What I ended up going for is this: I used data-hidden instead of hidden, with CSS that only visually hides. In addition, I added the inert attribute (and its polyfill, as it has no browser support), to make sure the elements are not only invisible, they are also unavailable to use (until they should). Unavailable not only visually, but also for keyboard and AT users. It’s hacky, but it did circumvent LastPass’ bug.

Conclusion

Password managers are essential to secure internet usage, so making our login fields work with them is extremely important. This will mostly happen automatically if you follow best practices. The autocomplete attribute can make it easier for password managers to recognise your fields. Using hidden attributes can make password managers fail altogether. This can be hacked around, but I do not recommend doing so, unless absolutely necessary.

Many thanks Job, Krijn, Mathias and Henrik for suggestions and feedback

Originally posted as Making password managers play ball with your login form on Hidde's blog.

[email protected]?subject=Reply%20to:%20Making password managers play ball with your login form">Reply via email

aria-expanded does not require a fallback

2018-01-22T00:00:00Z

When building a control that toggles content in a web app, we can use aria-expanded to let the control know whether the content is shown or hidden. Expanded or not expanded. In assistive technologies (AT) that support this attribute, AT users can figure out whether the element was expanded.

The other day, a website I worked on was audited for accessibility compliance. The auditor suggested we would add a fallback for aria-expanded, so that it would work for more users. After some discussion back and forth, we decided against this and went with no fallback.

For those who don’t know the attribute, aria-expanded is an attribute you can put on a button that toggles content. When toggling the content, you update the attribute to be true of false. This lets browsers, accessibility APIs, platform APIs and ultimately your end users know that the thing is now open or closed. It is the mechanism that powers the details element in HTML, but you can also use it on your own controls, for example a hamburger menu or in a questions and answers sections.

Providing a fallback

For users of AT that does not support the aria-expanded, a fallback can be implemented. One way to do this is to simply add visually hidden text that conveys the control’s state:

<span class="visually-hidden">
 (expanded)</span>

I would not recommend this. Yes, if we add this text like this to the control, it will get conveyed to users of AT. With it, potentially more users can use and understand the control. However, it might cause more problems than it solves.

No fallback

These are some reasons not to provide a fallback for aria-expanded.

A string that needs maintenance

There is now a string of text that needs to be maintained. It sits in your markup, it requires time to explain to new team members and you’ll have to decide whether you want it managed by a CMS.

Non-standard text

If you add this text yourself, you or your colleagues may end up picking different text across the site. Or text that is different from what users hear on other sites that have expandable elements in them. And if someone new starts on the team, they may not understand what this is and can’t look it up in a spec, as it is not standard.

No automagic localisation

Screenreaders that support aria-expanded, will read out the status of the control: when it is collapsed, it says ‘collapsed’, when it is expanded, it says ‘expanded’. This is if your screenreader speaks English. If it speaks Dutch, it adapts and will say ‘ingeklapt’ or ‘uitgeklapt’, respectively. It’s up to the screenreader and its settings what it says, but we can be sure it will be consistent and free of maintenance.

Redundant for most users

Users that use AT with aria-expanded support, will hear the status twice. Ok, this can be mitigated by using hidden text instead of the attribute, but then the other points still stand.

So what is AT support like?

The question this might leave you with: what is AT support for aria-expanded like? It is well supported across platforms, and works in screenreaders like JAWS, NVDA, VoiceOver and Narrator. This means a fallback would leave most AT users to hear the status twice, to solve a problem for very few.

So, in conclusion: it is now best to use aria-expanded without fallbacks.

Originally posted as aria-expanded does not require a fallback on Hidde's blog.

[email protected]?subject=Reply%20to:%20aria-expanded does not require a fallback">Reply via email

You don't always need alternative text

2018-02-06T00:00:00Z

In a project I worked on recently, I noticed almost everything in the page had alternative text. Sometimes this can be redundant, for example if there is already text on the page that says what the thing is. Let’s look at some examples.

Why alternative text

A lot of the web is text. This is great. As a medium, that makes the web super parseable for external tools like search engines and assistive technologies (AT). It makes it even a better medium than the real world, where such parsing still requires a lot more effort. Until machine learning is ubiquitous, I guess, the fact that we have so much text on the web, makes the web the ultimate medium for accessible content.

When it is needed

Whenever we include non-text elements on a page, it is a good practice to add alternative text. For example, when adding an image, whether it is a photo or something with three words of text in it, we can use the alt attribute to convey what’s on the image to anyone who can’t see it. We’ve all seen this:

<img src="delirium.jpg" alt="A pink elephant" />

Or when adding a video, it is useful to add subtitles, for users who cannot hear the people talking in the video:

<video src="instruction-video.mp4">
  <track src="instruction-video.vtt" />
</video>

When it is not needed

Sometimes, alternative text is redundant. Look at these examples:

Speaker photos on a conference website

A page is divided in sections, with sections for each speaker. The heading in the section is the name of the speaker. There is also a portrait of the speaker. The photo does not require alternative text here, as it would be the same as the section heading, and that would be redundant. Note that the alt attribute is required, so in this case I would recommend an empty alt attribute: alt="".

I only learned when I was involved with Fronteers Conference, which follows this pattern on its speaker pages (thanks Krijn).

Labelled icons

Here’s a close button:

<button type="button">
  <img src="close.svg" alt="Close" />
</button>

In this case, there is only an icon, it exists on its own. An alternative text would be useful here, especially since it is used as an interactive element (like <a> or <button> ). If a button is just an icon, it does not have text that can function as the element’s ‘name’. So when, for example, a screenreader announces ‘button’, it doesn’t announce what the button is (as it doesn’t know). Adding a text like ‘Close’ helps with that, so that the screenreader can announce ‘button - close’

But when an icon has a word next to it, for example ‘Log out’, the icon itself is decorative and does not need an alternative text:

<button type="button">
  <img src="close.svg" alt="" /> 
  Close
</button>

In this case we can leave the alt attribute empty, as otherwise a screenreader would announce ‘button - close close’.

When captions describe photos

Sometimes, photos come with visible captions that describe them. In these cases, it is not necessary to add text into the alt of the photo, as the alternative text is already out there, the description has fulfilled the need.

Conclusion

Alternative text is a great opportunity to make the non-text parts of the web accessible. However, look out for redundancy, and only add it when it conveys something that isn’t already there.

Originally posted as You don't always need alternative text on Hidde's blog.

[email protected]?subject=Reply%20to:%20You don't always need alternative text">Reply via email

Donuts and Fronteers

2018-04-09T00:00:00Z

At the Open Innovation team at Mozilla, I learned about Donutbot. It is a Slack bot that randomly matches people from the team to each other, so that they can then go on and enjoy donut together. They are usually just metaphorical donuts, you could totally go for bubble tea or lunch. It doesn’t even have to be together, in person. You could use video conferencing software. But if you do meet IRL, selfie-sharing is appreciated.

Random donuts are a fun way to meet people you don’t directly work with. Or people you, for whatever reason, never talked to. It is also like a water cooler for remote workers. I really like the idea, so I suggested it to Fronteers, the Dutch professional association for front-end developers. It has a large-ish Slack community of mostly Netherlands-based front-end developers.

The way Donutbot works is as follows: it lives in a specific channel, which everyone in a Slack community is invited to join. Every two weeks, it matches everyone in the group with a random other person. To do this, it will start a group conversation with itself and the two people. That’s it. They can then sort out a date and time to physically or digitally meet. After two weeks, it will ask if you have had a chance to meet.

As of this week, Donutbot exists on Fronteers Slack. To be part of it, join the #meetandgreet channel, and who knows who you’ll meet next.

Originally posted as Donuts and Fronteers on Hidde's blog.

[email protected]?subject=Reply%20to:%20Donuts and Fronteers">Reply via email

A Dutch version of the Inclusive Design Principles

2018-04-16T00:00:00Z

I love the Inclusive Design Principles and often refer to them in discussions about accessibility. I also like language, so I thought why not translate them into Dutch?

The Inclusive Design Principles are written by the good people of The Paciello Group. They give guidance on how to make your websites and apps work for more people and make user-centered choices. The document urges makers of websites to think about context, consistency, choice and control, and emphasises that our products should add value, offer the same to all users and make primary content and tasks the first thing on a page.

If you would like to read or share them in Dutch, you now can, as Principes voor Inclusive Design is now live.

Originally posted as A Dutch version of the Inclusive Design Principles on Hidde's blog.

[email protected]?subject=Reply%20to:%20A Dutch version of the Inclusive Design Principles">Reply via email

For everyone

2018-04-20T00:00:00Z

At accessibility talks, I love to show a photo of Sir Tim Berners-Lee and the words he made appear on enormous screens during the 2012 Olympics opening ceremony in London: ‘This is for everyone’.

Copyright: Martin Rickett/PA Wire, from The Guardian

With ‘this’, he meant the web, I assume. I like to ponder what the other bit means, ‘for everyone’. It’s probably a number of different things:

Everyone can have a website. As in, you can register a domain, get hosting and put your site on. All at low cost and sometimes free. You do not need permission and are free to put whatever content on: your corporate mission statement or your love for the Vengaboys. Anything.
Everyone can go to websites, there’s no entry fee or barrier to the web —although there is to some sites and in some countries— the web is open to access by default.
Everyone can access the web, it is built to work for lots of different users, including those with visual, auditory or motor impairments, those with slow connections, those with new and those with old machines.

I think ‘this is for everyone’ refers for a large part to the universal accessibility of the platform. It is what makes the web awesome.

A different ‘for everyone’

During a meetup that took place at Uber Amsterdam’s offices this week, I learned about that company’s mission statement. Before I continue, it is very kind of them to host meetups, they are a great way for the web community to meet each other. I admire the hospitality that makes this possible.

Anyway, the statement:

Uber’s mission is to bring transportation — for everyone, everywhere.

I’m sorry, but it struck the wrong chord with me. Their everyone (and indeed their everywhere) means something else. Admittedly, this may come across as extreme cynicism, but let’s try and think about what it means for them. What Uber mean by making transport available to everyone, is that they want everyone’s transport transactions to run through their systems. So that they can get their financial cut.

This is, of course, a perfectly fine strategy and it is how economies work. It isn’t inherently wrong for companies to try and increase market share and profit, but it is definitely a different ‘for everyone’. It’s the same language with a different meaning. As the web-style ‘for everyone’ wouldn’t break sensible laws that protect vulnerable people, it wouldn’t monetise people in distress, it would not order fake rides to beat competitors, it would not deny users with guide dogs and it would not use its data to spy on ex-girlfriends, track one night stands and… well, the list goes on.

This is for themselves, not for everyone. Uber wouldn’t do those things if its for everyone was really about people and not about profits. They make Uber’s ‘for everyone’ sound hollow. And I don’t like that, because the web’s ‘for everyone’ is not hollow, it is built into how the platform technically works, in web standards, in all of that.

Conclusion

It appears ‘for everyone’ can have different meanings and I think it is important to see the difference between them, so that we are not fooled by for-profit companies that present themselves as charities. The web itself is a place where people are put first, and a place where power is not exercised on people, it is given to people.

Surely, it is great that so many companies are now using that platform for commercial purposes. Arguably that has helped with the platform’s popularity. It’s been pretty good for many of the world’ s economies too. But I can’t help but think about what the web could look like if we would make more things that really solve problems for everyone… let’s ask this: ‘what is the problem and who are we solving it for?’

Originally posted as For everyone on Hidde's blog.

[email protected]?subject=Reply%20to:%20For everyone">Reply via email

More accessible markup with display: contents

2018-04-21T00:00:00Z

CSS Grid Layout lets you turn an element into a grid, and place the element’s direct children onto it. Given that, it might be tempting to use flatter markup, but less meaning is usually less accessibility. With display: contents, we can place grand children on a grid, which lets us have accessible markup and beautiful layout. Let’s dive into the details!

Below, I will explain in more detail what I mean by children and grand children, and then show how we can use display: contents to improve this. Note: this caused an accessibility bug in all major browser engines, which has been addressed partially in all major engines since May 2022, with open issues, see below for details

Grid works on direct children

In Grid Layout, when a grid is defined on a given element, only direct children of that element become grid items and are layed out on it. To refresh for those not familiar with the syntax, let’s look at an example and write a recipe. With this HTML:

<div class="container">
  <h1 class="item">Penne with tomato sauce</h1>
  <p class="item">This simple recipe has few ingredients but tastes delicious.</p>
  <div class="item ingredients">
    <h2>You'll need</h2>
    <ul>
      <li>canned tomatoes</li>
      <li>onions</li>
      <li>garlic</li>
    </ul>
  </div>
</div>

we can have this CSS:

.container { 
  display: grid; /* element is now a grid container */
  grid-template-columns: repeat( 4, 1fr );  /* grid now has 4 columns */

.item:nth-child(1) {
  grid-columns: 1 / 2; /* Place item between grid line 1 and 2 */
}

.item:nth-child(2) {
  grid-columns: 2 / 4; /* Place item between grid line 2 and 4 */
}

.item:nth-child(3) {
  grid-columns: 4 / 5; /* Place item between line 4 and 5 */
}

I’ve used .container and .item as classnames, because that’s core to Grid Layout: there’s grid containers and grid items. Obviously, use any naming convention your projects require.

The reason we can position these items on the grid, is that they are direct children of the grid container. But look at what happens if we’d like to add a list of sponsors, like this:

We could add the list to our markup:

<div class="container">
  <h1 class="item">Penne with tomato sauce</h1>
  <p class="item">This simple recipe has few ingredients but tastes delicious.</p>
  <div class="item ingredients">
    <h2>You'll need</h2>
    <ul>
      <li>canned tomatoes</li>
      <li>onions</li>
      <li>garlic</li>
    </ul>
  </div>
  <ul class="item sponsors">
    <li>Supermarket 1</li>
    <li>Supermarket 2</li>
  </ul>
</div>

But we won’t be able to position each sponsor onto the grid. This is because only the <ul> is a direct child of the container element and therefore a grid item. The <li>s are not: because they are not direct children of our grid container, they don’t get to participate in its grid game. But what if we really want to align the sponsors onto the grid?

Flatter markup

One obvious method of making the sponsors participate is to remove the <ul> and use a <div> for each sponsor. But what we would then do, it ‘flatten’ our markup. That’s throwing away the baby with the bathwater.

The benefit of using the <ul> (unordered list) element are plenty:

it will stay a list outside the context of our page, for example in Safari Reader mode, it will show as a list
when printed with stylesheet turned off, it will show as a list
for people who use screenreaders, it is a list (screenreaders can announce things like ‘list, 3 items’).

If we would make our markup flatter, we lose those benefits.

`display: contents` to the rescue

With display: contents, we can have our markup and our grid placement. This property makes the element so that it no longer seems to exist. It does not generate a box, so backgrounds, borders and other box-related properties will no longer work on it. Grid placement properties will also no longer work. But all of these things will work for the element’s children. The spec says the element behaves ‘as if it had been replaced […] by its contents’. If that sounds weird, I can recommend Ire Aderinokun’s detailed explainer.

Effectively, for our purposes here, using display: contents on an element does this: the element stops participating in the grid, and its contents start participating in it. It lets us specify our sponsors onto the grid, instead of the list they are contained in.

There’s some interesting edge cases listed in the spec, for if the property is used on elements like img and video.

Accessibility concerns with current browser implementations of `display: contents`

For people who use assistive technologies (AT), browsers expose accessibility properties, including the role of elements on the page. This is so that their AT knows what’s what on the page. Many elements come with a built-in role, for example lists have a role of list.

This is where it goes wrong in current browsers that support display: contents. They do not interpret display: contents as a lay-out thing only, they also derive meaning from it. This is problematic and a bug according to the spec’s comment on display affecting layout:

The display property has no effect on an element’s semantics: these are defined by the document language and are not affected by CSS. Aside from the none value, which also affects the aural/speech output and interactivity of an element and its descendants, the display property only affects visual layout: its purpose is to allow designers freedom to change the layout behavior of an element without affecting the underlying document semantics.

(emphasis mine)

Looking at our sponsor list example, it means that the item is no longer seen as a list, but as something else (test case in CodePen).

I’ve added my test results per browser below. In each of them, our <ul> gets the correct role without display: contents, but once the property is set, it loses its role.

Firefox 61

The list gets a role of text leaf (Firefox bug). Update: this is now fixed; it will ship in Firefox 62 in August 2018

Chrome 66

The list shows as ‘accessibility node not exposed, element not rendered’ (Chromium bug). Update: this is now fixed; it has shipped in Chome 89 in March 2021

Safari

The list shows as ‘no accessibility information’ (Safari bug, Webkit bug #185679, Webkit bug #237834 that they did more work in)

Update 13 June 2022: this was reported fixed in Safari TP 144 / Safari 16
Update 9 July 2022: Adrian Roselli reports work is still needed in Safari

Related to this issue is that display properties in CSS have impact on table semantics, as Adrian Roselli explains; see also Steve Faulkner’s explanation of where the responsibilities lie.

Conclusion

With display: contents, you can place grand children of a grid container on the grid. This allows for more semantic mark-up, which is great for accessibility. The more meaningful your mark-up, the more detail an assistive technology can provide to its users. However, there is one caveat: none of the browsers that currently support display: contents expose elements that have the property to the accessibility tree with their original role.

I believe the accessible roles should not disappear when setting display: contents, as that defeats a lot of the purpose of display: contents. I have filed bugs with Firefox, Chromium and Safari for this. I really hope we will be able to use display: contents while keeping the accessible roles of elements intact, so that we can have great layouts and great accessibility. To be continued, I hope!

Originally posted as More accessible markup with display: contents on Hidde's blog.

[email protected]?subject=Reply%20to:%20More accessible markup with display: contents">Reply via email

Vague, but exciting…

2018-06-04T00:00:00Z

Last week I saw Sir Tim Berners-Lee, inventor of the web and receiver of the Turing Prize, give the ACM Turing Lecture. He spoke about redecentralising the web.

In less than an hour, Tim Berners-Lee talked us through the history of the web, its current state and what we need to do to have a healthy future for the web. Redecentralisation, he phrased this. The web was invented as a decentralised thing, but that model is currently under threat. Large portions of the web have become walled gardens from within which it is hard to exchange with others: data is kept within its own garden.

A universal and decentralised web

The decentralised web, Berners-Lee explained, started at CERN, a research institution that brings together lots of different people, from different universities, with different preferences for both natural and programming languages and, of course, lots of documentation that was stored on computers.

Berners-Lee worked at CERN as a software engineer and he had this idea for making documents easier to access by having unique identifiers for them. When talking about this idea at the coffee machine, a colleague said he should write it down. He did and when his boss read the proposal, he wrote the now so famous words ‘Vague, but exciting’ on the memo. When he later had some time in between projects, what an impactful coincidence, he started to develop this idea further.

URI vs UDI vs URL

A key component of the initial idea was that everything on the planet should be named so that it has something to be accessed by universally — or uniformly, there was plenty of debate around the distinction, he explained.

The universality of the web, Berners-Lee said, is that it works independent of:

hardware and software, including browsers
the type of network access (e.g. mobile or cable)
whether you want the data to be publicly or privately available
the polish of the content: it works equally well for polished publications and scribbled ideas (or Vengaboys fansites)
language and culture
disability
whether the data is to be consumed by people, machines or a combination of both

A web that has the above independencies is one worth fighting for, Berners-Lee explained. The W3C famously does great work in this, but less well known is that Berners-Lee found another organisation: the World Wide Web Foundation. It wants to make the web a better place for more people. He argued that if people spend 98% of their time on the web, they might as well spend 2% defending it.

We might be going in the wrong direction

Berners-Lee first showed a virtuous circle: if all goes well the web lets people publish, which inspires conversation and more publications. This is the utopian scenario and we’ve seen a lot of this actually happen. The web community itself it s a great example of this, we teach each other stuff and good blogs inspire other people to start blogging, this very blog is an example of that effect.

The ideal web is a virtuous circle

However, if we’re not careful, Berners-Lee warned, there can also be a vicious circle, a dystopian scenario. This happens when algorithms cause people to meet more people like themselves, narrows down their circle and alienates them from people who are different. Or when websites are used to harvest people’s personal data that are then used for political gain. Or when falsehoods are presented as facts. These seem pretty much like the things that Mozilla identify as issues concerning internet health.

Towards more decentral web

There’s all sorts of things we can do to make better things for the web, and perhaps, consequently, make the web better. Berners-Lee urged us to build things that facilitate open dialogue and discussion, not flame wars. Human rights should be at the center of such things, and it would probably only work if it was not a centralised solution: we might need new (social) networks altogether in order to get what we need. Solid is an initiative led by Tim Berners-Lee aimed at building social websites that are not centralised and let people have control of your own profile and data.

It was an inspiring morning and great to see Berners-Lee speak in person (for what was my second time). The principles that the web was built on are strong and the lecture was a great reminder of how we can make better things on the web. We should make good things!

Originally posted as Vague, but exciting… on Hidde's blog.

[email protected]?subject=Reply%20to:%20Vague, but exciting…">Reply via email

How I learned to stop worrying and love CSPs

2018-06-26T00:00:00Z

To gain precise control over what styles, scripts and other assets do on your site, you can serve pages with a Content Security-Policy. What does that mean for the front-end, and for those of us building user interfaces in browsers? Well, it can be tricky to set up, but there are useful benefits.

Why CSPs?

CSPs basically work like a whitelist of asset domains that the browser will accept for your site. This is great, as browsers have no notion of benevolent or malicious assets. Only website owners do. By telling browsers where the good stuff is located, website owners can rest assured users of modern browsers won’t get bad assets executed. They are one out of many security headers.

CSPs have been around for ages (see for example the Twitter blog in 2011), but usage numbers seem to be quite low. It seems to me they have recently gained more traction though, as more people get interested into website safety and content integrity. See also how Mozilla Add-Ons did it.

How they work

Technically, a CSP is a string that contains key-value pairs, served as a header with the response (or via a meta element in the page). They describe for each type of content how it can be used within your page. To be more precise: where it can be loaded from. Definitions for each type of asset are separated with semicolons, the definitions themselves have spaces in between.

Here’s an example:

script-src https://hidde-cdn.com; style-src https://hidde-cdn.com

This will only allow scripts or styles if they are served from https://hidde-cdn.com.

There are also a number of keywords.

self will allow assets from the same domain that the page is served from
unsafe-inline will allow inline assets

See for example, this policy:

script-src 'self' https://hidde-cdn.com; style-src 'unsafe-inline' https://hidde-cdn.com

This allows scripts only from the current domain or from https://hidde-cdn.com, and allows styles inline or when served from https://hidde-cdn.com.

There are also directives: font-src for fonts, img-src for images,connect-src for fetching/requests and default-src if you want to set a default. Best set default-src to none, so that you already have a policy for any asset types you don’t or forget to define.

The unsafe-inline directive is interesting: it has the word ‘unsafe’ in it, because inline assets are considered harmful. I should clarify: inline assets aren’t harmful because they are inline as such, but it is the case that whenever malicious scripts or stylesheets are injected, they are likely to be inline. Blocking their execution altogether mitigates their risk. If that feels like too much, it is also possible to allow some inline scripts: identify one script with a nonce (a number used once) and whitelist that nonce.

In summary, a CSP lets you whitelist locations to load assets from. Although these whitelists themselves are simple when you grasp the concept, their consequences can be unexpected and, for front-end devs, rather inconvenient.

Some side-effects

When I recently implemented a CSP in a project I was working on, I found a couple of surprises that were inconvenient, some of them related to disallowing inline assets. Note that those specific issues will be go away if your setup has a different, less stringent CSP locally.

Adding styles via Developer Tools

Sometimes when I’m working on some CSS, I’ll inject CSS via the Dev Tools, so that I can see what the effect of my changes are without actually making them just yet. If your CSP disallows inline styles, you are out of luck as this feature will stop working.

Browsersync

If your local development environment uses script to reload the browser when you’ve changed a file, this likely uses inline scripts that will be blocked when your policy forbids inline scripts.

Analytics

If you’re using external analytics scripts, don’t forget to add the domains that they load from, if they are different from your own domain. This is the case for Google’s Analytics and Tag Manager products, for example.

Polyfills that inject CSS

The inert polyfill injects some CSS into the page in order to prevent user selection on inert elements. Injected CSS counts as inline CSS (obvs), so that will not work.

Inline styles in SVGs

Double-check that SVGs that you are including in your page do not contain style attributes, as some browsers can deem those to be a violation of unsafe-inline.

The good and the bad

What I love about CSPs

The great thing about CSPs is that, if implemented well, you know exactly where to expect attacks. Without a CSP, the ‘attack vector’ is unknown and likely big or of infinite size, with a CSP you know where it can come from.

If you work in a large organisation where the marketing team can insert scripts via Tag Manager(-like) solutions, which is quite common these days, CSPs are also a useful treshold. Scripts that are useful for gaining marketing insights could at the same time be risky from a security standpoint (not to mention privacy).

There are some design choices that make CSPs a joy to work with, for example the built-in report-uri directive, that lets you specify a URL to report CSP violations to, which can be used to track violations using a service like Sentry.

What I slightly dislike

If your site is served over SSL and you sanitise all the things (in other words, you avoid Little Bobby Table scenarios), your CSP does not actually make it more secure. Note that this is a huge if. If you’re healthy, a health insurance isn’t going to make you more healthy, but it is extremely sensible to have one in place anyway. This is kind of the point of CSPs, they provide extra cover for if things like SSL and XSS protection aren’t (correctly) in place. Mistakes can be easy to make in the security space. So I’ve learned to love this: CSPs don’t harm if you can work around the side-effects.

Something else I don’t really like is the usability of error reports for CSP violations in browser Dev Tools. They will make clear that there is an error, but aren’t too helpful in pointing towards the right direction. Browsers could be clearer about which exact bit of your policy is stopping an asset from working.

TL;DR

CSPs can nullify what XSS attackers can do once they’ve managed to attack. This is great, although implementing it can make some things harder on the front-end. But that’s ok, it is our job after all. For help with implementing a CSP for your site, check out Mozilla’s Laboratory Add-On and Google’s Web Fundamentals page on CSP.

Originally posted as How I learned to stop worrying and love CSPs on Hidde's blog.

[email protected]?subject=Reply%20to:%20How I learned to stop worrying and love CSPs">Reply via email

What kind of ethics do front-end developers need?

2018-07-05T00:00:00Z

Now that the technology sector of the world is rapidly transforming all of the world’s things into digital things, many have called for more ethics in our field. That is in many instances quite a vague goal, so let’s apply it to one part of digital: front-end development. How can we be more ethical as front-end developers, what kinds of things can we do? I thought I’d try and make a list.

I don’t know what is good for us. I mean, I have ideas about that, but this post is not about those ideas, it is about what kinds of things front-end developers can think about if they want to apply ethics to our field.

What and why

In my talk for Inclusive Design 24, I said that ethics is about how we want our world shaped. But ethics has many definitions, another one is that it answers the question ‘what should I do?’ In that question, note the word ‘should’. It’s about what you’re obliged to do. It also implies taking a moral stance and choosing between different paths. It is about coming up with reasons based on what is considered the right thing, based on a set of rules. An example of such a rule is ‘only act according to rules that you would want to apply to everyone’ (said Kant). And there is The Golden Rule: treat others as you would want to be treated.

The ethics described above is roughly what the literature would refer to as duty-based ethics, it is based on the idea of a moral obligation. There is also consequence-based ethics. Consequentialists look at the outcome of their decisions and actions. They consider how decisions or actions impact the world, for example whether they increase or decrease the total amount of happiness in the world. It doesn’t matter how you get to an increase of total happiness, it matters that you do.

When trying to apply ethics to technology, it should be fine to be pragmatic and combine both approaches. Do things because they are right and do (or leave) things because of their consequences.

The reason that ethics can make an important contribution to the web is its focus on why and how we do things rather than just what we are doing. That focus has the unique chance to make our choices more human, because arguably without ethics we could just leave our decision making to machines. It takes a human to make ethical decisions, said the awesome Laura Kalbag. Thinking ethically about decisions also makes them more human. It works both ways.

Tim Berners-Lee already talked about how ethics is important for the web at the first WWW conference in 1994. He describes this in his book Weaving the web (2000, 86):

I finished by pointing out that, like scientists, people in the Web development community had to be ethically and morally aware of what they were doing

This, about the origins of the Web, is recommended reading, by the way. Don’t judge it by its cover design…

Ethics is important for everyone who makes things for the web: people working on design, product and management. But also for front-end developers. We drive a lot of how modern web products are built and uniquely know of weird details and consequences of products decisions. If ethics is about consequences, we are part of it. So let’s worry about what decisions are made. Rather than just using our expertise to build products, we can think about decisions and then build products. Because it is also our duty and we can help increase (or not decrease) total happiness in the world.

Ok, so do I just `npm install ethics`?

Admittedly, I’m stretching it a bit, but I would like to show what ethics is not. I should stress that ethics can’t be just added to something that exists, it has to be in the decision process before. Automating ethics won’t work either, trying to do it would also sort of miss the point of ethics. Package managers like npm can install most things that a web project could possibly depend on, but it should be clear by now that ethics is not one of them. Computers can automatically foresee consequences sometimes, they can use statistical analysis see how big your JS bundle will be. Or, more real-world, use facial recognition to see that someone is cheating on their partner. But the point is, ethics is the assessment that can start after metrics like these. It requires humans.

There are plenty of situations in our jobs where we can apply ethical thinking to what we do. Let’s look at some real-world examples.

Front-end developer impact

Ensure accessibility

The web is accessible by default, but as a developer it’s easy to break that in the flow of getting features shipped. I sometimes do this myself, and I specialise in accessibility. There are ways to improve though, for example by focusing (part of) your personal development on learning about making accessible products. By being aware of how to meet the Web Content Accessibility Guidelines and generally accessibility good practices, you can directly contribute to letting more people enjoy the web through code.

Analytics with Do Not Track

You’re asked to implement trackers in a site. You are aware that technically, this will allow some megacorporation to spy on people. You are also aware that modern browsers support Do Not Track. It will likely be your choice to honour your user’s Do Not Track settings, and otherwise your duty to convince the people in the company who prefer more metrics over more valuing user preferences. Or maybe you research a way to completely anonomise the data. This combines duty and consequences.

Impact on society at large

This is a more general example, applying to what you work on and where you choose to work. There’s a degree of ‘but not everyone is so privileged that they have choice’ to this, but I still believe we can all choose to some degree. When working as a front-end developer, it is likely that what you work on will somehow shape the world, sometimes even disrupt it. Should you build the front-end for a product that ‘disrupts’ an industry, but also introduces more inequality and makes the lives of other people harder?

Code of conducts in open source

If you released some of your code as an open source project and it attracted a bit of a community around it, considering community values would make a huge difference. Things like how you want people to feel empowered to make suggestions, feel included in the community, participate and show empathy to each other. A Code of Conduct (for example, a CODE_OF_CONDUCT.MD) could help make these values explicit, and heck, you could even npm install one (just note that this only adds value if you also have a plan for getting incidents reported and responding to them).

Diversity in hiring

As a front-end developer you may sometimes be involved in hiring new team members. This is also a great opportunity to influence how the world is shaped: be aware of possible biases in order to give good recommendations to HR.

Recognising dark patterns

If you don’t like to be tricked into buying services you don’t actually need or want, then your users likely feel the same. Learn to recognise dark patterns and start the discussion if you’re asked to implement one.

Keeping users secure

By being aware of common security risks we can ensure our users are safer online. Most of the responsibilities fall within front-end (and back-end) development scope. The Golden Rule applies here: if you surf the web as a consumer, you would also like the developer who has built the site to have done so securely.

These are all things where an ethical attitude and contemplating why and how we do things can be helpful in creating a better web. They’re not all easy things, some of them are hard to get right. But if we’re going to play a role in making all the things digital things, let’s do it responsibly.

Conclusion

As front-end devs, we can apply ethics to our work by having an ethical mindset when doing our work. Practically we could do this by applying the Golden Rule and thinking about consequences of our code for users and our colleagues, for example by ensuring accessibility, security and a safe and welcoming working environment.

Originally posted as What kind of ethics do front-end developers need? on Hidde's blog.

[email protected]?subject=Reply%20to:%20What kind of ethics do front-end developers need?">Reply via email

Accessible page titles in a Single Page App

2018-07-19T00:00:00Z

According to WCAG 2.4.2 pages should have titles. How to go about this in a single page world?

What are titles for?

Pages have titles so that people can recognise where they are. They are like a plaquette on a meeting room door, signposts that mark the platform in a train station or the signage for a supermarket aisle. They help people figure out where they are.

Additionally, page titles also signify uniquely what’s on a URL. This is helpful for search engines, they display the title. Or for social media platforms, they display it when you share a link. People using screenreaders hear the title, it lets them figure out what a page is when they land on it.

Titling pages, the traditional way

In a site with multiple pages, you can put different content in the <title> element for each different page. This is trivial if you build each page separately, it is a little more work when the value comes out of a CMS, but still fairly straightforward.

Titling pages in Single Page Apps

In a Single Page App (SPA), the user never leaves the page. There is no new page with a new title. Instead, you’ll have to update this manually by changing the value or document.title , which is where the page title is in the DOM.

Changing pages in SPAs is often done with routers like react-router and vue-router . I was surprised to see that, by default, those two only update content and the URL, not the document title.

You can update the page title manually, though. In React, you can do it in the componentDidMount() of a route, and there is a react-document-title package that does it for you. If you want to update more meta info than just the title, there is React Helmet.

In Vue, I had luck doing it in beforeEach of the router:

router.beforeEach((to, from, next) => {
  document.title = `${to.name} - Your site`;
  next();
});

But if you’d like to abstract this further and update the page’s title along with other things in the head of your document, there is Vue Helmet or Vue Meta.

(Update 2 June 2020) In Svelte, you can set page titles using the special <svelte:head> element in the components that you use as a route, like so:

<!-- MyPage.svelte -->
<svelte:head>
  <title>Page Title goes here</title>
</svelte:head>

Announcing titles

In screenreaders, when a user goes to a new page, it will read out the title of that page. In a Single Page App world, you can update the title with document.title , but, sadly, that change does not trigger a screenreader announcement. It is helpful to do this manually, for example by putting content into a live region (the on demand live region abstracts this).

There are different strategies as to what to read out on a route. In an SPA, you could choose to set focus to the top of the document when you do a route, this would make it feel like a multi page application. Users would have to use skip links to get back to the content, just like in multi page applications. But maybe you only update one section, and your strategy is to move focus to the new content. In this case, you could ensure the title of whatever is new is read out, rather than the updated page title. For example, if you replace the main by something new and then focus the new content, convey to assistive technologies what the title of the newly focused content is, for example by having its first heading announced.

Does this mean the title is irrelevant in SPAs? Not really, it is still useful to have an up to date title , for example for people switch between tabs or when you turn on Server Side Rendering.

TL;DR

Giving pages unique titles aids accessibility and is compulsory if you are after WCAG 2 AA compliance. If you build a single page app, update the title manually, but also look at having something useful announced when new content is inserted. It could make more sense for this to be a section title than the document’s title, depending on what you’re building.

Originally posted as Accessible page titles in a Single Page App on Hidde's blog.

[email protected]?subject=Reply%20to:%20Accessible page titles in a Single Page App">Reply via email

An AI reading list

2018-08-07T00:00:00Z

Having been long interested in artificial intelligence, it was one of my focus areas in university, I looked for theoretical background beyond the hype. If it is also summer where you are, you may have some extra reading time, too. So, I present you: an AI reading list.

This list is mostly about the philosophy of AI: what intelligence means, how it can be represented, what the ethical implications are of teaching machines, those kinds of questions. Expect to read about psychology, mathematics, linguistics, philosophy and computer science. It’s all of those things together that the field is made up of.

A common theme in these books is that AI application aren’t that intelligent yet or anywhere near ready to replace human intelligence. Phew. I discovered this myself looking for recent books on philosophy and AI. Online bookstore search engines (or category pages) were not that helpful for finding what I was looking for. Look in the ‘philosophy’ department and a book by Plato is listed first. Who reads Plato just by themselves? Book review pages in newspapers, blogs and humans in book stores helped more. Yes, humans!

The New Dark Age

In The Guardian’s review of this book they said enjoyment of it depends on whether you are a glass half full or half empty kind of person. Very much true, I think. The New Dark Age describes a lot of dark consequences of what Bridle calls ‘computational thinking’, the idea of throwing tech at every problem. This thinking seems prominent in Silicon Valley and it is dangerous, Bridle explains, because our problems are less about what we know (data) and much more about what we do and think. This book is not just about AI, it is also a lot about the impact of technology on society. We should think twice if we want to outsource decision making to systems, Bridle warns. Buy from the publisher to get a free e-book with your hardback.

Plato and the Nerd

Is AI ‘our biggest existential threat’, as Elon Musk once claimed? Edward Ashford Lee, writer of Plato and the Nerd doesn’t think so. What is more likely to happen and what we should want to happen, he explains in this book, is that humans and machines complement each other. We are creative, they can crunch lots of data at mesmerising speeds. We may not be more than just neurons (Lee isn’t a dualist), but it is unlikely we’ll ever be able to reconstruct human brains and minds in machines. If we’re making abstractions, like Plato did with his theory of Ideas, we should be careful not to confuse the map with the territory. This book brilliantly explains machines from semiconductors to programming languages to mathematical possibilities. It gets very technical and mathy at points. Lee shows how engineers are creative rather than technical: the most technical layers are abstracted away from them. He also talks about the relationship between tech and society: ‘I do not see how a true humanist today can understand society without understanding technology’, he says and I could not agree more.

From Bacteria to Bach: The Evolution of Mind

From Bacteria to Bach by philosopher Daniel Dennett is about evolution, what it means to (not) understand something (explained with the interesting notion of ‘competence without comprehension’) and how that changes our view on artificial intelligence, language, culture, consciousness and much more. The book is full of anecdotes and side steps, which for me at some point started to prevent Dennett from clearly getting his point across, it was a bit overwhelming. But then again, the book is full of interesting analysis of where the fields of philosophy, psychology and computer science have overlap. See also The Guardian’s review, who said this about the book:

This is an infuriating book – too long and self-referential – but underlying it all is an interesting argument

Common sense, the Turing test and the quest for real AI

In 2018 many of us think of adaptive machine learning (AML) if we think about AI. In Common sense, the Turing test and the quest for real AI, Hector J. Levesque takes us back to what it all started with: good old-fashioned artificial intelligence (GOFAI). It goes into detail about what can’t really be learned by machines: common sense. He explains Winograd Schemas, which is his modern equivalent of the Turing test: they can be used to figure out if a machine is ‘making it or faking it’. I liked how concise and lucid this book is.

Turing’s Vision

Turing’s Vision, which I raved about before, is about one of Alan Turing’s most interesting papers, in which he tries to prove the mathematician Hilbert wrong. That paper shines new light on something called the ‘decision problem’ (‘whether we can write algorithms that can decide if certain mathematical statements are true or false’). This book is fairly technical, I had to skip parts because I had not enough intelligence. Your mileage may vary.

That’s all for now, happy reading! I’d love to hear what others are reading in comments or e-mail.

Originally posted as An AI reading list on Hidde's blog.

[email protected]?subject=Reply%20to:%20An AI reading list">Reply via email

Let's serve everyone good-looking content

2018-08-11T00:00:00Z

In Benjamin’s poll, the second most voted reason to avoid Grid Layout was supporting Internet Explorer users. I think it all depends on how we want to support users. Of any browser. Warning: opinions ahead.

What lack of Grid Layout means

Let’s look at what a browser that does not support Grid Layout actually means.

What it is not

To be very clear, let’s all agree this is not the case:

Browsers that support Grid Layout: users see a great layout
Browsers that don’t support Grid Layout: users see a blank page

That would be bad. Luckily, it is not that bad. CSS comes with a cascade, which includes the mechanism that the values of style rules are always set to something. Rules have a default value, which is usually what browsers will apply for you. It can be overridden by a website’s stylesheet, which in turn can also be overridden by user stylesheets. Because of the design of CSS, properties always compute to some value.

What it is

When turning an element on the page into a grid, we apply display: grid to it. At that point, it becomes a grid container and we can apply grid properties to it (and its children). If we set display: grid in an unsupported browser, the element will simply not become a grid container, and it will not get any of the grid properties you set applied. The display property will be whatever it was, usually inline or block, different elements have different defaults.

A little sideline: per spec, if you use floats (or clear), they will be ignored on children of grid containers. This is great for fallbacks.

Without Grid Layout, you still get your content, typography, imagery, colours, shadows, all of that. It will likely be displayed in a linear fashion, so it will be more or less like most mobile views. That is a perfectly ok starting point and it is good-looking content that we can serve to everyone.

Serving users good-looking content

I think our goal, rather than supporting specific browsers or specific CSS properties, should always be this: to serve users good-looking content and usable interfaces that are on-brand. I think good-looking and usable do not depend on how griddy your layout is. On-brand might, though. Some brand design guidelines come with specific grids that content needs to be layed out in. But aren’t we already used to stretching such guidelines, building responsive interfaces that work across viewports? Shouldn’t we let go, because we cannot control a user’s browser?

If for some small proportion of our users, we let go of the specific grid we created with grid layout, that will not hurt them. Likely not without any fallback, but definitely not with a simple fallback based on floats, inline-block or maybe flex and/or feature queries. But keep it simple. As Jeremy Keith wrote:

You could jump through hoops to try to get your grid layout working in IE11, […] but at that point, the amount of effort you’re putting in negates the time-saving benefits of using CSS grid in the first place.

I don’t think we owe it to any users to make it all exactly the same. Therefore we can get away with keeping fallbacks very simple. My hypothesis: users don’t mind, they’ve come for the content.

If users don’t mind, that leaves us with team members, bosses and clients. In my ideal world we should convince each other, and with that I mean visual designers, product owners, brand people, developers, that it is ok for our lay-out not to look the same everywhere. Because serving good-looking content everywhere is more important than same grids everywhere. We already do this across devices of different sizes. For responsive design, we’ve already accepted this inevitability. This whole thing is a communication issue, more than a technical issue.

Save costs and sanity

If we succeed in the communication part, we can spend less time on fallbacks, now and in the future (I’m not saying no time, we want good-looking content). An example: that mixin we created to automatically fallback grid to flex to inline-block might look like a great piece of engineering now, it may later become a piece of hard to comprehend code. Solving the communication issue instead of the technical one, will save time in initial development costs and help prevent technical debt.

Originally posted as Let's serve everyone good-looking content on Hidde's blog.

[email protected]?subject=Reply%20to:%20Let's serve everyone good-looking content">Reply via email

Heading structures are tables of contents

2018-09-01T00:00:00Z

The heading structure of a web page is like its table of contents. It gives people who can’t see your page a way to navigate it without reading everything.

To be clear, by ‘heading structure’ in this post, I mean the heading elements in your HTML: <h1> to <h6> . These elements can be strongly intertwined with what they look like, but for our purposes it is the markup that matters.

The best analogy I’ve been able to come up with for heading structures, is the feature in Microsoft Word that lets users generate a table of contents automatically. It is used a lot by all kinds of people, in all kinds of environments (in long corporate documents, but also in academia). If you’ve set document headings correctly, it lists all sections and subsections. It even remembers, and updates, which page they are on.

Example of the automagic table of contents feature in Pages. It even lets you select which heading levels to include!

All websites have this too, as a similar feature is built into most screenreaders. In VoiceOver, for example, users can press a button to see a list of all headings and use this to navigate a page. In fact, this is a common way for screenreader users to get around your page without reading everything.

The headings feature in action on Wikipedia. Note that Wikipedia also lists the headings explicitly, with section numbering.

Only use headings to identify sections

To let users get the best navigate-by-headings experience, only use heading elements for content that actually identifies a section. Ask ‘would this be useful in my table of contents?’, and if the answer is no, best choose a different HTML element. This way, only table of contents material makes it into your heading structure.

For this reason, by the way, I recommend to avoid having headings be part of user generated content (as in: content added not by content specialist, but by users of your site). If you offer Markdown for comments, for example, headings in those comments could mess with the usability of your heading structure.

If you choose something to be a header, make sure it describes the section underneath it. This can be hard to get right, you might have great puns in your headings, or maybe they were written by a SEO expert.

Visually hidden headings

Not all sections have headings, often the visual design makes it clear that something is a distinct piece of content. That’s great, but it doesn’t have to stop a section from also showing up in your table of contents. Hidden headings to the rescue!

A hidden heading is one that is ‘visually hidden’, this is content that is not visual on screen, but it exists in your markup and screenreaders can use it:

<h2 class="visually-hidden">Contact information</h2>
<!-- some content that looks visually a lot like contact
     information, with icons and a receptionist stock
     photo that makes it all very obvious-->

(More about CSS to visually hide)

The heading goes into your virtual table of contents, but it is not visible on screen.

Note that visible headings are much preferred to hidden headings. There are two problems in particular with hidden headings:

Like with other hidden content, it can easily be forgotten about by your future self or the next team member. Hidden content that is not up to date with the visible content is unhelpful, so it is a bit of a risk.
Serving slightly different content may cause confusing conversations, for example if an AT user and a sighted user discuss a page and only one of them knows that there is a heading.

‘Don’t skip heading levels’

Although WCAG 2 does not explicitly forbid skipping heading levels, and this is controversial, I would say it is best not to skip heading levels.

If a contract has clause 2.4.2, it would be weird for there not to be a 2.4 — the former is a subclause of the latter. It would be weird for the subclause to exist without the main clause.

The most common reason why people skip headings is for styling purposes: they want the style that comes with a certain heading and that happens to be the wrong level for structural purposes. There are two strategies to avoid this:

have agreement across the team about how heading levels work
use .h1, .h2, .h3 classes, so that you can have correct heading levels, but style them however you like

The former is what I prefer, on many levels, but if it is a choice between weird CSS and happy users, that’s an easy one to make.

Automatically correct headings

The outline algorithm mentioned in HTML specifications is a clever idea in theory. It would let you use any headings you’d like within a section of content; the browser would take care of assigning the correct levels. Browsers would determine these levels by looking at ‘sectioning elements’. A sectioning element would open a new section, browsers would assume sections in sections to be subsections, and headings within them lower level headings.

There is no browser implementing the outline algorithm in a way that the above works. One could theoretically have automated heading levels with clever React components. I like that idea, although I would hesitate adding it into my codebases. That leaves us with manually choosing plain old headings level, from 1 to 6.

Conclusion

Heading structures give screenreader users and others a table of contents for our sites. By being conscious of that, we can make better choices about heading levels and their contents.

Originally posted as Heading structures are tables of contents on Hidde's blog.

[email protected]?subject=Reply%20to:%20Heading structures are tables of contents">Reply via email

Overlapping skills in front-end development

2018-09-09T00:00:00Z

Last week a poll about CSS did the rounds with a question about the cascade. It got me thinking about CSS and overlapping skills in front-end development.

Is the cascade more complex than other concepts?

The question was, given two class selectors applied to two elements which had the order of classes as their only difference, what they would look like. Many respondents got it wrong. CSS nerds replied that the question was fairly basic, JS nerds replied CSS is shit. Ok, that was likely a troll. There were also sentiments like ‘you don’t get web development if you don’t understand the cascade’ or ‘you don’t get web development if you do like doing CSS’. Oh oh, social media… why am I on it?

Before continuing, I do want to defend CSS. It is a pretty smart and well-considered language. It is not a programming language by design. Concepts like the cascade are complex, but they aid the simplicity of the language, which was an important design principle.

Admittedly, it takes time to grasp such concepts before you can take full advantage of them. But isn’t that the case for most concepts in web development? Component lifecycle hooks, accessibility trees, dockerisation, OIDC, Lambda functions, writing mode agnostic (logical) properties, Content-Security Policies, DNS entries, git rebase… they all make complex-to-understand things available in simple-to-use ways. About many of these, I was frustated at first, but happy and excited ever after.

CSS may (seem to) miss some of the determinism, scoping and typing that many programmming languages offer, but I believe it is precisely the lack of those sorts of things that makes it extremely accessible to learn and use. It is by design that you can’t know what you HTML will look like. And we’re able to use JavaScript to add such features ourselves, if our codebase or team is of a size that requires them.

Overlapping skills

As people who make websites, we all specialise in different things. They often overlap. Some of us are markup nerds, server side rendering nerds, svg nerds, sysadmin nerds, security nerds, network nerds, Grid Layout nerds, webfonts nerds… most are a combination of many of these things. Some of us aren’t even nerds. It’s all good. In my view, it is unlikely any person overlaps with all the things, although there are people who get dangerously close.

If I learned anything from reading the comments, besides ‘don’t read the comments’, it is this: I need to remind myself that we can all learn so much from each other, because skills overlap. That requires not a ‘X is shit’ attitude, but a ‘how does X work?’ one.

Originally posted as Overlapping skills in front-end development on Hidde's blog.

[email protected]?subject=Reply%20to:%20Overlapping skills in front-end development">Reply via email

#HackOnMDN

2018-09-25T00:00:00Z

This weekend I joined a bunch of web developers, tech writers, web standards lovegods and other friendly folks in London, to work on accessibility documentation for MDN, Mozilla’s platform for learning about web development.

I had a brilliant time, meeting familiar faces from social media IRL and catching up with others. Not only did I learn lots about nails and stools (thanks Seren and Estelle), it was also great to be amongst like-minded people to overhear deeply technical accessibility discussions between people who already wrote about accessibility when I wasn’t even born yet.

Photo: Bruce Lawson, with a hipster filter added, as we were in Shoreditch

On the first day we got to know each other and picked projects to work on. While others looked at adding screenreader compatibility data and documenting WAI-ARIA better, I teamed up with Seren, Eva and Glenda to improve and add accessibility information on MDN pages that were about non-accessibility topics.

What I liked about that particular project, is that it exposes accessibility knowledge to people who are not necessarily looking for it. If you want to know how order works in CSS, you get some information about how it affects screenreader users for free. I’m optimistic. I believe most developers will do the right thing for their users. As long as they have the information on what the right thing looks like in code, design, strategy, testing, et cetera.

After lunch a lot of us gave lightning talks! Eva talked about the problems of automatically translating content and making technical videos available with captions, and Michiel did a great TED-style talk on when to use ARIA. It was just one slide.

Although MDN is a developer network, there are pages for many others. So on the second day I worked on revamping the page Accessibility information for UI/UX designers. It was fairly outdated, so it felt sensible to replace it with more hands-on advice.

On the last day I continued work on that page and did a PR to improve icon accessibility. I also gave a short lightning talk entitled “Making password managers play ball with your login form”, which is also a blog post on this site.

Photo: Bruce Lawson

Others in the room did great work on getting screen reader compatibility data onto MDN, adding ARIA reference pages, cleaning up docs, modernising Spanish content, updating the WCAG reference with 2.1 content and improving MDN’s tooltips. There were also very informative lightning talks about focus styles, display properties and semantics, WCAG 2.1 and beyond (Silver) and accessible syntax highlighting.

It’s been a great three days. I’ve thoroughly enjoyed both doing contributions to MDN, as well as meeting and learning from like-minded people. And I’m proud we got so much done!

Originally posted as #HackOnMDN on Hidde's blog.

[email protected]?subject=Reply%20to:%20#HackOnMDN">Reply via email

Review: New Frontiers in Web Design

2018-09-26T00:00:00Z

Last week I had the chance to read New Frontiers in Web Design, the latest in the series of Smashing Books. It just came out and is full of interesting knowledge for people who work on the web in 2018. From CSS custom properties to advanced service workers to bringing personality back to the web.

What’s it about?

Let’s dive right into it. The book consists of 10 chapters, all about different subjects.

Design systems

No elephants in the room were avoided in this chapter about design systems. I loved reading what Laura Elizabeth said about the idea some have of design systems: that they are somehow quite trivial. Creating, promoting and maintaining design systems isn’t simple, and Laura brilliantly shows this. The list of questions to answer for management is very useful.

Accessibility in SPAs

Marcy Sutton writes about the accessibility of Single Page Applications. She shows common pitfalls and how to avoid them. Marcy also goes into managing focus, focusless announcements and when to use which. Later in the chapter she explains how to do automated tests and what they can test for.

Grid Layout in production

In this chapter, Rachel Andrew talks about Grid Layout in the real world. She explains most if not all of the cool things Grids let you do, and explains what one can do about fallbacks using Grid Layout’s built-in scenarios (‘new layout knows about old layout’).

Custom Properties in CSS

Mike Riethmuller contributed a chapter about Custom Properties. I learned various things, like that the var() function takes a fallback value, and that you could use calc() to give unitless custom property values a unit. His examples of writing way fewer CSS rules, by updating values, not which property is being used, are an invitation to go and use this stuff now.

Service Workers

Lyza D. Gardner’s chapter about Advanced Service Workers is great: it is advanced, but explains basic concepts, too. That made it easier to follow along. It reminds of how hard caching can be, and contains some nifty tricks, like giving your Service Worker an ID, that you can use when cleaning out old caches. The chapter also does a great job explaining push notifications and background sync.

Loading resources

‘Loading resources on the web is hard’, concludes Yoav Weiss in his chapter about loading our websites faster. He talks about how websites load and discusses a wide variety of strategies to optimise loading. Both old school classics and fancy new features. One interesting reminder early in this chapter is that HTML is progressive, which makes it load faster than anything as browsers can start processing it when only part of it was downloaded.

Designing conversations

Adrian Zumbrunnen explains what’s important when designing a bot to talk to, and behaving human-like is one of those things, he says. It made me think about how human customer service often offers a robot-like experience, in that their agents strictly stick to their scripts. If we design conversations with bots to be more human, will all conversations end up being very similar?

Chatbots and virtual assistents

Continuing from designing conversations, the next chapter is about engineering them. Greg Nudelman talks about creating plugins for voice assistants as well as standalone bots. As an engineer, I found it a fascinating insight in how this stuff works. As a citizen slash consumer, I would dislike any services that replace their friendly and smart humans with statistical analysis. That may be just me.

Cross reality

Cross reality is the umbrella term for virtual, augmented and mixed reality. In this chapter Ada Rose Cannon explains how to create scenes in browsers, using web standards and some libraries that abstract them. She also goes into improving rendering performance and there’s a useful list of things she wished she had known when she began.

Making it more personal

The last chapter in the book is written by Mr Smashing himself. Vitaly Friedman tells us all about how to put more personality into our work. Earlier this year, I saw him talk about the same at ICONS in Amsterdam. Vitaly encourages us all to create more interesting things. The theme resonates a lot with me. Yes, we need more things that are visually interesting and different. We also need more things that have well considered UI patterns, that ‘exceed expectations’, as Vitaly writes.

My thoughts

Reading this book feels a bit like going to a good conference. There is lots of variety, plenty to learn and you get away with stuff to try out on your project when you get back to work.

There is also lots of variety within each chapter. I felt some chapters covered too much, they could have been more concise. The upside is that you get a lot of content for your money, so there’s that.

One other thing that could be improved is the way references work: footnotes contain just (shortened) URLs, which obfuscates their original address. It may be just me, but I like seeing the name of the author and the name of the post/page being cited, to connect dots quicker.

If a majority of the covered subjects piques your interest, don’t hesitate to buy Smashing Book #6. There will be plenty of new things to learn. Regarding the physical book: I have not seen it yet, but going by the tweets, the hardcover edition is beautiful, so that is one to consider.

Originally posted as Review: New Frontiers in Web Design on Hidde's blog.

[email protected]?subject=Reply%20to:%20Review: New Frontiers in Web Design">Reply via email

Accessibility wars and the state of talking to machines

2018-09-29T00:00:00Z

This week I attended Accessibility London. It took place at Sainsbury’s headquarters, who were kind enough to host the event.

The Accessibility Peace Model

Glenda Sims talked about what she and Wilco Fiers like to call the accessibility interpretation problem: people disagree about how (much) accessibility should be implemented and tested. There are normative guidelines (WCAG), but experts have different views on what complying to the norm means. Glenda explained that this is ok, ‘there are multiple valid ways to use WCAG’.

Glenda Sims on why interpretations differ

She explained a scale of interpretation styles:

bare minimum (only where WCAG says ‘this is normative’)
optimised (beyond strictly normative, also tries to act in spirit of the whole document and look at the Understanding and Techniques pages)
idealised (tries to look beyond what’s currently possible and maximises accessibility).

Different people at your team or your client’s teams will be on different places of that scale. Knowing this is the case can help think about expectations. I found this a super refreshing talk, it resonated a lot with my experiences. The full whitepaper can be found on Deque’s website.

The history and future of speech

Léonie Watson walked us through the history and future of people talking to computers (Léonie’s slides). From synthetic voices that existed way over 90 years ago to modern computer voices that can sing reasonable covers of our favourite pop songs. There are various W3C standards related to speech, Léonie explained, like Voice XML and the Speech Synthesis Markup Language, and there is a CSS speech spec (‘why should I have to listen to everything in the same voice?’, Lèonie asked. A great point.) As far as I know, nobody works on CSS Speech anymore, sadly.

Léonie also explained how we can design for voice with the Inclusive Design Principles in mind, with useful do’s and don’ts. At the end, she left us with questions about embedding privacy, security, identity and trust in voice assistants.

This was an excellent event with great speakers, I was so glad I was able to attend.

Originally posted as Accessibility wars and the state of talking to machines on Hidde's blog.

[email protected]?subject=Reply%20to:%20Accessibility wars and the state of talking to machines">Reply via email

Grids in cards

2018-11-04T00:00:00Z

Paddings in cards are great, but how about using grids in cards? Using columns and rows for whitespace can give great flexibility, and lets us have optional padding: we can turn it off when we want to.

Note: this is an exploratory post, not something I necessarily recommend to apply to all the things.

A card with padding everywhere

Most card-type components will have a padding set across all dimensions, so that the content does not stick to any of the sides of the box:

.card {
  padding: 1em;
}

An example card with 1em of padding around. Source: Wikipedia - Gelada

This is a very effective way of doing things, especially with box-sizing set to border-box. But what if you wanted to have something like this:

On the left hand side, the padding works, but on the right hand side, we want the background of the content to stretch to the sides of the box, which will not work if it had a padding. Let’s see if CSS Grid Layout can help!

A card with some padding turned off

So here’s CSS for a card that looks the same, it has 1em of whitespace all around, but this time it is built with Grid.

.card {
  display: grid;
  grid-template-columns: 1em auto auto 1em;
  grid-template-rows: 1em auto 1em;
}

Grid tracks for padding!

(Example on CodePen, recommended to view with Firefox Grid Inspector)

We create a grid and make the first and last column, as well as the first and last row, exactly 1em. In this example, there is two auto grid track in between, there could be more if you wanted.

When we used padding, that was all we had to do to make the content stay inside the padded area. With grid, we have created an ‘optional padding’ situation so we will have to explicitly place the content inside the padded area.

If we want a piece of content to be in the padded area:

.card__content {
  grid-column: 2 / 3;
  grid-row: 2 / 3;
}

If we want the content to have a background that extends to the boundaries of the box, we position it to take up the first to the last row, and position it to take up space until the last column:

.card__meta {
  grid-row: 1 / 5;
  grid-column: 4 / 6;
  padding: 1.5em;
  background-color: #eee;
}

You could, of course, style .card__meta with negative margins, but I feel that method is less intuitive. I’m curious to hear how people think about using Grid instead.

Originally posted as Grids in cards on Hidde's blog.

[email protected]?subject=Reply%20to:%20Grids in cards">Reply via email

My first MozFest

2018-11-04T00:00:00Z

This weekend I attended my first Mozilla Festival in North Greenwich, London. It was great. In this post I’ll share some takeaways from my favourite sessions.

Ever since I started working for Mozilla, I learned more about their communities. They have wide interests, ranging from Rust to machine learning to WebVR. Sometimes related to Firefox, but often not. People from these and other communities come together at MozFest, to talk, learn and think about what Mozilla calls internet health. Internet Health is an umbrella term for various issues related to what’s happening to the web. They include (de)centralisation of power, online harassment, privacy, security and how people understand the web works (e.g. distinguish sponsored content from journalism). There’s also an Internet Health Report.

Mozilla Festival 2018 was 9 floors of internet health goodness, each with its own theme. The spaces had lots of meeting spaces that hosted small-scale workshops and talks.

There was also a photo opportunity with a fox

Targeted advertising and human rights

“Targeted advertising is used as a delivery mechanism for propaganda”, said Nathalie Maréchal. She is a researcher at Ranking Digital Rights, a non-profit that tries to find out how much some of the world’s largest corporations respect their user’s privacy online. It did not take long for me, to realise how this is indeed a human rights issue. We can ask questions about enabling companies to know all about us in order to sell us products. It gets worse, though, when political parties use the same mechanisms in order to win elections. Or when the algorithms automate discrimination or create dangerous bubbles.

Design for renaming

This session was about the problems trans people face when there is a mismatch between their official identity documents and what they self identify as. It was heartbreaking to hear some real-world experiences of trans people. After an introduction, we broke out in groups to define the problem space and then worked on finding solutions. We found we can do a lot if we avoid using a birth name as someone’s unique identifier in a system. In general, we should stop assuming names are fixed. This is easier said than done, because a lot of the systems banks an governments use are very old and not so flexible.

Fooling AI

I also attended a session about a special sticker that fooled a machine learning algorithm, presented by Anant Jain. When fed a picture of a banana, the algorithm correctly classified it as such. When said special sticker was applied to the banana, the algorithm confidently classified it as… wait for it… a toaster. That’s a funny example, but the idea that machine learning systems can be fooled is not. There are lots of situations where this could lead to dangerous situations, like a self-driving car’s ML that fails to recognise a human crossing the street.

AI’s collateral damage

In the AI’s collateral damage panel (video), four very smart people shared their thoughts around potential consequences of artificial intelligence on our society. They talked about the danger of algorithms and our lack of understanding how they work. Guillaume Chaslot, who worked on YouTube’s machine learning algorithms, admitted he did not fully understand how they worked. And then there was the question of what to optimise algorithms for. If tech companies optimise for engagement, which they often do as it is good for ad-selling, this drives the content in a certain direction. Algorithms optimised for engagement are likely to recommend content that outrages people, fueling polarisation online. A third aspect the panelists discussed was legislation. Is it likely our governments are equipped to legislate AI, looking at how Mark Zuckerberg’s Senate hearing painfully exposed the senators’ tech illiteracy?

The content of MozFest was often pretty dark, but, surprisingly, people were pretty positive. They were looking for ways to bend the bad things into positive results. I had a great time and learned plenty of new things. I was even able to do a round of guerilla user testing a new product I am working on at the moment.

It was super cool to be among people that care about an open, inclusive and decentral web. Yup, I realise that makes me sound like my thoughts were re-programmed with Mozilla marketing speak. But being there, hearing about these issues and seeing people from all sorts of organisations care, it was brilliant. Would attend again!

Originally posted as My first MozFest on Hidde's blog.

[email protected]?subject=Reply%20to:%20My first MozFest">Reply via email

Up to speed with web performance

2018-11-10T00:00:00Z

On Thursday and Friday I learned all sorts of things about making sites faster at the performance.now() conference in Amsterdam. I frantically took notes at each talk, so here’s my summary of the event.

Performance has always been one of my main interests in web development: if you want a good user experience, speed is essential. The performance.now() conference was two days, with eight talks on each day. Some had lots of theory, others were case studies. The balance between different types of content was excellent. I thoroughly enjoyed learning more about resource hints, HTTP/2, rendering performance of UI and fonts, the web itself and how performance works in large organisations.

HTTP/2 was a recurring theme

Day 1

Steve Souders - Making JavaScript fast

The conference kicked off with the grand… eh godfather of web performance: Steve Souders. He talked about the issues that stand in the way of everything (the ‘long poles in the tent’), based on data from the HTTPArchive. The longest pole: JavaScript fatigue. Scripts are not just bad news for performance because of download time, but also because parsing them costs CPU time on our user’s devices. Steve recommended reducing it (check code coverage, budget 3rd parties), and for what is left: load it async (or better: defer), use <link rel=preload as=script> (or better: as a header) and double-check your assets are actually compressed.

Harry Roberts - Third-party scripts

Harry Roberts discussed third party scripts in four stages: understanding what the problem is, auditing for it, talking to internal teams and vendors and reducing the problem where possible (Harry’s slides). Third party scripts can affect user’s security, they can slow things down (or even be a single point of failure). For auditing, Harry mentioned Request Map, a tool that takes a Web Performance Test as input and creates a map. With the data in hand, he explained, you can go talk to the vendor or the scripts (note: they might lie). Or you can go to the department responsible for the scripts and have a polite meeting with them (‘ask questions, don’t demand immediate removal’). This sparked some discussion at the drinks afterwards: polite is probably good, but shouldn’t developers really be quite strong about reducing tracking? To mitigate third party performance issues, Harry recommended self-hosting, async loading where possible and preconnect to ‘warm up’ the connections to origins that are most important and that you’ll need frequently.

Anna Migas - Debugging UI perf issues

Anna Migas showed us how to impove what she calls ‘perceived load performance’ (Anna’s slides). If we want smooth interactions, we have to do our calculation work between frames. This is because we should ensure our users get not only 60fps, but possibly also 120fps, it’s a thing on iPad Pro and Razer devices. She exposed step by step how a browser builds a frame and shared great tricks for avoiding jank (offload tasks outside the main thread) and diagnosing its cause in Dev Tools (Performance, Rendering and Layering tabs). She also explained issues with certain interaction patterns, like animations (janky if wrong properties or too many), parallax scrolling (‘paint storms’), fixed elements (lots of repainting) and lazy loading images (content jumps). A great trick for improving performance of fixed or sticky elements: try to get browsers to load them in their own layer (can be forced by using will-change or transform: translate3D(0,0,0)). She did warn here: be mindful that more layers consume more memory, use them wisely.

Adrian Holovaty – Geeking out with performance tweaks

Adrian created Soundslice, which is a cleverly built web interface for sheet music. Because it displays sheet music, it displays complex combinations of notes. Hard to get performant, one might think. Soundslice works with a canvas that can (has to) do redraw very often. It has clever things like that it will highlight the currently played note. You can get kind of stuff super performant with very careful coding, Adrian showed. You do just the things required, not too often, etc. Being the co-creator of a famous library himself, Django for Python, he surprised some by saying he recommends not to use frameworks, as they are often full of things your app doesn’t need. Specifically this is true for front-end frameworks, as their redundant code gets shipped to and parsed by users. Food for thought, I heard many say in the break after. So, no big library, but a small set of 8 utility functions in vanilla JavaScript. Adrian also showed how requestAnimationFrame helped to not redraw too often. Google Dev Tools and Google’s Closure Compiler helped him ship better code. Other cool tricks: one global tmpList that gets reused every time a function requires a temporary array, singleton functions where possible to allow for a cache of fractions to avoid memory overuse, caches for expensive calculations and bitfields to use less bytes for saving meta information of notes (one byte per boolean instead of the default 8). Mind. Blown.

Adrian shows sheet music

Zach Leatherman - Fonts

Those who had hoped to walk out of Zach Leatherman’s talk with the one, ultimate, bullet-proof solution to loading fonts fast, were out of luck (Zach’s slides). There is just too much to think about. Most solutions will be a trade-off in some way. But there’s lots to tweak. Zach walked us through improving font loading in a default WordPress theme. He showed lots of tools that can help us deal with what he called the biggest enemies of font loading: invisible text (because font not yet loaded) and moving text (because of fallback font getting replaced by the real thing). Reflowing content is annoying, so Zach proposed a new performance metric: ‘web font reflow count’. Good web font implementations try and keep this number low, while no web font implementations have it at zero. Waiting endlessly for final versions of all fonts is also not ideal. Reflow could also be avoided if fallback fonts look a lot like the webfonts, or if bold webfonts are fallbacked by synthetically bolded regular weights (which, Zach showed, Safari can do). He also talked about how to use preconnect (in some cases), self hosting, font-display (can have sensible results without JS), the Font Loading API (full control over what and when) and subsetting, with clear and helpful examples. I loved it and will review this site’s web font choices.

Natasha Rooney - Protocols

As someone who is just an ordinary front-end developer, I always find people who understand all about networking a bit intimidating. So was Natasha Rooney, even though she said ‘protocols are easy’. She works on protocols and networking standards at the W3C and IETF. In one of her first slides, Natasha showed the absolute boundaries of network speeds on a map. They are dictated by physics, ‘you can’t beat the speed of light’. To optimise that part of the web stack, the advice is to serve content from servers physically closer to your users (think CDNs). With awesome supermarket metaphors, she explained pipelining. She then went into the details of SPDY, Google’s protocol that later was the basis for HTTP/2, and QUIC, again a Google invention. QUIC may help solve head of line blocking issues by reducing latency. It could end up becoming standardised as HTTP/3. Both SPDY and QUIC run on existing protocols (TCP and UDP respectively), because middle boxes often disallow other protocols.

Andrew Betts – Fun with headers

When Andrew Betts worked in the Technical Architecture Group (TAG), he had to review proposals for new HTTP Headers, amongst, presumably, lots of other tasks. For this talk, he looked into the HTTPArchive to show us some headers. Those we should want and those we should not want. The ones to keep were restrictive headers like Content-Security-Policy, Strict-Transport-Security and Referrer-Policy (all for security) and permissive ones like Access-Control and client hints (full overview in Koen Kivit’s tweet). Andrew also looked a bit at the future. Particularly Feature-Policy looked pretty interesting and the idea of setting some of these headers in a JSON file served from a well-known endpoint.

Tammy Everts - What’s the best UX metric?

Tammy Everts shared with us what she thinks works best as a performance metric focused on user experience (Tammy’s slides). She started by sharing some history of performance metrics and what their problems are, then went into current metrics that aid UX. More modern metrics often start with ‘First’ (First Paint, First Interactive, etc), and SpeedCurve introduced metrics for important things on the page (like ‘largest background image rendered’). Tammy also said you can define your own custom metrics. Some companies do, like some social media (‘Time to First Tweet’). Collecting measurements is one thing, but what to do with them? Tammy talked a bit about per page performance budgets, based on some of the metrics she showed before.

Day 2

Tim Kadlec - The long tail of performance

Tim Kadlec’s talk opened day two and it was about ‘the long tail’. That isn’t always the same people: it could be you on a flight, you who forgot to charge or you visiting a rural area. In other words: the real world. Tim showed how he worked with the MDN team to reduce loading times. A large part of page size was fonts. Choosing a system font instead of Mozilla’s brand sans-serif and subsetting their slab serif helped heaps. Talking more generally, Tim explained he had, in years and years of audits, never seen a case where the site couldn’t have improved making the core user tasks faster. There’s always assets, old code or other stuff that could be removed. And we can choose to do that, Tim explained, we can be proactive and provide a resilient and solid experience. Truly inspiring opening words. Practically, he recommended us to test on older devices and slower connections.

Speakers quoting speakers: Tim Kadlec refers back to what Steve Souders said the day before

Yoav Weiss - Resource Loading

Yoav Weiss talked about what makes resource loading slow, how we can solve it today and how it will be better in the future. The problems: establishing a connection has many roundtrips, servers take time to process requests, starts are slower than necessary, browsers sometimes have idle time while figuring out which resources to load, when they’re loading they go in turns and then we sometimes load more than necessary (bloat). HTTP/2 helps with a lot, not everything. In the future, we’ll be able to use the wait time by using HTTP/2 Push, we should unshard domains (as it is an antipattern in HTTP/2) and take advantage of preload and preconnect headers (responsibly; adding it to everything messes with prioritisation and make things worse) and we can turn on BBR (See also: Optimizing HTTP/2 prioritization with BBR, via Tammy Everts).

Kornel Lesiński - Optimising images

Did you know JPEG images don’t contain pixels? Kornel Lesiński explained they have layers of abstract patterns instead. Together they form the image. Some parts contain details and others don’t, and by moving all non-detail data to the beginning of the file, you get this effect of low res slowly becoming hi-res, they load ‘progressively’. Progressive JPEGs have one issue: if you have multiple, they load one by one. In other words, as a group they’re not progressive. This can be mitigated by configuring nginx to send just the first 15%, then wait so that the network can do other things, then send the rest of the file. The doesn’t work on CDNs, they’ll serve static from cache, unless you use Edge Workers. Kornel also showed different future image compression techniques, the best of which just exist in browsers as video codecs. The trick to that? Load hero images in a <video> and you’re good to go, Kornel explained. Clever. And probably not for production.

Katie Sylor-Miller - Performance archeology

Katie Sylor-Miller (Katie’s slides) had this fantastic approach of marrying archeology (her background) with web performance, and with… Indiana Jones. The talk was, at the same time, a case study of Katie’s work at Etsy. The team’s hypothesis was that listing page performance improvements would lead to more conversion, so they surveyed, found the culprits and acted on them. It involved manual JS removals at first, but that was later replaced by a very nifty looking (in-house) solution called ‘Vimes’. It automatically finds which parts of the JS are never or rarely used. To avoid having to do this, Katie recommended to ‘architect for deletion’. Interesting findings from the research were that before/after difference got much larger on slower connection speed and that, yes, performance definitely affected conversion.

Jason Grigsby - Progressive Web Apps challenges

It’s been a couple of years since the idea of Progressive Web Apps was introduced. Jason Grigsby talked about some challenges in 2018 PWA land (Jason’s slides). One such challenges is the definition, it would make sense to have different definitions for developers (like Jeremy’s) and marketeers (Alex and Francis’ original definition, or Google’s, that has gone through a couple of iterations). If anything, the acronym is not for developers. There’s plenty of FUD around Progressive Web Apps, Jason explained, and they can do more than we think. Geolocation, Web Payments, an app shell architecture and offline support can all be part of a good PWA experience. Hidden challenges include appearing to use more storage than expected (security measures in browsers dealing with opaque responses) and designing for the intricacies of a seamless offline experience.

Scott Jehl - Move fast and don’t break things

While most speakers talked about how to make existing sites faster, Scott Jehl recommended us all to not make them slow in the first place. His technique of choice for this: progressive enhancement. It as effective many years ago and it is effective still, Scott explained. For performance, but also for accessibiliy and SEO. He discussed various techniques that fit well within this mindset: HTTP/2 Server Push (Filament already use it in PROD), inlining CSS (or the most critical subset of it if there’s a lot), the lazyload attribute that is in experimental Chrome (PR for lazyload against the HTML specification) and Service Workers on the CDN level so that you can A/B test without bothering users (if you do it on the client, consider this new metric: second meaningful content). Great conclusion: it is easier to make a fast website than to keep a website fast.

Michelle Vu - Performance at Pinterest

Michelle Vu runs the performance team at Pinterest. Her fantastic talk gave us insight in how they got and keep their site fast. The results were very positive: 30% faster got them 10% more sign-ups. Michelle explained that what worked for them is to pick a key metric, which in Pinterest’s case was a custom metric. She said it is helpful to tie performance metrics into business metrics. When measuring, it is helpful to look both at synthetic data (test runs) and RUM data (real users). Michelle showed they each serve a need: synthetic results are consistent and you can run the tests before deploying (e.g. upon code merge) and RUM data shows impact on real users. Michelle also showed a bit of their performance tooling: regressions are measured and there’s performance regression pager duty. So cool! The most important lesson I learned from this talk is that education is very important. Pinterest do this in their pattern library and document things like the experiments (how they were ran, results, etc) and the details of optimisations. Besides documentation, communication and in-person training was just as important to educate others.

Paul Irish - Closing keynote

Closing of the last day of the conference was Paul Irish. He talked about the state of metrics, specifically two kinds: visual metrics and interactivity metrics. Visual metrics are things like First Meaningful Paint, Visual Completion, Layout Stability (a.k.a. ‘layout jank’) and something Paul called Last Painted Hero, a measurement for the last paint of most important content (see also: Rendering Metrics by Steve Souders). Interactivity metrics are things like First CPU Idle and First Input Delay. Paul also showed how to measure these metrics with real users using a PerformanceObserver. The flow he recommends for this is to write code, test it synthetically (‘in the lab’), ship it, then validate it with real users (‘RUM’).

Originally posted as Up to speed with web performance on Hidde's blog.

[email protected]?subject=Reply%20to:%20Up to speed with web performance">Reply via email

Calm tech, platform abuse and reality

2018-11-28T00:00:00Z

This week I attended the Digital Design Ethics conference in Amsterdam. I learned about calm technology, how platforms are abused, what our options are and how to try and prevent abuse earlier. My write-up of the day.

Calm technology

Amber Case started off. She explored the kind of technology she wants to see more of: calm technology. In this age, she explained, attention is more scarce than technology. So we ought to be critical of how we want our tech to interrupt us. Does it really need to talk? Often quieter signals are just as effective. Our industry replicates voice assistants we saw in films, instead of informing solutions by social norms and human needs. Humanity is important in general, Amber explained. For instance, if we make smart machines, let’s consider how to include human intelligence to contribute to that smartness. She mentioned an algorithm that helps find cancer cures, and complements raw data with input from PhD students, instead of figuring out everything alone. Or if we make a smart fridge that refuses to operate if the wrong human stands in front of it, let’s consider they may require food for their diabetic brother. Let’s take reality into account, said Amber.

Slightly shorter version of Amber’s talk: Calm Technology on YouTube

Amber Case on the dystopian kitchen of the future

Indifferent platform executives

The theme of reality continued in talk two. I’m not sure if I’ve ever seen a web conference speaker so furious on stage. Mike Monteiro talked about Mark Zuckerberg of Facebook and Jack Dorsey and Biz Stone of Twitter. The thing is: people use their platforms to spread fake news and declare nuclear war (the US president did). In response to the latter, Twitter did not kick the president off their platform and hid behind corporate speak. Mike finds this problematic, because there is insincerity in pretending to fairly apply rules, if instead, you bend them to keep profitable accounts online. It doesn’t take much cynicism to conclude these decisions are about money. Monteiro backed this up with an analyst’s valuation of what removing Trump from Twitter would cost the company: 2 billion dollars, or a fifth of its value.

We should not look away. Photo: Peter van Grieken

It isn’t just the executives, Mike explained: everyone who works at a company like Twitter should ask themselves why they are still there. Paying a mortgage, he said, is not enough. He warned us: if you work as a designer or developer at a company that has terrible effects on the world, be mindful of not “slowly moving your ethical goalposts”. I cannot help but think there’s quite some space between moving ethical goalposts and completely quitting your job. Mike mentioned the Google walkout: they try to move stuff from the inside.

If you’d like to watch Mike’s talk, see How to Build an Atomic Bomb - Mike Monteiro - btconfDUS2018. Warning: contains a lot of swearing and Holocaust references.

Design as applied ethics

According to Cennydd Bowles, we should regard design as applied ethics. In his recent book Future Ethics, he explains that in detail (go read, it is great). At his Amsterdam talk, he gave a fantastic overview of his book’s themes. Cennydd talked about when ethics comes into play: always. When you invent a thing, it’s extremely likely it can be used for bad things. So, worrying about avoiding bad consequences should be intrinsic to our design processes.

Cennydd’s talk had good advice for mitigating the issue that Mike mentioned earlier: if you create a platforms that is abused, how should you respond? Cennydd went into concrete actions that help take abuse into account in the design stage.

One of the actions Cennydd mentioned: add people who would potentially suffer from your product to the list of stakeholders. Another one: the persona non grata: design for the persona of someone with bad intentions as a strategy to make your product less bad. And he talked about Steve Krug’s well known ‘don’t make me think’: if we want to give users agency, Cennydd explained, sometimes the opposite, making them think, is preferred. For example, if you give people privacy settings, a ‘consent to all the things’ button requires less thinking, but a more fine-grained control yields more privacy and shows you view people as people.

The veil of ignorance

Both Mike and Cennydd mentioned the veil of ignorance, a thought experiment by the political philosopher John Rawls. I used this concept in a talk I gave a couple of weeks ago (Trolleys, veils and prisoners), please allow me to quickly reiterate that here. The idea is: imagine a group of people that you ask to come up with all the rules that govern our world. But there’s one trick: you strip them away from their position in society. Whether they were Uber’s CEO or an Uber driver, from a rich or a poor family, haves or have-nots… they are now none of those things. They wear a ‘veil of ignorance’. They are in what Rawls called the ‘original position’. After they made up the rules, they’re randomly distributed into positions in society. If they are put in the ‘original position’, the theory goes, these people will distribute rules fairly. This is simply because they don’t know how they’ll get them applied to themselves. It’s a powerful concept, and I believe something that applies brilliantly to tech. In quite practical terms, it means if you build or design something, would you want to be the person using that product?

If I had to summarise the event in four words, they would be ‘take reality into account’. Amber Case said we should do so in the opening talk. Mike Monteiro said we should not let ourselves get away with ignoring reality. Cennydd Bowles offered some great tips for getting bringing reality into our design process. Hearing these three useful perspectives on bringing ethical thinking to our design processes, I had great day at the Digital Design Ethics conference.

Originally posted as Calm tech, platform abuse and reality on Hidde's blog.

[email protected]?subject=Reply%20to:%20Calm tech, platform abuse and reality">Reply via email

Scroll an element into the center of the viewport

2018-12-10T00:00:00Z

Say your page displays a list of names and you want a certain person to be highlighted and scrolled into view. There’s a browser API for that: Element.scrollIntoView(), which scrolls an element into view.

Element.scrollIntoView() can take two types of elements: a boolean or an object. The object argument gives developers more control over how elements ‘in view’ are aligned, but has slightly less browser support. Let’s look at what we can do with both.

The boolean argument

Say, you have a couple of people in a list:

<ul>
  <li id="alice">Alice Cruz</li>
  <li id="daniel">Daniel Ho</li>
  …
  <li id="julie">Julie Howard</li>
  …
</ul>

(Example on Codepen)

If you want Julie to be scrolled into view, find the relevant element, then call scrollIntoView():

const julie = document.getElementById('julie');

julie.scrollIntoView();

This scrolls the element into view. With a boolean argument, you can have some control over alignment. If you pass true (default), the browser will scroll so that the element is at the top of your viewport or other scrollable element. With false, it scrolls so the element is at the bottom of the viewport:

julie.scrollIntoView(true) // align top
julie.scrollIntoView(false) // align bottom

Note that the underlying terminology is not ‘top’ or ‘bottom‘, I’ll get into that in the next section.

For most use cases, this boolean argument may be all you need. It lets you choose if you want the element to align top or bottom.

This isn’t always ideal, sometimes you may have a sticky header, so scrollling an element to the top of the document would not actually get it into view. If something like that is the case in your project, the object argument comes in handy. It gives more control over alignment and allows for smooth scroll.

The object argument

In the latest version, you can also pass Element.scrollIntoView() an object, which lets you set two things:

should it scroll smoothly or jump instantly?
how should the element align along the block and inline axes?

julie.scrollIntoView({
  behavior: "smooth" | "auto";
  block: "start" | "center" | "end" | "nearest";
  inline: "start" | "center" | "end" | "nearest";
});

Smooth scroll

With the behavior parameter, you can set whether scrolling should be instant, so the page just jumps to the element, or smoothly, over a number of seconds (to be decided by the browser).

Unsurprisingly, the "smooth" value triggers smooth scroll. The "auto" value triggers instant scroll, as long as the element’s computed value for the scroll-behavior in CSS is not "smooth".

Alignment

Where I’ve been saying ‘top’ and ‘bottom’, I should have said ‘start‘ or ‘end’. They are the logical properties that you might recognise from other recent CSS specs like Grid Layout and flexbox.

As a quick reminder, the inline direction is the direction in which your text runs: it is the direction in which the words of this article are added. The block direction is the opposite of that, it is where block level elements are stacked, or where paragraphs of this text are added.

In a page with a vertical scrollbar, on the block axis, start means top, end means bottom. That’s the case on this page, for instance. But if your page uses vertical writing mode, you’d scroll horizontally, like in Hui-Jing Chen’s example of Chinese typography; in those cases, start means right, end means left on the block axis.

Fallbacks can be tricky

All browsers that understand element.scrollIntoView() accept the boolean argument. But only some accept the object argument. The good thing is, browsers will fallback for you. The default for the boolean argument is true, which sets the equivalent to block: start. If you use the object argument to use block: center or block: end, browsers that don’t do the object argument, will regard the argument to be true (because objects are truthy). So you’ll end up with block: start in those browsers. That’s often great, except when it is the opposite of what you’re fallbacking for.

If your interface requires precisely control over scroll alignment, fallbacks can be tricky. As an alternative you can also roll your own alignment with element.scrollTo(), as Jan Hoogeveen pointed out (thanks Jan!). If you end up going for that, I would recommend using coordinates as an argument, as the object argument does not work in some recent browsers, including Edge. See also window.scrollTo on MDN.

In the works: scroll snap

If you find scrollIntoView interesting, you may be interested in Scroll Snap, too. This is new CSS, currently being worked on, which lets you define things like a padding for the scroll container. Rachel Andrew has written a guide on the basic concepts of Scroll Snap on MDN. Some of the properties are already available in some browsers.

Originally posted as Scroll an element into the center of the viewport on Hidde's blog.

[email protected]?subject=Reply%20to:%20Scroll an element into the center of the viewport">Reply via email

Making single color SVG icons work in dark mode

2018-12-24T00:00:00Z

In a project I work on, we had a couple of buttons that consisted of just icons (with visually hidden help text). The QA engineer I worked with, found some of those did not show up in dark mode, which rendered the buttons unusable for users of that mode. Using inline SVGs with currentColor fixed the issue.

What’s dark mode?

Dark mode (similar-ish to high contrast mode) is a setting on platforms, browsers or devices that inverts a user’s colour scheme: from dark elements on a light background to light elements on a dark background.

This setting improves the experience for all sorts of users. For instance, people who work in the evening, those spend a lot of time behind their screens and users with low vision. It also saves energy on some types of screens.

Dark mode is available on the latest macOS and Windows 10, but also in the form of a browser plugin (Dark Background and Light Text add-on for Firefox, Dark Night Mode Chrome extension). In this post I’ll refer to Dark Modes as one thing that generally works the same across different implementations. In reality, there can be inconsistencies, of course. They can be tricky to test remotely, as testing platforms like Browserstack don’t support dark modes for security reasons.

Some dark modes will flip colors on existing websites, turning your white colours black. In our project, we try to make our interface work with that kind of dark mode, as some of our users use these settings and it lets them have a much better experience. This is a relatively cheap accessibility win.

Inline SVGs to the rescue

Let’s assume our site has a light background with black icons. One way to include an SVG icon is to use an <img> tag pointing to the SVG. Here’s an example of a chevron icon:

<img src="chevron-right.svg" alt="" aria-hidden="true" role="presentation" />

(examples on CodePen)

In Windows High Contrast, Dark Background and Light Text and Dark Night Mode, the icon simply did not show. I believe the reason is that Dark Modes generally parse style sheets only, they ignore the contents of markup (including SVG files). In those cases, they will not replace black with white.

If we could only set the color for these SVGs in our stylesheets! Well, currentColor allows for that, and, it turns out, that actually works with Dark Modes:

<svg
  xmlns="http://www.w3.org/2000/svg"
  width="24"
  height="24"
  viewBox="0 0 24 24"
  fill="none"
  stroke="currentColor"
  stroke-width="2"
  stroke-linecap="round"
  stroke-linejoin="round"
> 
  <polyline points="9 18 15 12 9 6" />
</svg>

For those new to currentColor: it resolves to whatever the CSS color is (as set or inherited) of the element the svg is used in. So if a tool updates all colors in the page, the SVGs automagically change colour too. It is also popular because it works great with states like hovers: for icons with text, icon colours will change whenever you change the text colour.

Declaring supported color schemes

After I posted this, Amelia Bellamy-Royds helpfully pointed me at a proposal for declaring color schemes preference. It is proposed to be a property you can set at root level (supported-color-schemes: light || dark) or as a meta tag, so that browsers can be in the know before they start parsing CSS. The property basically lets you tell a browser that your CSS supports dark modes and will not break in them. Safari has experimental support for the property in Technology Preview 71.

The supported-color-schemes property is meant to be used in conjunction with the prefers-color-scheme media query.

Conclusion

So, if you use currentColor for the only (or primary) colour in your SVG icons, they will work better in dark modes. I’ve not done much more research than this, but hope it helps others who try to make their icons work in dark mode. Feedback more than welcome!

Originally posted as Making single color SVG icons work in dark mode on Hidde's blog.

[email protected]?subject=Reply%20to:%20Making single color SVG icons work in dark mode">Reply via email

2018 in review

2018-12-26T00:00:00Z

The year is about to end, so here is another year in review post!

Some might think it is odd to summarise one’s own year, but I think it is fun to share some facts and thoughts. I love reading these kinds of posts from others (hi Zell, Andy, Chee-Aun, Nienke, Heydon). So here we go. Like last year, I’ve divided stuff into highlights and things I learned. To be clear, that doesn’t mean I had a year consisting of 100% highlights and learnings. That would be weird. Of course there was also stuff that went wrong, wasn’t amazing or was personal. I just think they’re for elsewhere (in person over drinks).

Highlights

Projects

In 2018, I spent most of my time in Mozilla’s Open Innovation team, that I’ve been part of for over a year now (as a contractor). I feel very lucky to get to work with so many smart people. I’m specifically working on the IAM project. For those unfamiliar with the acronym: IAM is short for identity and access management, it is about how people prove who they are (for instance, with email or a third party) and get access to stuff with as little friction as possible. That is particularly challenging when people have multiple identities, which most do. As part of the IAM effort, it’s been super exciting to build most of the front-end for a project codenamed “DinoPark”, which is currently in closed beta. I’m excited to continue this work in 2019 and share more when we can.

In Q4, I also spent a day a week working at the City of The Hague, specifically helping with improving accessibility and profesionalising front-end development of their digital services. It’s been great to see improvements shipped both in the application’s code as well as the content management system product. Looking forward to what we’ll do next year.

Other short engagements included:

teaming up with Jeroen and Peter, I helped NOS, the Dutch broadcaster, with an accessibility audit, user tests with visually impaired users and an in-house presentation on technical accessibility
I ran a one day workshop on accessibility guidelines at Zilveren Kruis
with Peter, I worked on JavaScript to power a chat-like interface for the Dutch government

Volunteering

I did not do a lot of volunteering this year, but I did translate the Inclusive Design Principles into Dutch and worked on improving MDN documentation on accessibility.

Cities

This year, I traveled to Munich, Bristol, Munich (twice), Taipei, San Francisco, Mountain View, Paris, Como, London (twice), Berlin (twice), and Düsseldorf. I’m not so proud of this carbon footprint, and experimented with European train travel, which took a bit more time, but was pretty ok for productivity.

My terrible attempt at taking a panorama picture from the rooftop of the Mozilla offices in San Francisco

Conferences and events

This year, I attended these events:

Proof that I attended events: new stickers!

I spoke multiple times, too:

about password managers at MozTW community meetup (Taiwan) and #HackOnMDN (UK)
about graphic design and the web at Front-end United and CSS Day
about accessibility essentials at Refresh Conference
about philosophical ethics at Accessibility Club Conference (Germany)

I did my CSS Layout workshop three more times (for Fronteers and at Front-end United) and ran a new accessible components workshop (for Frozen Rockets).

Organisers, thanks so much for having me, a newbie speaker. The first time conference speaking was stressful, time-consuming and very scary, but also satisfying. I got great feedback, both praise (yay!) and things I can improve on (thanks, you know who you are).

I’d love to speak more in 2019, please do get in touch if you want to have me present at your event or give a workshop.

Writing

I published 26 posts on this blog, not including this one. Like I said in last year’s review: I very much recommend writing to fellow people who work on the web, it can be helpful in many ways. It is also great to be able to do this on a domain you own, on pages you designed and built. If anyone needs mentoring around this, get in touch, I would love to help!

Some of the most read posts:

More accessible markup with display:contents on a bug in display: contents implementation in major browswers that undoes accessibility benefits the property could have brought otherwise (since fixed in Firefox stable and being fixed in Chromium)
What kind of ethics do front-end developers need? - in which I tried to make the idea of ‘more ethics’ practical for front-end developers
Let’s serve everyone good looking content on, wow, really, in 2018, that websites don’t need to look the same in 2018. I find this is still a thing at my clients and those of devs I talked to.
How to make password managers play ball with your login form sharing what I learned about password manager compatibility

Reading

It felt a bit weird to have the Goodreads app keep me in check reading-wise, but it did the job. I managed to read more than the goal I set: 46 books. Some that readers of this blog might find interesting:

Brotopia, about the ‘bros’ that founded some of the biggest Sillicon Valley corporations and the culture they created. I must admit some doubts towards the word ‘bro’ , but wow, the book taught me a lot about how I don’t want to be and where I don’t want to work.
Klont – if you read Dutch, get it! This novel brilliantly captures the phenomenon ‘datafication’ and how it endangers some of the basic concepts of free societies, as well as, unrelated, the phenomenon of ‘experts’ traveling the world to give talks
Common sense, the Turing test and the quest for real AI – sometimes fairly technical and academic, but I loved the hype-free thinking about artifical intelligence and what to expect from it
Killing Commendatore – if you’re into Murakami or want to start reading his work, this is great. It is a lot of pages, in two parts, but worthwile. I read the Dutch translation, it is available in many other languages, too.

For all the ‘big data’ and AI expertise that Amazon, which owns Goodreads, has, the app is still very bad at recommending new books. For me, it doesn’t go beyond what the most generic airport bookshops stock. The real human beings I follow on the platform brought much more reading inspiration.

Things I learned

Some random things I learned:

I finally got my hands dirty in declarative client-side component frameworks. My framework of choice was Vue.JS. I learned concepts like routers, props down / events up, reactivity and lifecycle hooks, found they mostly just made sense and enjoyed working in this paradigm. I also found that within these concepts, I mostly wrote just JavaScript, good markup and sensible CSS. For instance, X is now ran inside a lifecycle hook, but X itself is just a method in JavaScript. Y is exposed as a component template, but Y itself is just plain old good table.
I learned in multiple projects this year how hard it can be to explain the concept of focus. It exists as a thing in the browser (the document.activeElement), but also as a thing in people’s thinking, not necessarily the same way. And then I’m not even talking about indicating focus yet. In my talk in Groningen I spent a number of slides trying to get it crystal clear. I like Laura Carvajals “You wouldn’t steal their cursor” and tried a streetlights metaphor (they are not pretty, but if they’re not there, you can’t see where you’re going at night)
I worked with WCAG 2.1 in real projects (testing for the newly added success criteria and talking about them in slides)
I added CSPs to some sites (see also How I learned to stop worrying and love CSPs)
I did more background reading to better understand the world we’re developing front-ends for (super meta), inspired by various colleagues, conference speakers and friends
It’s totally workable to use Firefox Nightly as a main development browser, I had expected the occasional crash, because it is an early release channel, but had none. It is not as unstable as it advertises as. Also: tabs and sessions get recovered after updating (I knew this, but had not taken the risk before).

What I want to get better at next year:

writing and presenting
I want to try and build something with Rust
get more people excited about having a personal website with a blog
take more time off

With that, I wish all readers a fantastic 2019! If anyone has written year in review posts, I’d love to hear about them in the comments/webmentions, and read what you have done.

Originally posted as 2018 in review on Hidde's blog.

[email protected]?subject=Reply%20to:%202018 in review">Reply via email

Return of the blog roll

2019-01-02T00:00:00Z

Personal blogs are making a comeback among web folks. I like this. I have even gone so far as to add a blog roll to this site, so that you can see which blogs I like to read (fwiw).

Personal blogs FTW

When I started getting interested in the web, about 15 years ago, blogs were how I learned new stuff. It was not just learning either, it was reading what interesting people were up to. This is something I heavily used RSS for: the data format that allows easy subscribing to content (or ‘syndication’). In an RSS reader, for whoever is unfamiliar with it, I was able to follow all the feeds I subscribed to in one place.

In the last 5-10 years, Twitter took over a lot of that. I stopped using an RSS reader at some point. If I discovered blog posts, it was because the authors tweeted about them, via round-ups like The Daily Nerd (it was great and is dearly missed) or via newsletters like Rachel Andrew’s CSS Layout News, David A. Kennedy’s A11y Weekly and Zoran Jambor’s CSS Weekly.

Twitter has become a little less attractive recently. They made changes so that third-party apps like Tweetbot are mostly broken. The platform’s leadership fails to deal with the abuse that happens to its users. They keep experimenting with orders that are not historic order… all this made me realise I should go back to consuming blogs directly. I have been gone back to reading blogs through an RSS reader for a couple of months now (I use Feedbin).

There seems to be a revival of RSS, Jonathan Snook noted this week:

I like that RSS seems to be making a very small comeback. I find it easier to keep track of and means I don’t have to be on constant lookout on Twitter for updates.

Sara Soueidan said reading RSS gives less noise:

My RSS reader is like a private, quiet, comfy reading room, compared to Twitter which is more like a crowded, noisy coffee shop.

RSS is a great means to take back control over the web we love from platforms like Twitter. Ben Ubois, founder of Feedbin, a service to read RSS, explicitly says so in his latest blog post, Private by default:

I want Feedbin to be the opposite of Big Social. I think people should have the right not to be tracked on the Internet and Feedbin can help facilitate that.

This is music to my ears.

Earlier this year, NetNewsWire, the 16 year old RSS reader for Mac, was returned to Brent Simmons, its original inventor. He plans to release a new reader, open source, and make it the very best.

Šime Vidas of Web Platform News recently published his list of over 600 RSS feeds, worth a scroll through.

So yes, more people are getting interested in using RSS again. And in personal sites.

This site now has a blog roll

For those who aren’t using it: this site has two RSS feeds: full articles and summaries. You can read them in whichever reader you like, or open the posts in the browser from your RSS reader. Then you’ll see my fonts of choice.

And, as of this week, this site has a blog roll. Blog rolls are lists of (personal) blogs, usually displayed in a sidebar of a website. They have disappeared from a lot of blogs in the past years (I do like Jeremy Keith’s bedroll), but I completely agreed with Marcus Herrmann, when he suggested they should make a comeback. I love blog rolls to discover more people to follow, sometimes outside my own bubble.

On this blog, the blog roll has sites of people whose stuff I like to read. The people that inspire my writing here. The blogs I can recommend. For what it’s worth. I hope more people will follow Marcus’ example.

Originally posted as Return of the blog roll on Hidde's blog.

[email protected]?subject=Reply%20to:%20Return of the blog roll">Reply via email

On the importance of testing with content blockers

2019-01-07T00:00:00Z

I recommend everyone to browse with content blockers turned on. The goal: protection against tracking. Safari and Firefox have good tracking protection features. With more people using these features, we should test our sites with content blockers turned on.

Content blocking

In the age of surveillance capitalism, some browsers have started getting more aggressive in how they block ad trackers to protect the privacy of their users.

Firefox has had Tracking Protection since version 42. It works with a blacklist of domains. When something is blocked, it will show up in the Dev Tools Console (“The resource at X was blocked, because tracking protection is enabled”).

Safari not only can block trackers for you, it also allows third parties to define blocking behaviour. Third party blockers can match patterns in URLs and detect things like the domain a script is loaded on (same as site vs not same as site, the latter means third party). When a tracker is identified, developers can choose what to do: block it altogether, just block cookies or hide elements from the page. Users can install one or multiple content trackers. There is a “load without content blockers” feature (long press reload on iOS), but note users may be unaware of it. I know I was until very recently.

What can break

Four examples I encountered in the last few months:

I wanted to purchase clothing on Zara’s website, to pick up in a store. On the part of the form where I had to select which store, nothing showed. I could also not go to the next step. TypeError: X is null was thrown in the browser Console. A Facebook tracking script was blocked by my content blocker, presumably the reason for the script to fail.
I wanted to find opening times at my local supermarket. Search did not yield results until I turned off content blockers.
I wanted to open a hamburger menu. It did not open. (This one is very common, actually)
A link did not work at all.

On this page, I could not select a store or press continue, because Facebook’s tracking script did not load

To understand the last example better, see Stephanie Hobson’s Google Analytics, Privacy, and Event Tracking, which shows how Google Analytics recommended tracking code breaks links for people who block the tracker.

We should not need to track to take people’s money. Or to let them find opening times, open a hamburger menu or follow a link. Metrics can be useful, but they are rarely questioned.

A working website: some strategies

I understand companies want behavioral data in order to improve their sites. But if it puts a stop to taking people’s actual money, doesn’t that defeat the purpose of why you have a website as a company? Is figuring out how many people open your hamburger menu more important than having the feature work at all?

Use no scripts

This one is easy in theory. It is hard in the reality of modern web development, because people will laugh at the suggestion. If your site does not rely on JavaScript to build features like to take people’s money, search for opening times, show a navigation on mobile or go to other pages, these features can potentially just work.

Progressive enhancement

If you manage to develop in a way that does not assume JavaScript (or CSS), you’re likely doing progressive enhancement of some sort. It means that when you build new features, you start with the very basic building blocks, like headings and lists. Simple HTML that describes the feature in a way the most basic browsers understand. You then turn it into something fancy, using web technology a modern as you like. For example, use Web Components to make it tabs, as Andy Bell described. If the fancy thing breaks, the basic building block likely still works.

Not only should progressive enhancement help make your site more robust and resilient, if your whole team can think this way, it can help setting priorities sensibly. See also Resilient Web Design, Jeremy Keith’s free book on building resilient web sites and Dear developer, a talk by Charlie Owen.

Conclusion

To build good websites, I think we should prioritise working websites above gathering potentially useful data (if doing that at all). As developers, we should keep in mind trackers could get blocked and, consequently, never rely on their availability.

Originally posted as On the importance of testing with content blockers on Hidde's blog.

[email protected]?subject=Reply%20to:%20On the importance of testing with content blockers">Reply via email

Linking to translations

2019-01-18T00:00:00Z

The other day I worked on some front-end code that takes users to a version of the website in a different language. Two attributes can make such links more accessible: lang and hreflang. What’s the difference?

Strings in another language

The lang attribute can expose what language a page is in, when it is added to the root tag. For example, a page in English, will likely have this as its root element:

<html lang="en">

You can also use lang on any tag in a document, to signify a section, paragraph or word is in a different language. This is useful when you link to a translation. If the link text has a different language than the rest of the document, you can expose that.

A link with link text in Chinese, as spoken in Taiwan, one of my favourite countries:

<a href="/zh-TW">
  中文
</a>

The same link, now with the language exposed:

<a href="/zh-TW" lang="zh-TW">
  中文
</a>

That’s all. Note: this only means that the word within this tag is in a different language. It says nothing about the page we’re linking to.

Words marked up in an HTML element with a lang attribute, will get read out with a voice in that language in Safari with VoiceOver and some versions of other screenreaders, depending on settings and voice availability

Links to pages in another language

If the page you’re linking to is in a different language, you can use hreflang to signify that (hreflang in the spec).

For example:

<a href="/zh-TW" hreflang="zh-tw">
  Chinese
</a>

If you link to a page in a different language and the text you use is also in a different language, both attributes can be used at the same time.

<a href="/zh-TW" hreflang="zh-tw" lang="zh-TW">
  中文
</a>

To be very honest, I don’t know of an actual system using it for detection. Implementing the attribute doesn’t hurt though, if more of us do it, tools can more reliably take advantage of that. The hreflang attribute is also used by people who want to increase their search engine rankings, in a per page setting exposed via a link element or as a header.

Language tags: BCP 47

The format of languages used in lang and hreflang is specified in something called BCP47.

They consist of one or more subtags, separated by a hyphen (-). The first one is the primary language, for example en for English and zh for Chinese (zhōngwén means Chinese writing). Most are two characters, some are more.

There is a list of language tags on the Library of Congress website.

Summary

So, to sum up:

lang on any HTML element describes what language is used in that element
hreflang on a link (<a>) describes the language of the page you’re linking to
both lang and hreflang are in the format described in BCP47

Happy internationalising!

Originally posted as Linking to translations on Hidde's blog.

[email protected]?subject=Reply%20to:%20Linking to translations">Reply via email

Console logging the focused element as it changes

2019-01-30T00:00:00Z

When you build a Single Page Application, chances are that you manage some of the focus through script. For debugging, it can be super useful to log the currently focused element to the Dev Tools Console.

Logging the focused element

The focused element is known in the DOM as document.activeElement, so you can just console.log() that if you want to know what the currently focused element is.

Logging it as it changes

Thanks to Eva, I recently learned a way to log the active element as it changes:

document.addEventListener('focusin', function() {
  console.log('focused: ', document.activeElement)
}, true);

The focusin event is like focus, but it bubbles, so when any element within document receives focus, focusin bubbles all the way up to document.

When I posted this on Twitter, Christian Schaefer helpfully pointed out that, although focus does not bubble, it can be intercepted when the capturing flag (addEventListener’s third argument) is set to true. Phil Walton then added that focus fires also for non-interactive elements and when the window receives focus. Even better!

So this is what you could use to log the active element when it changes:

document.addEventListener('focus', function() {
  console.log('focused: ', document.activeElement)
}, true);

Also relevant: PPK’s Delegating the focus and blur events, over 10 years old, in which he explains that lack of bubbling in focus makes sense, because we would not want it to bubble to window, as the `window’ having focus means that the user has focused the entire browser window.

Originally posted as Console logging the focused element as it changes on Hidde's blog.

[email protected]?subject=Reply%20to:%20Console logging the focused element as it changes">Reply via email

Three ways to build Crouwel's Hiroshima poster in CSS

2019-01-31T00:00:00Z

Recreating old posters, I figured there are at least two approaches to deciding how many grid tracks your component or page needs: one can make it visually perfect, the other is more flexible if content is bound to change.

In the past 1.5 year or so I spread my excitement for flexbox and Grid Layout through workshops. An assignment I used in each one, is to recreate Wim Crouwel’s iconic “Hiroshima” poster using CSS. Poster recreation in CSS is an idea, of course, popularised by Jen Simmons and her awesome Experimental Layout Lab. She has lots of poster experiments on that site, check it out if you have not.

I like having a poster recreation exercise in the workshop, as it lets people learn CSS properties, without worry over maintainability or other concerns that come in mind when doing real-world CSS coding. It also lets the participants build graphic designs that are wildly different from most websites, think outside of the box (oh wait, CSS is ALL boxes, as Hui Jing Chen explains in her Box Alignment talk).

Photos from the exhibition about Crouwel’s work at the Design Museum in London (2010), photos by Ben Terrett. On the right: the original Hiroshima poster.

One poster I like to use is Wim Crouwel’s “Hiroshima” poster. Crouwel is one of The Netherlands’ most influential graphic designers. As co-founder and designer at the influential agency Total Design, he worked on large corporate house styles. He is best known though, for the posters he designed for Dutch museums, including the Stedelijk Museum in Amsterdam. The “Hiroshima” poster was made for an exhibition in the Van Abbe Museum in Eindhoven, The Netherlands. It’s not a complicated poster, sporting the name of the exhibition, a subtitle, location and the opening times.

The letters used for the word “Hiroshima” were manually designed by Crouwel. They have inspired various typefaces, including “Shima” by Nate Navasca, which closely resembles it, and UT Morph by Oscar Cobo.

Column choices

If you look closely, you’ll find that the opening times and exhibition duration align with the stem of the second letter ‘h’. The subtitle aligns with the letter ‘o’. Presumably, this is on purpose.

A column for each stem

One way to design the columns for this poster, is to define a column for each of the stem: 17 in total. The minimal space between the letters can be the grid’s column-gap. This leaves us closest to what we presume the poster maker intended.

We then need to decide one or more columns to each letter: one for the ‘i’ and three for the ‘m’, for instance.

A column for each letter

Another approach is to create a column for each letter, and let the columns be of auto width. They will then grow with the letters contained in them.

The content-based choice

We could also base our track choices on the four bits of content (title, subtitle, opening times, exhibition duration). This is a more functional approach, and less precise. The bits of content will likely not fully align with the letters of the word “Hiroshima”.

Ok, show me the code!

I’ve built examples with all three approaches: 4, 9 and 17 columns.

The two extremes: 4 columns and 17 columns, visualised using Firefox’s built-in Grid Inspector.

4 columns

The 4 column has least markup and classnames related to the function of the element in the whole. With just those four columns, it does the bare minimum. Dates and opening times don’t align with the letters they’re supposed to align with. But had someone decided to change the exhibition’s name, little harm would be done.

I approximated the size of the columns by making them all 1 part of the available space:

grid-template-columns: repeat( 4, 1fr );

9 columns

My 9 column version, has each letter wrapped in a span. Only direct children of grid containers get to play in the grid game, but with display: contents on the <h1> , it gets skipped and its children become grid items. Warning: do not use display: contents in production just yet, as the heading will lose its accessible role in most browsers.

In this one, the columns are of auto size, so that they grow with their content:

grid-template-columns: repeat( 9, auto );

Note that this works because the letters are the largest things in their respective tracks. If we had put anything larger in the same column, for instance in another row, that larger thing would have made the whole column larger.

Because of display: contents, the spans within the h1 became grid items. With no explicit placement, they get auto-placed in a column of their own, allowing for alignment of content with the actual letters. With that in place, I then told all spans to go to the correct row:

h1 span {
  grid-row: 3;
}

17 columns

In the 17 column version, I’ve wrapped each letter in a span with a classname. I did not need to space each letter individually, but I did have to address differences in how many columns a letter should span: the letters ‘i’ require one column, the letter ‘m’ requires three and all the others require 2. I did unique classnames for each letter, with the two h’s and i’s sharing one between them:

.hiroshima-r,
.hiroshima-o,
.hiroshima-s,
.hiroshima-h,
.hiroshima-a {
  grid-column: span 2;
  grid-row: 3;
}

.hiroshima-m {
  grid-column: span 3;
  grid-row: 3;
}

.hiroshima-i {
  grid-column: span 1;
  grid-row: 3;
}

Another, more abstract approach could be to have a span-1, span-2 and span-3 classname.

What’s better?

Thanks for reading this far in a post that is just about grid columns. Basically, my point is about two approaches: visual perfection versus functional pragmatism. I’ve seen both in real world CSS. Either can be effective. Neither of the two is better, everyone can grid however they like.

I would say visual perfection makes more sense in a promotional type of website, where the site was designed just for one purpose, maybe to communicate a one off event. A conference that you already know the name of. That sort of thing.

The functional approach is ideal when working with a CMS, where content can change, or there are multiple instances of the same design work. It’s more resilient to change.

Originally posted as Three ways to build Crouwel's Hiroshima poster in CSS on Hidde's blog.

[email protected]?subject=Reply%20to:%20Three ways to build Crouwel's Hiroshima poster in CSS">Reply via email

Content-based grid tracks and embracing flexibility

2019-02-23T00:00:00Z

Something I love about CSS is that it lets us define visual design for unknown content. This is kind of magic. We can even size things based on content, with min-content, max-content and auto. This post is about how that works in CSS Grid Layout, and what usage in real projects would mean.

In Grid Layout, there are many ways to size a column or row (I’ll refer to them as ‘track’ from here). You can be absolute and define tracks in pixels, or even centimeters, which is pretty useful if you’re doing print work. You can use relative units too, for example relative to the root element’s font size (rem), viewport (vw, vh, vmin, vmax), the width of a 0 (ch)… any CSS length size, really. Of course, all of these sizing methods can be mixed in grid definitions. For example, you could make one column flexible, the other absolute and yet another one content-based. In fact, that’s often a sensible thing to do.

Why size at all?

In Grid Layout, you don’t have to size anything. If you don’t define (some) track sizes, their size will be auto, based on the content they need to fit. You could still say which tracks you want with the grid-area syntax, but leave sizing up to the browser. Or you could refrain from defining areas at all, in which case the browser will create tracks for each of your grid items, then size them.

The obvious reason to define some, most or all of your track sizes anyway, is because you have intentions about your lay-out. You want your content area to have a maximum length for better readability, or you want your ad bar to be certain size for business reasons.

Another reason to give some sizes, is that it saves the browser from parsing your content in order to figure out track sizing by itself, the spec notes:

when content-based sizing is used on an item with large amounts of content, the layout engine must traverse all of this content before finding its minimum size, whereas if the author sets an explicit minimum, this is not necessary

This is not an issue with small amounts of content, the spec concurs that that’s trivial, but it is a potential concern if you have lots of grid items or content.

Content versus context

The go-to CSS spec on sizing is CSS Intrinsic & Extrinsic Sizing Module Level 3. It deals with two ways to size: based on context and based on content.

Context-based or extrinsic sizing of an element is sizing based on the container it is in. This is often its parent, or it could be the viewport. The extrinsic size of a block element is the size of that container, minus padding and border. If you set an element to, say, width: 50%, it is said to be extrinsically sized to be half of the container.

Content-based or intrinsic sizing, on the other hand, is sizing based on the element’s content, so it is independent from its context.

Before I continue: one place we already have widespread content-based sizing on the web is in tables. They size based on how much content is in the cells. If you place two tables on the same page, they’ll likely differ in size (like the schedule for day 1 and day 2 on the Fronteers website differ). This happens automagically, unless you start setting explicit sizes.

min-content, max-content and auto

So how do min-content, max-content and auto work? Let’s take the following line of text (from Charles Darwin’s On the origin of species, 24):

Some facts in regard to the colouring of pigeons well deserve consideration.

If it is displayed in a browser using CSS, it will sit in a box. The minimum width of that box in order to fit this content, is the size that fully fits the longest word, so without ‘overflowing’. In this sentence that would be ‘consideration‘. To size this box to that word, CSS lets you use the min-content keyword. If you set width: min-content onto the element that has this text, it will be sized something like this:

Some facts in
regard to the 
colouring of 
pigeons well 
deserve 
consideration.

Note that if your box contains more than just words, more things influence min-content, for example largest image or fixed size box.

The maximum width of that box is the width of this entire sentence. Think of the width it would require if white-space: nowrap was applied. To size the box to the maximum that is required for the content, CSS has the max-content keyword.

Keep in mind that min-content and max-content are all about sizing in the inline direction, the one in which words flow, as opposed to the block direction, in which blocks, like paragraphs, flow.

In CSS, we can use the min-content and max-content keywords as sizes for elements that contain content. In Grid Layout specifically, we can use the keywords to size tracks. Say you’re using min-content to size a column, it will be calculated based on the minimum required for content throughout all the rows in that column.

And then there’s auto. This keyword can mean different things throughout CSS (for a more in-depth look, see fantasai’s Defining auto at CSS Day 2015). For example, in block level elements an auto width takes up the full available width, while in inline level elements, it takes up just the space needed for the content. In grid tracks, it behaves similar-ish to inline elements, it will take up the space of the content. One exception is that if there is a grid item inside the track that has a size, that size can make the whole track grow.

Embrace the web’s flexibility

As I said above, I really like content-based sizing, so it bugs me that I don’t see it used a lot in real-world projects. Websites don’t need to look the same in all browsers, right? That theory is convincing, at least in the circles of front-end developers and designers, but clients often expect more sameness across browsers than we’d like. Even within teams, this is common.

Going from websites that look the same in all browsers, what about looking the same with all content? Content-based sizing units are potentially very useful, but will they make sense on production websites? I see two potential hurdles: it could still be hard to incorporate them in our design processes, and they could create purposeful inconsistencies that some may see as mistakes.

Design process

One of the hardest problems in designing for the web is that the designer has to deal with unknowns. Websites have CMSes, so content can change. It’s likely unknown. Users come with all sorts of devices and screens, so canvas size is mostly unknown, too.

CSS does a fantastic job at giving us tools to solve that exact problem. If you want a certain amount of characters in a column, you don’t need to know what the characters are in order to get what you want. Just write what the rule is, and the browser worries about how to apply it to actual content. But even if this is solved in CSS, that doesn’t mean it is solved in the tools we design websites in. I have met with designers who write CSS and design in the browser, but design in software like Sketch is also very common.

If we want to use content-based sizing in designs and use design tools that are not the browser, whoever writes the CSS should demonstrate what the web can do. The CSS person can show how flexibly built websites can work better in different languages, on different devices and for different people. Designers and developers can team up, make demos. Browsers can help too, they are improving design tools to expose what’s happening. Tools like the new flexbox inspector in Firefox Dev Tools can bring design and code closer together.

Is intentional inconsistency ok?

What does it mean if subsequent pages end up having slightly (or wildly) different grids? This may create a confusing or “broken” user experience. I think inconsistencies can be very powerful, because they lead to an ideal space distribution. The track that needs most space, gets most space (in an auto scenario). This is ideal for content, but does it yield the ideal for visual design and user experience? I don’t know, maybe?

Content-based sizing could be most effective in components that exist once on a page, so that there are no inconsistencies. Or in pages that are quite unique, like temporary landing pages and one off sites for conferences, exhibitions and the like.

Wrapping up

With the min-content, max-content and auto keywords, we can size grid tracks based on their content. I think this is very cool. If we manage to embrace as much of the web’s flexibility as we can, we can get the most out of these tools, and let CSS help us with designing for the unknown.

Originally posted as Content-based grid tracks and embracing flexibility on Hidde's blog.

[email protected]?subject=Reply%20to:%20Content-based grid tracks and embracing flexibility">Reply via email

Component frameworks and web standards

2019-02-28T00:00:00Z

At last year’s Fronteers Conference, I had numerous conversations about the merits of using client-side frameworks for virtual DOMs, declarative templating and routing, versus a classic, vanilla approach to building websites. I had always been a vanilla-fan, but built a recent project in a framework, liked that too, and, well… I think they aren’t the polar opposites that they used to be in my head!

This post has three parts: in the first, I look at what I like about “the web standards stance” or a “vanilla approach”. In the second, I share what I liked when I used a JavaScript component framework. In the last part, I look at whether these two approaches are actually different: maybe I assumed a false dichotomy?

The web standards stance

As I see it, Fronteers Conference has traditionally been very web standards focused. We had no talks about Sass until years after it came about. We did hear about new CSS specs years before they were in browsers. Standards over abstractions. Progressive enhancement and accessibility have been recurring themes from the very first event. I’m not saying any of these things are superior over others, just that learning about them influenced me and many other regulars in our thinking about the web.

Personally, I have until recently managed to avoid JavaScript frameworks in projects. Did I miss out? Maybe. I did my front-end work in teams with a rather traditional stack. Often, they used Node to turn abstractions of HTML, CSS and JavaScript into browser-ready code. But the browser would not be sent much JavaScript and there would be no virtual DOMs.

It’s applying what’s in web standards directly, without a framework that wraps them. I’ll call this the ‘vanilla’ approach. It is basically a very minimal one, with no or few dependencies. Hand-written solutions for just the problems at hand. Some call it ‘not invented here syndrome’, which has a negative connotation, but there are also downsides to whatever the opposite of ‘not invented here’ is (packages can go bad, and what about christmas effects in production?).

I believe going vanilla is a totally valid approach to making sites. Large companies do it. Like GitHub, they even open sourced their components, but also Netflix, Marks and Spencers and others. Going vanilla is controversial, too, I found. When Sara Soueidan tweeted:

It’s really depressing that most useful tools these day are made for React projects and/or require React knowlegde to set up and use. This locks out many of us who are not using React for everything & who still prefer the vanilla route for their projects.

she got various people tell her she should learn React, some very unfriendly. But vanilla is a fine choice too, and more cross compatible, as her point proves: a vanilla component or library could work across multiple ecosystems or outside any ecosystem. A vanilla approach assumes the web itself as its ecosystem or platform.

It’s not just easier cross compatibility though. I have seen in real world projects, including some for very large organisations, that these traditional, vanilla stacks let us have fast, accessible and maintainable sites. By default.

Fast, because (JavaScript) code you don’t ship to the user, is code they don’t have to download and their browsers don’t have to parse. See also the performance.now() keynote of Steve Souders, “grandfather of web performance”, and Alex Russel’s piece on ‘ambush by JS’: Can you afford it?
Accessible, because the web is accessible by default. Because web standards are standards, they have the biggest chance of being the thing that makers of assistive technologies adopt to base their tech on. Using a select rather than a library that customises one and makes it inaccessible in the process (happens), increases the chance of the component to work for more people
Maintainable, or I should say, maintainable for potentially a longer time, because if you depend on less things, there is less chance your project stops working because of a third factor.

I’m not saying you can’t have these things if you use frameworks. As I said, from real world projects, I learned that traditional, minimal dependency stacks have these benefits. I should note here, you can also get these benefits if you use a framework: giving users more speed and accessibility is also the goal of some frameworks, and there are lots of people in the framework world that are very effective at improving such aspects through framework code.

(Yup, I find accessibility and speed, i.e. aspects that users experience, the most important criteria for judging my tools)

Having said all this, I tried a framework and I loved it! Probably not a surprise, as almost the whole world seems hooked to frameworks.

I tried a framework

In the last few months I built my very first framework-based front-end, in Vue.js. I complemented it with a router, a store and a GraphQL library, in order to have, respectively, multiple (virtual) pages, globally shared data and a smart way to load new data in my templates.

Those of you who work with front-end frameworks will likely nod along to the above description. Others may feel confuses and/or start laughing. Multiple pages, global scope and loading data can be done in web-default stacks with vanilla code. In way fewer lines. Multiple pages by literally creating pages and links between them, global scope by putting stuff in the window object (scoped to your app if you like), loading data with plain old XHR or fetch(). Why let users download lots of kilobytes of framework code, if the web already has the functionality?

Well, let’s start with things I learned to love. If you have worked with front-end frameworks, you probably want to skip ahead.

Routers

Routers are pretty useful abstractions of which types of pages exists and what data they can have. It took me a lot of uneasy feelings to replace the plain old <a>’s in my site with instances of Vue Router’s <router-link> component.

For those unfamiliar with what this means: in an <a> you use the href attribute to say where the link goes. A <router-link> points to a predefined named route, and accepts in its to attribute objects for settings that you invent, as well as query parameters.

So if you’d write an <a> to go to a page with parameters:

<a href="/search?query=css&category=tutorials">
  CSS
</a>

you can instead define it as a <router-link> , a special component that comes with the Vue Router library:

<router-link :to="{ 
  name: 'SearchResult', 
  query: { 
    query: 'css', 
    category: 'tutorials' 
  } 
}"/>CSS</router-link>

(note this is a difference in the template only, the DOM and accessibility trees will only ever see something like the first)

Either is pretty readable. The router link is more abstract, if you don’t construct the URL yourself, you may make less mistakes and it may be easier for others what’s happening. This is not a client-side framework advantage, of course, you can find similar concepts on the server side, like in Flask routing. Routing is as old as the web itself.

The major advantage isn’t readability, it is that the client-side router ties in with the state your website is in. Because it has a fuller picture, it can make useful decisions like to only reload parts of the page. If you link to the same type of page, it may just update the difference in content. This does come with some focus and scroll management challenges, but that’s for another post.

Real components

Ask five people on a web team what a component is, and you may end up with wildly different definitions. Even in our world where most web teams made components central to their way of working, we struggle to mean the same by the word.

As a front-end developer, I’ve long thought of components as a blob of markup, with optional corresponding style and/or script, all living in the same folder. They would have a shared classname on the root element, which would be unique to instances of that component. Just by being in the same folder, they’d be a component for anyone working with the code. They exist because the team agrees not to clash names.

In declarative JS frameworks like Vue and React, components are defined as components. You define each component in the syntax the framework provides. This is arguably more rigid and meaningful than the ‘being in a same folder’ form of defining components I described above. In the case of Vue’s ‘single file components’, the JS knows of a component its name and possible properties (and their types). For associated scripts, it knows the component’s methods, life cycle hooks (a fancy word for: scripts to execute before or after component markup exists in DOM) and event handlers. For styling, it also knows the component’s associated CSS.

Reactivity

All template languages offer some form of variables:

<h1></h1>

The text inside the h1 becomes whatever header resolves to. When there is reactivity, variables aren’t resolved once, but will update when they need to. For example, if a component is expanded, the value of expanded can update from true to false, at a programmatically determined time. Following whatever logic your component has for expanding. In online banking, the value for totalBalance could be reactive and change on some event that is triggered by money coming into the bank account. The credit card logo URL could be reactive and change from mastercard.svg to visa.svg based on what credit card number is being typed in. That sort of thing.

Easy to get started

Both Vue and React have a command line tool that creates a project, with lots of stuff built in (create-react-app and create-vue-app). This scared me at first, as I was afraid it would by default put stuff into bundles I would send to my users. It turns out a lot of what create-*-app setups offer is build and testing tools. My least favourite part of making websites is configuring tooling, a ‘just works’ default is good enough for my needs.

Also, wow, there is some very good documentation for these frameworks, that explain just enough to get started, but also let you dive much deeper if you want or need to. It’s all very welcoming and nice.

Thankfully, I also had great colleagues at work and peers at Fronteers Slack that I could direct questions to, have code reviewed by, et cetera. If you want to get started with a framework, I do recommend joining a Slack group for the framework or your area.

What I liked less

Backwards compatibility

Web standards are extremely backwards compatible. Very rarely do HTML tags get deprecated (hi <blink> !), almost never do DOM methods or ECMAScript features get taken out. This makes sites built with vanilla code future proof. You will likely have to do security updates to old sites, but it is unlikely you’ll have to write your HTML, because someone decided fieldsets are no longer supported.

If you’re using a framework, the features you rely on are more likely to disappear. When Vue just came out, one would loop through an object like this:

<ul id="tags">
  <li v-repeat="tags">
    
  </li>
</ul>

(example from Vue 0.11)

Then v-for was introduced. My point is, this sometimes happens. Frameworks come up with better paradigms (see also Hooks and Suspense in React). When your site wants to update to a new version, your team needs to rewrite and know what to rewrite. All of Twitter is like “I’ve rewritten this project X to use Hooks”, but this is not trivial, even less so if it is the complicated codebase of your large corporate client.

There are lots of organisations out there using Angular 1 in projects, and I see them struggle to find developers willing to do the work. They’ve since moved on to newer frameworks. The orgs are stuck with outdated paradigms that are incompatible with the now. For freelance front-end developers in The Netherlands, recruitment calls for a certain bank that went all-in on Angular may sound familiar?

I feel this is a real difference between ‘just’ using web standards and buying into a framework. There is also legacy vanilla code, of course. But if that is, as I described in the introduction, very minimal, few dependency code, maintaining it is consequently less involved.

Different origins

I love the origin story of the web, and the idea that it was further developed at an independent consortium and groups like WHATWG. The origins of the big component frameworks are big corporations like Google (Angular) and Facebook (React). Corporations that are more for profit than for humans. Even-though the projects themselves are open source and have volunteer communities full of great humans.

A false dichotomy?

As I described above, there are lots of things to like about using modern JavaScript frameworks to build websites, and a couple of things to moan about. But let’s look now at how that approach differs from ‘just’ using web standards and vanilla code. Let’s look at how it differs from the approach of which I said it gives us good things like accessibility and performance by default. If there is a difference, because maybe frameworks versus web standards is a false dichotomy?

De-facto standards

Various frameworks from the past have inspired web standards. jQuery’s selector engine Sizzle inspired querySelector/querySelectorAll. The modern component frameworks seem to diverge towards standard ways of working, both in syntax patterns and in broader concepts, like routing and reactivity. They are not in specs, but they could inspire new web standards. As far as I’m aware, nobody is standardising concepts like reactivity, but there for example this proposal for declarative routing in Service Workers, and among the new proposals in ECMAScript there are many ideas inspired by how people write framework code, like optional chaining. Still, epic standard battles to make features happen are epic.

Framework-browser collaboration

Framework engineers and browser makers collaborate, said React engineer Andrew Clark:

Our team has a regular weekly meeting with Chrome engineers. Sometimes we meet more than once! We’re collaborating on display locking, main thread scheduling, resource prioritization, and more. Great relationship, much credit to @stubbornella and @shubhie

Chrome PM Nicole Sullivan confirmed this:

My favorite part of my job is collaboration with frameworks. The web platform engineers are beyond excited about the tight feedback loops we’ve developed and are developing. We even added getting framework feedback to our intent to implement process.

I don’t really know of such a direct collaboration between framework authors and the Firefox browser. Or other browsers. Such collaborations are quite different from web standards efforts, but I guess they can lead to improved performance and accessibility for large amounts of users. Less “open” improvements, but improvements.

Lots of vanilla code in frameworks components

If I’m comparing vanilla to frameworks, I should also say that within the framework wrapper, I’ve always ended up using vanilla knowledge. Not only is it still important to know which HTML elements there are and what they mean, because framework-based sites yield accessibility trees just like regular sites do. It’s essential to have a deep understanding of all things JavaScript (for instance, everything on Chris Fernandi’s JS roadmap, because the component frameworks offer just that: a framework to get started. Within that, it’s your choice if you want to solve your problems with your own custom solutions, or use libraries, plug-ins, etc Or, of course, and this is common, do either when it makes sense.

Progressive enhancement

Progressive enhancement and client-side frameworks do seem to be hard to marry, because by default they do their work in the browser. There are plenty of ways to make servers do the initial render, but if we are honest this is not trivial. Regardless of where we render, we can and likely should apply a progressive enhancement way of thinking to a framework-based project. To stretch what progressive enhancement means very far: make no assumptions. Not about your user’s devices, not about their permissions, not about their content blockers, not about any other of their choices.

For example:

if you ultimately want to plot on a map the cars nearest to a user’s location, you could display a list of car locations initially. When users have location abilities, their browser’s support exposing those through the location API and they have granted your site permissions, then try and do the plotting.
in a project I worked on, we generated identicons on the client. The process involved the Web Crypto API, to convert strings into hashed strings. In browsers that don’t support Web Crypto, we fell back to a hardcoded hashed string. Browsers that got the full thing showed avatars based on people’s username, so they were unique for each user, browsers all showed non-unique avatars based on the string ‘user’.
you want to lay out a component of your site using CSS Grid Layout. To the 10-20% of browsers that don’t support this spec, you serve a simple fallback, so that all the content is usable, readable and looks not broken.

Conclusion

I love vanilla code, and things that are invented here. Thoughtful developers that solve a problem at hand. I’ve sometimes felt worried that working with front-end frameworks like React or Vue would be at odds with that mental model. I feel I was probably wrong there, there is a lot of grey between vanilla and frameworks, and people do all sorts of cool things on either side to get to solutions that are accessible and performant. This is great. I am glad I tried a framework and found its features were extremely helpful in creating a consistent interface for my users. My hope is though, that I won’t forget about vanilla. It’s perfectly valid to build a website with no or few dependencies.

Originally posted as Component frameworks and web standards on Hidde's blog.

[email protected]?subject=Reply%20to:%20Component frameworks and web standards">Reply via email

Book review: The age of surveillance capitalism

2019-03-06T00:00:00Z

This week I read The age of surveillance capitalism by Shoshana Zuboff, an enlightening book about how big tech companies are watching what we do, and what their end game might be. I thought I had heard all of this, but, of course, I couldn’t be more wrong.

Beyond “You are the product”

You’ve likely heard people say ‘if a product is free to use, you are not the customer, you are the product’. It’s a bit of a cliché now, that Zuboff completely reframes in The Age of Surveillance Capitalism. We aren’t exactly the product… we, or the data that describes our behaviour, to be more precise, are the raw material of a whole new iteration of capitalism.

The book is huge, but only just over 500 pages, the rest is footnotes

The Age of Surveillance Capitalism explains this new iteration in the context of early capitalism (Ford’s, and even the age of gilds). Zuboff explains how the founders of Google, and later Facebook and others too, set the scene: how they found use for data that previously looked useless, their secrecy about exposing the size of their data collection and their lobby against rules. Yup, they prefer to make their own rules. And will insist that their way is the only way, which the world just needs to accept: Zuboff coins this ‘inevitabilism’.

This attitude of setting their own scene is a recurring theme throughout the book. For instance, when Facebook does behavioral research, they don’t follow “The Common Rule“, Zuboff explains, that academic experimenters apply to themselves to avoid power abuse. This abuse in a corporate setting could be much worse than that in an academic one, as there is more conflict of interest in play (in the corporate setting there is a need to earn profits for shareholders).

A new iteration of capitalism

So what’s this new iteration of capitalism? Zuboff explains that in this new paradigm, data is the raw source or ‘commodity’, extraction of it the production process (a supply route that the big tech companies work hard to protect) and predicting people’s behaviour is the product.

The production process (‘extracting’ data from people) has expanded massively over the past years, as tech corporations found new ways to get behavioural data (‘behavioural surplus’, as Zuboff calls it). They offer more and more services, sometimes increasing their speed by purchasing other companies (Facebook bought WhatsApp and Oculus, Google bought YouTube). And it isn’t just online either. Tech companies discovered there is lots of data to be gathered in the real world, through physical things with internet connections. Google Maps cars that ‘accidentally’ take WiFi hotspot data. Hotel rooms that come with Alexa built-in. And sometimes they give rewards in exchange, like an insurance company that offers a lower rate in return for replacing a monitoring device in your car.

There is this notion in the book that we accept too much without foreseeing the full picture. At some point Zuboff describes the nature of contracts online: legally they likely cover all they need to do, but might it be unreasonable to assume that anyone ever reads them? What if they refer to other contracts? The large scale data extraction operetion, that Zuboff later calls Big Other, may be a case of the horseless car syndrome, she suggests. When the first car was invented, we were used to horses and carriages, and thus that was how we tried to name and understand this new phenomenon: as a horseless carriage.

The dystopia of a data-driven society

The latest big thing isn’t just studying behavior, it is influencing behavior, too. Experimenters at Facebook found they could hugely influence people in whether they would go vote or not by using techniques from behavioral psychology. With these techniques, humans become merely tools. Zuboff introduces the notion of instrumentarialism, which she compares do and notes is quite different from totalitarianism. They both overwhelm society and do some sort of social domination, but for different reasons, the market vs the political realm.

Zuboff shows how the world in which surveillance capitalism plays the role it plays in ours, is somewhat dystopian. She compares it to Orwell’s and Skinner’s. One of the aspects that makes it dismal is that humanity gets reduced away. The tech leaders are utopians and believe in a “data-driven society”, Zuboff says. They insist that that is ’practical and feasible but also a moral imperative in which the benefits to the collective outweigh all other considerations’ (438). People like Pentland don’t believe in individuals with opinions and attitudes to live… if we see others do something, we’ll copy, we are easily conditioned.

Is this a conspiracy theory?

I have to ask, as last week a group of Dutch actors accused of hyperbolic complot theories held up the book in a talkshow as their bible. It contains some strong claims and assumptions about people’s intentions, but overall Zuboff’s book is very thorough. Her claims and statements are consistently supported by extensive footnotes.

A lot of the practices she asks questions about, actually happen. Tech leaders don’t deny them, and sometimes even boast about them, Zuboff shows. This is in the realm of private companies. What if the instruments of these private companies get used by authoritarian governments? Zuboff talks about how private companies helped American intelligence agencies with all sorts of technology. China’s Sesame Credit systems rates people’s character and gives or denies them perks, including things like purchasing rail tickets and using dating apps. The numbers are staggering. Again, these are not conspiracies, they actually happen.

It is also important that this argument isn’t against capitalism, it is against systems that break basic principles of democracy and human autonomy.

Conclusion

The age of surveillance capitalism is a great read, be sure to get a copy if you want to understand what surveillance capitalism is and could become. It does a great job at demonstrating what she presumes are the dynamics behind the internet economy. It’s convincing, and thought-provoking. It has gotten me worries, but also strangely positive about which world I want to fight for. It’s not an easy or quick read, as it is an academic book and sentences tend to get long and detailed. Alternatively, you can hear Shoshana Zuboff talk about surveillance capitalism at The Intercept or her interview with Mozilla’s IRL podcast.

Originally posted as Book review: The age of surveillance capitalism on Hidde's blog.

[email protected]?subject=Reply%20to:%20Book review: The age of surveillance capitalism">Reply via email

Content and colour at #idea11y in Rotterdam

2019-03-22T00:00:00Z

Last night I joined the ‘inclusive design and accessibility’ meetup (idea11y) at Level Level in Rotterdam, to learn more about optimising content and colors.

When I talk about accessibility, I often approach the subject from a front-end code perspective, and I make a point of disclaimering: this is only one of the many aspects to ensure the accessibility of a website. Content and colours are two other very important aspects that are essential to get right, so it was great to hear Damien Senger and Erik Kroes talk us through those subjects.

Content

Damien Senger, designer and accessibility advocate at Castor EDC, talked about cognitive impairments: ‘they are interesting, because they are often invisible’ (Damien’s slides). This is a great point, it also implies that these aspects are harder to catch in automated tests. Lighthouse can’t warn about them like it can about ill-formatted ARIA. Cognitive impairments we can optimise for include dyslexia, autistic spectrum disorder and ADHD. Users with such impairments benefit from less content, better organised content and more readable text.

Damien explained we read not by word but by ‘saccade’, jumping between parts. He also showed how shapes are important, and lack thereof bad for readibility, for instance all caps or justified text. These four C’s help, Damien said: continuity (repeat same information for reassurance), conspicuity (make it obvious), consistency (use same wording for same things) and clarity (ensure copy is understable).

Damien gave lots of tips for designing, on four levels:

micro typography: too much contrast can make letters dance for dyslexics, so dark grey is preferred to black; breaking highlighting is bad at people use that to see where they are
macro typography: think about heading hierarchy and group related things
layout: ensure consistency of layout and always offer multiple ways to find content
global: avoid distracting users with things like autoplaying videos; reduce content

Colour

Erik Kroes, accessibility specialist at ING, talked about colour, specifically what colour contrast means and how to create a for-screen colour palette for your brand that can be used with black and white accessibly.

Most people will know that colour contrast is important and use tools like Lea Verou’s awesome Contrast Ratio. For AA-level conformance, WCAG 2.1 prescribes contrast ratios of 3:1 (large text) and 4.5:1 (all text). These tools simply tell us whether our colours are within the range. Erik wanted to know more than just the numbers and had great feature requests (‘why do none of these tools show contrast with black and white at the same time?’).

Most of the talk was about creating colour schemes that lead to sufficient contrast ratios. Erik showed how HSL doesn’t really help when working out a contrastful scheme… to really get into finding colours with enough contrast, we need to look at ITU-R Recommendation BT.709, a standard from the 90s that describes colors for television screens that takes the human eye’s workings into account (‘useful luminence’, Erik called it). I had no idea, that this is what WCAG colour contrasts ultimately are based on. The reason this 30 year old standard is still somewhat suitable, is that screens still use sRGB and human eyes are still the same.

Erik explained that in WCAG 2.1, ratios range between 1:1 (zero contrast) and 21:1 (black on white). What I never realised, and am still unsure if I fully get how, is that when a colour has a ratio of 3:1 on a white background, it has a 7:1 ratio on a black background, because 21 divided by 7 equals 3. The maximum of 21 makes that the set of accessible colour combinations is limited.

To help with finding colour schemes that work well with black and white texts, Erik recommended the Contrast Grid tool. He also works on his own tool to meet his contrastful color needs, this looks very exciting (and is Web Components based).

Erik’s tool

Wrapping up

This was a great evening, thanks to Job. Rumour has it that there will be another one next month, so I am looking forward to that!

Originally posted as Content and colour at #idea11y in Rotterdam on Hidde's blog.

[email protected]?subject=Reply%20to:%20Content and colour at #idea11y in Rotterdam">Reply via email

Naming things to improve accessibility

2019-04-18T00:00:00Z

One thing you can do to improve the accessibility of your work is to always ensure things have accessible names. Unique and useful names, ideally, so that they can be used for navigation. In this post I’ll explain how browsers decide on the names for links, form fields, tables and form groups.

This post is based on part of my talk 6 ways to make your site more accessible, that I gave at WordCamp Rotterdam last week.

Accessibility Tree

When a user accesses your site, the server will send markup to the browser. This gets turned into trees. We’re probably all familiar with the DOM tree, a live representation of your markup, with all nodes turned into objects that we can read properties of and perform all sorts of functions on.

What many people don’t know, is that there is a second structure that the browser can generate: the accessibility tree. It is based off the DOM tree, and contains all meta information relation related to accessibility: roles, names and properties. Another way to say it: the accessibility tree is how your page gets exposed to assistive technologies.

Assistive Technology

Assistive Technology (AT) is an umbrella term for all sorts of tools that people use to improve how they access things. For computers and the web, they include:

alternate pointing devices, like a mouse that attaches to a user’s head
screen magnifiers, they enlarge the screen
braille bars, they turn what’s on the screen into braille
screenreaders, they read out what’s on the screen to the user

All of these tools, to work efficiently, need to know what’s happening on the screen. To find out, they access Platform APIs, built into every major platform, including Windows, Mac and Linux. The APIs can expose everything in the OS, so they know about things like the Start Bar, Dock or the browser’s back button. One thing they don’t know about, is the websites you access. They can’t possibly have the semantic structure of every website built into their APIs, so they rely on an intermediary — this is where the Accessibility Tree comes in. It exposes your website’s structure. As I said, it is based on the DOM, which is based on our mark-up.

A handy flow chart

The accessibility tree exposes roles (is this a header, a footer, a button, a navigation?), names (I’ll get into those in a bit), properties (is the hamburger menu open or closed, is the checkbox checked or not, et cetera) and a number of other things.

If you want to see what this looks like on a site of your choosing, have a look at the Accessibility Panel in Firefox Developer Tools, or check out the accessibility info boxes in Chrome, Safari Tech Preview or Edge developer tools.

Accesssible name computation

Names are one of the things the accessibility tree exposes for its objects. What a thing’s name is, gets derived from markup. There are many aspects that can influence this. If you want to know this in detail, check out the Accessible Name and Description Computation Specification.

Unique names help distinguish

Before going more into how to expose names, let’s look at which names we want. What the names are is crucial for whether they are accessible or not.

What if your family has four cats, and each of them is named ”Alice”? This would be incredibly impractical, as it would make communication difficult. “Has Alice been fed yet?”, you might wonder. “Is Alice outside?”, you might ask your partner. Ambiguity is impractical. Yet, this is what we do when our homepage has four news items, with each “Read more” as its link text.

Imagine all of your cats were named Alice (photo: stratman2 on Flickr)

This is very common, sadly. In the WebAIM Million project, in which WebAIM looked at over a million sites and ran automated accessibility checks, they found:

24.4% of pages had links with ambiguous link text, such as ‘click here’, ‘more’, ‘continue’, etc.

Reusing “Read more” as the link text for each news item makes our code and content management simpler, but it provides bad usability for screenreader users. When they use the link shortcut to browse through links on the page, they will have no idea where each links leads them. In the example above, when you ask an AT to read out all links, it will read “Link Read more, Link Read more, Link Read more, Link Read more”.

Naming things

So, unique and descriptive names are useful to AT users. Let’s look at which HTML can help us provide names. As I said before, the heuristics for determining names are in a spec, but with just HTML providing names for most things is trivial. The following section is mostly useful for people whose HTML is rusty.

Links

The contents of an <a> element will usually become the accessible name.

So in:

<a href="/win-a-prize">
Win a prize</a>

the accessible name would compute as “Win a prize”.

If there’s just an image, its alt text can also get used:

<a href="/win-a-prize">
  <img src="prize.png" alt="Win a prize" />
</a>

And, to be clear, if there’s nothing provided, the name would be null or empty string, so some people would be unable to win any prize.

Form fields

Form fields get labelled using the <label> element. In their aforementioned research, WebAIM also found:

59% of form inputs were not properly labeled.

Let’s look at what a labelling mistake could look like:

<div>Email</div> <!-- don't do this-->
<input type="email" id="email" />

In this example, the word “Email” appears right before the input, so a portion of your users might be able to visually associate that they belong together. But they aren’t associated, so the input has no name— it will compute as null or '' in the accessibility tree.

Associating can be done by wrapping the input in a <label> element, or by using a for attribute that matches the input’s id attribute:

<label for="email">Email</label> <!-- do this-->
<input type="email" id="email" />

Tables

To give a table a name, you can use its <caption> element. This is used as the first element in a <table>.

Groups in a form

Within forms, you sometimes want to group a set of form inputs, for example a collection of radiobuttons or checkboxes that answer the same question. HTML has <fieldset> for grouping form elements. To name this group as a whole, use the <legend> element:

<fieldset>
  <legend>Don't you love HTML?</legend>
  <input type="radio" name="yesno" id="yes"/>
  <label for="yes">Yes</label>
  <input type="radio" name="yesno" id="no"/>
  <label for="no">No</label>

If you were to inspect this fieldset in the accessibility tree, you will notice that the group is now known as “Don’t you love HTML?”.

What about ARIA?

Those familiar with the Accessible Name and Description Computation spec might wonder at this point: doesn’t ARIA also let us give elements accessible names? It totally does, for instance through the aria-label / aria-labelledby attributes. When added to an element, they overwrite the accessible name (if there was one).

Good reasons to prefer standard HTML tags over ARIA include:

better browser support (a lot of browsers support most ARIA, but all support all HTML, generally speaking)
more likely to be understood by current or future team members that don’t have all the ARIA skills
less likely to be forgotten about when doing things like internationalisation (in your own code, or by external tools like Google Translate, see Heydon Pickering’s post aria-label is a xenophobe)

Sometimes ARIA can come in handy, for example if an element doesn’t play along well with your CSS (like if you want a Grid Layout in a fieldset), or if your (client’s) CMS is very inflexible.

It’s the markup that matters

In modern browsers, our markup becomes an accessibility tree that ultimately informs what our interface looks like to assistive technologies. It doesn’t matter as much whether you’ve written this markup:

in a .html file
in Twig, Handlebars or Nunjucks
as the <template> in a Vue Single File Component
exported in the JSX of your React component
outputted by a weird legacy CMS

It is which markup that determines if your site is pleasurable to experience for AT users. In short: it’s the markup that matters

There’s good chance your site already uses all of the above HTML elements that name things. They have existed for many years. But I hope this post explains why it is worth the effort to always ensure the code your site serves to users, includes useful names for assistive technologies. Markup-wise it is trivial to assign names to all things on our site, the real challenge is probably two fold. It’s about content (do we come up with useful and distinguishable names), and about tech (can we ensure the right markup gets into our user’s DOMs).

Originally posted as Naming things to improve accessibility on Hidde's blog.

[email protected]?subject=Reply%20to:%20Naming things to improve accessibility">Reply via email

Baking accessibility into components: how frameworks help

2019-05-24T00:00:00Z

Complex components like date pickers, custom selects and modals can be tricky to get right. They can be tricky to make accessible. They need good internals, like sound semantics, keyboard usability and focus management. All well tested, preferably with a diverse set of real users. Once that is done, once a complex component is built to a high standard, frameworks or Web Components could help make that component very reusable.

Well, what’s new, you might think? Isn’t reusability of components the whole point of UI frameworks and Web Components? Yes, probably. But that is often pointed out as an advantage that increases developer convenience. I’ve heard that phrased as ‘if the developer has convenience, the user will, too’. Meanwhile, component framework-powered websites have a somewhat negative connotation among accessibility experts. This post tries to explore how component frameworks help. How they, too, can make the web a much better place for users, especially in terms of accessibility and usability. (Disclaimer: conclusions in this post may be trivial to declarative framework developers)

When I had to build a custom select

The longer a project goes on, the bigger the chance that someone will want a custom select to be built. I usually try and resist, because these are very hard to get right. Native selects have a lot of thought put into them. They work across platforms in a way that matches each platform (see native select behavior on Android, iOS). But sometimes there are good reasons. Really.

What I’m talking about, just to be clear, is not just a custom trigger (those are relatively easy), but also custom options within them. Everything custom!

The use case that initially triggered this piece of work, was a Mozilla project that had a component where someone could set field level privacy settings. There was a number of fields, like ‘First Name’ and ‘Last Name’, each with their own privacy setting. It was designed to have just the icon in collapsed state, and icons plus labels in the expanded state. An interface with all options spelled out for each field, would likely cause mental overhead. This is not a setting people set often, but we want it to be there, easy to find, because it is important to have control over your data privacy. With that in mind, it would make sense to show just an icon in the collapsed state.

No ARIA this time

ARIA is a fantastic initiative that essentially lets developers polyfill semantics. It involves adding attributes to an HTML element, in order to set accessibility-related meta information like the names, descriptions, roles and states of that element. It is specifically aimed at rich internet applications. Something to remember about it is that, while the ARIA suite adds new semantics to use in HTML, it is not a successor to the existing set of HTML elements. Those elements are still there and often very appropriate to use. The first rule of ARIA is not to use it.

Yep, it’s usually fine and appropriate to use existing semantic HTML elements.

The problem with the existing HTML element that is select, is this: browsers provide no way to customise what the options look like. But a select is not so different from a group of radiobuttons, right? Either let users pick one out of many. (I’m leaving the multiple attribute out of this, but let me just say they could map to checkboxes).

One big advantage of radiobuttons is that they are easy to customise, because you can visually hide them and then do whatever you like with their associated label element.

This is the basic version of a custom option:

<input type="radio" id="option-1" name="option-set" />
<label for="option-1">Rotterdam</label>

With this, you can apply a visually hidden technique to the input, use the for styling, and rely on the name to associate multiple options to be one thing. You could wrap the group of options in a fieldset and give that a maximum height. And probably a sensible (max?) width. Also, you’ll want to ensure it opens where there is space (and not outside the viewport).

Then, if your list of options is all done, there is one piece left: the thing that toggles the options. For this, I would suggest a button:

<button type="button">
  Choose city
</button>

If you want, you could use some ARIA to convey that this button controls your fieldset. This can be done with aria-controls, with an ID as its value (use the ID of the element you expand):

<button 
  type="button" 
  aria-controls="custom-select">
    Choose city
</button>

In Using the aria-controls attribute, Léonie Watson explains that although support is inconsistent, creating a “controls” relationship in the DOM can make a component more robust, while not getting in the way of users:

The presence of aria-controls won’t damage the User Experience (UX) for people using UA that don’t support it, but it will enormously improve the UX for those people whose browser/screen reader combinations do.

Another thing you can do to the button is set the expanded state, with aria-expanded. This takes a boolean:

<button 
  type="button" 
  aria-controls="custom-select" 
  aria-expanded="false">
   Choose city
</button>

The aria-expanded needs to reflect the actual expanded state, so when the custom select is open, set it to true, if not, set it to false.

So… say, you’ve done all this work, and you start using these custom selects across your website. One risk of reusing through copy/paste is that the code ends up in many places, and only in some of the places, all the markup is used as intended. This could be detrimental to the user experience. Maybe we could actually benefit from an abstraction here.

When component abstractions aid accessibility

If we do the above and make it available as a declarative component, perhaps React, Vue or an actual vanilla Web Component, one benefit is state. As we’ve seen in the above example, there are some things that rely on state, like the setting of aria-expanded. Declarative component frameworks make such settings trivial (once you’re up and speed with using the framework, that is, we’ll get into that later).

A second big advantage, is that it becomes one whole at the point of usage. Let’s say it is called custom-select.

Whenever we want to use custom-select, we do (pseudo code):

<custom-select options="options" />

In which options is some JavaScript object of options.

We declare it, we say what the options are, and in the DOM, it becomes a custom select with those options. This “becoming a custom select” might worry front-end folks, but it is not some sort of magic. We have described exactly what this means, how it should be done. With which semantics, keyboard behavior, focus styles and usability. These things are very important metrics for quality, they require careful consideration. The advantage of using some sort of component abstraction is that only one person or one team has to do this thinking. Others then ‘just’ use it, without worrying about the internals.

In my case, I’ve gone for a button that toggles a fieldset, but if there is a better way, custom-select can become whatever that better way is in the future. We need to come up with excellent internals, even be ready to improve them after a user test or accessibility. But all in all, I find this separation between internals and actual usage helpful.

A good example of a similar separation of concerns, from existing HTML, is the <video> element. It has a couple of internals that developers don’t need to worry about at the point of usage. We just need to tell it where our video and subtitles live. It then deals with internals for us: play buttons, closed captions, even multiple video formats… all the good stuff.

I’m more and more convinced that containment of ‘the good stuff’ can make the web better for users.

Increased complexity

There is a disadvantage to this nice containment of components using a framework: it’s complex. I mean, the tooling required to ship code is, because it requires advanced knowledge of JavaScript. That potentially scares people away. Complexity could reinforce privilege and moving all of a component into JavaScipt can turn full-stack developers into gatekeepers. Heydon Pickering describes there is a problem with full stack:

if you put someone in charge of all [the full stack], it’s highly likely they are going to be much weaker in some areas than others

In his post, Heydon identifies that what I call a component’s “internals” above are often built poorly. For two reasons: because improving internals now requires knowledge of complex frameworks and because the people specialising in them get undervalued. People who are good at writing front-end code that improves accessibility, but not at advanced JavaScript, might give up, at which point the web could lose out on accessible functionality. That’s sad.

I really like working on the detailed stuff that affects users: useful keyboard navigation, sensible focus management, good semantics. But I appreciate not every developer does. I have started to think this may be a helpful separation: some people work on good internals and user experience, others on code that just uses those components and deals with data and caching and solid architecture. Both are valid things, both need love. Maybe we can use the divide for good?

Conclusion

Modern websites commonly contain complex interaction patterns that aren’t default on the web. We may dislike that or prefer simplicity, but that’s a different (and also interesting) discussion. If we are going to code these complex interactions, it makes sense to contain the result in a component. Let’s assume we’ve worked hard on very accessible and usable ‘internals’, ran user tests and are confident that they are good. Then re-usability is a great thing, because the people who reuse, don’t need to worry about the internals. Like they wouldn’t worry about the internals of a video element when they use that. This is how I think frameworks can help make the web more accessible to users. And, ultimately, pave the way for more user convenience.

Update 31/1: In this post, I regard framework components and Web Components as one group for lack of a better word, but as Šime Vidas notes in the comments: if we make accessible components it makes more sense to do it in framework-agnostic Web Components than in a framework. To add to that, it might not only be tool-agnostic, but also more future proof.

Originally posted as Baking accessibility into components: how frameworks help on Hidde's blog.

[email protected]?subject=Reply%20to:%20Baking accessibility into components: how frameworks help">Reply via email

Hello W3C!

2019-05-27T00:00:00Z

In June, I will start working at the W3C as a Web Front-end Accessibility Specialist in the WAI team. This also means I’m leaving Mozilla and the City of The Hague, where I currently contract. Goodbye is never easy, but I’m very excited for this next challenge.

With 1¾ years, my freelance contract at Mozilla is my longest since I started contracting. Being a contractor is never forever, but I’m still sad to leave. I learn a lot and feel I am able to contribute a lot, too. I like this balance. It is great to work with Mozilla’s Open Innovation team, and specifically the IAM Project. I feel at home. It is difficult, too, at times, as our team is distributed across the globe in an ever-changing organisation (some of that is fun, too).

The majority of my time in the last year was spent on a project codenamed DinoPark, where people can browse other people’s profiles and edit their own. This is currently in Staff-only beta. Technically it is a Vue-based front-end which talks to back-ends using GraphQL. It is even more exciting from a human perspective. It fits Mozilla’s Manifesto in many ways, for example in privacy (how it lets users control who can see their data), security (designed with security at the core) and accessibility (we tackled accessibility challenges early in the process). I like and very much align with the Mozilla stance in the web, which is well captured in the manifesto… this makes me want to continue my relationship with Mozilla as a contributor. I’m still figuring out where that could be (there’s some ideas).

I will also leave the City of The Hague, where I rewrote the existing front-end code into a component-based system, exposed as a pattern library. I also worked on the accessibility throughout this system and the web pages it powers. Working for the government is something I had wanted for a long time, because governments have lots of IT problems, and solving them right can provide incredible value to people’s lives.

I will certainly miss working with both of these teams.

But really, the web is not accessible enough, and I feel like I’ve developed a passion for helping people get it right. At work, but also through talks and workshops. I’m delighted that I’ll get to spend more time on accessibility work.

In the last 10 years, I was often the “accessibility person” on the team. In my role at W3C, I am excited to become a person who is part of an “accessibility team”. I’ll be a Web Front-end Accessibility Specialist, working on WAI-Guide, that’s mostly what I know and can share right now. I’m equally nervous and excited for what awaits me.

Originally posted as Hello W3C! on Hidde's blog.

[email protected]?subject=Reply%20to:%20Hello W3C!">Reply via email

Indicating focus to improve accessibility

2019-06-06T00:00:00Z

It’s a common, but fairly easy-to-fix accessibility issue: lack of indicating focus. In this post I will explain what we mean by focus and show you how focus outlines make your site easier to use.

What is focus?

Focus indicators make the difference between day and night for people who rely on them. Let’s first look at what they are, and which people find them useful.

Focus is something that happens between the interactive elements on a page. That’s the first thing you should know. (See the focusable elements compatibility table for a more detailed and nuanced definition.) Interactive elements are elements like links, buttons and form fields: things that users can interact with.

On a page, at any given time, there is one element that has focus. If you’ve just loaded a page, it is probably the document, but once you start to click or tab, it will be one of the aforementioned interactive elements. The currently focused element can be found with document.activeElement.

By default, browsers convey which element currently has focus by drawing an outline around that element. The defaults vary between browsers and platform. With CSS, you can override these defaults, which we’ll get to in a bit.

Who benefits

Focus outlines help users figure out where they are on a page. They show which form field is currently filled in, or which button is about to be pressed. People who use a mouse, might use their cursor for this, but not everyone uses a mouse. For instance, there are many keyboard users: a person with a baby on one arm, people with chronic diseases that prevent the use of a mouse, and of course… developers and other power users. .

Beyond keyboards, there are other tools and input devices that rely on clearly indicated focus, like switches. Focus indication also helps people who have limited attention spans or issues with short term memory, for example if they are filling out a lengthy form.

If the idea of indicating the current element in a website seems weird, consider TV interfaces. Most people use them with a remote control or game controller, and therefore rely on the interface to convey what’s currently selected.

Never remove them

Not everyone likes how focus outlines look, some find them ugly. But then that’s the case with street lights, too. They are unlikely to win design awards, but if you have to walk home in the dark, you are glad they help you see where you are.

Removing focus styles, as some websites do, is as detrimental for keyboard users as removing the mouse cursor would be for mouse users.

Nobody would override the browser’s default cursor, effectively removing the cursor altogether:

body {
  cursor: none; /* you wouldn't do this */
}

So we shouldn’t do this either, which removes the browser’s default outline:

:focus {
  outline: none; /* so, please don't do this */
}

Or, as Laura Carvajal put it at Fronteers 2018:

Even if you provide an alternative with something like box-shadow, best set outline to solid transparent, because box-shadow does not play well with high contrast modes.

Good focus indicators

One way to indicate focus is to rely on browser defaults. It works, but I would recommend designing your own focus outlines. This gives you maximum control over how easy they are to see, and lets you integrate them with brand colours or the style of your site. Usually, thicker outlines (from 2px onwards) are better, as they are simply easier to see.

The :focus pseudo class takes CSS rules like any other selector, so you could style it however you like. In some cases a background color or underline could indicate that something is active.

Examples

Below are focus outlines as seen on Schiphol.nl and the City of The Hague websites. They make it easy to distinguish in a list of links which one is currently active.

Transitions

Focus outlines do not have to be boring. The outline property can be transitioned with CSS, so why not add a subtle animation? Make it pop!

Contrast

In WCAG 2.1, focus indicators are bound to the same contrast rules as other parts of the content, as per 1.4.11: Non-text contrast. This means a contrast of 3:1 between the outlines and their background is required.

On websites that have both light and dark parts, it is quite common to have a dark and a light focus style. For example, if your focus outline is blue for parts with a white background (for instance, the main content area), you could make it white for parts with a black background (for instance, the footer).

Special cases

Focusing non-interactive elements

As mentioned earlier, focus works on interactive elements. In special cases, it makes sense to focus a non-interactive element, like a <div> , if that element is a piece of expanded content or a modal overlay that was just opened.

Any element can be added to focus order with the tabindex attribute in HTML. Best use it with 0 or -1:

tabindex="0": element can be focused with keyboard and through JavaScript
tabindex="-1": element can be focused through JavaScript, but cannot be tabbed to

A tabindex with a number larger than 0 is best avoided, as this sets a preference of where the element goes in the tab order. If you set it for one element, you will have to set and maintain (!) a tabindex value on all interactive elements on the page. See also: It rarely pays to be positive by Scott O’Hara.

Only for keyboard users

If you are a developer and the design team is unwilling to apply bold focus styles, you could propose to show them to users who need them, for instance only to keyboard users.

There are two caveats to this notion of “users who need them”:

Not all people who rely on focus styles use a keyboard. We mentioned switches earlier, but that’s only one use case. As a general rule, keep in mind that you can’t predict all the ways your visitors choose to browse the web.
Making focus styles keyboard-only takes away an affordance for mouse users too, as focus also indicates that something is interactive.

For these reasons, we should be careful making decisions about when and how to show focus styles. Luckily, there is a CSS property invented to help us out here: focus-visible. According to the spec, it lets us:

provide clearly identifiable focus styles which are visible when a user is likely to need to understand where focus is, and not visible in other cases

In other words: it aims to let you indicate focus only for people that need it. It is preferable to avoid such heuristics and convey focus rings to everybody, but if you have to, focus-visible is ideal. Especially if the alternative is nothing at all.

Focus styles as keyboard accessibility

A focused element that isn’t highlighted has a big impact on usability for keyboard users. You could make keyboard checks part of your development workflow to ensure that you don’t forget focus indicators. For instance, you could include “Can be used with a keyboard” in your definition of done. This is a check that most people in the team should be able to do before a new feature goes live. As we’ve seen above, focus styles don’t just benefit keyboard users, but keyboard operability is a good way to test them.

When testing, you might find that not all browsers and platforms let you tab through interactive elements by default. Here are some of the most common settings across platforms and browsers:

macOS: under System Preferences > Keyboard > Shortcuts set ‘Full keyboard access’ to ‘All controls’
Safari, macOS: in Safari > Preferences, under ‘Advanced’, check ‘Press Tab to highlight each item on a webpage’
Chrome: in chrome://settings, under ‘Web content’, check ‘Pressing Tab on a webpage highlights links, as well as form fields’

Summing up

Hopefully this post inspires you to try out your (client’s) site with just a keyboard. Maybe it is a pleasure to use already. If not, perhaps this post convinces you or your team to address the problem and design some on-brand focus indicators. Together we make the web more friendly to users of keyboards, sticks and switches. Together we make the web work for everyone.

Focus outlines are one of many ways to design for accessibility. For more tips on design with accessibility in mind, see Accessibility Information for UI designers on MDN and Tips for designing with accessibility at the W3C.

Originally posted as Indicating focus to improve accessibility on Hidde's blog.

[email protected]?subject=Reply%20to:%20Indicating focus to improve accessibility">Reply via email

CSS Day 2019: some things I learned

2019-06-18T00:00:00Z

Last week I joined over 400 web nerds at CSS Day 2019, which took place once again in the lovely Compagnietheater in Amsterdam. These are some of the things I learned.

The badges were beautiful and there were smoothies (scroll-behavior: smoothie)! Speakers from left to right: Natalya Shelburne, Rachel Andrew, Tab Atkins, Heydon Pickering. Photos on the right by Joyce Goverde, the event’s awesome photographer

When I attended the first installment of the conference, I had not expected that there would be more. I mean, there’s only so much you can say about CSS. Of course I was wrong and more happened… every year. Last week was the 7th (!). The 2019 edition was not, as tweets may have suggested, a day for bashing JavaScript or the people who write it. Apart from the occasional tongue in cheek comment on people’s motivations to pick React (React?), this conference was full of interesting tidbits on what CSS can do now, how it is being developed (in specs and in browsers) and how we can, as CSS developers, be effective team members, able to sell CSS as the serious language that it is. With all due respect for our colleagues who write JavaScript (I and many others do both, too).

Note, I missed the first talk (the good thing about a conference nearby is: can do some daughter time in the morning). Luckily Rachel Andrew’s video and Rachel’s slides are already online, I just watched the video and it is very, very good. One great point she makes in it is that we should stop talking about CSS as if it is a hack, because if we do we reinforce the idea that CSS is weird, quirky and a series of hacks. She said this in the context of using auto margins for alignment, which she said is simply using CSS as it is specced, not a hack.

What CSS can do now

Something you might not think about daily: when should lines break? Florian Rivoal showed how whitespace between words works on the web, and what some of the challenges are in deciding when to break a line to the next (Florian’s slides, Florian’s video). This is specifically interesting within tables, as a cell that contains a long line of content increases the whole table’s size, unless the line breaks. The same happens in Grid Layout cells, by the way. Breaking is defined in Unicode, annex 14, you can automate with auto hyphens (always set a lang and star the Chromium bug to express interest in support) or manually influence with <wbr> or a soft hyphen character.

Steve Schoger showed tips and tricks to make websites look better (Steve’s video). No actual CSS was shown, but it was interesting to see how small visual changes can make a big difference. Think about how to choose the right colors, create visual hierarchy and design good tables. A great tip regarding tables was: they don’t have to represent your database structure: often you can show less columns by combining or omitting some information, and make the core information easier to find. It was good to see that in many of his tips, Steve also took accessibility into account.

Heydon Pickering introduced how smart CSS can let flexbox layouts resize between linear one column things and multiple columns, without that weird in between state where the last item takes double space and therefore looks more important, and, importantly, with no media queries (Heydon’s video). They depend on window width, which is not helpful in a world where components can exist in all sorts of containers. His solution is aptly (?) named the holy albatross, and in his talk he revealed a project called Every Layout where that technique and others will be made available as custom elements, built together with Andy Bell.

How it is being developed

Line boxes have existed for ages in CSS, Elika J. Etemad a.k.a. fantasai explained, they ensure content does not overlap (fantasai’s video). But, non-overlapping content could mean a less ideal vertical rhythm, and this annoys typographers working with CSS. The definition of ‘fits within linebox’ may need to be redefined, Elika explained, there may be a switch between this old and new model for how lines are sized. What if you have a graphic or heading on a page that is not as tall as exactly X amount of lines? That would interrupt the vertical rhythm. To deal with that, CSS might get a block-step-size property that could insert extra space above and/or below that graphic, to fill the gap between the space the graphic needs and the space the vertical rhythm offers. You would even be able to choose whether to add it as margin or padding (with block-step-insert), and where to align it (block-step-align: auto | center | start | end). This is all defined in CSS Rhythmic Sizing, currently open for feedback. Elika also went into linebox trimming with leading-trim-over/leading-trim-under, which gives better control over leading in the top and bottom of a text, to allow for alignment without magic numbers (see #3240). Interestingly, for this to work, it’s not just CSS, but also font foundries, who need to add the required metrics. Font metrics are also important for baselines (in future CSS you can set a dominant baseline with dominant-baseline (TIL there are multiple baselines)) and drop caps. For all of these things, languages beyond English (including CJK: Chinese-Japanese-Korean), are very much taken into account by spec writers, because the web is for everyone.

Manuel Rego Casasnovas showed how CSS is developed as features inside browsers: what the steps are to follow, what kind of actual C++ code goes where in the code base and how features go from existing behind flags to stable browser features that will forever exist because backwards compatibility (Manuel’s video). One of the many interesting things I learned in this talk is that it takes hours to compile a browser.

If we had grid-skip-areas, we could choose to autoplace grid items in all areas, except some. Then we could create the word CSS out of a grid.

Being a CSS developer

It is unlikely for a question to attract as many trolls online as: ‘is CSS a programming language?’ Lara Schenck decided to do the research and shared her results with us in a talk that was excellent in so many ways (Lara’s slides, Lara’s video). CSS fits right into one of the programming paradigms, domain-specific declarative programming languages, Lara explained. There are lots of criteria sceptics could come up with, like that programming languages should be Turing complete, suitable to write algorithms in and ‘have consequences’. She addressed these brilliantly in a sort of Socratic dialogue. Yes, you can replicate rule 110 in CSS with :checked and :not(), ok and a user and HTML, you can (and probably should) write CSS algorithms that are groups of declarations to produce a specific output, and yes, CSS has consequences, that can be addressed with programming methodologies. A great serious note she ended with is that a consequence of labeling CSS as “not programming” is that it renders companies unable to hire people who are good at CSS. People see it as not a skill worthy, and this is a problem, because without good CSS developers, companies lose out on well-built front-ends. To add a data point: I see this phenomenon almost everywhere I work (sadly).

Lara’s Turing machine

Natalya Shelburne talked about the mindset of people who write CSS and how it combines different mental models (Natalya’s talk). She talked how CSS developers can bridge the gap between designers and the actual application’s you’re working on. One tool that helps is design systems: it can bridge domains, enforce shared vocabularies. Another cool thing she showed was a special ribbon like menu that she deploys just on staging. It has tools to help designers understand grids and, amazingly, the boxes that exist in the CSS reality, as compared to the boxes that are in the designer’s software. What an awesome way to collaborate! Natalya also discussed technological barriers: by moving a lot of our code into React components that are written in a way that’s mostly optimised for reading the JavaScript that exists around it, highers the bar for pure CSS people to contribute. She suggested having a pure HTML/CSS version to allow designers to contribute. Rather than thinking about or sticking to certain technologies, we should think about how to enable people, Natalya said. She celebrated that there are lots of people in the web community doing great work in this space.

Wrapping up

It was really good to see some new CSS that is coming up (seriously. watch fantasai’s video) and learn about how to use existing CSS. Another recurring theme throughout the day was: as a community of CSS people, we should demand this language we love to be taken much more seriously. If not for our own sanity and valuation, then for the companies we are writing CSS code for. I urge you to watch Lara’s video and Natalya’s talk.

One call to action that a couple of speakers mentioned in talks and in the hallways: please have a say in how CSS develops, all discussions happen on GitHub, everyone should feel free to comment. Blogging about things you’d like to see or use is also encouraged.

The CSS Day organisers have once again set the bar very high for the next edition, let’s hope there will be another one in 2020!

Originally posted as CSS Day 2019: some things I learned on Hidde's blog.

[email protected]?subject=Reply%20to:%20CSS Day 2019: some things I learned">Reply via email

How accessibility trees inform assistive tech

2019-06-27T00:00:00Z

The web is accessible by default. It was designed with features to make accessibility possible, and these have been part of the platform pretty much from the beginning. In recent times, inspectable accessibility trees have made it easier to see how things work in practice. In this post we’ll look at how “good” client-side code (HTML, CSS and JavaScript) improves the experience of users of assistive technologies, and how we can use accessibility trees to help verify our work on the user experience.

People browse differently

Assistive Technology (AT) is the umbrella term for tools that help people operate a computer in the way that suits them. Braille displays, for instance, let blind users understand what’s on their screen by conveying that information in braille format in real time. VoiceOver, a utility for Mac and iOS, converts text into speech, so that people can listen to an interface. Dragon NaturallySpeaking is a tool that lets people operate an interface by talking into a microphone.

A refreshable Braille display (Photo: Sebastien.delorme)

The idea that people can use the web in the way that works best for them is a fundamental design principle of the platform. When the web was invented to let scientists exchange documents, those scientists already had a wide variety of systems. Now, in 2019, systems vary even more. We use browsers on everything from watches to phones, tablets to TVs. There is a perennial need for web pages that are resilient and allow for user choice. These values of resilience and flexibility have always been core to our work.

AT draws on these fundamentals. Most assistive technologies need to know what happens on a user’s screen. They all must understand the user interface, so that they can convey it to the user in a way that makes sense. Many years ago, assistive technologies relied on OCR (optical character recognition) techniques to figure what was on the screen. Later they consumed markup directly from the browser. On modern operating systems the software is more advanced: accessibility APIs that are built into the platform provide guidance.

How front-end code helps

Platform-specific Accessibility APIs are slightly different depending on the platform. Generally, they know about the things that are platform-specific: the Start Menu in Windows, the Dock on the Mac, the Favorites menu in Firefox… even the address bar in Firefox. But when we use the address bar to access a website, the screen displays information that it probably has never displayed before, let alone for AT users. How can Accessibility APIs tell AT about information on websites? Well, this is where the right client-side HTML, CSS and JavaScript can help.

Whether we write plain HTML, JSX or Jinja, when someone accesses our site, the browser ultimately receives markup as the start for any interface. It turns that markup into an internal representation, called the DOM tree. The DOM tree contains objects for everything we had in our markup. In some cases, browsers also create an accessibility tree, based on the DOM tree, as a tool to better understand the needs and experiences of assistive technology users. The accessibility tree informs platform-specific Accessibility APIs, which then inform Assistive Technologies. So ultimately, our client-side code impacts the experience of assistive technology users.

HTML

With HTML, we can be specific about what things are in the page. We can define what’s what, or, in technical terms, provide semantics. For example, we can define something as a:

checkbox or a radio button
table of structured data
list, ordered or unordered, or a list of definitions
navigation or a footer area

CSS

Stylesheets can also impact the accessibility tree: layout and visibility of elements are sometimes taken into account. Elements that are set to display: none or visibility: hidden are taken out of the accessibility tree completely. Setting display to table/table-cell can also impact semantics, as Adrian Roselli explains in Tables, CSS display properties and ARIA.

If your site dynamically changes generated content in CSS (::before and ::after), this can also appear or disappear in accessibility trees.

And then, there are properties that can make visual layout differ from DOM order, for example order in grid and flex items, and auto-flow: dense in Grid Layout. When visual order is different from DOM order, it is likely also going to be different from accessibility tree order. This may confuse AT users. The Flexbox spec is quite clear: the CSS order property is “for visual, not logical reordering”.

JavaScript

JavaScript lets us change the state of our components. This is often relevant for accessibility, for instance, we can determine:

Is the menu expanded or collapsed?
Was the checkbox checked or not?
Is the email address field valid or invalid?

Note that accessibility tree implementations can vary, creating discrepancies between browsers. For instance, missing values are computed to null in some browsers, '' (empty string) in others. Differing implementations are one of many reasons plans to develop a standard are in the works.

What’s in an accessibility tree?

Accessibility trees contain accessibility-related meta information for most of our HTML elements. The elements involved determine what that means, so we’ll look at some examples.

Generally, there are four things in an accessibility tree object:

name: how can we refer to this thing? For instance, a link with the text ‘Read more’ will have ‘Read more’ as its name (more on how names are computed in the Accessible Name and Description Computation spec)
description: how do we describe this element, if we want to add anything to the name? The description of a table could explain what kind of info that table offers.
role: what kind of thing is it? For example, is it a button, a nav bar or a list of items?
state: if any, does it have state? Think checked/unchecked for checkboxes, or collapsed/expanded for the <summary> element

Additionally, the accessibility tree often contains information on what can be done with an element: a link can be followed, a text input can be typed into, that kind of thing.

Inspecting the accessibility tree in Firefox

All major browsers provide ways to inspect the accessibility tree, so that we can figure out what an element’s name has computed to, or what role it has, according to the browser. For some context on how this works in Firefox, see Introducing the Accessibility Inspector in the Firefox Developer Tools by Marco Zehe.

Here’s how it works in Firefox:

In Settings, under Default Developer Tools, ensure that the checkbox “Accessibility” is checked
You should now see the Accessibility tab
In the Accessibility tab, you’ll find the accessibility tree with all its objects

Other browsers

In Chrome, the Accessibility Tree information lives together with the DOM inspector and can be found under the ‘Accessibility’ tab. In Safari, it is in the Node tab in the panel next to the DOM tree, together with DOM properties.

An example

Let’s say we have a form where people can pick their favourite fruit:

<form action="">
  <fieldset>
    <legend>Pick a fruit </legend>
    <label><input type="radio" name="fruit"> Apple</label>
    <label><input type="radio" name="fruit"> Orange</label>
    <label><input type="radio"  name="fruit"> Banana</label>
  </fieldset>
</form>

In Firefox, this creates a number of objects, including:

An object with a role of grouping, named Pick a fruit
Three objects with roles of label, named Apple, Orange and Banana, with action Click, and these states: selectable text, opaque, enabled, sensitive
An object with role of radiobutton, named Apple, with action of Select and these states: focusable, checkable, opaque, enabled, sensitive

And so on. When we select ‘Apple’, checked is added to its list of states.

Note that each thing expressed in the markup gets reflected in a useful way. Because we added a legend to the group of radio buttons, it is exposed with a name of ‘Pick a fruit’. Because we used inputs with a type of radio, they are exposed as such and have relevant states.

As mentioned earlier, we don’t just influence this through markup. CSS and JavaScript can also affect it.

With the following CSS, we would effectively take the name out of the accessibility tree, leaving the fieldset unnamed:

legend { display: none; /* removes item from accessibility tree */ }

This is true in at least some browsers. When I tried it in Firefox, its heuristics still managed to compute the name to ‘Pick a fruit’, in Chrome and Safari it was left out completely. What this means, in terms of real humans: they would have no information as to what to do with Apple, Orange and Banana.

As mentioned earlier, we can also influence the accessibility tree with JavaScript. Here is one example:

const inputApple = document.querySelector('input[radio]');
inputApple.checked = true; // alters state of this input, also in accessibility tree

Anything you do to manipulate DOM elements, directly through DOM scripting or with your framework of choice, will update the accessibility tree.

Conclusion

To provide a great experience to users, assistive technologies present our web pages differently from how we may have intended them. Yet, what they present is based directly on the content and semantic structure that we provide. As designers and developers, we can ensure that assistive technologies understand our pages well writing good HTML, CSS and JavaScript. Inspectable accessibility trees help us verify directly in the browser if our names, roles and state make sense.

Originally posted as How accessibility trees inform assistive tech on Hidde's blog.

[email protected]?subject=Reply%20to:%20How accessibility trees inform assistive tech">Reply via email

Click here to kill everybody: a review

2019-07-05T00:00:00Z

This week I read Click here to kill everybody, a book that is at the same time worrying and encouraging. A security nightmare is waiting to happen, but there is still time to save the world. Yeah, the book is a tad dramatic, but generally a great read that I can recommend.

The book

More and more devices are connected to the internet, and it is not just traditional devices with browsers, like desktop computers, laptops, tablets and smartphones. It’s also things like washing machines and fridges. Even in mission critical things like thermostats, pacemakers and nucleair power plants. We, humans, are in the middle of this new world: we give input to and accept output from our devices. In his book Click here to kill everybody, security expert Bruce Schneier coins the phrase Internet+ for this new reality (the internet, things and ourselves). He worries about Internet+, as it is grows rapidly and is a lot less secure than we should want it to be. With your car on the network, a hack could mean turning off its breaks while on the highway. With internet enabled medical devices in our body, a hack could mean turning you off. Yup, lots to worry!

The book gives a good overview of security risks that we can find in internet connected devices and how villains could exploit them. Many of those devices have problems that we technically already know how to fix. Encryption exists, but companies produce baby monitors that don’t encrypt voice data, to name just one example. Some of this sounds oddly familiar to accessibility: WCAG is over 20 years old now, but it is not implemented as widely as one would hope.

There’s lots of reason for pessimism, Schneier explains, if you think about the incentives of companies and governments. Companies focus on maximising profits, and lack of security is often no threat to those profits. This is because usually customers face the consequences. Surveillance capitalism also gets in the way, because you cannot trust companies to keep you secure if their business model is surveillance. In short, and the book goes into a lot more detail, we should not expect a lot from companies. Governments sometimes work against security: they try to keep security protocols weak and keep certain vulnerabilities secret, to make the work of intelligence agencies like NSA and FBI easier. Or they propose to ban encryption altogether (Cameron and May in the UK). Schneier questions whether such attempts are going to help: real criminals will find their way around, so it won’t stop them, but it will certainly make the world a lot less secure for ordinary consumers. Can we afford that?

Still, Schneier looks at the government for solutions. Because they could actually do something about companies’ lack of security, by legally forcing companies into making their products more secure. Earlier in the book, Schneier talks about how useful it would be if security and detailed aspects of it become metrics by which products get compared. I could imagine that to be policy, too: force companies who make Internet of Things devices to disclose whether or not they have certain security features. Does this particular baby monitor encrypt data, and with which algorithm? Oh, this other one does not encrypt at all. It fits well in Schneier’s call for transparancy: more transparancy about data breaches and security implementation is essential for a more secure future, he says.

One of the risks in governments getting policy about technology right, is that policy makers often lack technological understanding, Schneier explains. Last year’s Mark Zuckerberg hearings in the US Senate were probably a good example of that, although that was about privacy, not security. It was sad to watch many of the Senators ask the wrong questions, because they clearly did not get what they should have worried about. Many policy makers don’t seem to realise the risk of storing so much personal data on corporate servers, Schneier concludes. So he ends with a call to action. There is a huge need for people with an engineering background to be interested in policy, and get involved. Schneier also points at some experts who are already doing this, like Latanya Sweeney (“probably the best analyst in de-anonymysation”, now professor of government and technology) and professor Susan Landau who testified before US Congress about ubiquitous encryption.

I like the book. It is a bit sensational, has a click-baity title and focuses too much on the US and Europe, but it gives a really good overview of the stakes across companies, ethics and politics with regards to internet security. Its mostly about stakes, and not so much about practical security advice, which I’m sure you can find in one of Schneier’s other books. Click here to kill everybody ends positively: we can get this right, let’s take action now.

Originally posted as Click here to kill everybody: a review on Hidde's blog.

[email protected]?subject=Reply%20to:%20Click here to kill everybody: a review">Reply via email

Meaning without markup: Accessibility Object Model

2019-07-22T00:00:00Z

Meaningful markup is essential for accessibility, because it brings semantics. In short, it tells the browser what things are. Proposals for the Accessibility Object Model include a new way to convey semantics: without markup, directly in JavaScript. In this post, we will look at the proposals and their current status.

Beyond the scope of HTML

To get a more detailed overview of how the quality of our markup impacts end users, see my previous post How accessibility trees inform assistive tech. To summarise: our markup gets used to construct accessibility trees, which inform assistive technologies (AT) about what things are on our pages. With this information, AT can offer features like ‘browse by heading’ and advanced table navigation.

There are plenty of semantic elements to choose from when we build a component. The set of HTML elements is enormous. Even if you build a new thing for which no semantic element exists, custom components that combine existing HTML elements let you have at least some of your semantics for free.

Sometimes the set of HTML elements really does not cut it. You’ve created an interface concept for which reasonably no semantic tag exists in HTML. This is where WAI-ARIA comes in: it lets you provide accessibility-relevant information to the browser using standardised attributes, including semantics, states and labels.

Some examples of effective ARIA:

with aria-expanded="true|false", you can set the state of a button that expands/collapses content
with role="alert" you can turn an element into a live region: when content is updated, the update is announced to AT users

There is also ARIA that can turn elements into elements for which there are already existing HTML equivalents, such as buttons and links. This is not recommended, because apart from changing semantics, it also makes affordances like keyboard behavior the developer’s responsibility. For instance, instead of <span role="button">, it is much safer to use <button type="button"> and get the keyboard behaviour for free. In 2019, styling native buttons is no longer a problem. Certainly not one that warrants accessibility bugs like reduced keyboard support.

How AOM will help

So, let’s say you are making something that passes the first rule of ARIA (paraphrased: “don’t use ARIA if it is not needed”). You could use markup for this: just add the appropriate attributes. Once the Accessibility Object Model is implemented, you could also apply ARIA without markup.

The proposed Accessibility Object Model (AOM) will be “a JavaScript API to allow developers to modify (and eventually explore) the accessibility tree for an HTML page”. In other words: it gives developers direct access to the accessibility tree. In a way, that’s a bit like what Service Workers do for the network and Houdini for style: give developers control over something that was previously done only by the browser. All in the name of an extensible web: control over these low-level features enables developers to experiment and create new things without waiting for the standards process. Perhaps, with AOM, people could define Web Components that don’t exist in HTML just yet.

Having access to low-level features like these, gives developers power (yay!). But at the same time, they also give developers more direct responsibility, regarding aspects like security, performance and accessibility. It can be tricky and time-consuming to implement best practices and fulfill all those responsibilities. Admittedly, is it easier, and often sensible, to use browser defaults. Extending the web like this is probably most practical for teams that are able to invest the time.

AOM is currently developed by people from across Mozilla, Google and Apple. They’ve defined four phases for the project. Let’s look at some of the plans and how they help.

No more ‘sprouting’

Interfaces with a lot of advanced controls can quickly become a sea of attributes, which the HTML spec calls “sprouting”. Even a simple disabled button might require role, aria-label and aria-disabled attributes. That’s a lot of attributes, not just to add, but also to maintain (in markup). To solve this, AOM will let developers set accessibility attributes of an element directly in JavaScript.

For example, to set aria-expanded on an element, you could do it on the element directly:

el.ariaExpanded = true;

Previously, we could only set this attribute to expanded by switching the value of the attribute in the markup. With AOM, the set of ARIA attributes will also exist as properties that DOM nodes can have, so called IDL (Interface Definition Language) attributes. The IDL attributes are said to reflect attributes in the markup. In the above example, that means that upon setting el.ariaExpanded to true, an attribute (if it does not yet exist) is added to el and it is set to true.

The mapping of ARIA attributes to IDL attributes is defined in the ARIA 1.2 specification.

Note that in applications that have some form of virtual DOM, like those built with frameworks including React and Vue, best practices prescribe “don’t touch the DOM, let the framework deal with DOM changes”. In those applications, defining semantics in the markup or a template will probably still be the go-to approach.

Relationships without IDs

In HTML, the id attribute uniquely identifies an element. Form labels make use of this: we associate label attributes with their corresponding input by pointing the label’s for to the input’s id. In ARIA, there are a number of properties that need to point to an id (or multiple ids), like aria-controls (this element controls that element) and aria-describedby (this element is described by this element/these elements).

With AOM, one can associate elements with other elements directly, by assigning them like this:

formField.ariaLabelledBy = formLabel;

Non-DOM nodes in the accessibility tree

In some very specific cases, a web application may contain content that does not exist as DOM nodes. For instance: drawing a train station’s map of available elevators on a canvas. Each elevator has a label, and also a informational popup that can be expanded. This information would currently be lost to assistive technologies. With AOM, you could define an accessibility tree containing all the labels and expanded states. These would then be conveyed to AT, so that users can understand them.

Good for testing

The AOM also aims to bring reading accessibility attributes. The intended use case: testing! With AOM, you would be able to access the names, roles and states of your HTML nodes directly in tests.

Tests can already access an element’s ARIA information by reading out attributes today. With AOM, they would read out what something has actually computed to in the browser’s accessibility tree. This functionality has the potential to make tests better.

Accessibility Events

In JavaScript, we have a number of useful events that let us act on user input like clicks, keyboard presses and touch. In some cases, there is a discrepancy between such events and input from users of assistive technologies.

In her talk Web Components and the AOM at JSConf Asia 2019, Léonie Watson explained that actions like “swipe up” and “swipe down” mean different things to users of VoiceOver on iOS:

When you have a screenreader running on a touch screen, the flick up and flick down gestures [developers] would probably use for adjusting the value of a slider, are already used for screenreader specific commands.

Because screenreader users already use “swipe up” and “swipe down” gestures to trigger screenreader specific commands, it would be impossible for them to use the same gestures for something else in the app you’re developing.

This is why AOM aims to bring events that are specific to assistive technologies, so that AT can design consistent ways to let the user perform certain actions. Apple calls these semantic events.

Some examples of accessibility events:

increment and decrement for going to the next item in a custom slider (like using up and down arrow keys)
dismiss for closing a modal overlay (like pressing ESC key)

There is a large privacy concern associated with AT-specific events: malicious site owners could use them to detect if someone has a visual or mobility impairment.

Current status

The specifications for AOM are still in progress, and so are implementations. Various browsers have implemented (parts of) AOM). The part that seems to have most implementations is attribute reflection. This feature works for most attributes in Chrome and Edge (enable via about:config) and Safari (pick ‘Accessibility Object Model’ from Experimental Features setting in Developer menu). There is currently no AOM support not in Firefox.

If you look at the IDL tests with AOM flags enabled, you can see how much your browser supports of the attribute reflection part of the specification.

Wrapping up

Simple solutions are often the easiest way to get your product to work for as many people as possible. For example, when for a date of birth field, you decide against a fancy, complex datepicker and rely on a clearly labelled input[type=text] instead. Standard, boring HTML goes a long way. Chances are it will work well for users and make your accessibility auditors happy. But if your product has custom controls that just don’t exist in HTML, you will want to convey the right accessibility properties to assistive technologies.

AOM is an interesting new proposal in which accessibility information gets its own APIs beyond existing DOM methods like setAttribute and getAttribute. Those methods set and get out values that compute into properties of accessibility trees, but they don’t deal with those properties directly. It’s a subtle difference. With direct access to accessibility info, we could set accessibility properties without markup, we could create accessibility trees for things that don’t exist in the DOM (like for contents of canvas elements) and testing accessibility may improve.

Originally posted as Meaning without markup: Accessibility Object Model on Hidde's blog.

[email protected]?subject=Reply%20to:%20Meaning without markup: Accessibility Object Model">Reply via email

Equality: a reading list

2019-08-23T00:00:00Z

The world isn’t as equal as it may seem to people who are white, heterosexual and able-bodied. This is a reading list about the inequality that they experience a lot less of. It has books about the everyday experiences of people who are underprivileged, what identity means, how racism and sexism manifest themselves and what we can do about that.

A quick disclaimer: I’m not an expert in any of these subjects, just an interested reader. This selection is by no means exhaustive, but I hope it is helpful to others.

Goldfish in bowls don’t know what water looks like, because they’re in water. That they cannot leave their bowl is a fact of their lives. The thing is… people sometimes have the same problem. When they look at society, they don’t always see all structures that exist within it. Structures like racism and sexism, for instance.

The problem that is a common theme throughout all books in this list: people who aren’t affected by bad structures, often have a wildly unrealistic idea of what they mean and how common they are. Unlike goldfish though, those people have it relatively easy to peek outside of their bubble. Listening to or reading about what people with different perspectives experience is a good habit, and what I would encourage anyone with privilege to do.

(If, reading this, you find yourself thinking “but I’m not privileged”, but you are white, male and/or heterosexual, you most likely are. Sorry.)

When you’re better aware of inequality, you’re better equipped to speak up against it. Why do I post this on my mostly tech blog? Well, if a majority of tech workers is unaware of inequality and creates technology, we risk ending up with tech that reinforces inequality. That’s bad.

Sexism is everywhere and always

Laura Bates started the Everyday Sexism project, which collects experiences from women around the world. Misogynation is a collection of her essays about sexism, many of which draw from the experiences she collected as well as solid statistics. She answers a wide range of questions people may have about sexism, and provides excellent analysis of the phenomenon in the workplace, on our streets, at home, in healthcare, in politics and in education. I admire how she combines serious and humorous. Many feminists, Bates explains, get attacked for being ‘oversensitive’ and ‘too negative’, but this kind of response ’normalises and engrains the treatment of women as second class citizens, opening the door for everything else’. Yes. Providing an enormous range of examples, Bates shows that gender inequality is very real, often pretty ridiculous and that we should and can fight it successfully.

Misogynation by Laura Bates (for some of the essays, see also: Laura Bates on sexism in The Guardian)

Racism is a system

Teaching workshops about racism in workplaces around the world, Robin DiAngelo noticed certain patterns in the attitudes of white people when confronted with racism and their part in it (everone has a part in it). They get defensive, angry and upset. She calls this white fragility: the phenomenon of white people unable to deal their racial stress. It’s painful to read about this, especially when compared to the actual problem: the experiences of people who are affected by racism itself.

Racism is not a badly intended person being racist to another per se, it is the system, DiAngelo explains. It is our society in which wealth is not equally distributed between people from different races, and in which prejudice is concealed in euphemisms like “bad neighbourhood”. That system is shaped best for white people, therefore it you are white you benefit, whether you like (or want) it or not. DiAngelo explains it much better than I can, so I would really urge you to pick it up, and/or read Alice Bartlett’s notes about White Fragility, which inspired me to read it.

White fragility: why it’s so hard for white people to talk about racism by Robin DiAngelo

Blame the liars, not the lied to

James O’Brien is a radio presenter who talks to people phoning in from all across the UK. He found that a lot of his callers have been lead to believe falsehoods by cheap journalists that prioritise clicks and paper sales above truthseeking. His book How to be right in a world gone wrong is fundamentally about challenging their bogus arguments. This takes patience and confidence, neither of which O’Brien lacks in. If we don’t share them, we owe it to ourselves to challenge beliefs, myths and lies about subjects like LGBT rights, islam and Brexit.

Blame the liars, not the lied to, is the lesson in this book: O’Brien blames the media more than individuals who rely on them. If you can stand it that O’Brien is sometimes a bit full of himself —I think he does sufficient self-reflection, but that may be me being a non-native speaker of English— this is a very entertaining read. It may help in convincing less enlightened family, friends or acquaintances.

How to be right in a world gone wrong, by James O’Brien

A British perspective on race

In Why I’m no longer talk to white people about race, Reni Eddo-Lodge confronts us with a comprehensive account of the history of (British) racism and slavery, and describes heartbreaking accounts of racism in cities like Bristol. The reason that this is important, she explains, is that too many (white) people think there is no racism problem, which is largely because history of racism isn’t taught in most British schools and people don’t do enough self-study. If the title puts you off, definitely read it. The problem of talking to white people about race, Eddo-Lodge explains, is that they tend to not accept racism exist and make it about themselves instead. That wastes the time of people who want to fight racism, because they now need to spend it on arguments irrelevant to the actual issue. Eddo-Lodge kindly takes the time to articulate why there’s no such thing as reverse racism (true racism requires power) and what’s wrong with being colour blind (‘I don’t care which colour people are’ can easily be an attitude of denying racism, which only works if it doesn’t affect you, i.e. you have the privilege to be white).

Like DiAngelo, Eddo-Lodge explains the fight against racism isn’t one against specific persons, i.e. nobody should feel personally threatened. It is about racism as a structure that has devastating consequences for people of colour, including lower grades, less benefit of the doubt, lower pay and less representation in the media.

Why I’m no longer talking to white people about race by Reni Eddo-Lodge (see also: Eddo-Lodge’s original blog post)

Racist search engines and algorithms

When a friend told Safiya Umoja Noble to do an online search for ‘black girls’, she was shocked to see what other suggested terms came up, and how that compared to searching for, say, ‘white girls’. It is excruciating. In her book Algorithns of oppression, Safiya Umoja Noble shows numerous shocking examples of how search engines contribute to more racism. She seems to put the blame on companies like Google for capitalising on racism, but with Ockham’s razor in mind I feel that could be unrelated, wouldn’t anyone who tries to index the web, also index the racism on it? But that’s not the point: when the first few pages of many search results in the largest search engine reinforce racial bias, a lot of people’s online information gets racially biased. Search engines could do something about this problem and have both the technical possibilities and moral obligation. Especially because the problem is likely to be much bigger when applied to other algorithms. Racial bias in systems that make decisions for the police for example, for instance, see also Inspecting algorithms for bias in MIT Technology Review and When algorithms discriminate in The New York Times. The author’s point is solid, but I wasn’t a big fan of the argumentation or writing style.

Algorithms of oppression: how search engines reinforce racism, by Safiya Umoja Noble (see also: Safiya Umoja Noble’s TED talk)

Making of a man

Trans people get asked odd questions, philosopher/writer Maxim Februari explains in De maakbare man (in Dutch, translations available), so he decided to write this short book to answer some of them. While he’s at it, he also critiques various legal and administrative burdens trans people face, and how our world is shaped by specific norms when it comes to sex and gender. Februari’s first person account is a great introduction to transsexuality. Interesting notes on the absolute inappropriateness of certain questions, the difference between sex and gender and what some of his environment’s responses were to Februari’s transition.

De maakbare man: notities over transseksualiteit by Maxim Februari (Dutch, available in English as Making of a man)

Are identities a lie?

People feel part of their identity, behave according to it and are treated in specific ways because of it. Yet, as the Ghanese-British philosopher Kwame Appiah shows in The lies that bind, reality is more complex than identities based on gender, class, creed (religion), colour, country and culture suggest. They bind people together, but they are also made up. In his very eloquent book, Appiah shows that none of these concepts refer really to one thing: there’s no such thing as having an English, gay or Muslim identity, because all three can vary wildly depending on time and place. He can know it, as someone who has many different identities. While many of the books in this list talk in terms of identity, this one provides excellent and thought-provoking analysis of what that means.

The lies that bind by Kwame Anthony Appiah (see also: Appiah’s Reed lectures about the same subject, also available as a podcast)

Originally posted as Equality: a reading list on Hidde's blog.

[email protected]?subject=Reply%20to:%20Equality: a reading list">Reply via email

Managing accessibility in open source CMSes: a write-up

2019-09-03T00:00:00Z

Last week, I attended a meetup that was about the accessibility of not just one CMS, but two: WordPress and Drupal. It brought together people from both communities to talk about their accessibility efforts. Because CMS accessibility can make a huge difference. It was kindly organised by Level Level, a WordPress consultancy in Rotterdam.

Disclaimer: I work on authoring tool accessibility at the W3C/WAI, this write-up is in my personal capacity, views are, as always, my own.

Short introductory talks were given by Rian Rietveld, former WordPress accessibility lead, and Mike Gifford, “godfather of Drupal accessibility”, who visited from Canada. They talked about how they moved their respective communities towards doing (a lot) more work on accessibility.

Rian and Mike

WordPress and catching up (Rian)

Rian explained that back in 2011 a lot of accessibility discussions in WordPress were still of the “why is it important” and “raising awareness” kind. Rian wanted it all to be more practical and focused on getting things done. The time seemed right, because more people got interested in the subject, partly because accessibility legislation was about to get stricter. Something else that helped was that the WordPress Slack community just started and turned out to be great for facilitating conversations. In 2016, WordPress announced:

All new or updated code released into WordPress core and bundled themes must conform with the WCAG 2.0 guidelines at level AA.

(see: WordPress goes WCAG)

Things got complicated around the release of Project Gutenberg, a new block based content editor. It was pushed by Automattic, the company of WordPress’ inventor Matt Mullenweg that also dedicates a lot of its developers to WordPress core, as it would strategically bring WordPress in line with other modernised forms of content editing. This type of content editing is hard to get right.

For the accessibility team, Gutenberg was extremely tricky, Rian explained, because of the process: first features were developed, then designed, then accessibility checked. This order of things made that the accessibility team would always have to play catch up, in a fast moving project. The accessibility team warned about issues in the editor from the very start, but it was hard to catch up with the speed of development and convince people of the need for accessibility. Rian left the team when it became clear that Gutenberg would be included into WordPress without the accessibility issues addressed.

An accessibility audit of the Gutenberg editor was then crowdsourced, hundreds of issues were found and filed in GitHub. They are being addressed, but there are still many issues, and the catch up problem seems to have remained unsolved. Monique, who is in the core design team now, mentioned that she notices more designers and developers ask accessibility questions earlier on in the process, which is hopeful.

Others mentioned the active accessibility community on WordPress Slack, that makes a difference by checking core code as well as plug-ins and themes. This is something WordPress has had for a while, but it is still “catching up” rather than “considered from the start”, which one would hope WordPress would do more, as it often ends up being cheaper and easier. The WordPress governance project, that includes accessibility, may help with this, and improve how the efforts of the accessibility team are supported.

Drupal and ATAG (Mike)

Mike talked about how, in 2008/2009, he started looking into Drupal accessibility, because he had known people in the disability rights scene for years and wanted to apply what he knew to Drupal. He filed accessibility issues, and found it oddly addictive to tag them and get them in the issue queue.

Mike explained that, some years ago, Drupal’s founder Dries Buytaert had identified a number of “gates” for Drupal quality control:

Core changes must pass through a series of “gates” to ensure their quality is up to standards. Gates are essentially “checklists” that can be used to evaluate a patch’s readiness, by both developers and patch reviewers/core committers.

(see: Drupal core gates)

Accessibility is one of those gates, others include performance and usability. Needless to say, being one of the gates helped ensure accessibility throughout the ecosystem.

Drupal publicly committed to being WCAG AA, see Drupal’s commitment to accessibility on Dries Buytaert’s blog. Mike said accessibility work in Drupal was focused on not just the front-end, but also the back-end (just like in WordPress): they want to make Drupal itself accessible. The standard to follow for that kind of accessibility is ATAG, which Mike put a lot of effort in promoting within the Drupal community.

For those who are unfamiliar, ATAG has two parts: part A is about accessibility of the CMS so that content editors with disabilities can use it, part B is about improving the accessibility of output, so that web users with disabilities can use the resulting website. In Drupal 7, Mike said, they more or less met part A of ATAG, in Drupal 8, they tried to incorporate as much as possible of part B.

A major driver for improving accessibility in Drupal, Mike explained, was the idea of scale: rather than do work to fix one website, they did work to fix a platform that is used on 3% of the web. Yes, this is awesome about making CMSes more accessible: you’re potentially improving a lot of sites at once. This also gives the team some leverage when, say, talking to a browser vendor about a specific bug, then you would normally have as the owner of just one site.

Challenges and solutions

After hearing Rian and Mike talk about their experiences in their respective community, we talked about various interesting subjects:

is it possible to educate all developers in the world about basic accessibility, or should we ensure that’s built into libraries and CMSes? The latter could be super effective and help teach people where they are
adding to the previous question, Mike said governments could take this up: as they use a lot of open source software and are paid with tax money, why not spend some of their resources on contributing accessibility improvements (as in: code) back to the open source projects they use?
in procuring websites and CMSes, is it sufficient to ask for WCAG compliance? Mike suggests to ask more questions than that, see his Accessibility Contracting Best Practices
what’s the role of ATAG in this? Mike said we give content editors a lot of power, but not enough guidance. Implementing the B part of ATAG in CMSes can help here. It does seem harder to do than WCAG, he said, because the effects of (and investment in) ATAG improvements are much earlier in the process, they are about what it’s like for the content editor and how they are encouraged.
Mallory, in the audience, mentioned the work that Greg Whitworth is doing on standardising form controls, people were excited for the potential of this project to make one common accessibility issue go away
we talked briefly about Dragon Naturallyspeaking, an assistive technology that is often forgotten about when testing the accessibility of user interfaces

It was an interesting and constructive evening, with many experiences shared and plenty to think about. It’s clear that CMSes can play a huge role in making the web more accessible. One the one hand, for end users of the web: by encouraging and explaining content editors, implementing automated checks and high quality HTML output (this depends on many things, like templates used and also the very nature of WYSIWYG). On the other hand for content editors, by being usable for content editors with disabilities.

Originally posted as Managing accessibility in open source CMSes: a write-up on Hidde's blog.

[email protected]?subject=Reply%20to:%20Managing accessibility in open source CMSes: a write-up">Reply via email

Book review: Zed

2019-09-19T00:00:00Z

Zed by Joanna Kavenna is a dystopian satire, set in a future Great Britain, where a tech giant called Beetle runs most of society. Their ‘lifechain’ product is able to predict the future, which the justice department uses to prosecute people for future crimes (very Minority Report). They also deal in currency (BeetleBits), transport (Mercury cars), virtual assistents (Veeps) and VR (Real Virtuality).

Beetle’s CEO, Guy Matthias, is one of those tech CEOs that Sillicon Valley seems to have way too many of. Before he addresses a conference in Davos, he orders his robot to read Thomas Mann’s Magic mountain, and distill a funny opening from it. When he needs a date for a dinner party, he checks out the expected success rate.

Beetle takes pride in that they’ve created a reality where everything can be predicted and determined by smart algorithms… except it can’t, it sometimes fails. Of course it does. Those who insist we should compute every aspect of our lives clearly fail to truly understand every aspect of our lives.

Zed is an excellent novel about what could go wrong if big technology corporations have too much power and not enough humanities majors in their leadership. It is very resemblant of the real world: Facebook who want to introduce a currency, Uber who try to reinvent transport… the list goes on.

Someone on Goodreads called it ‘the fictional extension of Zuboff’s Surveillance Capitalism’, which I think is apt. I would warmly recommend this to people who are interested in a critical look at the tech industry. See also the review in The Observer.

Originally posted as Book review: Zed on Hidde's blog.

[email protected]?subject=Reply%20to:%20Book review: Zed">Reply via email

Notes from the Internet Health Report 2019

2019-09-21T00:00:00Z

This week I read (the print-version of) the Internet Health Report 2019, published by the Mozilla Foundation about issues that potentially stand in the way of a web that ‘puts people first’. With the phrase ‘putting people first’, the report means ensuring aspects like safety, openness, inclusion and control. Some of these things improved in the past years, some less so than one would have hoped.

I read it by the waterside on my holiday

The Internet Health Report is edited by Solana Larsen for Mozilla Foundation and puts together input from hundreds of readers and experts in an extremely readable format. Or multiple formats, really, as there is the website, the ebook and (new this year) a printed edition. The print version definitely helped me read the full thing. Everyone is invited to participate:

this publication is neither a country-level index nor a doomsday clock. We invite you to join us in assessing what it means for the internet to be healthy, and to participate in setting an agenda for how we can work together to create an internet that truly puts people first

(From the README)

In his update, Mozilla Foundation’s Mark Surman calls out three things that improved: calls for privacy are becoming more mainstream, people start to speak up about and work on more responsible AI and a healthy discussion about big tech is taking place among more and more people. Some things also got worse, Surman writes: there is more internet censorship, biometrics are being abused and increased AI usage specifically affects minorities because of bias, despite efforts like ethics boards.

This post has some of the things that piqued my interest, with links. For the full content, including all sources and links, get the printed edition or visit the Mozilla Internet Health Report 2019 website, where you can read everything or just the things you’re interested in. There is also a PDF of the short version.

Data: this year’s spotlight

In the spotlight section, the Internet Health Report features three articles that all have something to do with data.

AI

‘Use of AI is skyrocketing (for fun, as well as for governance, military and business) and not nearly enough attention is paid to the associated risks’, says the report. Governments start to use AI in military, for immigration decisions and for surveilling citizens, places one can imagine (racial) bias can cause serious harm. OpenAI decided not to release a trained data set as they worried about malicious uses of the technology. Some companies founded ethics boards to govern their AI usage, but they are often big companies with, inevitably, competing priorities. See also: Let’s ask more of AI

Cities

Data is useful for cities to base their policies on, and are somewhat envious of the ‘data monopoly’ big tech companies like Uber and AirBnB have. Some only give permission to do business on the condition of getting access to businesses’ data. See also: The power of cities

Paying for products with your personal data threatens freedom and human rights, because the algorithms that let companies do targeted advertising, can also be exploited by people with bad intentions. Some change is happening: Facebook, Twitter and Google all took some action against abuse after public pressure and new legislations. Lots of browsers now protect against tracking and/or block ads. Companies also start to realise targeting and knowing everything about everyone doesn’t necessarily make them more effective. See also: Rethinking digital ads

Safety

More and more awareness around privacy on the web is raised; by the campaigns of non profits like the EFF and Mozilla, but also by numerous data leaks that got into mainstream news and GDPR, the European data protection legislation that affects pretty much all businesses that are online. Tracking protection has become something browsers compete on (Firefox and Safari are ahead in this game), and even Facebook’s CEO announced that they now care about privacy.

While anonymity online can be abused by criminals, it is also absolutely worth defending and an important tool for whistleblowers reporting on corruption, or for people whose government oppresses them. See also: In defense of anonymity
If you don’t want big tech to have your data, you just don’t give it, right? Well, Katarzyna Szymielewicz has a useful metaphor of three layers of data: the first is data you share and control, the second is behavioral data and metadata that others collect (if you want to control this, you need expertise) and the third is what machines think about you (we have no control, because they are the result of companies combining data with algorithms we often can’t see). See also: Show me my data and I’ll tell you who I am

Openness

The web has always been fundamentally open. Imagine starting a new website required a government issued permit, or that getting onto any website required a certain kind of education, nationality or payment… Worldwide, this openness is threatened, as there exist walled gardens, social media taxes and shutdowns.

Governments who want to frustrate their citizens’ communications used to turn off the whole internet, but this was relatively easy to detect (for instance, by organisations protecting human rights), so they try out other tactics, like shutting down the internet in just one region or slow it down instead of turning it off. See also: Internet slowdowns are the new shutdowns
Various African countries now have taxes on using social media and messaging apps (Uganda), VOIP (Zambia) and even blogging and vlogging (Tanzania). See also: Taxing social media in Africa
Germany implemented a law against online hate speech and harrassment, which can force social media companies to take down certain content. Some call for web companies to be open about who reported content and how complaints are handled. See also: Inside Germany’s crackdown on hate speech
Wikidata, a project by the non-profit behind Wikipedia, offers lots of volunteer-created structured data. Technology firms who make voice assistants get a lot of value from this. Despite that, vast majority of donations is still from individuals, and only 4% from corporations. See also: Wikidata gives wings to open knowledge

Inclusion

Is the internet a level playing field yet for people from all backgrounds? This question has multiple sides to it: it is about how online communities fight harrassment and abuse, and about the working conditions of people who make internet hardware.

Women and women of colour in journalism are (still) much more likely to be harrassed online than men, various study showed. See more: Women journalists feel the brunt of online harassment
Contributors to open source projects that power a lot of the world are often a homegeneous group. That’s bad as code is not neutral and i.e. biased towards the people who write it. Strictly enforced code of conducts are appreciated by underrepresented groups, have helped community members call out bad behaviour and are therefore a helpful instrument in trying to make open source communities more diverse. See also: Codes of Conduct now guide open source communities

Web literacy

Do people understand the web well enough to make informed choices about things like sharing baby photos and recognising fake news? Do we understand it well enough to use it to people’s benefit, for example as a platform for activists to collaborate on?

3101 people from 124 countries worked together analysing footage, interviews and expert analysis in a project called Decoded, to show that the US-led coalition’s bombing of the Syrian city of Raqqa costed not 23 civilian deaths, but over 1500. See also: Decoding images of war in Syria
User tracking and targeting employed for manipulation of public opinion with fake news threatens democracy. Cambridge Analytica was not only involved with influencing the British and US electorates, but also worked in many other countries, including Kenya, Brazil and Mexico. For this year’s European Election, Google, Twitter, Facebook and Mozilla pledged to do somethimg about this, signing the European Commission’s Code of Practice on Disinformation. See also: The challenge of democracy in the digital era
Are we addicted to the internet? Research that showed Americans spend 6 hours a day on their devices and (other research) showing maintaining a user’s attention as a design principle seem to suggest so. That’s probably not time well spent. In the meantime Apple and Facebook introduced features to limit screen time. See also: Breaking free of the addiction machine

Control

Should the web be controlled by few or many? In other words, should power lie with a couple of companies that everything centers around, or do we want the web to be more decentralised? The Internet Health Report 2019 contains lots of good arguments for decentralisation.

There’s the question of ‘who (literally) controls the internet’. The cables deep under the sea that make the web work used to be built by telecom cariers in the early 90s, but are now invested in by private companies like Google, Facebook, Amazon and Microsoft (who, in 2018, owned or leased over 50% of these cables between them). See also: The new investors in underwater sea cables
For Uber, and many ‘unicorn’ companies like it, the structure of ‘everything (taxi rides, etc) goes through our company’, ie centralisation, is what gets their investors’ hope for returns up. Fine, that’s capitalism. But the model gets in the way of others providing alternatives or putting users in control. This is an issue when such companies have become utilities, says Nathan Schneider. These companies would probaby do things very differently if their users owned them, in which case they would only have to consider user interests. See also: What if Facebook were owned by its users?
The largest five internet companies make money by selling user’s attention to advertisers (Google, Facebook and Baidu), selling devices (Microsoft and Apple), being a middle man (Amazon and Alibaba) and doing lots of things from payments to in-app purchases to ads (WeChat parent company Tencent). See also: How do the biggest internet companies make money?
Nextcloud is an effort to create an open source cloud, but unlike with traditional open source software it is not cheaper (free) compared to alternatives, it costs more (because you need to pay for hosting somewhere). See also: An open source alternative for “the cloud”

I learned a lot from reading the Internet Health Report 2019, from great new initiatives to serious problems that I wasn’t aware of. As a reader of this blog, I invite you to dive in yourself, too!

Originally posted as Notes from the Internet Health Report 2019 on Hidde's blog.

[email protected]?subject=Reply%20to:%20Notes from the Internet Health Report 2019">Reply via email

Breaking barriers with your CMS

2019-10-21T00:00:00Z

A couple of weeks ago, I joined the Fronteers Jam Session to talk about something that I’ve been working on in the last couple of months: the ways in which CMSes can bring accessibility benefits. This is a written version of that talk.

Note that these are just some examples of things that CMSes can do… truth is, I only had ten minutes. But still, I’m hoping more people will think of CMSes as accessibility accelerators, as there is lots of potential!

From one block of content to lots of content blocks

As an industry, we have gotten a lot better at designing content on the web since the early days. Away are the times of boring looking documents with little white space and ineffective typography.

We have gotten better at web design since this.

Part of why we got better, is that modern CSS has gotten some exciting new features in recent years. We now have things like variable fonts, HSL colours, blend modes and floats that are not rectangular. And of course, there’s this now widely supported new lay-out mode: Grid Layout. It lets us be intentional about white space. We can lay content out in ways that we truly did not have before.

Something else that has changed is how we thing about what we are designing. Thanks to the work of people like Alla Kholmatova (Design Systems) and Brad Frost (Atomic Design), we have, as an industry, started to think about our work in terms of components or patterns… distinct pieces of functionality, rather than full, all-encompassing pages.

This leaves us with a new content management challenge. Previously, these long documents could be edited with one big block of WYSIWYG-text. Components require something different, you would probably create fields for every bit of data they contain.

A teaser component might have fields for a title, sub title, call to action text and link destination, for instance. For front-end developers, that might mean you can have all this data as strings, and wrap it in whatever HTML makes most sense. This isn’t necessarily new or recent, many CMSes have had this option for years, and it is has become the standard in headless systems. But still, many large organisations don’t.

Example component-specific edit screen

There is also a different content management trend that addresses our new component-based world: visual editors. Or, as they’re sometimes referred to: “no code editors”. This might sound worrying to all front-end developers, because when you wrap markup around data, you can do all sorts of good for performance, code quality and accessibility. Having a system deal with all of that automatically is… scary? And what about accessibility specifically, what if this harms actual users?

I could turn this question around… what if CMSes benefit actual users, by having accessibility built in?

The accessibility standard for CMSes

Accessibility standards consider CMSes as part of a larger group, that also includes other tools, like Learning Management Systems (LMS), wikis, social media, WYSWIYG editors, ”Save as HTML” functionality… basically everything that creates web content or facilitates the creation of HTML. These tools that create web content are also known as authoring tools. They can potentially improve a lot of accessibility at once.

Among a number of standards and specifications, the W3C has published three standards for web accessibility (“Accessibility Guidelines”):

WCAG is for web content, adopted by governments worldwide
UAAG is for browsers (“user agents”)
ATAG is for authoring tools, like CMSes

So yes, there is a standard specifically about the accessibility of authoring tools, including CMSes and other things that produce HTML (see also: ATAG: the standard for accessibility of content creation).

There are two things that ATAG requires from CMSes: they should be accessible themselves (i.e. work for people with disabilities), and they should encourage accessibility (i.e. produce and assist content editors with producing accessible output).

The editing experience

Creating an accessible editing experience means that people with disabilities have no barriers to create content: they can use the buttons, understand relevant context and access the interface with the input method that works for them.

To give some examples, and yes, these also exist on websites that are not CMSes:

Accessible names: A common accessibilitity issue is that the buttons in the interface are visually just icons. To make those work for users of assistive technologies, it is important that they have proper labels or accessible names. More about this in Naming things to improve accessibility
Keyboard accessibility: Something else that is common in CMSes is that they require a mouse to be fully used. By ensuring keyboard accessibility, you can make the interface work for various groups of people. This includes indicating what has focus. See also: Indicating focus to improve accessibility
Zooming: Some users will be using the CMS interface with their screen set to zoom in considerably, say 200 to 300 percent. This works well in the type of text documents I discussed at the start. On the web, text just reflows. It becomes more tricky in complex CMS interfaces, because there could be floating and sticky things that overlap with content when zoomed too much. See: Test content scaling

An interesting overview of what accessibility issues could look like in a real CMS is the crowdsourced accessibility audit that was done for WordPress’ new Gutenberg editor. As someone who is interested in the accessibility of content management systems, I am grateful that this was released publicly, this way everyone can learn.

The output

Apart from breaking barriers in the editing experience, we can also break barriers for users of the actual website. If we improve how HTML is produced by a CMS, we can potentially make a difference for all pages and sites produced by it.

Alt attributes

Most front-end developers will be aware images require alternative text in their alt attribute (or a conscious decision to leave it blank). Yet lots of websites lack it on some of their images. I don’t think this is because people aren’t aware of what the alt attribute is for. This could simply be a responsibility issue: the developer only built the template, the content editor only used the template, etc… Somewhere in between the attribute did not get shipped to the user.

The CMS could be smart about this. It could:

throw an error for missing alt attributes when an editor saves a page
provide information on what makes a good alt text
come with a checkbox that says “This needs no alternative, it is a decoration or already covered in other text”
throw an error if someone tries to link an image that has no alt (because alt attributes can become link texts)

Spelling

If you’ve accidentally used “Swbmit” as a button text, that might not impact visual users so much, as they will probably see from the visual context what the word should be. For someone using a tool like Dragon NaturallySpeaking, which lets users tell their computer which buttons to click, the mismatch could be more problematic. For someone who uses a screenreader, it could also be annoying to have misspelled content, because if it is misspelled, it will get mispronounced , too.

What if the CMS had a built-in spelling checker? That way, we could identify issues before they exist, and fix them before they get shipped to the user.

Colour contrast

When your site uses that design pattern where there is a text layed over a photo, it matters a lot what the photo is. Is it a dark-ish photo with light text on it, or are text and photo both light? The latter could lead to super low contrast, and with that, barriers for all sorts of users. This can affect people with various kinds of visual impairments, but also people who are outside in the sun, or those who have turned Brightness on their phone down to safe battery life.

Colour contrast issues can be programmatically detected, so why not do it right in the CMS? After uploading a new header image, the CMS could do a quick contrast check and display an error if the page no longer meets the criteria. Again, we could identify issues before they exist, and fix before shipping.

Whether it be with automated checks, carefully crafted content editing screens, extensive documentation of accessibility features… if we manage to bring some of our accessibility fixing to the CMS, we may be able to prevent barriers from shipping to users.

Conclusion

As front-end developers, we are all involved in the creation of web content. With this post, I hope to have given some examples of how CMSes can help create more accessible web content. Of course, it is just a couple of examples… but I think there are CMS-based solutions like this for a lot of different accessibility problems that we see on the web today. To be continued!

Originally posted as Breaking barriers with your CMS on Hidde's blog.

[email protected]?subject=Reply%20to:%20Breaking barriers with your CMS">Reply via email

Tech vs society: a reading list

2019-12-03T00:00:00Z

Within the bubble of technologists, the future looks bright and exciting. Outside of it, worried scholars and publicists have written a lot of books about the dangers of Big Tech, surveillance and the power of the market. This is a list of some interesting reads to better understand the impact of technology on society.

This may sound depressing, and it is, to some extent. The world is doomed and it is technologists’ fault! But when we understand better how technology, the tech sector and “computational thinking” fit in the context of society, it will get easier to decide whether we should push back.

As always, this reading list is what I happened to read on the subject, there are lots of other interesting publications out there.

How power dynamics changed

I already wrote about The Age of Surveillance Capitalism before, but I wanted to re-include it here. This book really ought to be the first item on a list of books about how tech impacts society. It defines “surveillance capitalism” and shows its workings in great detail. As I said in my review, it is not a quick read, but absolutely recommended for anyone who works in tech. We’ve got to understand this if we want to make things right.

The Age of Surveillance Capitalism by Shoshana Zuboff

A critique of “disruptive” technologies

In his fantastic Radical Technologies, “to be played at maximum volume” as the last page says, Adam Greenfield explains and critically evaluates a wide range technologies that are supposedly the future, including internet of things, augmented reality, blockchain, 3D printing and machine learning. His angle is not “wow, exciting!”, but ”what is this, is it really as good as promised, and how will large-scale deployment impact society?”. I wish we would all adapt the same mindset when assessing new tech, because there are many reasons to oppose these “radical” technologies. Blockchain doesn’t scale, internet of things devices have major security and privacy implications and machine learning is, despite many practical applications, often not fully misunderstood (as people tend to forgot that data is not neutral, not objective and always a subset of reality). The book ends with a number of future scenarios, ranging from utopias to dystopias, which help ask the question: “what do we want a tech-driven society to look like?”

Radical Technologies by Adam Greenfield

Has Big Tech lost its soul?

Many of Silicon Valley’s big companies once started with idealistic mantras and values, like ‘Don’t be evil’ and ‘Information wants to be free’, but the tide has turned. The book shows how (excerpt from the cover):

a world where “information wants to be free” became one in which we are the product being monetized, how the geeks tinkering with motherboards in their basements grew to be arrogant billionaires monopolizing the lion‘s share of the economy, and how the “democratized” internet we were promised can threaten the very fabric of our democracy.

Foroohar brilliantly explains where it went wrong. Tech companies made their products extremely addictive with the help of behaviorist psychology. Secondly, they have become monopolies in ways we haven’t seen before by both creating the market and operating in it. Thirdly, they got heavily involved in government with far-reaching lobbying for tax cuts and deregulation and by lending their targeted advertising platforms (as well as their consultants (!) for advice) to political campaigns. All of this is enabled and strengthened by surveillance capitalism.

Foroohar backs up her arguments with extensive research, and provides solutions, too. Is it depressing? Well, slightly, but it certainly left me with the feeling that having the picture painted so clearly will help address it.

Don’t Be Evil - The Case Against Big Tech by Rana Foroohar

What government surveillance looks like

The extent of Big Tech’s collection of personal data may be extraordinary, but the government’s mass surveillance programs are as disturbing, as Edward Snowden’s 2013 revelations have shown in great detail. In Permanent Record, Snowden tells two histories: that of his own growing up and that of how the intelligence community (IC) got more and more powerful after 9/11. I found the personal stories interesting, the analysis thorough and the details thought-provoking. He makes useful semantic distinctions; for instance, he explains how metadata is more intimate than content data, because we create it unknowingly, rather than thoughtfully. The book is full of wordplay… a “permanent record” is what this book is of Snowden’s life, but also what the intelligence communmity keeps of every citizen. “Hacking” is what Snowden used to do as a kid to minimise time spent on homework, but also what would become part of his work and revelations.

Permanent Record by Edward Snowden

The impact of tech company culture on society

Super Pumped is New York Times journalist Mike Isaac’s book about Uber. It gives detailed accounts of the company’s founder, culture and attitude. Three things that are are, it turns out, closely interrelated. The book’s odd name is literally one of Uber’s corporate “values”, and yes, I too was surprised to read that this company has those (given the plethora of scandals on so many different aspects of human dignity). There are the accounts of bad things that happened, but then there’s also how the company tried to cover those bad things by hiring prominent PR firms. I understand… every organisation above a certain size will have people who work to maintain and defend the company’s public image. Sure. But this book shows it clearly Uber doesn’t care, the company carries out an agenda that benefits few and hurts many, and has its bro-y culture leak into society in many bad ways. This has definitely put Uber on the top of my list of companies I would never want to work for.

Super Pumped by Mike Isaac

Political activism through technology

When an anthropologist studies a hacker slash activist movement, it might just yield a super interesting book about online culture. Hacker, Hoaxer, Whistleblower, Spy by Gabriella Coleman is a investigative study of Anonymous, with a look into what they do, want and think, completed with IRC logs, which I think were a great way to provide a look into online culture. Sometimes she talks a little too much about herself, but I feel it kind of works in this context. This book gives some interesting insights into Anonymous, the “lulz” and the motivations between some of the group’s core members.

Hacker, Hoaxer, Whistleblower, Spy: The Many Faces of Anonymous by Gabriella Coleman

Originally posted as Tech vs society: a reading list on Hidde's blog.

[email protected]?subject=Reply%20to:%20Tech vs society: a reading list">Reply via email

2019 in review

2019-12-20T00:00:00Z

Wow, the year only has 8 days left 😱! Time for a review, with some useless stats and links to things I worked on.

Like last year, I’ve divided this into highlights and things I learned.

Highlights

Projects

In the first half year of 2019, I continued my project at Mozilla’s Open Innovation team, building their People directory, and worked in the City of The Hague on accessibility and the internal design system.

In July I started a new project: at the W3C’s Web Accessibility Initiative (WAI), I am now working as part of the European Commission-funded WAI-Guide project. My work there is focused on improving the accessibility of/in tools that create web content, like CMSes. In short: we want more accessibility both for content editors (a good editing experience) and for end users (good output).

Apart from my work at the W3C, I’ve been doing the occasional WCAG audit and accessibility/CSS workshop in my own capacity too.

Speaking

Last year I spoke at my first conference. This year I got the opportunity to do new (and some older) talks in various places, of which some were as part of my project at the W3C/WAI.

In March, I did a talk called It’s the markup that matters at De Voorhoede. It was part of their Future Proof Components event, and covered building accessible components, accessibility trees and the AOM.

At WordCamp Rotterdam and Inclusive Design Ghent, I shared 6 ways to make your site more accessible, based on my experience looking at common accessibility problems that front-end developers can do something about.

In October, I presented a very short lightning talk at the Web We Want session at View Source Conference, about how some accessibility problems could cease to exist if browsers would automatically fix them. The problems: zoomability, readability, color contrast and focus indication (the first three are each solved in at least one browser, the fourth has not). This talk, shockingly, won both the jury and audience award.

Also in October was a talk called Breaking barriers with your CMS at the Fronteers Jam Session (on behalf of W3C/WAI). This presented some of my recent work at WAI: it explained ATAG and the role of the CMS in accessibility efforts.

At the Design in Government Conference in November, I talked about the case for web accessibility from philosophical ethics, again on behalf of W3C/WAI, and I did an updated version of my graphic design on the web talk in Dutch for Freshheads in Tilburg.

Then in December, I joined dotCSS to talk about the history of CSS: On the origin of cascades put some of that in a Darwin-themed talk. The venue was enormous and intimidating, and there was transport strikes, but the event itself was excellent, with a great atmosphere and very well organised.

I also did a number of in-house talks and workshops, about CSS Layout, ARIA and accessibility guidelines.

Reading

I read much more than last year (72 books so far), and have written more about books on this blog (see reading list about equality and reading list about tech and society). Reading more books helped me read less social media, watch less video and generally relax more. Please become my friend on Goodreads (it’s not great, but if more people join we can all share recommendations)!

Some notes:

Audiobooks are great as you can read them in situations where holding a book doesn’t work (e.g. walking a dog, housework)
To read more, finding the right books is half of the work (I mean, not literally… but it is important). I found more people to follow on Goodreads, keep a close eye on the literary supplements in the papers and love posts like 2018: books in review by Karolina Szczur.
Dutch libraries have ebooks and audiobooks that can be ‘borrowed’ via apps.

Writing

This year I wrote 24 posts (including this one), which means I have now over 100 posts in total on this blog.

Some posts that people found interesting:

On the importance of testing with content blockers
Component frameworks and web standards on my first experience using a front-end framework
Naming things to improve accessibility on the importance of accessible names in things like buttons, links and tables
Baking accessibility into components: how frameworks help: frameworks can get a bad name in the accessibility world, but I increasingly think when used by accessibility-aware developers, they can make things better, not worse
Meaning without markup: Accessibility Object Model: a primer on the Accessibility Object Model, a technology that is still under development and potentially interesting for a variety of reasons

I also contributed to the Mozilla Hacks blog, writing Indicating focus to improve accessibility and How accessibility trees inform assistive tech. Thanks to Havi Hoffman for the opportunity!

Cities

This year I traveled to Antwerp, Berlin, Bristol, Essen, Ghent, Nice, Paris, Taipei and Vienna, using trains where possible, but I need to do better at that.

Things I learned

Here’s some random things that I learned about in the past year:

Recently I started working on an app with Svelte, the front-end framework that doesn’t ship in its entirety to the user’s runtime, but tries to compile as much as possible to vanilla JavaScript. Small bundles, yay!
As I started my project at the W3C, I learned a lot the standards process, the dynamics in Working Groups and the bots that help run teleconferences.
A large part of my work centered around authoring tools, or tools that create web content, and how they can help bring more accessibility in the world.
I became increasingly aware of the role of surveillance capitalism in the world.
I learned to love AirTable as a way to organise and plan the non-coding parts of my work, which are becoming a larger part of the whole

In any case, I’d like to thank the readers of this blog for reading and sharing the posts I’ve published, it means the world to me.

I wish you all a great 2020!

Originally posted as 2019 in review on Hidde's blog.

[email protected]?subject=Reply%20to:%202019 in review">Reply via email

Could browsers fix more accessibility problems automatically?

2020-02-04T00:00:00Z

Last year, I was lucky to be selected to present at the Web We Want session at View Source in Amsterdam, to argue for something that’s bugged me (and others) for a while: browsers could be more proactive in fixing accessibility issues for end users.

This post is part write-up of that 5 minute talk, part new additions.

Outreach only does so much

The accessibility community produces lots of information about making accessible websites. Especially for folks who want to get the basics right, detailed info is out there. Sources like WAI, The Accessibility Project and MDN Accessibility have information on what to do as designers, developers and content creators.

This is great, but realistically, this guidance is only ever going to reach a subset of website owners. There are always going to be websites that do not include accessibility best practices, for all sorts of reasons. Whether it’s ill will or obliviousness, it impacts people’s ability to use the web effectively.

It would be pretty useful if browsers could give users the power to override the web, so that they can browse it better. They would then be less at the mercy of willing or knowing developers.

Note: I do not want to say browser features can remove the need for us to worry about improving accessibility. Usually, websites can make the best choices about accessibly offering their content. When it comes to responsibility for accessibility, it is the website’s, not the browser’s.

Can browsers fix issues when they find them?

Most web folks will be aware of WCAG 2.1, the internationally embraced web standard that defines what it means for a website to be “accessible”. The sources I mentioned earlier often refer to this document (or earlier versions of it). When we speak of an “accessibility problem”, there’s often a specific success criterion in WCAG that specifies it.

WCAG conformance is largely tested manually, but luckily we can detect some accessibility problems automatically. An interesting project to mention in that regard, is ACT Rules, a Community Group at the W3C. They are mostly people from accessibility testing software vendors, like aXe and SiteImprove, who work on rewriting WCAG as testing rules (paraphrase mine). While doing that, they help harmonise interpretation of the WCAG success criteria, in other words: find agreement about when some web page conforms and when it does not. Guideline interpretation is not trivial, see The Web Accessibility Interpretation Problem by Glenda Sims and Wilco Fiers of Deque.

Interpretation may not be trivial, there are issues that are pretty clear. There are some that we can get true positives for (note, this is a small subset of WCAG; useful, but small). So, if we can automatically find these issues, can we also automatically fix them?

What browsers could do today

There are some issues that browsers could fix automatically today. In my ideal world, when a website has one of those barriers, the user notices nothing, because the browser fixed it proactively. This is not a Get out of jail free card for developers, designers or content people, but more so one for end users, to improve their experience when they encounter inaccesibility.

For lack of a better metaphor, I imagine each of these features to exist as a checkbox within the browser. I’ll gladly admit this is somewhat oversimplified and high level, it is really just to make the point. Browser makers will likely solve these problems most effectively.

During my research, I found that some browsers already fix some of these issues. Yay, go browsers!

Force zoomability

Some users may depend on zoom functionality to read content. With the Apple-invented viewport meta-tag, web developers can disable zooming:

<meta name="viewport" content="user-scalable=no">

This may be useful in some edge cases, like in photo cropping or maps functionality. But often, it prevents what was a useful feature to some users.

Browsers could fix this automatically, for example via some sort of preference that bypasses the developer’s preferences in favour of the user’s.

This fix exists currently, as Apple does ignore the user-scalable directive in the latest versions of iOS (>10), and it seems some Android browsers do, too.

Force readability

Claiming that 95% of the web is text, Oliver Reichenstein once said:

It is only logical to say that a web designer should get good training in the main discipline of shaping written information

(from: Web Design is 95% Typography)

Plenty of websites out there aren’t great at “shaping written information” at all. There may be differences in taste and all, but some design decisions objectively make content illegible to at least a portion of users. Common problems include: light grey text on a white background, typefaces with extremely thin letters as body text and way too many words per line.

Browsers could fix such readability problems automatically, by forcing page content into a lay-out optimised for reading. Examples of browser features that do this:

Safari has had a Reader View for a long time, it lets you select fonts and colours and is marketed as allowing for distraction-free reading
Firefox Reader View, which will let you make some choices in typography, dark modes and can even speak the page content out loud so that users can listen instead of read
Microsoft Edge has Immersive Reader View (previously Reader View), which can, like Firefox, read aloud. It even has grammar tools, that will let you do things like highlight nouns.

Examples of reader mode: Safari, Firefox, Edge

Enforce contrast

When there is too little colour contrast in our UIs, they are harder to use for people with low vision and as well as people with color deficiencies. With contrast checkers (like Contrast Ratio), designers can ensure their work meets WCAG criteria like Contrast Minimum and Non-text Contrast. Still, whenever new content gets added, there’s a risk new contrast problems emerge. That text on a photo on the homepage could turn from super readable to hardly readable in a whim.

You might be getting the theme by now… browsers can deal with contrast problems automatically. Why not have a “enforce contrast” setting, that adds a black background to any white text, always?

It turns out, some browsers are already working on this, too! I was unaware when I prepared my talk. The basic idea is to fix contrast for users that use Windows High Contrast Mode (HCM). So, rather than the individual setting I suggested, it ties in with a related and existing preference. Much better!

The details:

Microsoft Edge’s solution is a readability backplate that could be behind all text when High Contrast Mode is on. Melanie Richards also mentioned this in her talk Effectively Honoring Visual Preferences at View Source 2019 (also goes into some great other colour-related accessibility features Microsoft are working on)
Firefox is also adding a backplate, see bug 153912, which works in HCM and uses theme background color. Firefox used to completely disable background images in HCM, which ensured lots of contrast, but also in losing potentially important context.

Fix focus styles

For many different kinds of users, it is important to see which element they are interacting with. As I wrote in Indicating focus to improve accessibility, focus indicators are an essential part of that.

Some websites remove them, which makes navigation with keyboards and some other input methods nearly impossible. It is a bit like removing the mouse indicator. CSS allows for doing either, but that doesn’t mean we should.

Browsers could fix this automatically! I would welcome a setting that forces a super clear focus indicator. Basically, it would activate a stylesheet like :focus { outline: 10px solid black; } (and probably a white outline for dark backgrounds), and boom, people who need focus indication no are no longer dependent on individual website’s willingness to provide it.

A simplified example of what “force focus indication” could look like

I am not aware of any browsers that implement this, but believe it could be an effective way to mitigate a common problem.

Update 26 April 2021: From Chrome 86, there is a Quick Highlight functionality that can be turned on in settings://accessibility. It will force focus outlines on any interactive element, even if the website didn’t provide any. The outline disappears after a few seconds.

Autoplay optional

There’s a number of potential accessibility problems with autoplaying content:

autoplayed audio can get in the way for screenreader users trying to navigate (see Understanding 1.4.2)
some autoplayed content can be in the way for people with attention deficit disorders (see Understanding 2.2.2)
certain autoplayed videos (notably with flashing content) could cause seizure (see Web accessibility for seizures and physical reactions on MDN).

Some websites fix this automatically now. Twitter disabled animated PNGs after they had been used to attack users with epilepsy.

Browsers could fix such issues automatically, too… what if they had a setting that would never allow anything to autoplay? It turns out, Firefox has a flag for this. In about:config, you can set image_animation_mode to none, or once if you prefer (via PCMag). For Chromium, there are plugins.

Block navigation

When every page on a website starts with a bunch of navigation and header elements, it can be cumbersome to users of some assistive tech. If you use a system that reads out web pages sequentially, you don’t want to listen to the navigation menu for every page you go to. 2.4.1 Bypass Blocks exists for this reason, and many websites implement it with a “skip link” (e.g. “Skip to content”) that lets users jump to the content they need.

Browsers can determine blocks of repeated content between pages, especially if they are marked up as labeled regions (see: Labeling regions). If a page has one <main> element, browsers could provide navigation to skip to that element.

Wrapping up

In an ideal world, websites ensure their own accessibility, so that they can do it in a way that works with their content and (sometimes) their brand. Website owners have the responsibility to make their stuff accessible, not browsers or other tools.

Yet, when websites ship with accessibility problems, browsers could fix some. They could automatically “fix” zoomability, readability, colour contrast, focus indication, autoplay and block navigation. If they did, users need to rely less on what websites provide them.

Originally posted as Could browsers fix more accessibility problems automatically? on Hidde's blog.

[email protected]?subject=Reply%20to:%20Could browsers fix more accessibility problems automatically?">Reply via email

More accessible defaults, please!

2020-03-01T00:00:00Z

Useful HTML elements like date inputs and <video> could make the web a much better place, if browser accessibility bugs in their implementations were prioritised.

On ‘the web is accessible by default’

I like to claim ‘the web is accessible by default’, a sentence that requires nuance (see below). Yes, the web is accessible by default in many ways. The fact that websites are made of text, structured text in most cases, allows for an amount of accessibility that print never had. We can enlarge it, copy paste it, feed it to translation software, have it read out by screenreaders… this is awesome, and very helpful.

But the web has become more than text, in 2020 it is a lot more than that. Websites and web apps now have videos, complex forms and clickable areas that are usually more than a couple of words to form a link. I would love to tell my clients that they can just use HTML, the language that has accessibility built in. More often, the answer is ‘it depends’, when people ask for solutions.

The components of an accessible web

An accessible web has many components, which all somehow circle around web content. On an accessible web, everyone can create and view web content. That’s the basic premise (and the basic promise). To get there, we need not just accessible content. We also need tools that can create accessible content (like CMSes), web standards that allow for marking up accessible content (like HTML) and tools that can display content accessibly (like browsers). We need developers, authoring tools, web standards and browsers to all play along, if we want the web to be accessible.

The browser part of the accessibility picture can have a huge impact. Last month, I wrote about the potential for browsers to automatically fix accessibility problems, in other words mitigate issues caused by inaccessible content. But what about content that is accessible in principle. but breaks ‘because of browsers’?

What browsers could do

In HTML, the inaccessible parts, Dave Rupert listed a bunch of HTML elements that have known accessibility problems in browsers, like date inputs and <video> . Developers use these elements because they trust the web to be accessible by default, their strategy is to stick close to the standards. That promise is somewhat broken for these specific elements.

In Dave’s article, there is a link with more details for each problem (recommended reading!). It somewhat shocked me to see all these issues in one list, even though I had heard about the majority. Basically, if any of those HTML elements are used, a browser displays the content inaccessibly, despite that the standard defined a thing that could be accessible, and developers implemented a thing that could be accessible.

It’s important for me to note at this point: browsers are complex beasts. Browser engineers are extraordinary people who work very hard to build all sorts of features that generally benefit the web. And, of course, we don’t just need an accessible web. We also need a secure web, a web with user privacy, a web with amazing graphic design capabilities (I love CSS Grid), a web that doesn’t lose market share to app ecosystems, a web that efficiently runs complex JavaScript applications, a web that’s fast, a web that can be a compilation target for Rust and C/C++, et cetera.

I should also clarify that while browsers might be breaking things in these examples, there are also plenty of examples where standards are inconsistent despite heroic efforts, or developers build things that cause nightmares for web compatibility engineers (keeping browsers compatible with the web is hard, explained Mike Taylor at View Source 2016).

So, with the caveats that browsers have many priorities, and that standards and developers can also cause trouble, let’s return to the issue of this post: inaccessible HTML elements in browsers. How can we mitigate these problems? Some of the issues can be addressed by web developers themselves with trivial code. If they have heard of the bug, not all developers will. For other issues, there are third party libraries, like AblePlayer for more accessible video. Again, it’s safe to say only a subset of developers is aware of the issues like those with <video> .

Browser makers are in a unique position to fix all of these particular issues for all, so that people with disabilities need to rely less on the willingness of individual developers to enjoy content. There are bugs filed against the relevant browsers, some of which have been open for over a decade, like the bug for keyboard accessibility for <video> in Firefox.

It would be so good if accessible rendering of HTML elements was prioritised more.

Some developments are happening:

There is some exciting work being done in Edge/Chromium to make the default rendering of form controls better
For elements beyond what exists in HTML today, my hopes are on OpenUI, a project of the W3C’s Web Incubator Community Group. They aim to standardise form controls and components in which, among other things, “accessibility, focus and other foundational items work as expected”.
Firefox has recently improved the accessibility of number input types

Wrapping up

Yes, there are lots of priorities beyond the rendering of HTML elements in browsers. Yet, I’d like to make the case for browsers to prioritise accessible implementations of HTML elements. If browsers implement these elements with maximum default accessibility, they can make improve a lot of the web platform at once.

As Eric Eggert said on Twitter:

We need a movement to fix the web platform to make those essential building blocks of the web accessible for all.

I’d like to join this movement, please! But really, I hope for browsers to support this movement.

Originally posted as More accessible defaults, please! on Hidde's blog.

[email protected]?subject=Reply%20to:%20More accessible defaults, please!">Reply via email

Minimum Viable Data Collection

2020-03-09T00:00:00Z

The gist of the EU’s General Data Protection Regulation (GDPR) is simple: protect citizens from data-hungry corporations. It gives people control over how their personal data is collected, as it requires website-owners to stick to a set of rules when dealing with people’s data (I’m paraphrasing). In short: it gives rights to citizens and duties to (digital) businesses.

Most websites in Europe have taken action to comply with parts of their duties, by implementing cookie consent banners. In the least bad scenario, the response of such website-owners was: let’s find out which cookies we set and which ones we allow others to set. Then ask users for permission and set cookies if permitted. So, basically, business as usual, but with a banner for explanation.

Of course, cookies themselves are not the problem per se. It is the broader strategy, which hardly requires cookies. It is to try and get as much information from users as possible and combining everything you can find, to create detailed profiles of website visitors. This is enabled by and helps enable surveillance capitalism, which threatens our societies and people in many ways.

What if website-owners used the logical opposite of that strategy? What if our industry championed… Minimum Viable Data Collection? This strategy would collect the minimum information from users. Maybe it would actively destroy and anonymise any personal data. You would find out what kind of tracking you do or enable (via third-parties) and reduce it. Ideally to zero. This strategy respects citizen’s rights much better.

Does this idealist blogger need more realism? Well, maybe. Let’s still explore this idea.

The current state of affairs

How do websites currently deal with their privacy-related obligations? Well, many ask permission to set cookies. Some use pointy formulations like ‘would you mind some cookies?’, completed with a picture of a cookie jar. Oatly, a company that makes vegan milk (yay!), is just of many going down this route:

“Cookies go nicely with oat drinks. As it happens, the digital kind do too. So is it okay with you if we use cookies on this site?”

These are sometimes funny and original, but, also, they indicate these companies do not see online tracking as a serious problem. That’s understandable, it’s a complex problem, maybe we can’t expect marketeers to do their homework. But isn’t this too important to be turned into a joke?

Why do websites track?

The amount of cookie banners in the wild may lead us to conclude: websites really need tracking to function. Yet they don’t. So why do websites track?

From the perspective of surveillance capitalist companies, the need for tracking is clear: their business is built upon it. Again, see Shoshana Zuboff’s The Age of Surveillance Capitalism.

What I’m interested in: why do website owners wilfully welcome bad trackers on their web properties? Surely, it would be easier to comply with data collection regulations by not collecting data at all? Minimum Viable Data Collection seems to be the most straightforward solution (Ockham’s razor!).

I think these are some of the common reasons why sites don’t focus on minimising data collection yet:

Unaware of the harm: Some organisations may not have read up the consequences of using whatever part of their tools come with naughty trackers. This is not a valid excuse, but it may explain a majority of cases.
User research: Often, website owners want to track users to inform their design decisions. Through A/B tests (which aren’t trivial to get right, or other quantitative UX research on live websites.
Social media: A lot of websites embed content from third-parties, like videos from YouTube. Some also include buttons that allow social sharing, like Tweet This buttons. All of these come with tracking code more often than not. It’s unclear if people actually use them (but it seems some do).
Data collection for marketing: Some websites, especially those in the business of sales (like hotel or flight booking sites), collect user data so that they can make better (automated) decisions on offers and pricing.

Instead of maximising consent, minimise collection

The question all website owners should be asking, is: do we really, really need these trackers to exist on our pages? Can’t we do the things we want to do without trackers?

I think in many cases we can:

Unaware of the harm: More awereness is needed. As people who make websites and know how tracking works, we have to tell our clients and bosses.
User research: Maybe prioritise qualitative research? Or urge vendors of this software to design privacy-first?
Social media: Social sharing buttons could just be regular links () with information passed via parameters. Video embeds could be activated only when clicked.
Data collection for marketing: Maybe just don’t? If trust is good for business, dark patterns are not.

The no tracking movement

Excitingly, some websites choose to avoid or minimise tracking already.

The mission statement

Privacy and accessibility expert Laura Kalbag describes why she chose not to have trackers on her site:

For me, “no tracking” is both a fact and a mission statement. I’m not a fan of tracking. (…) That means that you will not find any analytics, article limits or cookies on my site. You also won’t find any third-party scripts, content delivery networks or third-party fonts. I won’t let anyone else track you either.

(From I don’t track you)

Laura was inspired by designer and front-end engineer Karolina Szczur, whose personal website sports ‘No tracking’ in the footer. So cool, and very thoughtful.

Dutch public broadcasters go cookie-less

I was pleasantly surprised to see STER, the department that runs advertising for Dutch public broadcasters on tv, radio and internet, decided to go cookieless for all of their web advertising in 2020. Instead of profiling users, they profile their own content. STER classifies their content into 23 “contexts” (like “sport/fitness” and “cooking/food”). They then allow advertisers to choose in which context they want to promote their brand. Cool, they can be in the advertising business, offer contextual advertising spots, without the need for tracking all the things.

NRC: “our journalism is our product”

Dutch newspaper NRC also stopped using third party cookies, and takes a clear stance:

Our journalism is our product. You are not. So we do not sell your data. Never. To nobody. We do not collect data for collection’s sake. We only save data with a tangible goal, like dealing with your subscription.

From NRC privacy (translation mine)

I like the stance, but should note my tracker blocker still has to filter 5 known trackers out when I read the news (also goes for paying users).

New York Times: less targeting, more revenue

Last year, The New York Times swapped behavioural targeting for targeting based on location and context. This did not decrease their revenue. Jean-Christophe Demarta, Senior Vice President for global advertising at the paper: “We have not been impacted from a revenue standpoint, and, on the contrary, our digital advertising business continues to grow nicely.”

Digiday editor Jessica Davies:

The publisher’s reader-revenue business model means it fiercely guards its readers’ user experience. Rather than bombard readers with consent notices or risk a clunky consent user experience, it decided to drop behavioral advertising entirely.

(Emphasis mine; both quotes from: After GDPR, The New York Times cut off ad exchanges in Europe - and kept growing ad revenue)

Again, my tracker blocker found 3 trackers when I visited nytimes.com this morning.

For large scale websites, it seems minimising data collection is easier said than done. Currently, there may not be any large sites that are truly tracker-free (besides Wikipedia).

GitHub: “Pretty simple, really”

In 2020, code platform GitHub decided to get rid of their cookie banner,by getting rid of their cookies. CEO Nat Friedman writes:

we have removed all non-essential cookies from GitHub, and visiting our website does not send any information to third-party analytics services.

(from: No cookie for you)

This fits well within their values, Friedman explains, “developers should not have to sacrifice their privacy to collaborate on GitHub.” I’d still love them to stop working with ICE.

Wrapping up

It is a concept for mostly inspirational purposes, but really… I think minimum viable data collection can be a great strategy for businesses who want to comply with the duties of privacy regulations. The advantages:

you need to build less complex cookie consent mechanisms
users stay on your site as they are less frustrated
you can serve customers that use tracking protection (see below)
your company gets hundreds of internet points

To users who need to browse today’s web, I strongly recommend using a browser with strong tracking protection, like Firefox (has Enhanced Tracking Protection) or Safari (has Intelligent Tracking Prevention. For nerds who want to read more, check out the intelligent tracking posts on the WebKit blog, including Preventing Tracking Prevention Tracking or the Firefox Tracking Protection section on MDN.

Originally posted as Minimum Viable Data Collection on Hidde's blog.

[email protected]?subject=Reply%20to:%20Minimum Viable Data Collection">Reply via email

Uncanny Valley

2020-03-12T00:00:00Z

“It’s unfortunate that the world does not reward conciseness more. Making books shorter will effectively increase the rate at which we can learn.” This tweet from a start-up founder is quoted in Anna Wiener’s hilarious memoir Uncanny Valley, in which she tears apart the “dreary efficiency fetish” of the San Francisco tech scene, among other things. It touched me, because I love books and don’t want them disrupted.

At 25, Wiener left her life in Brooklyn, New York for San Francisco, to go work in the Valley. This book is her “memoir”. She was astounded by what she found: the constant gospel of work as the most important part of life, men who are overly confident about their own ideas, open bars, the 24 hour hustle, the dress code of company branded hoodies, God Mode, camping trips with no actual camping, childish company names, companies ran by people in their 20s, an office reception that is a replica of the Oval Office… the book is full of these on point details. Most of these phenomena were not new or shocking to me (as someone who works in tech), but I enjoyed Wiener’s liberal arts perspective on them. Her somewhat ironic tone works really well for this kind of thing, as it nicely cuts through the nonsense. I chuckled a lot. It’s not a 300 page rant, though, Wiener does not simply attack everything the Valley stands for (there are other books for that), it’s more subtle.

It also isn’t just irony and fun. Wiener also takes the time to discuss serious problems in tech, including the feeling of “not belonging”, both as a women and as a non-engineer (she worked in support, and apparently that’s lower in the hierarchy). When, for work, she attended the Grace Hopper Celebration of Women in Computing, she describes she doesn’t feel like a women in computing, “more like a women around computers, a woman with a computer”. The “young founders” aspect, besides great to poke fun at, is also a serious problem, when tech companies hugely disrupt society. Their leaders may not have enough life experience to see the full picture, yet they feel they do, because venture capitalists put them on a pedestal.

Uncanny Valley doesn’t name names, it offers descriptions instead. A great style choice, because the descriptions say much more than the actual names would have. They add a little bit of context. The social network that everybody hated, the data analytics startup where everybody wears company-supplied “I am data driven” t-shirts, the venture capitalist who had said ‘software eats the world’, the open source code platform and the highly litigious Seatle-based conglomorate (that ends up buying that code platform). Uncanny Valley is not about the specific companies, but about the culture and the kinds of companies.

The book has a special place for Silicon Valley thought leaders and what Wiener calls the “founder realism genre”: the blog posts they publish. Men, mostly men, give each other ‘anecdote-based instruction and bullet point advice’. You know the kind of Medium post. Not all men, not all Medium posts, but you get the idea. Founders who are convinced everything needs the type of efficiency they specialise in, while shielded from the consequences of their own transformations. Founders indifferent to some of the big problems of our time: inequality strengthened by their business models, hate speech amplified by their platforms and mass surveillance enabled by their data, In an interview with Vox, Wiener says:

Silicon Valley is a culture focused on doing, not reflecting or thinking.

Reflecting is essential, and the Valley could do more of it. Wiener reflects also about herself, her life and her career choices. Wiener seems to like and understand the people she meets, truly tries to figure out what motivates them and isn’t just ranting about them. For her, it seems to be a love/hate relationship, with quite a bit of both. That makes this book so strong.

Recommended reading! If you want to learn more, see the interview with Anna Wiener at the Strand Book Store, listen to Anna Wiener at Recode/Decode or go to the book’s website.

Originally posted as Uncanny Valley on Hidde's blog.

[email protected]?subject=Reply%20to:%20Uncanny Valley">Reply via email

How deployment services make client-side routing work

2020-06-27T00:00:00Z

Recently I deployed a Single Page Application (SPA) to Vercel (formerly Zeit). I was surprised to find that my client-side routes worked, even though my deployment only had a single index.html file and a JavaScript routing library. Here’s which ‘magic’ makes that possible, for if you ever end up needing the same.

How servers serve

In the most normal of circumstances, when we access a web page by its URL, it is requested from a server. This has worked since, I believe, the early nineties (URLs were more recently standardised in the URL spec). The browser deals with that for us, or we can do it in something like curl:

curl GET https://hiddedevries.nl/en/blog/

We tell the server “give me this page on this host”. To respond, the server will look on its file system (configs may vary). If it can find a file on the specified path, it responds with that file. Cool.

Now, If you have a Single Page App that does not do any server side rendering, you’ll just have a single page. This is, for instance, what I deployed:

public
- index.html
- build
  - bundle.js
  - bundle.css
- images
  - // images

Let’s say I deployed it to cats.gallery. If someone requests that URL, the server looks for something to serve in the root of the web server (or virtual equivalent of that). It will find index.html and serve that. Status: 200 OK.

Client side routes break by default

Our application is set up with client side routing, but, for reasons, we have no server side fallback (don’t @ me). It contains a div that will be filled with content based on what’s in the URL. This is decided by the JavaScript, which runs on the client, after our index.html was served.

For instance, there is cats.gallery/:cat-breed, which displays photos of cats of a certain breed.

A British shorthair - photo by Martin Hedegaard on Flickr

When we request cats.gallery/british-shorthair, as per above, the server will look for a folder named british-shorthair. We’ve not specified a file, the server will look for index.html there. No such luck, because we created no fallback, there’s just the single index.html in the root. If servers don’t find anything to serve, they’ll serve an error page with the 404 status code.

It does matter how we’ve loaded the sub page about British shorthairs. Had we navigated to cats.gallery and clicked a link to the British shorthair page, that would have worked, because the client side router would have replaced the content on the same single page.

How do they make it work?

One way to fix the problem, is to use hash-based navigation and do something like cats.gallery/#british-shorthair. Technically, we’re still requesting that index.html in the root, the server will be able to serve it, and the router can figure out that it needs to serve cats of the British shorthair breed.

But, we want our single page app to feel like a multi page app, and have “normal” URLs. Surprisingly, this still works on some services. The trick they need to do is to serve the index.html file that’s in our project’s root, but for any route. Want to see British shorthairs? Here’s index.html. Want to see Persian cats? Look, index.html. Returning to the home page? index.html for you, sir!

Vercel

Vercel does this automagically, as described in the SPA fallback section of their documentation.

This is the set up they suggest:

{
  "routes": [
    { "handle": "filesystem" },
    { "src": "/.*", "dest": "/index.html" }
  ]
}

First handle the file system, in other words, look for the physical file if it exists. In any other case, serve index.html.

Netlify

On Netlify, this is the recommended rewrite rule:

/*    /index.html   200

GitHub Pages

Sadly, on GitHub Pages, we cannot configure this kind of rewriting. People have been requesting this since 2015, see issue 408 on an unofficial GitIHub repository.

One solution that is offered by a friendly commenter: symlinks! GitHub Pages allows you to use a custom 404 page, by creating a 404.html file in the root of your project. Whenever the GitHub Pages server cannot find your files and serves a 404, it will serve 404.html.

Commenter wf9a5m75 suggests a symlink:

$> cd docs/
$> ln -s index.html 404.html

This will serve our index.html when files are not found. Caveat: it will do this with a 404 status code, which is going to be incorrect if we genuinely have content for the path. Boohoo. It could have all sorts of side effects, including for search engine optimisation, if that’s your thing.

Another way to hack around it, is to have a meta refresh tag, as Daniel Buchner suggests over at Smashing Magazine.

Let’s hope GitHub Pages will one day add functionality like that of Vercel and Netlify.

Wrapping up

Routing was easier when we used servers to decide what to serve. Moving routing logic to the client has some advantages, but comes with problems of its own. The best way to ‘do’ a single page app, is to have a server-side fallback. so that servers can just do the serving as they have always done. Generate static files, that servers can find. Don’t make it our user’s problem that we wanted to use a fancy client-side router. Now, should we not have a fallback for our client-side routes, redirect rules can help, like the one’s Vercel and Netlify recommend. On GitHub Pages, we can hack around it.

Originally posted as How deployment services make client-side routing work on Hidde's blog.

[email protected]?subject=Reply%20to:%20How deployment services make client-side routing work">Reply via email

22281

2020-07-07T00:00:00Z

In July 2019, my main browser of choice, Firefox Nightly, landed a new dashboard. It shows how much was blocked by the browser’s tracking protection feature. This can be found in about:protections. Let’s look at the stats after this first year.

Tracking protection is essential on today’s web. It’s a feature that both Firefox (Enhanced Tracking Protection) and Safari (Intelligent Tracking Protection) have had for quite some time now. Most websites are still full of naughty scripts that pass on information to social media giants, track you across websites, exercise finger printing and even mine crypto currencies.

I use the “Strict” mode in Nightly, which comes with a warning: ‘causes some sites to break’. I don’t recall ever seeing sites break at all, but your mileage may vary. Where it does happen, an exception can be made for a specific site.

The dashboard in about:protections tells you what types of trackers were blocked over the past week, as well as a total since you started using the future. After just over a year, mine shows 22281 trackers since July 5, 2019.

Like I’m excited browsers can fix accessibility problems, I’m grateful that they help address this problem when many websites don’t. It’s time for more minimum viable data collection. Happy birthday, tracking protection dashboard!

Originally posted as 22281 on Hidde's blog.

[email protected]?subject=Reply%20to:%2022281">Reply via email

Reply via email

2020-07-14T00:00:00Z

I noticed Ethan Marcotte and Robin Rendle added “Reply via email” links to their RSS feeds. I decided to steal their idea for this blog.

In the early days of the web, it was common to leave long-winded responses on each other’s blog posts. I didn’t blog back then. Now, (almost) all long form stuff that ends up in my comment queue is from content marketeers that show up just for the link juice.

I do really like getting replies, positive, negative or neutral, so I’ve added a Reply via email link to make that easier. Hope it is useful to some!

Originally posted as Reply via email on Hidde's blog.

[email protected]?subject=Reply%20to:%20Reply via email">Reply via email

Equality, a reading list (2)

2020-07-16T00:00:00Z

Last year, I published Equality, a reading list. I’ve continued to read about equality, so here’s a second reading list, with even more recommended reads.

As with the previous list, I am no expert. The books in this list helped improve my understanding of a number of different inequalities and how they intersect. I hope they can help you, too!

Two notes:

The word “equality” may have been poorly chosen on my part, and equity may be a better thing to strive for. Equality is the concept of treating everyone the same. Equity recognises not everyone has the same needs. It strives to treat people differently based on specific needs. Both want to promote fairness, so there’s that.
A major misconception about racism is that it consists of tangible and objectively verifiable acts committed by mean people. Like a bar tender who refuses to serve [insert race] people. Pretty much all of the books in this list clarify that racism is often none of those things. They explain it as a system, demonstrated by ‘lived experiences’ of the people affected by it, often invisible to others. It commonly involves nice or well-intended people. Any given person may be more racist than they think. All of this makes the subject hard to talk about it for people, as all people have different experiences

Without further ado, these are the recommendations, I hope there’s something in it for you.

“Not racist” is not enough

Ibram X. Kendi’s very popular “How to be an antiracist” is an extensive analysis of racism. It looks at history, culture, class, biology, ethnicity and more from an antiracist perspective. Antiracist, Kendi explains, is not the same as “not racist”. It’s not personal or about specific people either, it’s about working to dismantle a system. To be antiracist, says Kendi, is to act in ways that support antiracist policies (“policies that reduce racial inequity“). Almost every chapter starts with one or more definitions, often drawing clear distinctions. They help the reader identify what lacks in their thinking about the issues, and ensure a good understanding of the argument Kendi makes. To be antiracist, requires careful scrutiny of one’s own actions and ideas, something Kendi himself does, too. This is not something we can sit down and do one afternoon, the scrutiny should be an ongoing process. This book is the ideal guide to that process. Get the audiobook if you can, it’s great and author-narrated.

How to be an antiracist by Ibram X. Kendi. See also Brené Brown with Ibram X. Kendi (podcast)

Nice people

When you believe nice people cannot be racist, you don’t understand what racism is or how it operates, explains Austin Channing Brown in “I’m still here”. This belief in various shapes and forms, that are all harmful to the antiracist cause. There is what Channing Brown calls “relational defense’: “when people say they cannot possibly be racist, by appealing to the relationships of those who ‘know’ them”, or when they have black friends. Seems nice, but it puts the onus on the harmed. And there’s the concept of color blindness, which, again, seems nice, but it defeats the purpose if it is a blindness for racial injustice at the same time. Channing Brown’s perspective is that of a black Christian woman, and, like many of the other authors in this list, she shares generously from her own experiences and perspectives. Her treatment of the facade that diversity policy can be, is particularly well articulated. Again, I can recommend the author-narrated audiobook.

I’m still here by Austin Channing Brown. See also, Brené Brown again… Brené Brown with Austin Channing Brown (podcast)

Talking about racism

Talking about race can be uncomfortable, and can leave people with questions. “So you want to talk about race” very patiently and straightforwardly answers some of those. It treats important subjects like privilege (and what it means to “check your privilege”), microagressions, police brutality and cultural appropriation, and makes for a good entry-level book about anti-racism. This book is American, some themes might make less sense to people elsewhere (“on campus arrests” and lack of universal healthwcare come to mind). Like Kendi, Oluo is frank about her personal experiences, whether it is in examples of microagressions she experienced or tales of how she had to re-examine her own prejudice. I found this mixture of memoire and hand book very helpful.

So you want to talk about race by Ijeoma Oluo

Bananas

Pete Wu is a Dutch journalist and “second generation” Chinese. His mom calls him “banana”, yellow outside, white inside. As he wrote his book “De bananengeneratie” (The banana generation, Dutch only), he found this was the case for other Chinese-Dutch, too. The book has interesting reflections on discrimination and cliches, and crystal clear analysis of what it means to be Chinese-Dutch in The Netherlands. I previously read Sun Li’s excellent De zoetzure smaak van dromen, which covers some of those subjects, from a slightly different angle. De bananengeneratie also explains how being Chinese-Dutch intersects with being gay, as Wu describes his experiences in online dating (the phrase “no asians” is apparently common in the online Dutch gay scene).

De bananengeneratie by Pete Wu

The myth of “trickle-down”

Some say it will lead to more equality if minorities make it to the top. This idea of “trickle down” is questionable, shows Dawn Foster in her short book “Lean out”. Sheryl Sandberg may have successfully made it to the top, but her “journey” cannot simply be copied by others. Making it to the top shouldn’t be an aspiration of feminism anyway, explain the authors of “Feminism for the 99%”, as sexism often intersects with other problems, like poverty, and there are bigger problems to solve at the bottom.

Lean out by Dawn Foster and Feminism for the 99% by Cinzia Arruzza, Tithi Bhattacharya and Nancy Fraser

Winners take it all

Not to be confused with ABBA’s The winner takes it all. This is a good reminder that we should be extremely wary of people who say or pretend that they’ll save the world or make it more equal, especially if they’ve made large contributions to equality through their previous work. “Winners take all” makes fun of thought leaders and their conferences, explains what it means if philanthropists involve with politics and why “win win” without friction is a pipe dream.

Winners take all: the elite charade of changing the world by Anand Giridharadas

Such a fun age and Little fires

Novels are a really good way to better understand racist dynamics, so I want to end this list with two of my favourite reads this year, “Such a fun age”, by Kiley Reid, beautifully shows how good intentions cannot prevent bad impact, by exploring racial inequality from two points of view, a rich white woman and a single black twenty-something. “Little fires everywhere”, by Celeste Ng, takes place in Shaker Heights, a suburb of Cleveland Ohio, where everything is planned, including careers, as if there is no privilege, and everyone is colour blind, as if there is no racial tensions. This is also a tale about motherhood, identity, and social status, the comedy is top notch and the characters are fantastic. This was also turned into a tv series on Hulu.

Such a fun age by Kiley Reid and Little fires everywhere by Celeste Ng.

Originally posted as Equality, a reading list (2) on Hidde's blog.

[email protected]?subject=Reply%20to:%20Equality, a reading list (2)">Reply via email

When there is no content between headings

2020-09-05T00:00:00Z

For accessibility purposes, you could think of headings as a table of contents. But what if there are headings without contents?

On a web page, a heading (h1, h2, h3 etc) signposts ‘a section about X starts here’. Heading names are section names, in that sense. If, in a banana bread recipe, one heading says ‘Ingredients’, and the other says ‘Method’, expectations are set about what can be found where. Under the first heading, we’ll expect what goes into the banana bread, under the second we’ll expect some steps to follow.

The issue

Now, a problem I saw on a website recently: headings with no content. The issue wasn’t empty hx elements, it was that there was no content between these elements and the next. This can happen when the heading element was picked merely for its looks, rather than as a way to indicate that there is some content—and what kind of content.

<h1>Banana bread</h1>
<h2>It's tasty</h2>
<!-- nothing -->
<h2>It's healthy</h2>
<!-- nothing -->
<h2>It can be anyway</h2>

On a site with beautiful heading styles, this could look great, but structurally it is unhelpful, because when someone navigates to one of these h2 ’s, they find nothing.

It could also constitute a failure of WCAG 1.3.1: Info and relationships, because you’re basically claiming a structural relationship when there isn’t one.

So, the two questions to ask for headings:

useful description: does this clearly say what kind of content I can find underneath?
content: is there any content available underneath?

In the example above, only the h1 meets the criterion of being something we would want to navigate to. The bits underneath are more of a list of unique selling points. Something like this would be better in this context:

<h1>Banana bread</h1>
<ul>
  <li>It's tasty</li>
  <li>It's healthy</li>
</ul>

Note: the problem is not multiple headings as such, it’s multiple headings of the same level, that have no non heading content that they are a description for.

In summary

When you use a heading element, you set the expectation of content—always have content between headings of the same level.

Originally posted as When there is no content between headings on Hidde's blog.

[email protected]?subject=Reply%20to:%20When there is no content between headings">Reply via email

Why it's good for users that HTML, CSS and JS are separate languages

2020-11-25T00:00:00Z

This week, somebody proposed to replace HTML, CSS and JavaScript with just one language, arguing “they heavily overlap each other”. They wrote the separation between structure, styles and interactivity is based on a “false premise“. I don’t think it is. In this post, we’ll look at why it is good for people that HTML, CSS and JS are separate languages.

I’m not here to make fun of the proposal, anyone is welcome to suggest ideas for the web platform. I do want to give an overview of why the current state of things works satisfactorily. Because, as journalist Zeynep Tefepkçi said (source):

If you have something wonderful, if you do not defend it, you will lose it.

On a sidenote: the separation between structure, style and interactivity goes all the way back to the web’s first proposal. At the start, there was only structure. The platform was for scientists to exchange documents. After the initial idea, a bunch of smart minds worked years on making the platform to what it is and what it is used for today. This still goes on. Find out more about web history in my talk On the origin of cascades (video), or Jeremy Keith and Remy Sharpe’s awesome How we built the World Wide Web in 5 days.

Some user needs

Users need structure separated out

The interesting thing about the web is that you never know who you’re building stuff for exactly. Even if you keep statistics. There are so many different users consuming web content. They all have different devices, OSes, screen sizes, default languages, assistive technologies, user preferences… Because of this huge variety, having the structure of web pages (or apps) expressed in a language that is just for structure is essential.

We need shared structure so that:

screen reader users can navigate web pages by heading (see headings are tables of contents).
people with an attention disorder can turn on reader mode
people with motor impairments can use autofill (see Identify Input Purpose)
people who want to read a foreign language page in their mother tongue can stick a URL into Google Translate

All of these users rely on us writing HTML (headings, semantic structure, autocomplete attributes, lang attributes, respectively). Would we want to break the web for those users? Or, if we use the JSON abstraction suggested in the aforementioned proposal, and generate DOM from that, would it be worth breaking the way developers are currently used to making accessible experiences? This stuff is hard to teach as it is.

Even if we would time travel back to the nineties and could invent the web from scratch, we’d still need to express semantics. Abstracting semantics to JSON may solve some problems and make some people’s life easier, but having seen some attempts to that, it usually removes the simplicity and flexibility that HTML offers.

Users need style separated out

Like it is important to have structure separated out, users also need us to have style as a separate thing.

We need style separated out, so that:

people with low vision can use high contrast mode; a WebAIM survey showed 51.4% do (see also Melanie Richard’excellent The Tailored Web: Effectively Honoring Visual Preferences)
people who only have a mobile device can access the same website, but on a smaller screen (responsive design worked, because CSS allowed HTML to be device-agnostic)
people with dyslexia may want to override some styles use a dyslexia friendly typeface (see Dyslexic Fonts by Seren Davies)
people who (can) only use their keyboard can turn on browser plugins that force focus outlines
users of social media may want to use a custom style sheet to turn off the Trending panel (it me 🙄)

Users need interactivity separated out

Some users might even want (or have) interactivity separated out, for instance if the IT department of their organisation turned the feature off company-wide. Some users have JavaScript turned off manually. These days, neither are common at all, but there are still good reasons to think about what your website is without JavaScript, because JavaScript loss can happen accidentally.

We need interactivity separated out, because:

some people use a browser with advanced tracking protection, like Safari or Firefox (see my post On the importance of testing with content blockers)
some people may be on low bandwidth
some people may use an old device or operating system for valid reasons
some people may be going to your site while you’ve just deployed a script that breaks in some browsers, but you’ve not found out during testing, because it is obscure

As Jake Archibald said in 2012:

“We don’t have any non-JavaScript users” No, all your users are non-JS while they’re downloading your JS

That’s right, all your users are non-JS while they’re downloading your JS.

Existing abstractions

None of this is to say it can’t be useful to abstract some parts of the web stack, for some teams. People abstract HTML, CSS and JavaScript all the time. People happily separate concerns differently: not on a page level, but on a UI component level.

On the markup end of things, there are solutions like Sanity’s Portable Text that defines content in JSON, so that it can be reused across many different “channels”. This is a format for storing and transferring data, not for displaying it on a site. Because before you display it anywhere, you’d write a template to do that, in HTML. In a government project I worked on years ago, the team abstracted form fields to JSON before converting them to HTML. I currently work on a project where we use XSLT to specify some stuff before generating HTML.

For CSS there are extensions like Sass and Less, utility-first approaches like Tailwind and many methods to define CSS inside JavaScript component. From JSSS (from 1997) to CSS in JS today, there is lots to choose.

As for JavaScript: there are numerous abstractions that make some of the syntax of JavaScript easier (jQuery, in its time), that help developers write components with less boilerplate (like Svelte and Vue) and that help teams make less programmatically avoidable mistakes (TypeScript).

I don’t use any of these abstractions for this site, or most others I work on. Yet, many approaches are popular with teams building all sorts of websites. Choose any or no abstractions, whatever helps you serve the best HTML, CSS and JS to end users.

We’re very lucky that all of these abstract things that are themselves simple (ish) building stones: HTML, CSS and (to a different extent) JavaScript. With abstractions, individual teams and organisations can separate their concerns differently as they please, without changing the building blocks that web users rely on.

Could you benefit people in your abstractions? Maybe. The proposal mentions specific parameters for visual impairments and content that can trigger seizures. But it is better for users (including their privacy) to have such things in the main HTML and CSS, regardless of whether that was written by hand or outputted by some abstraction.

Conclusion

The separation between HTML, CSS and JavaScript as it currently is benefits web users. It does this in many ways that sometimes only become apparent after years (CSS was invented 25 years ago, when phones with browsers did not yet exist, but different media were already taken into account). It’s exciting to abstract parts of the web and remodel things for your own use case, but I can’t emphasise enough that the web is for people. Well written and well separated HTML and CSS is important to their experience of it.

Originally posted as Why it's good for users that HTML, CSS and JS are separate languages on Hidde's blog.

[email protected]?subject=Reply%20to:%20Why it's good for users that HTML, CSS and JS are separate languages">Reply via email

2020 in review

2020-12-17T00:00:00Z

It’s that time of the year again! In this post, I’ll share some highlights of my 2020, a year that I personally can’t wait to leave behind. Below, you’ll find what I’ve been up to and some things that I have learned.

This year I have had some great things happen to me: I became a father for the second time and moved house. It has also been a struggle in many ways. But I’ll repeat my disclaimer from 2018, in these public posts, for reasons, I chose to leave the “lowlights” out. Rest assured there were many, as I imagine was the case for you too.

Highlights

Projects

It has been a good year for my freelance practice, also a stressful one, particularly in lockdown times.

I spent the vast majority of my time this year working with the Web Accessibility Initiative at the W3C. This year, I worked on various things:

redesign of WCAG supporting documents, like Techniques and Understanding, to launch sometime next year, with improvements including syntax highlighting and clarified context
talks about the importance of authoring tools, like Your CMS is an accessibility assistant for WordPress Accessibility Day
launched the ATAG Report tool, which can be used to report on accessibility issues in authoring tools, like CMSes, e-learning systems and form generators

In the time that was left, I did a bunch of accessibility audits and workshops in my own capacity. Some for my own clients, some for the clients of consultancies like Firm Ground and Eleven Ways. I also had a short advisory role on the CoronaMelder website, helping with accessibility and code reviews.

I gladly said yes to all of these things, and loved combining the standards-oriented work with the practical hands-on stuff. It’s truly been good to see people understand accessibility better.

Speaking

Almost all of my speaking this year was virtual. I had planned to represent W3C/WAI at the CSUN accessibility conference this year, but this ended up the first of many events cancelled.

The only in-person talk of the year was a practice round for that CSUN talk: Amplifying your accessibility with better authoring tools. It was in Groningen, close to where I grew up and first worked, and I also got to see Maike do her awesome talk about empathy in government.

I also did some private talks, and these public talks, all online:

Amplifying your accessibility with better authoring tools at A Future Date
Advancing authoring tool accessibility at an AccessU event with an all-WAI line-up introducing all we’ve been working on
On the origin of cascades by means of natural selectors, a Darwin-themed look into the evolution of CSS, at CSS Café, virtually in Boden, Germany
6 ways to make your site more accessible at Full Stack Utrecht
Your CMS is an accessibility assistant at WordPress Accessibility Day
On auto sizes in Grid Layout, about sizes in CSS. It was a dream come true to speak at Singapore CSS, an event organised by awesome humans.
It’s the markup that matters at Vercel’s Nextjs Conf, packed with accessibility info, aimed at full stack developers.

Generally, online talks felt harder than IRL ones, because of less audience interaction and more preparation time. There was also less meeting people and traveling.

Less traveling was also an advantage: I could cook family dinner after delivering a talk, instead of being away for a few days. There was also one time where I attended my Q&A with a plaster, because I thought I could do some meal prep in a conference break. 🩹

Reading

I was able to read plenty and discovered a bunch of new authors that brought me joy and wisdom. I did one reading list post this year: Equality, a reading list (2).

If you’re looking for recommendations, find me on Goodreads (email/DM for my handle), I read in Dutch and English. These are some highlights in fiction:

Celeste Ng’s Little fires everywhere, and also her debut Everything I never told you
Anna Wiener’s Uncanny valley, about a woman in publishing who moves to Silicon Valley and is rightly shocked by the men, the hustle, the offices, weird camping trips… (see also my review)
Naoise Dolan’s Exciting Times, about millennials in Hong Kong
Johan Harstad’s Max, Mischa & Tetoffensiven, about identity, living abroad, friendship, Norway, the US and much more, blew me away. Sorry if you don’t read German, Dutch or Norwegian, it wasn’t (yet) translated to English.

These were my favourites in non-fiction:

Jia Tolentino’s Trick Mirror, essays about the culture of the self
Wendy Liu’s Abolish Silicon Valley, about what’s wrong with Silicon Valley’s ideology
Michael Sandel’s The Tyranny of Merit , about why meritocracy is a lie
Ibram X Kendi’s How to be an anti-racist – paraphrasing Dutch journalist Pete Wu: it’s probably not right to think in strict boxes but the categories of “racist” and “anti-racist” seem like a very useful distinction to make. Ibram X Kendi’s work has been my favourite about anti-racism so far. He narrates the audiobook himself and it is super powerful.

Writing

I wrote a lot less. Partly, I’ll blame 2020. Partly, it may be due to more of my work involving writing.

Some of the posts I did write:

Could browsers fix more accessibility problems automatically and More accessible defaults, please– the web could be made more accessible from many sides: teams building website, website creation software, but also browsers. These posts go into what could be built into browsers.
How deployment services make client-side routing work about hosting SPAs with routers
Minimum Viable Data Collection, where I argue that if we want to follow the spirit of GDPR, we should collect data minimally, rather than beg for permission to collect maximally.

For the next year, I have some drafts floating around, that I hope to once finish and publish.

Cities

Last year, I had a “Cities” section. This section will be resumed next year.

Things I learned

I didn’t really do any side projects or volunteering this year. Some things I have learned this year:

the basics of XSLT, which is used at W3C/WAI to generate the documents that support the WCAG standard
I struggled a bit with git submodules, and ended up learning a bit about them
For obvious reasons, I worked on talk recording skills and found out it’s all about light, light and light. And that I pull weird faces and should move my head less.
Audiobooks allow one to read while going for a walk or doing the dishes, which are some of the few tasks reading can nicely be combined with.
Static site generators are perfect for creating WCAG conformance reports. Turning HTML into an accessible PDF is not trivial, and one almost certainly requires PrinceXML for it. It doesn’t support Grid Layout, but has lots of print-specific CSS that is fun to play with, should you be a CSS nerd.

Dear readers, I hope 2021 treats you well. Hang in there.

Should you want to read more personal review posts, check out those of Michelle, Matthias, Melanie, Chee Aun, Una, Nienke, Max, Marcus and Brad.

Originally posted as 2020 in review on Hidde's blog.

[email protected]?subject=Reply%20to:%202020 in review">Reply via email

How I turned my Goodreads data into a self-hosted website with Eleventy

2021-01-04T00:00:00Z

In the last week of 2020, I decided to export my Goodreads data to display it on my personal website. This post is about what I did and how.

Why export?

First, I quite like Goodreads. It lets me see the reads of friends and acquaintances. It lets me share my own. This is all splendid, but it is still somebody else’s site. Somebody with very different life goals from my own, in fact. For more control on what I display and how, I decided to create a new section of this website dedicated to books, fed by an export of my Goodreads data.

The two main reasons I use Goodreads are people and books. I want to connect with (internet) friends and be inspired by what they read. I also want to keep track of what I have read and plan to read, for instance when a person or article mentions an interesting book. When I’m reading a book review in the paper, I’l sometimes grab my phone and add the thing to the list. Goodreads has an easy to use catalog that usually lists what I searched.

Some things to dislike about the platform are the gamification and the generic recommendations: it’s noise that I could do without (“you read something in philosophy, maybe you’ll like this book by Plato”). There are also lots of trackers, and it is powered by a faceless multi-billion dollar enterprise that threatens the livelihood of friendly, local bookshops.

Some features

Various people’s online bookshelves inspired me to create one on this site, including Melanie Richard’s highlights, focused on highlights, Dave Rupert’s Bookshelf, which features many short reviews and half stars, Tom McWright’s, Maggie Appleton’s, Mandy Brown’s, Alex Chan’s, Sawyer Hollenshead (also with highlights) and Amanda Pinkster (includes where she read them).

I like the processes of other people: Katy Decorah uses GitHub actions, Nienke uses her own What.pm and Jeremy Keith tags notes with ISBN numbers. My process is still different from each of them though, for no particular reason.

For me, a personal book repository does not require a lot, but these are some features I wanted to have:

Separate views for Dutch and English: I mostly read in these two languages, some viewers may only be interested in either section.
Hand-picked book covers: ‘Never judge a book by its cover’, they say. Well, I like book covers as expectation setters and did not automate the cover art collection process.
Links to author’s personal sites: Personal sites deliver on the promise of the web, said Matthias Ott in Make it personal. I haven’t enriched a lot of the data with this piece of information, but will be.
Dark mode: Because CSS is fun. I went for a midnightblue background with khaki text.
No tracking: This site does not track users. Minimum Viable Data Collection (zero, in this case) ftw.

What I could automate

CSV entries to front matter in Markdown

I decided to use Eleventy to turn my data into a web page, as I like its flexibility, its focus on simplicity and its firm hesitation to make decisions for developers using it.

Goodreads provides reading data in CSV files, which are reasonably well structured. For the Eleventy site, I needed a folder full of Markdown files, one for each book, with basically the metadata from the Goodreads export as Yaml front matter:

---
title: "Uncanny Valley"
author: "Anna Wiener"
isbn: "0374278016"
isbn13: "9780374278014"
rating: "5"
publisher: "MCD"
pages: "281"
publishYear: "2020"
read: "2020"
goodreads_id: "45186565"
---

I did this in Node using a slightly modified version of CSV to Markdown. The project is archived and I could not get the Noderize wrapper to work, but the provided script in index.js did the job for me.

It seems like Hay Kranen’s dataknead may be a great alternative to do this work (in Python).

Image processing

This site has a lot of images, and resizing or optimising would not be my definition of fun. I used the official Image plugin for Eleventy to generate correctly sized images from my source images, and the documented Nunjucks shortcode to output a picture element with webp and jpg versions in various sizes.

I used the native lazyloading attribute, loading="lazy" , which I learned only in this project, is not added to the picture-element, but to the fallback <img> .

The grid

I knew how I wanted my content to be layed out, but I didn’t know what my content would be. Grid Layout is fantastic if that’s your situation. I used grid’s autoplacement feature: I defined a grid, added the content in HTML and each book magically appeared in its right place.

On small screens, I used the non-default autoflow value column, to make new items appear horizontally.

What I didn’t automate

In web projects, we often balance between spending time to automate versus doing it manually. Sure, automation can be a fun thing to work on. But if I’m honest, I only want to do it if it saves more time than it costs.

Book covers

Cover art is among the highest forms of graphic design. Covers of music and books can be incredibly creative. Film posters can be a prone to cliche overuse, but have you seen Saul Bass’s movie posters?

Books often get different covers when they are reprinted or distributed in different countries. This project was the perfect excuse to handpick my favourite for each book.

CSS authoring

There was not enough complexity to warrant any form of CSS processing, so I just created a single CSS file and started adding styles. I used no methodology or framework. I did mostly avoid classes, because in my day to day work I overuse them and it seemed like a fun challenge.

Extra data

I’ve also added some data manually that I didn’t have in Goodreads, like the language I read a book in. And I want to slowly add more data to some books, like the URI for the author’s personal website, and, in case I wrote a review, a link to that review.

Future features

There are some things that I would like to improve when there’s more time or less lockdown. A website is never finished!

Some interface to add data: Adding a new book now involves me manually creating a Markdown file with the right front matter and a JPG file with the same name for the book cover. I could automate at least part of this.
Filters: Books can currently display by language. If I started adding tags to books, I could create sub lists, “Show books about topic X”. That would be fairly trivial to do.
Better sorting: I messed up transforming the date field in the Goodreads export, so now I only have a year and no way to sort by reading date. I plan to add this for new books.
RSS: I doubt anyone would subscribe to something like this, but wide availability of reading list RSS feeds would allow us all to create a decentralised Goodreads in feed reader software of our choice.
Better lazyloading: Currently, all images on the book site have the loading="lazy" attribute. The recommended way is to only add this attribute for images that are not in the viewport. I’m not sure how to solve that on this site, because my grid grows with the viewport. Which images are in your viewport, depends on how wide it is.
Better markup: Maybe I can use more standard markup for the books, like microformats. The indieweb personal library page has some pointers, including Paul Munday’s example of microformats for books.

Woops, that’s quite the list. Let me just postpone it to the next sprint.

Wrapping up

So, my book site is available on books.hiddedevries.nl, the source is on GitHub. This has been a fun weekend project, and to be honest, I am very much looking forward to continue expanding the existing data and add new stuff.

If you have one of these digital bookshelves yourself, please do share them in the comments or reply on Twitter! If you have any thoughts or opinions on what I’ve done, feel free to let me know.

Originally posted as How I turned my Goodreads data into a self-hosted website with Eleventy on Hidde's blog.

[email protected]?subject=Reply%20to:%20How I turned my Goodreads data into a self-hosted website with Eleventy">Reply via email

It's easier when you do it earlier

2021-02-04T00:00:00Z

Web accessibility becomes easier and cheaper, when you address it earlier. In this post, we’ll look at various ways to do that, like picking the right CMS and making accessibility part of the agile process. Combine them for maximum effect.

A quick disclaimer before we start: while this post is about web accessibility, the same probably goes for web security, web privacy and other important aspects of a healthy web.

To make websites accessible, most organisations choose to follow the Web Content Accessibility Guidelines (WCAG). It’s also the standard most governments embed in their rules. Meeting WCAG does not guarantee accessibility, but the standard is a good baseline. It is our best bet as a shared understanding ‌of what ‘this is accessible’ means.

Choose a CMS that helps with accessibility

WCAG is about the accessibility of content, so it makes sense to optimise what we do when we create content. We could pick CMSes that help editors create accessible content. In my talk “Your CMS is an accessibility assistant”, that I did last year, I discuss just that.

What if a CMS, when you add a video, prompts for subtitles? What if it, when you place text on a hero image, it helps you pick a color that has sufficient contrast, or suggests to add a background color? Some CMSes already ship with features like this.

WordPress’s Gutenberg editor, for instance, will tell you when you’re starting to use colours with insufficient contrast:

Features like this are super helpful, because they let us spot accessibility issues early in the process. Without them, we may have only found out about problems once the functionality went live and got audited. With good early warning systems, WCAG audits can focus on the more complex issues.

Check accessibility with every user story

A lot of web projects rely on some form of agile project management, many move new functionality through a set of stages. If you can build accessibility steps into the process, somewhere before the last stage, you can find and fix accessibility problems before they go live.

There are many ways to do this. You may not want to do a full WCAG audit on each piece of functionality, but I’ve seen teams leverage checklists that address low hanging fruit. When you combine a bunch of fairly easy to execute manual checks with some automated accessibility checker, you will likely be able to address problems while they emerge. For instance, add that keyboard handler while you’re building the widget, rather than following a formal accessibility audit months after the feature initially launched.

Some checks you could include are:

do the automated checks (for instance from axe-core, Tenon, Polypane or Siteimprove) return zero issues? Note, automated checks can only check 10-30% of WCAG issues, don’t rely on just automated checks
can all controls in the feature be used with only a keyboard?
can you still use everything if the browser is set to 400% zoom?
for all form inputs, does the input activate when you click on the label?

Checklists have caveats though… the most important is to realise that “what’s most easy to check” is not necessarily the same as “what’s the most important to check”. It would be quite the coincidence if it was. But having said that, easy checks are probably the checks that are most feasible to include with each piece of functionality.

Level up on HTML proficiency

A large portion of issues I find in my WCAG audits relates to HTML and how to use it. Developers who know the HTML spec inside out are at a massive advantage when it comes to the WCAG compliance of the product they work on. Which elements to use when, how to build forms, what attributes exist for tables… it will all help write more accessible code.

For instance, developers who are aware that input-elements have an autocomplete attribute, will have no trouble meeting Identify input purpose (Success Criterion 1.3.5, which requires that attribute for form fields that collect personal information).

Ensuring new developers can bubble sort may be important to your business goals, but so is testing for HTML proficiency. Even, maybe especially, when you interview a full stack developer for your team, make sure you also interview for the HTML bit of the stack. It will help the team create accessible code from the start.

Wrapping up

In conclusion, with the right CMSes, checklists for every user story and high levels of HTML proficiency, teams can get a lot of their accessibility right early in the process. These all may all seem like no-brainers, but I’ve only seen very few organisations adopt them. I’m curious if others have more strategies for putting accessibility earlier in the process, please do reply via email or socials, or in the comments below.

Originally posted as It's easier when you do it earlier on Hidde's blog.

[email protected]?subject=Reply%20to:%20It's easier when you do it earlier">Reply via email

My typical day

2021-02-15T00:00:00Z

In recent weeks, people have been publishing “typical day” posts. They have been fun to read. In what Ethan Marcotte aptly called a “blogging chain”, started by Colin Devroe, Michelle tagged me and some others. So, here it goes, some typical things about my daily life.

I’ve been admiring other people’s ability to wake up early, go for early-morning runs and/or have carefully carved out daily schedules. If you want to read what other people’s days look like, I liked those of Michelle, Matthias, Ethan , Cassie, Jeremy and Sara.

Days have been very different in the last six weeks, as I’ve taken most days off during the Dutch daycare lockdown. Those days were full of cooking together with the kids, long walks with the kids and, when it rained, painting loo rolls (again, with the kids). Super challenging, because how do you balance all that and a freelance business? Working with a baby on one arm and a toddler running around the room is a myth. It was also super rewarding, for all the obvious reasons: babies and toddlers can be immensely cute and lovely. We learn a lot from and about each other.

Below, you’ll find a description of a somewhat regular day. The times and activities can vary.

07.00-8.30

A combination of wake up, make breakfast and coffee. We get everyone dressed, read the morning paper. I read my morning paper physically. This was initially so that I could skip online news, but who am I kidding–even with most news sites blocked via my /etc/hosts, I can’t resist and go peek on my phone.

08.30-9.30

Walk kids to daycare. If I’m alone, this is usually my chance to listen to audiobooks or podcasts on the way back home, and take a longer route if time allows. Podcast-wise, I’m a sucker for long form interviews, like NTR Kunststof, Nooit meer slapen and Groenteman in de kast in Dutch, and James O’Brien’s Full Disclosure and Brené Brown’s Unlocking us in English.

09.30-13.30

This is where I try to get a lot of work done. I usually don’t have meetings, as my US counterparts are still asleep. I may be working on an accessibility audit or presentation slides, or, if it’s a W3C day, I may be coding accessibility conformance tooling, review surveys from the Education & Outreach Working Group or generate the WCAG XSLT over and over for our current redesign project. Usually I drink Taiwanese high mountain tea.

13.30-14.00

Lunch time! I extend it sometimes, especially if I have evening meetings, so that I can go outside and/or cook hot lunch.

14.00-17.00

This is usually a combination of meetings, 1:1s and getting work done. I may be doing some work on components for the WAI website, talk to CMS vendors for WAI-Guide or attempt to split up large amounts of work into GitHub issues. Some time into the global pandemic, I purchased a second hand hifi set and placed it inside my home office, so that I can listen to all the jazz, ambient, pop, rock and hiphop when not in meetings. I check the number of positive COVID tests, which is easier if it decreases.

17.00-19.30

Daycare pick up, cooking and eating. Depending on how smooth things went and how much time there still is, we also use food delivery. I get better at not feeling too guilty about that. After dinner we usually put on music and dance a bit. Sting and Shaggy, Chika, Gregory Porter, Nile Rodgers and Moby have been recent favourites. K3 and their song about washing hands and Juf Roos, too.

19.30-21.00

Trying to get the kids to sleep, read bed time stories, answer mesmerising questions about the universe and its workings. Also wash up and prepare baby food. Sometimes I have an evening meeting. On Thursdays I recently started attending Open UI telecons.

21.00-23.00

Oh, is it this late already? We may watch Mock the Week if there are new episodes, see how Ku explores Taiwan or how Waes visits Japan. Travel and food themed shows help remind there was a prepandemic world. They give me hope that some of it may come back. Sometimes there’s a book I can’t stop reading or a guest in one of the late night talk shows that I don’t want to miss. I go to bed with a book.

Wrapping up

So, this is what my days roughly look like. I don’t really have any useful productivity hacks, but feel that walking, reading, listening, cooking and (even) cleaning are some things that I’m pleased to have in my days.

I’d like to invite Zell Liew, Ana Rodrigues and Eric Bailey to join this chain to talk about their days, if they want to!

Originally posted as My typical day on Hidde's blog.

[email protected]?subject=Reply%20to:%20My typical day">Reply via email

Accessible front-end components: claims vs reality

2021-04-02T00:00:00Z

My mission in web accessibility is to make it easier for people who want to create accessible interfaces. There are many means to that end, from building good understanding of how people with disabilities use the web to providing clear and well-tested code examples.

I mean, if you understand how people use the web with a mouse, it is easier to design a mouse cursor that works for them, or write the code to implement one. This also applies to keyboard, switch controls, voice navigation, touch and screenreaders.

I like the power of reusable components, as they allow for baking accessibility into components, whether in frameworks or vanilla. One day there may be better UI controls in the web platform and/or more accessible defaults in browsers. Now, teams often build their own components (see Smashing’s guide for tips). Of course, not all project teams can always build their own components every single time. This is not ‘Nam, there are deadlines. And so, we commonly use third-party components like custom selects, autocompletes and date pickers.

In this post, I will warn you about blindly trusting accessibility claims and share some questions to ask with each third party component you consider for your project.

“Accessible” doesn’t say it all

As accessibility-aware developers, we may look specifically for components that are accessible. Maybe we search the web for ‘accessible X’. If you do that, be aware that there are more components that claim to be accessible than components that actually are usable or great to use for people with disabilities.

Sometimes, ‘accessible’ means only partially accessible. That’s a problem, as accessibility is about making interfaces work for people with a broad range of disabilities (see Diverse abilities and barriers). For instance, what to think of a widget that was made to work with a keyboard, but breaks badly when zoomed in? It has perfect colour contrast, but no HTML semantics? The screenreader experience is excellent, but it is tricky for users who control their system with voice?

Sometimes, ‘accessible’ means ‘has a bunch of ARIA attributes’. In the best case ‘has ARIA attributes and keyboard behaviours that exactly meet the ARIA standard’. Sometimes that it is a 1:1 implementation of the ARIA Authoring Practices Guide (APG), a set of examples (not a standard) written by a subgroup of the ARIA Working Group. The APG is an excellent resource if you want to know how to write technically correct ARIA. But… it does not make claims about screenreader compatibility, see ARIA-AT and/or a11ysupport for that. It also does not make claims about user experience, so always be sure to test the patterns with people, or read blog posts from others who tested with people. Lastly, it also does not recommend whether to use ARIA or go HTML-only… it is just about using ARIA. Sometimes, HTML-only patterns are easier to understand for end users. More ARIA does not mean more accessibility.

Sorry, I realise none of this makes it particularly easy to find accessible components, but I want to be honest. In any case: don’t give up. Remember what Léonie Watson once said about accessibility: “it doesn’t have to be perfect, it just has to be a little bit better than yesterday”. The more research we do, the better informed our choice will be.

Some questions to ask

If we want to have a little more certainty about the accessibility of a component, there are some checks we can do.

How did they test?

It’s good news when a component’s website explains how a component was tested. Usually browser support is listed, sometimes support for assistive technologies like screenreaders is included, too. Maybe they’ve done formal WCAG testing or they have some sort of checklist. They may be running only automated tests, which are good and useful, but limited to things that can be automatically tested (most of WCAG cannot be). Information about the type(s) of testing can help inform us about the accessibility of a component.

Who did they test with?

Testing accessibility is ultimately not about technology, though, it is about making sure the pattern works for people with disabilities. If we look at a component, can we find whether they specifically included people with disabilities? Was a broad range of disabilities included?

Representation matters; accessibility often requires testing a broad range of people, disabilities and assistive devices. When Marcy Sutton user tested patterns for accessible routing, users of screenreaders, voice navigation and switch controls had varied experiences and comments (see What we learned from user testing accessible client-side routing).

Are they open about pros and cons of their approach?

Accessibility is not always one size fits all, sometimes there may be caveats to an approach, there may be things that may still be experimental. It’s a good sign if the component developer is open about this. Sometimes there will be an accessibility statement with known issues and planned fixes.

Who created them?

Sometimes I put extra trust if the people or organisations that created components work for the public good and/or in accessibility. Government-backed component libraries like the gov.uk design system, the New Zealand government design system and the US government’s design system contain gems. So do pattern libraries created by accessibility practitioners like Deque’s Cauldron and Tenon UI.

More indicators

I also asked around on social media! Below are some of the tips that were shared there (❤️ thanks all!)

Look at GitHub issues

Marcus recommended to look at GitHub issues about WCAG or accessibility, “their presence would be a warning sign”. Thea said it can also be a “sign that people care”, she suggests looking at activity and discussions on issues. Mitchell agreed: “the quest for optimal usability and interoperability is never done”. Mallory +1’ed too and looks at how authors respond.

Accessibility as an integral part

Sara warned to be wary of treating accessibility as a separate feature rather than an integral part of the work. If there is an accessible version and a non-accessible version, they’ve probably failed that test!

Find specifics

Bogdan would look for specifics of the accessibility claim: which version and level of WCAG are we talking? He and Weston also said to look for which specific screenreaders were tested.

Perform basic checks

Various people said basic checks can give away a lot: do the docs even mention accessibility (Oscar), is there sufficient colour contrast (Martin), does it work with just a keyboard (Brent and Eric)?

Find out about committment

Heather recommended to look at the website of the component; obvious accessibility issues there say something about the claimed commitment to accessibility.

Yakim said we should look at the testing method to gauge how sustainable accessibility efforts are: “are they ongoing and proactive, or are they reactive?”

In his blog post Be wary of accessibility guarantees of accessibility vendors, which is more about accessibility of tools in general, Adrian recommends going on Twitter and searching the company name combined with the #a11y hashtag.

Customisability

If nothing is perfect, why not improve one of the most promising candidates? Martin mentioned licensing: with a permissive license, we could fix any accessibility barriers ourselves. He and Jason mentioned this too: if the component has easy to use APIs and hooks for customisability, we can take matters into our own hands..

Wrapping up

To sum up: not all ‘accessible components’ are created equal, some will work a lot better for our end users than other. In this post I have listed a number of things you can look at if you are considering third-party components.

Originally posted as Accessible front-end components: claims vs reality on Hidde's blog.

[email protected]?subject=Reply%20to:%20Accessible front-end components: claims vs reality">Reply via email

Queuing up

2021-04-25T00:00:00Z

Distributing speaking time can be tricky when meeting face to face, but it is usuallly worse in virtual meetings. Especially those spanning long distances. In my current team, I learned how queues in remote meetings can make them better for everyone. Here’s how we queue.

Queues matter

As a Dutchman in Bristol, UK, where I lived for ~3 years, I’ve had to learn how to queue. Growing up Dutch teaches one about cycling, consensus and clogs, but it leaves most folks behind on the queuing front. Skills are sometimes culture-based. You see, when a Dutch train arrives, people will try and stand close to the entrance. When the door opens, they will try and push themselves in before others. Brits do this differently: they first look for a queue, form one if none exists, and so on. Most likely there are still significant gaps in my understanding of it all.

Anecdotes aside, fair queuing is important. In any kind of organisation. In a recent interview, a female Dutch cabinet minister shared how the prime minister always seemed to let male counterparts talk earlier and longer. It was resolved with promises to improve, but this is way too common in meetings everywhere. Some talk a lot, others find it hard to join in (I’ll say that I’ve been both depending on circumstances).

The queue bot

Since I started working with the W3C, I’ve learned to love a meeting management system that is old, but very effective. Meetings at the W3C are generally scribed: one or more people volunteer to write down who says what. This happens on IRC, which is a bit like Slack, but much older. It’s also not just a service, but an open and long proven protocol for which you don’t need (but can have) an account. That’s useful for us, as our meetings typically involve people from outside our own organisation.

Anyway, in W3C meetings, the group usually shows up both on some video conferencing platform and simultaneously on IRC. When the meeting is ongoing, if you want to speak, you type:

q+

This puts you on the speaking queue. Other meeting attendees will generally be on IRC, too, and see this. The chair of the meeting (usually) ensures that people speak in queue order—those who jumped on first, get to speak first. Unless there are practicalities, like the subject they were on queue for.

If you want to remind yourself or others of the subject or your point, you can write:

q+ to ask about comms plan

There are lots of hacks, like qq+ (put me on the queue, but skip to the front), and there is a bot in the meeting that will keep track of who’s on queue. If anyone asks q?, the bot responds with a list in the right order. I know, a machine that learns!

The bot, called Zakim, was named after a bridge near the Massachusetts Institute of Technology, I learned recently. In turn, that bridge is named after a human rights activist. It does more than just queuing, it also manages meeting agendas and who’s attending.

Wrapping up

Meeting with this system doesn’t guarantee equal talking time, nor does it pretend to, but the visible method of queuing is really nice to have, especially in virtual meetings. I wonder if other organisations have tools like this, and if not, why not?

Originally posted as Queuing up on Hidde's blog.

[email protected]?subject=Reply%20to:%20Queuing up">Reply via email

What's ‘normative’ in WCAG?

2021-04-27T00:00:00Z

I’m currently involved in a project to make some of the WCAG guidance more clear. One of the distinctions we’re hoping to clarify is: what’s normative in WCAG?

‘Normative’, meaning something like ‘required to meet the norm’, is a common phrase in (web) specifications. You’ll find it in WCAG, but also in HTML, CSS and many others. Specifications say what we should do (‘do X’), in a way that can be evaluated afterwards (‘was X done?’).

For instance, the normative sentence ‘Web pages have titles that describe topic or purpose’ (from: Page titled) can be evaluated: if a web page has a title and it describes topic or purpose, it’s a pass. Otherwise, it’s a fail.

The opposite of ‘normative’ is ‘informative’, it is something that is not required for conformance to the norm. You may also find it is called ‘non-normative’, ‘not required’ or descriptive in some places.

As an aside, the words ‘may’, ‘must’, ‘must not’, ‘not recommended’, ‘recommended’, ‘should’ and ‘should not’ have special meaning in the context of specifications like WCAG. This meaning is defined in a document called RFC 2119.

What’s normative in WCAG

The part of WCAG that is normative is the main WCAG text itself: the Principles, the Guidelines and the Success Criteria.

What’s not normative in WCAG

Some of the WCAG text is not normative, like the Introduction section. It is marked as such (“This section is non-normative”).

There is also a number of documents to help use WCAG, including Techniques and Understanding documents. These documents are not normative either. They are additional information, context and examples, but not requirements to meet the norm (see 5.1, Interpreting Normative Requirements).

For instance, if you would evaluate whether a website meets the WCAG criteria, what matters for conformance is the text of the relevant criterion. The text in a Technique or Understanding document can help understand the intents and purposes of the norm, but it is not the norm. You don’t need to follow any specific Technique to be conformant.

The same goes for pages like ARIA Authoring Practices Guide, which is a Working Group Note. For more info on different kinds of see also Documents published at W3C.

The norm is the core

In most standards, the part that has become the norm was discussed and tweaked by many people over an extended time. Working Groups often spend years ensuring a wide variety of people was consulted and many views heard. There are likely many other things that could have made it in, but this was the text on which the Working Group reached consensus: it was supported by a substantial part of the group, and no formal objection was registered.

That leads me to an important point regarding WCAG: the normative part is the minimum to make your site work for users with disabilities. There are lots of best practices outside WCAG scope that benefit actual people–absolutely do find and use those!

Conclusion

In WCAG, the main text is normative, which means it is required to meet the standard. Other texts like Techniques, Understanding documents and ARIA Authoring Practices are not, they provide useful context, examples, background information and more.

Originally posted as What's ‘normative’ in WCAG? on Hidde's blog.

[email protected]?subject=Reply%20to:%20What's ‘normative’ in WCAG?">Reply via email

Criticism pushes the web forward

2021-05-08T00:00:00Z

This week, a friend shared a blog post that critiqued a popular framework for CSS. Twitter started to discuss if it’s okay to criticise tools. In this post, I’ll say it is not just okay, it is also important.

I was a little disappointed to see the replies to this tweet. Among the many replies, the person who came up with the framework exclaimed seeing the post shared by her “ruined” his day. Note: the post was not about him, it was about the framework (the one that, on its homepage, criticises other people’s CSS methodologies) . Other commenters said the article was “not worth sharing”, “you’re just starting of fights” and “why would you amplify that?”.

I’m not interested in attacking anyone here, or going into the merits or faults of The Post, but would like to answer that last question. Or, in fact, a more generic one: “is it okay to criticise tools?”

Listening helps

The short answer is: yes. As long as it is aimed at the tool, not the person that created it, it is better to share criticisms than not. I have never been involved in the development of frameworks for the web, but in standards for the web, like HTML, CSS and ARIA, there is lots of criticism. People poke holes in each other’s assumptions, suggest ways to make features better and explain why things don’t work well for them. Good standards require diverse perspectives.

Again, the kind of criticism I’m talking about here is criticism of the content, not a person. Is some proposal vague? Should we really call that property “left justify” or number-form seems counterintuitive as a property name–just two examples of critiques of the first version of CSS, in 1995. They’ve made CSS better, because we’ve ended up with better names. Thanks to the people who took the time to send in comments. This is, for over 25 years, how we’ve evolved the web: by listening to each other and not taking critical comments personal.

Can we “just not use it”?

Maybe web standards like CSS are different. The web is built on it and you cannot not use CSS when you build a website. Browsers have stylesheets. But if we’re honest, the most popular tools and frameworks also impact all of us. Most web developers don’t always get to choose their own tools and frameworks, they join a team with existing code or have team members with other opinions.

I’ve never included Bootstrap in a project myself, but have contributed code to many projects that did. Just like it is helpful to comment on web standards, it is helpful to comment on tools and frameworks, because they too affect us all. This goes both for whether to use the thing at all, and for features the thing has or lacks.

Like critical thinking pushes the world of ideas forward, I mean in philosophy, criticism of ideas for standards, tools and frameworks pushes the web forward. We should give feedback respectfully and constructively, but we should give feedback. And open up to feedback, not demand it to go away. It may not be easy, but it is important to include perspectives outside your own.

Originally posted as Criticism pushes the web forward on Hidde's blog.

[email protected]?subject=Reply%20to:%20Criticism pushes the web forward">Reply via email

150

2021-05-18T00:00:00Z

This blog has now reached the somewhat random milestone of 150 posts. When I asked around what post #150 should be about, the Twitterverse said “blogging”. Well, OK!

Fun fact, this isn’t my first blog: from 2008 to 2014, I had a travel blog, where I tried to write funny posts about my trips abroad for family and friends. This blog is different as I try to, ahem, add “something” to the field of web development, I fact-check, look for previous work to credit and try to keep posts with technical recommendations up to date.

Why personal blogs are great

The fact that so many people publish their thoughts and share knowledge, is something I’ve always loved about the web. Whether it is practical stuff about how to solve a coding issue or some kind of opinion… everyone’s brain is wired differently. It may resonate, it may not, that’s also fine.

People’s blogs are what helped me get started in this industry and get a feeling for the kinds of problems we’re trying to solve. I started doing web development around 2006, and at that time, lots of people blogged. Many of the conversations happened on blogs. Since 2013, this blog is my attempt to join some of the conversations.

Blogging is like “a kind of catharsis”, said Bruce Lawson once in 2005:

In the old days, people used to shout at passers-by in the street; these days, we blog.

(Don’t follow the link and read about his other analogies to blogging)

Writing in public feels great, even if no one reads it, says Sara Soueidan in her post Just write:

Just write.

Even if only one person learns something from your article, you’ll feel great, and that you’ve contributed — even if just a little bit — to this amazing community that we’re all constantly learning from. And if no one reads your article, then that’s also okay.

It is ideal to do this on your own website. Matthias Ott put it beautifully in his post Into the Personal-Website-Verse—personal websites are about expressing and exploring yourself:

Personal websites are called personal websites because they are just that: personal. Thus, the primary objective still is to have a place to express ourselves, to explore ourselves, a place that lasts while the daily storms pass by. A place of consideration, and yes, a place of proudly sharing what we do, what we think, and what we care about. A place to contribute your voice and help others. A home on the internet. A place to tell your story.

This resonates so much.

Why blog

Social media is hard to search

Do you ever think “there was this tweet by X about Y” and attempt to find it? This can be really hard, as new tweets appear all the time in this endless stream of opinions, thoughts, jokes and anger. You may want to go to a person’s profile and look for the tweet, but with the endless loading that breaks CTRL/⌘ + F, I usually wish my past self had saved a direct link.

In contrast, your blog is “a place that lasts”, as Matthias says above. If you take those tweets and put them into context on your blog, that will make the conversation easier to find them later.

Social media is not optimised for organising thoughts

Not only do posts on social media fade away over time, they also have character limits. While you save words, you likely leave out nuance. Threads exist, of course, but on your website, people don’t have to click to try and expand more content. You get all the space you need.

Own your content

When you publish on your site, you own your content in a way not available on any of the centralised platforms, like Twitter or Medium.

Khoi Vinh says about this in an interview:

I personally can’t imagine handing over all of my labor to a centralized platform where it’s chopped up and shuffled together with content from countless other sources, only to be exploited at the current whims of the platform owners’ volatile business models.

Ana Rodrigues lists this and many other advantages of owning your own content in her fantastic post Autonomy online: a case for the IndieWeb, which also contrasts the IndieWeb with the Corporate Web.

What I write about

This blog isn’t particularly structured, but scrolling through the past 149 posts, I did find some common themes. I had forgotten about a lot of the stuff. Warning: there are a lot of links below.

Summaries of events

Sometimes, I write summaries of the conferences I attend, like when I met the TAG, attended ConfConf and joined MozFest. This requires me to hold my phone while listening, frantically taking notes, while being focused on what is being said. After the event, I structure my writings and try to piece together summaries per talk, adding links, sometimes revisiting slide decks if they’re available. This is exhausting, but helps me personally process what I’ve learned. It usually also leaves me with many tabs open and a bunch of self doubt about properly representing the speakers’ points.

Opinions

I’ve also published some ‘hot takes’. The one I’m now most embarrassed by is the clickbaitily titled Bootstrap considered harmful. Let’s say I had not read Eric Meyer’s awesome “Considered Harmful” Essays Considered Harmful yet, and I was younger. I also wrote about Web Components and which kinds we need, overengineering CSS, “your mom” jokes in corporate culture, why Uber’s for everyone isn’t like Timbl’s and why slowness of websites is optional.

Components

In the last 10 years component systems ruled front-end development. Before that, it would not be uncommon to be hired to build some full pages. Those times are gone. Components have been a favourite subject to write about. Recently this was about accessibility claims of third-party components, before that I wrote about baking accessibility into components, frameworks and standards, Web Components and native elements, the websites as an instance of a design system, grids and components and accessibility in pattern libraries.

Reading lists

I did some reading lists, too, with recommendations about AI, equality, tech and society and more equality.

Accessibility

Some of my more technical articles are about accessibility. I wrote about how accessibility trees work, alternative text and when you don’t need it, accessible names and focus traps. There were also posts about testing pattern library accessibility, inline error messages and making websites more mobile friendly.

CSS

I praised the wonders of CSS in many of the posts. It lets you style things that don’t even exist yet, has simplicity as its core principle and can be used to rebuild awesome posters. To me, the cascade is a feature, not a bug and I feel simple fallbacks for Grid Layout are preferred to complex ones.

My favourite local conference is CSS Day in Amsterdam and I did write-ups for CSS Day 2019, CSS Day 2017.

Progressive enhancement

One of my first posts about progressive enhancement was about an approach for progressive enhancement with data--attributes and I did a follow-up on initialising script from mark-up. More recently I wrote about the merits of separating HTML, CSS and JS.

Here’s to the years to come!

There are lots of things I would like to do better. One is to write better, maybe by writing more. Maybe also by submitting to other publications, so that I can get more feedback on my writing. There’s so much to learn about writing and it’s hard to learn alone. I would also like to write more interesting content (don’t we all? 🤓). So far I noticed something interesting can come out when I don’t expect it, and write something short that I never really planned to write about. Probably think about it less?

Anyway… I’ve really enjoyed having my own blog and I hope to continue posting for many years to come. Thanks everyone for support and encouragement, you know who you are! I hope to be back soon with a post that is more useful than this one.

Originally posted as 150 on Hidde's blog.

[email protected]?subject=Reply%20to:%20150">Reply via email

Introducing: an Eleventy starter project for WCAG reports

2021-05-24T00:00:00Z

When I audit websites for accessibility, I write Markdown files that Eleventy turns into reports. Today, I’ve shared the code I use for that. In this post I’ll provide some context.

At eleventy-wcag-reporter, I have published my Eleventy starter for reports about conformance to the Web Content Accessibility Guidelines (WCAG). It is issue oriented, promotes rich text, comes with a PDF export script and supports two languages (English and Dutch).

There is an example report available.

Note: this is just one specific way to create accessibility conformance reports. This works for me and my clients. Other approaches and requirements exists, and I can’t guarantee this works for you.

Issue-oriented reporting

WCAG conformance reports document whether a website meets the criteria in the WCAG standard. It will tell the reader which Success Criteria met the standard, which did not.

Many WCAG conformance reports list WCAG in its entirety and then specify the result for each. Say, a website is tested for WCAG 2.1, Level AA and 10 problems are found. The report will show all 50 Success Criteria (SCs): 10 say “Failed”, 40 “Passed” (or something else, like “Cannot Tell”). The accessibility problems are metadata of the success criteria, so to say.

In this Eleventy project, you’ll create one file for each issue

In my personal experience, teams that commission a report are mostly interested in the actual accessibility problems. They want to know “what needs fixing”. They may also want to know: how severe are the issues in comparison, which expertise can solve it (design? development?) and which assistive technology is affected. And, where relevant, what the issue or solution looks like in code. This is why I provide clients with an issue-oriented report: a list of issues, rather than a list of SCs. The Success Criterion is added as metadata of the issue, rather than the other way around.

A benefit of the issue-oriented approach, is that it can integrate better with a team’s workflow. Issue trackers are more common in workflows than SC-trackers. It also, as mentioned, makes it easier to include other meta data like responsibility and severity, and to include code examples and screenshots.

WCAG-EM, the standard methodology for accessibility conformance reporting, does not specify either of the two approaches. What is important for a conformance report is that all Success Criteria were evaluated, and that this fact is made clear. You want to be sure that “no issue filed for an SC” really means the sample did not contain any issues for that SC.

In other words: the report is only done when you’ve checked all sample pages for all WCAG Success Criteria in your scope (i.e. all 50 criteria for WCAG 2.1, Level A + AA). Always test them all. If your report follows the SC-based approach this is explicit, in the issue-based approach it is implicit.

The power of Markdown and YAML

One of the benefits of using Eleventy for my reports, is that it makes it easy to write rich text. That may sound like a no-brainer, but in many reporting tools I’ve seen, issues are described in plain text. The main reason I want to use rich text to describe issues, is that they can make tips more clear. Lists, links, images, code examples and even text level stuff like bold and italics can make a report more readable. This is important, because it increases the chance the team can fix the issues found.

Markdown is my favourite syntactic sugar for rich text, so that’s what I use, but you can use whatever else. HTML should work, too.

For each issue that is described, there is also a set of meta data, like which Success Criterion it relates to. It is described in Yaml front matter, so at the top of an issue.md, you would add something like:

---
sc: 2.1.1
severity: High
difficulty: High
title: Main menu does not work with keyboard
sample: homepage
---

Spelling out the meta data in front matter makes it powerful. We can do things like add up the issues filed for a specific page, or count how many were filed for a given Success Criterion.

Some essential metadata in WCAG conformance reports

Pointing out accessibility problems and solutions is the bread and butter of my conformance reports, as my goal is usually to help the team fix all issues. But accessibility reports are used in various contexts. There is some important metadata that helps someone looking at the report what’s going on, including monitoring bodies like governments. They may require publication of accessibility conformance reports to help them perform their regulatory duties, good metadata aids this monitoring.

Logius, the Dutch government department that keeps track of WCAG conformance reports that Dutch governmental organisations provide, uses a checklist to verify if conformance reports meet their requirements:

is the methodology (eg WCAG-EM) mentioned?
is the scope mentioned (domain and/or sub domains that are in scope, and those outside scope)
does the report declare that all 50 Success Criteria in WCAG 2.1, Level A + AA were evaluated?
is the level of accessibility support described (for instance: “the website can be used by all common browsers and assistive technologies“)?
is there a list of technologies used (eg HTML, CSS, SVG, etc)
is there a list of pages that were included in the evaluated sample?
is the person or company that did the evaluation listed?
are browsers and other software, including versions, listed?
is it dated?
are the results published in a human-readable or machine-readable format (EARL)?

The above is my translation of the checklist on the Controle door Logius page; many of these are also recommended in WCAG-EM; the requirements likely vary where you or your client are based.

The eleventy-wcag-reporter starter project has variables for each of these checkpoints. A lot of the meta data is added to the report’s index.njk as YAML front matter, so that it can be displayed.

FAQ

After reading this, you may have questions before trying to use the code. The questions below weren’t actually asked frequently, but I hope they have useful answers.

Will this find accessibility issues?: No, you find issues, create a Markdown file for each and then add some frontmatter. The code will then include it in a pretty report. Or really, a report that you can make pretty.
Why not integrate with automated tooling?: There are tools that can find issues, for ~20% of WCAG criteria (other estimates exist). You can use those tools to find issues and add them manually. It is usually easier for a human to group issues in a way that is most useful to readers of the report. For instance, if a brand’s primary colour contrasts badly with a white background, you may not need to file that more than once.
Can more languages be supported?: Yes, feel free to contribute. We need all of WCAG in JSON format (I have code to scrape) and translations for strings.
How many issues should I add to a report?: There is no minimum or maximum, but you should check all pages in your sample for all Success Criteria in your scope, and have issues for all situations where a SC is not met, in order to create a full report.
What about PDFs?: I like HTML as a report format. Some organisations prefer to receive a PDF document. Like web pages, PDFs also need to be accessible, and simply pressing “Save as PDF“ in a browser will be unlikely to include all semantics. So I use PrinceXML, which supports a lot of print CSS. There are licenses for a machine or server, or you can use the SaaS version DocRaptor. The starter project has a Shell script to generate a PDF with PrinceXML, you will need a license or end up with a watermark in your resulting PDF.

Wrapping up

So, find my starter project at eleventy-wcag-reporter, please don’t laugh at my code. Feedback is very much welcomed by email, DMs or in GitHub. I may not be able to get back very quickly, as the open version of this is a side project. Happy accessbility conformance report writing!

Originally posted as Introducing: an Eleventy starter project for WCAG reports on Hidde's blog.

[email protected]?subject=Reply%20to:%20Introducing: an Eleventy starter project for WCAG reports">Reply via email

Solutionism

2021-06-28T00:00:00Z

There is this internationally recognised physical proof of vaccination. Earlier this year, the Dutch health ministry said it won’t be used for registration of Dutch COVID-19 vaccinations. Why not? Well, an app was on the way.

The ministry was somewhat right. There wasn’t international agreement about use of that physical card for covid vaccinations. But there were other authorities, like the German government, that already accepted it. There was a use case. The EU Digital Covid Certificate, that the ministry put their money on, does sound promising. And it’s standardised across the EU.

But the dismissal of the paper proof, I feel, is a case of “solutionism”: you work on one solution for a problem, then forget there may be other ways to solve it, too. Why is that an issue? Multiple layers of solutions often work better. Especially if the dismissed is something physical and the new solution is some fancy new technology (see also: tech stacks on the web).

Don’t get me wrong, I like apps (though I prefer web apps). I work in technology. I like technology, and all the advancements it brings us. But as websites are best built from the simplest part of the stack outwards—HTML first, the rest later—something similar goes for including technology in society.

One of the powers of progressive enhancement is that it lets you cover use cases you didn’t know existed. Did your user’s JS download fail as they lost connection in a train tunnel? No biggie, you didn’t uniquely rely on JS, you didn’t assume it, it was just one of your layers.

A paper proof of vaccination could be a sensible baseline, on top of which more demanding technological solutions could be built. Demanding in the sense that they require digital literacy, smartphone ownership and what not. For some, the paper proof was their only way to enter the country they worked, especially if that was a country outside the EU. Paper proofs have their benefits and their problems, so do digital proofs.

IRL progressive enhancement is quite common when you think of it. You can board planes with paper boarding cards, but also with technology like QR codes and digital wallets. You can pay for a coffee with cash, card or phone. The variety serves diverse sets of people. Just like in web development, not dismissing the baseline lets us cover use cases we didn’t know existed. It is fragile, though: some manager somewhere probably has a fantasy about replacing everything with fancy tech and fancy tech only. (In fact… it’s quite common for shops not to accept cash where I live)

Just recently, the Dutch health ministry turned around and changed their guidance: the paper proof of vaccination will now be stamped for those who ask. In a different context, a service from that same ministry now offers a way to print a QR code to gain access to events following a recent corona infection, negative test or vaccination. Folks can use the app if they want to. Heck, the app is probably more convenient for many, but at least there is a paper fallback. Yay!

Originally posted as Solutionism on Hidde's blog.

[email protected]?subject=Reply%20to:%20Solutionism">Reply via email

A case for accessibility statements in app stores

2021-08-03T00:00:00Z

In Apple’s App Store and Google’s Play Store, apps can have certain bits of meta data. Categories, localisations, price, privacy policy URL… but where is the meta field for accessibility statements?

I’m more of a web person than an app person, but my clients sometimes need to publish statements about their apps. Accessibility is important to a large part of app users, showed Dutch web consultancy Q42: in over a million app users, they saw 43% use accessibility settings.

If app stores would have a field for accessibility statements, this would be good for users, organisations and developers, plus it highlights accessibility as something to compete on.

What is an accessibility statement?

An accessibility statement shows users that you care about accessibility and helps them understand what the expected level of accessibility is on your website or application (see also: Developing an Accessibility Statement).

Sites and apps that fall under EU Directive 2016/2102 (Article 7, section 1) require an accessibility statement, in a specific format. Other sites and apps can also benefit from some form of accessibility statement.

What is included in an accessibility statement?

In their accessibility statement, website or application creators declare whether their app is fully, partially or not accessible. If one of the latter two, they also list what the known issues are. Commonly, there is also information about when the website or application plans to address each issue.

Accessibility statements also include evidence of their accessibility claims. Usually this is a full WCAG conformance evaluation report, following a methodology like WCAG-EM. But accessibility does not equal WCAG conformance, you might say. This is true, it is ‘just’ a baseline. Yet, there is no other document with such a widely agreed baseline, so it is best to use this one.

Accessibility statements can also contain a feedback mechanism (they must, if published in a country that has implemented that EU Directive). Feedback mechanisms let people find out how to request content in a format that is accessible to them (e.g. can I have that untagged PDF as a Word document?), and where to report accessibility issues.

App stores have fields for privacy statements

Both the Apple App Store and the Google Play Store have a meta field available for privacy statements.

In Apple’s ecosystem it seems to be part of App Infos, in Google Play, developers can submit it through the Google Play Console.

Google does this, because they care about user privacy. They write in their Google Play Safety Section blog post:

At Google, we know that feeling safe online comes from using products that are secure by default, private by design, and give users control over their data.

It’s framed as letting developers showcase how well they do on privacy:

This new safety section will provide developers a simple way to showcase their app’s overall safety.

I, for one, applaud this effort. User privacy is super important and explaining privacy features is helpful. A standard way to do it helps users find this information more easily.

I would say we can apply the same thinking to accessibility. As mentioned earlier, app users require accessibility. It is likely they will want to find accessibility information easily. App developers and designers work hard on ensuring their app’s accessibility, so why not give them a way to showcase that too?

Why app stores need accessibility meta info

Accessibility meta info in app stores would be good for several reasons:

helps users understand the accessibility of an application better, and learn easily and consistently about where to file accessibility bugs or request accessible versions
helps organisations comply better with EU Directive 2016/2102, which says they should display an accessibility statement
helps developers show their commitment
renders accessibility as yet another aspect to compete on for application developers, because many consumers will use this to make purchasing decisions

Conclusion

App stores can be a helpful proxy between users and app creators. The vetting mechanisms and categorisations (try to) filter out low quality. They also make it easier for users to find what they need. This is why they provide filters for user-oriented features. If that’s great for privacy, it would be great for accessibility, too. Please, app store makers? 🙏

Originally posted as A case for accessibility statements in app stores on Hidde's blog.

[email protected]?subject=Reply%20to:%20A case for accessibility statements in app stores">Reply via email

How AI is made matters, confirms “Atlas of AI”

2021-08-16T00:00:00Z

Artificial Intelligence (AI) is often described as smart, efficient and superhuman. That sounds quite nice, but it leaves out a lot of details. In her book Atlas of AI, Kate Crawford maps out the power systems, impact on society and stakes that come with deploying AI. That’s important, because we, and the systems that affect us, increasingly rely on these technologies.

There are lots of worthwile pursuits in AI: we can make computers understand our speech, teach medical devices to recognise irregularities in scans and analyse financial transactions for fraud. But there is plenty of applications that may not actually contribute all that much, or are downward hostile if you consider what could go wrong. Systems deployed to surveil workers, filter resumes or drive cars (sorry) may not be worth their damage.

Natural resources and people

The impact of AI starts with the raw materials of machines, Crawford explains. Computers need chips and those require rare earth materials like tin. It’s easy to forget about that: mining such materials isn’t without consequences. It badly affects workers (and their conditions when working in mines), their direct environment (pollution) and the earth at large. Once the chips exist and machines run, there is also an environmental impact. The data centres that compute our data require enormous amounts of gas, water and electricity. One of the largest US data centres uses 1.7 million gallons of water per day, is just one of the many examples Crawford provides. When a company says ‘our product uses AI’, their product also uses these raw materials, these data centres and this energy.

Reassuringly, most big tech companies have very green ambitions, like powering 100% of their data centres with renewable energy. This is good. But when not all of the world’s energy is renewable, we’ve got to be sure there are good reasons for any energy that is used. We’ve got to focus on using less of it, and endlessly processing ginormous amounts of data does not help.

Input data and classification

Crawford also writes about the basic ingredient for AI and specifically machine learning: data. To teach machines about a thing, we need to show them examples of the thing. To produce AI, a company needs to collect data, ‘mine’ it, if you will. Data, like text messages, photos, audio or video. It is often collected without the consent of the people involved, like the people who are in the photos. Crawford warns us against ‘the unswerving belief that everything is data and is there for taking’ (AAI, 93).

There are exceptions, like Common Voice, a Mozilla project that aims to ‘teach machines how real people speak’ by asking people to ‘donate their voice’. The teaching machines part is not unlike other machine learning projects, but the data collection is. Common Voice data is not taken from some place, people provide it consentually and for the very purpose of training machines. This is uncommon (pardon the pun).

And then there is the issue of context. When images become data, context is considered irrelevant, it no longer matters. They serve to optimise technical performance and nothing else. This data is now seen as neutral, but, explains Crawford, it is not:

‘Even the largest trove of data cannot escape the fundamental slippages that occur when an infinitely complex world is simplified and sliced into categories’ (AAI, 98)

Taking data out of context also doesn’t remove all context. A data set could affect privacy in unexpected ways. Crawford discusses a set of data from taxi rides, that may have looked quite innocent and useful from the outset. What could go wrong? Well, from the data, researchers could deduce religions, home addresses and strip club visits.

Classification

Machine learning requires input data to be classified. This is a fire hydrant, that is a bicycle. Some firms pay people through Mechanical Turk… there are workers who spend all day describing images. Other companies demand the work to be done for free by users who want to login (hi recaptcha).

Perhaps more important than who does the work are the philosophical problems of classification. Is there a fixed set of categories? Does everything neatly fit in them? Such questions have boggled philosophers’ minds for, literally, millenia. It’s safe to say most would say no to either question. Yet, AI firms seem more confident. They have to, as classification of data is at the heart of how machine learning works.

The harm caused by classification problems depends on the subject, but it is widespread. Maybe the AI that was trained with some wrongly classified fire hydrants won’t cause too much trouble. But there are endlesss examples of AI exhibiting awful bias, including towards race and sexual orientation. Bias in AI has been seen as a bug to be fixed, but it should be seen as a problem of classification itself. ‘Classification is an act of power’, says Crawford (AAI, 127). The categories can be forgotten and invisible once their work in the model training phase is over, but their impact remains.

You can’t fix bias by merely diversifying a set of data, Crawford says:

‘The practice of classification is centralizing power: the power to decide which differences make a difference’ (AAI, 127)

Sometimes researchers measure the wrong thing, because are constrained by what they can measure. For example, it’s easy to measure skin colour, but it’s not the thing to measure if you’re after understanding something about race or ethnicity. It doesn’t work that way… ‘the affordances of the tools become the horizon of truth’, Crawford concludes.

Open data collections often show categories that reinforce racism and sexism, and that’s just the sets we can see. Is there a reason to assume the sets of Facebook and Google avoided these problem?

Emotion recognition and warfare

The last two chapters of “Atlas of AI” consider two of the scariest answers to ‘what could possibly go wrong?’: AI tech for emotion recognition and warfare.

Me at The Glass Room in Leeuwarden in front of an art work about emotion recognition

Research in emotion recognition, Crawford writes, comes from a ‘desire to extract more information about people than they are willing to give’ (AAI, 153). It is already in use by HR departments to scan applicants and try and match their facial expressions to personality traits.

Can it work? Scientists including Paul Ekman tried to find out whether emotions are universal. Some were confident, but as of yet there is no consensus on which emotions exist and how they manifest (AAI, 172). Crawford explains there is growing critique doubting the very possibility that there is a clear enough relationship between facial expressions and emotional states (AAI, 174). It’s merely correlations, she says:

In many cases, emotion detection systems do not do what they claim. Rather than directly measuring people’s interior mental states, they merely statistically optimize correlations of certain physical characteristics among facial images (AAI, 177)

So, like with other AI systems, AI for emotion recognition relies on categorisation, which Crawford explained is flawed and an act of power, so it has many of the same problems:

[An analysis of the state of emotion recognition] returns us to the same problem we have seen repeated: the desire to oversimplify what is stubbornly complex, so that it can be easily computed, and packaged for the market.

And while this may work for companies selling AI systems, the end result is likely a lack of nuance:

AI systems are seeking to extract the mutable, private, divergent experiences of our corporeal selves, but the result is a cartoon sketch that cannot capture the nuances of emotional experience in the world.

Governments use AI for warfare, in the US the ‘Third Offset’ strategy includes leveraging Big Tech to create infrastructure of warfare (189). In “Project Maven”, the US Department of Defense paid Big Tech firms to analyse military data from outside the US, like drone footage, to build AI systems that could recognise ‘vehicles, buildings and humans‘ (AAI, 190)

Crawford describes a shift from debating whether to use AI in warfare at all, to, as former Google CEO Eric Schmidts said, whether AI would be able to ‘kill people correctly’ (AAI, 192)

‘Militarised forms of pattern detection’, Crawford explains, go beyond national interests when companies like Palantir sell their technology widely (eg local law enforcement and supermarket chains). They are focused not on enemies of the state, but ‘directed against civilians’. Machine learning based patten recognition tech is used to find ‘illegal’ immigrants to deport (‘illegal’, because no humans are illegal). In Europe, IBM was tasked to use data analysis to assign refugees a ‘terrorist score’, capturing the likelihood of them being a terrorist. This would be a bad idea if AI systems were 100% able to make such distinctions, and let’s be clear: they can never be. Because of the inevitability of bias and the very nature of categorisation. If even humans don’t universally agree about what constitutes a terorrist, and they don’t, how can any human categorisation we do successfully help teach machines?

When systems impact government decisions, they requires oversight, and there is very little of that, explains Crawford (AAI, 197). Without that, we risk making things worse, she says:

Inequity is not only deepened, but tech-washed, justified by the systems that appear immune to error yet are, in fact, intensifying the problems of overpolicing and racially biased surveillance

Summing up

Atlas of AI provides insight in what we give up when employing AI. There may be applications that are mostly helpful and little harmful, like language. There are applications that probably harm more than help, like emotion and warfare.

The book also reassures us that some things may not be as computable as they seem. Good categorisation is hard for humans and harder for machines. There is this fantastic tv show broadcasted on Dutch television called Zomergasten: a person of interest is interviewed for 3 hours straight on live television, and they bring in their favourite video fragments. YouTube may have state of the art machine learning powered recommendation engines, the suggestions these people bring often delight and surprise me more.

Above all, Atlas of AI will give you a fresh perspective that you can use when you read about the next thing AI is claimed to solve. Yes, the possibilities are promising. The features often cool. But we’ve got to keep our feet on the ground and assess AI technologies carefully.

Originally posted as How AI is made matters, confirms “Atlas of AI” on Hidde's blog.

[email protected]?subject=Reply%20to:%20How AI is made matters, confirms “Atlas of AI”">Reply via email

Trying out spicy sections on here

2021-08-17T00:00:00Z

This week I had some fun with <spicy-sections> , an experimental custom element that turns a bunch of headings and content into tabs. Or collapsibles. Or some combination of affordances, based on conditions you set.

Background

Introduced in Brian Kardell’s post Tabs in HTML?, the <spicy-sections> element is a concept from some folks in the Open UI Community Group. In this CG, we analyse UI components that are common in design systems and on the web. The goal is to find out which ones might be suitable additions to the platform, the HTML spec and browsers.

All design systems teams could come up with their own tabs and figure out semantics, accessibility, security and behaviours. But what if some (or all) of those things could be built into HTML, with browsers implementing smart defaults? A bit like the video element… as a developer you only need to feed it a video and some subtitles, and boom, your users can enjoy video. Maybe your specific website needs the play button to be pink or trigger confetti, but generally, there are quite a lot of websites where the default is just right.

The nice thing about platform defaults is also that it can be optimised for the platform that renders it: a select on iOS is different than a select on Microsoft Edge. They work well on these respective platforms. Yes, everyone would like more control over styling of selects, and Open UI is looking at that too (and yay, accent-color is a thing soon). But can we know which styles a given user needs as well as the platform can?

Why spicy sections?

Tabs are among the most frequently requested components. They are also tricky. Some of the considerations:

meaning: tabs in your browser manage windows, tabs in a webpage manage, eh, sections? These are quite distinct.
accessibility: with ARIA, there are at least two ways to do tabs (eg activate on focus or not?), and in some user tests I saw, users prefers ARIA-less tabs
what about disabled tabs and user dismissable ones?
overflow: what if not all tabs fit on the screen? scrollbars?

(The Tabs Research from Open UI CG has many more tab engineering considerations)

The overflow issue begs the question: does content displayed in tabs always belong in tabs, or might there be better controls in some situations? Maybe on small screens we need to get rid of the tabs and use collapsibles? (Maybe we need to ‘uncontrol’ them in specific cases, like print?)

This makes all the more sense if you consider tabs in web pages are really just a different way to display sections and their headings. Headings are tables of contents, after all. “Spicy sections”, then, would be a web platform feature that lets you display sections in different ways: linear, as is the default way to display sections now, as tabs or as collapsibles. You pick which based on constraints, and media queries are the way the spicy-sections demo defines those constraints.

Yes, <spicy-sections> is a demo, the element exists to explore ideas and start the conversation. Brian encourages you to share your thoughts:

Play with it. Build something useful. Ask questions, show us your uses, give us feedback about what you like or don’t. This will help us shape good and successful approaches and inform actual proposals.

As Brian says in his post: it is critical that web developers see these proposals way before they exist in browsers. So if you happen to be a front-end developer reading this… consider if you like this experiment, share your thoughts or questions, don’t feel shy to open a GitHub issue.

Four sections, but spicier

On this website I have a fairly boring page that lists some stuff I do as a freelancer: services. Each service has a h2 and a bit of content. I decided to use this for testing the spicy-sections element IRL.

To get it to work, I included SpicySections.js, a JavaScript class that defines a custom element. The element looks in your CSS for a definition of when you want which affordances. I went for this configuration:

collapsibles when max-width: 50em (my mobile state) matches
tabs when min-width: 70em matches
otherwise, just the headings and content as they are

I could set this in my CSS, using:

spicy-sections {
  --const-mq-affordances: 
    [screen and (max-width: 50em) ] collapse |
    [screen and (min-width: 70em) ] tab-bar;
}

I rewrote my markup to have the following expected structure:

<spicy-sections>
  <h2>Name of heading</h2>
  <div>
    content be here
  </div>
  … repeat the h2 and div for more sections
</spicy-sections>

(also works with other headings; h1, h3, etc)

Note: this isn’t final syntax, it could be something else entirely, suggestions are welcomed.

Some overrides

After I had ensured my markup had the right shape, I included the SpiceSections JavaScript and I set my constraints in CSS, it worked very much as advertised. There were two things I tweaked.

Vertical tabs

With spicy-sections, you’re using headings as tab names. It seems my page has quite long headings. Horizontally, I didn’t have sufficient space, so I wanted mine to go vertical instead.

I got this to work by adding an extra affordance to the web component class, some code to set aria-orientation to vertical and a bit of CSS to make it work visually. I set white-space to normal and made spicy-sections a flex container in the row direction, for easy same height columns.

I could have done this all in CSS, except for aria-orientation, but I am unsure about the benefit of the attribute here: arrow keys for both orientations are supported by default.

Overriding a margin

In my website’s CSS, I have this line (don’t judge 😬):

*,
*::before,
*::after {
  margin: 0;
  padding: 0;
  box-sizing: border-box;
}

It somehow overwrote the right margin on the arrows that spicy-sections throws in for the collapsed view. No biggie, with CSS’s excellent cascading functionality this was easy to fix.

Nesting

I have also put some spicy-sections inside my spicy-sections: I have some ‘examples’ listed on the side on larger screens, it made sense to me to show them collapsed on smaller screens. This can be done with a combination of spicy-sections:

<spice-sections>
  <h2>A section</h2>
  <div>
    <spicy-sections>
      <h3>Oh my, I am nested!</h3>
      <div/>
    </spicy-sections>
  </div>
  …
</spicy-sections>

and this CSS:

.spicy-services-examples {
  --const-mq-affordances:
  [screen and (max-width: 50em) ] collapse;
}

So basically, I only list one affordance and it only applies to “small screens”, or what that means on this site.

Thoughts

This is all a long winded way to say: I quite like the idea of conditionally changing the appearance of sections. I think it makes sense on the web, because our sites and apps are viewed on so many different screen types and sizes (screen spanning, anyone?). Horizontal tabs are probably not always the best affordance, other affordances make sense in some situations, so a mechanism to switch between them is useful.

The way the experimental component works happens to be very styleable. When I was implementing it on my site, I felt I could make everything look exactly the way I wanted it to look. The tabs are just h2 elements and you can do whatever you want to them, using the styling language we all know and love: CSS.

Reusing media query-like syntax for defining when to use which affordances is helpful. Folks who build responsive websites will be used to them already.

There are also some uncertainties that came to my mind:

will people get it? Wrapping some content into a spicy-sections sections element fits well into the way I think about content on the web, I think about markup a lot, it matters to me. I fear it could feel weird to others, especially designers and developers who aren’t very concerned with markup, or who don’t see headings as tables of contents
is this easy to author in a CMS? In theory this would work well with any CMS content, it could be used with CMSes that exist today, because the markup that is required is “just” headings and content. There may be some trickery required to wrap the content underneath each heading into a div, and the set of sections into the right element, but that should be minor.
are there other affordances that are not in the current proposal? Maybe something that automatically generated a table of contents kind of thing, like GitHub does for READMEs?
could it confuse users that semantics and accessibility meta data (roles, states) can change based on constraints?

Wrapping up

Thanks for reading this write-up! If you like, please play with Brian’s demo on Codepen, perhaps use spicy-sections somewhere and give feedback if you have any.

Originally posted as Trying out spicy sections on here on Hidde's blog.

[email protected]?subject=Reply%20to:%20Trying out spicy sections on here">Reply via email

Subsets and supersets of WCAG

2021-09-08T00:00:00Z

“Could you give us a checklist for accessibility, please”, is a frequently asked question to accessibility consultants. Checklists, while convenient, reduce WCAG to a subset. To maximise accessibility, we likely need a superset. This post goed into how both subsets and supersets can be helpful in their own ways.

Why WCAG

In this post, I’ll consider WCAG the baseline, as many governments and organisations do. Accessibility standards are by no means perfect, but they are essential. To get their web accessibility right at scale, organisations need a solid definition of what “success” means when building accessibly. Something to measure. Such definitions require a lot of input and perspectives. They necessarily take long. Standards like WCAG are the closest we have to that, and yes, they have gotten a wide range of input and perspectives. In other words, full WCAG reports are a great way for organisations to monitor their accessibility.

We can’t be doing full audits all the time, if only because those are best done by external auditors, outside the project team. On the other end of the spectrum, just performing WCAG audits isn’t enough. To maximise accessibility, our organisation should test with users with disabilities and include best practices beyond WCAG.

Subsets

Using subsets of WCAG, more team members can work on accessibility more often. More team members, because checklists often require less expertise, and more often, because doing a few checklists requires no planning, unlike conducting a full WCAG audit.

Why settle for less?

Accessibility standards can be daunting to use. If we commit to WCAG 2.1 Level A + AA conformance, there are 50 Success Criteria that we should check against. For every aspect (content, UI design, development etc), for every component. I often hear teams say that this too much of a burden. If we want to decide what applies when and to which team members, we’ll need to be well-versed in WCAG, or hire a consultant who is. Regardless of whether we do that (please do, regular full audits are essential), it makes sense to have some checks that anyone can perform.

Sidenote: of course, in real projects, it takes less to evaluate against the full set of WCAG Success Criteria, as not everything always applies. For instance, a component that doesn’t include any “time based media”, can assume the four Level A/AA criteria that relate to such media don’t apply. And responsibilities per Success Criterion differ too (for more background: the ARRM project works on a matrix mapping Success Criteria to roles and responsibilities).

Have checks that anyone can perform

Checks that anyone can perform don’t require special software or specialist accessibility knowledge. Examples:

if you zoom in your browser to 400%, does the interface still work?
can you get to all the clickable things with just the TAB key, use them and see where you are? (this one may require some setup if you’re on a Mac)
when you click on form labels, does the input gain focus?

So that’s one subset of WCAG. Ideally, we would pick our own for our organisation or project, based on types of websites or content (will we have lots of forms? lots of data visualisation? mostly content? super interactive? etc). Pick checks that many people can perform often.

I’ve seen this approach can be a powerful part of an accessibility strategy. You know, Conway’s Game of Life only has four rules, yet you can use it to build spaceships, gliders, Boolean logic and finite state machines… sometimes there’s power in simple rules and checks.

Supersets

With a superset of WCAG, our website can become more accessible.

It’s no secret that WCAG doesn’t cover everything and this only makes sense. Creating standards takes a lot of time, the web industry is in continuous evolution and some barriers can be put into testable criteria more easily than others. The Accessibility Guidelines Working Group (AGWG) in W3C does fantastic work on WCAG (sorry, I am biased), including to cover more and different user needs and take into account the ever-changing web. I mean, WCAG 2.* is from 2008 and the basic principles still stand after all those years.

Test with people

One of the most effective ways to find out if our work is accessible, is to test with users with disabilities, either by including them in our regular user tests, or as separate user tests.

User testing with people with disabilities is mostly similar to ‘regular’ user testing, but some things are different. In Things to consider when doing usability testing with disabled people, Peter van Grieken shares tips for recruiting participants, timing, interpretation and accomodation.

The Accessibility Project also has a list of organisations that can help with testing with users with disabilities.

Guidance beyond WCAG

There are also lots of accessibility best practices beyond WCAG, some provided by the W3C as non-normative guidance, some provided by others.

For instance, see:

Making Content Usable for People with Cognitive and Learning Disabilities , a document filled with UX recommendations, specifically related to people with cognitive and learning disabilities, but useful for all
XR Accessibility User Requirements for if you’re building anything “extended reality”-like, such as virtual reality and augmented reality
Accessibility Requirements for People with Low Vision on how to make web content accessible to people with low vision
GOV.UK accessibility blog, where the folks behind GOV.UK share stories from their accessibility practice, tests they’ve done and more
Scott O’Hara’s Accessible Components

Summing up

Many use WCAG as a baseline to ensure web accessibility. This matters a lot, it is important to have regular WCAG audits done (e.g. yearly). In this post, we looked at what we can do beyond that, when we use subsets and supersets of the standard. Subsets can help anyone test stuff anytime, which is good for continually catching low hanging fruit. Supersets are useful to ensure you’re really building something that is accessible, by user testing and embedding guidance and best practices beyond WCAG.

Originally posted as Subsets and supersets of WCAG on Hidde's blog.

[email protected]?subject=Reply%20to:%20Subsets and supersets of WCAG">Reply via email

Patterns

2021-11-02T00:00:00Z

Last week, I attended a conversation with Cecilia Kang, the New York Times journalist who co-authored An Ugly Truth with Sheera Frankel. It was a lot about patterns in Facebook’s decisions, leadership style and press relations.

I was delighted to be back in a conference hall, and it happened to be the one where we hosted Fronteers 2009 and Mobilism 2011, the memories! These events had sponsors like Opera, Internet Explorer 8 and Blackberry. Anyway, I digress, let’s talk about Facebook.

Profit over people

Facebook wants two things, Kang emphasised: connect all people together through technology and grow their business. Sounds reasonable? Maybe, but these goals impact one another in a very specific way. Facebook sells ads. You can get most people to look at ads if the content triggers people, including when it is upsetting, hateful content. Growing business ends up growing hate. The site does bring people together, yes, but it profits most when they are upset together. And, problematically, maximising profit is the end goal, The Ugly Truth shows.

Is bad content a problem? Kind of, but most platforms have some of that and we should probably blame the authors of that content, not Facebook. Is profit a problem? Or maximising it? It isn’t that per se. All companies try to make profit, most try to make a lot. The problem is profit at the expense of people’s wellbeing and safety. This is where the tobacco and oil company comparisons come in. Facebook understands which content angers or harms people. They ran experiments with happier and less depressing newsfeeds. They knew about persecution of Rohingya people in Myanmar, fired up by a politician they gave a voice. They knew about extremists using their platform to organise storming the Capitol. They knew about the medical misinformation that undermined solutions for the global COVID-19 pandemic.

The thing is, extremism, misinformation and hate thrive on amplification, on being widely shared. Facebook’s inaction is so problematic, because it facilitates and accelerates that amplification to make more money. There would be extremists, liars and haters in a world without Facebook, but they would thrive a lot less less. They would thrive less on regular tv, and they would thrive less on a social media platform with more ethical content priorities. There are other platforms too that are based on amplification, which often have similar problems, but this is post is not about them.

The Facebook Papers, a large set of documents released by whistleblower Frances Hauben to a dozen news outlets, clearly confirm the conclusions of An Ugly Truth: Facebook knows what they amplify and don’t care enough to stop. Of course, they contract huge amounts of content moderators and mark COVID-19 information from trusted sources, but leadership decisions consistently put engagement (profit) before safety (moderating harmful content).

The Atlantic’s Adrienne LaFrance:

Again and again, the Facebook Papers show staffers sounding alarms about the dangers posed by the platform—how Facebook amplifies extremism and misinformation, how it incites violence, how it encourages radicalization and political polarization. Again and again, staffers reckon with the ways in which Facebook’s decisions stoke these harms, and they plead with leadership to do more.

And again and again, staffers say, Facebook’s leaders ignore them.

(From: ‘History Will Not Judge Us Kindly’ in The Atlantic)

The Wall Street Journal’s Facebook Files series evolves around the same conclusion in its opening words:

Facebook Inc. knows, in acute detail, that its platforms are riddled with flaws that cause harm, often in ways only the company fully understands. (…)Time and again, the documents show, Facebook’s researchers have identified the platform’s ill effects. Time and again, despite congressional hearings, its own pledges and numerous media exposés, the company didn’t fix them.

(From: ‘The Facebook Files’)

Inaction is a pattern An Ugly Truth confirms. Time after time, when Facebook leadership can choose between what’s good for people and what’s makes them more profit, they choose profit. These aren’t always at odds, but when they are, profit is consistently prioritised. And with that, the amplification of bad content.

Besides amplification of harmful content for profit, Facebook also engages in large scale data collection, as Shoshana Zuboff explained in The Age of Surveillance Capitalism. Facebook tracks even users who deactivated and had shady data sharing deals with device manufacturers.

Journalists have reported on lots and lots of serious problems related to Facebook’s priorities, some of which I linked above. This brings us to another pattern: Facebook’s press teams downsize the problems or outright deny them. They’ll call a story an absurd suggestion, only for it to turn out to be mostly accurate. They will also often point to the competition, which sometimes has similar problems. Or they attack the messenger. When Frances Hauben was testifying, Andy Stone, a Facebook PR person, shamelessly tweeted:

Just pointing out the fact that @FrancesHaugen did not work on child safety or Instagram or research these issues and has no direct knowledge of the topic from her work at Facebook.

Which is why she brought documents, as Jane Chung aptly replied. This time the press team responded childishly, the book also shows that they like to spin stories and deny truths when they see a chance.

The leadership

The book also goes into the people running Facebook and how to see the world. When I think of Mark Zuckerberg’s world view, I think about that time he called people who trusted him with their data “dumb fucks”. I hesitate to reduce a person’s world view to one quote from their past, but reading The Ugly Truth made me feel that his decisions and priorities of today still show he tends to dismiss other people’s safety.

When he addressed Georgetown University, he said he doesn’t want to ‘censor political speech’ and focused on free speech. The ideology seems to be that a president’s freedom to incite violence or spread covid misinformation, and the public’s freedom to ‘judge for themselves’, are more important than people’s safety. Everyone wants freedoms, but the question is whose freedom gets priority.

Mark Zuckerberg, Kang explained in Amsterdam, is inspired by Silicon Valley men like the controversial libertarian Peter Thiel, and not so much by what his own employees tell him. They often don’t bring important things to him, Kang said, as the company has a culture of protecting the leader. People want to be friends with him, not appear too critical. Maybe that’s the case for many CEOs, but it does make one wonder what the company had looked like under different leadership, that took inspiration from different places.

So, what now?

I think everyone gets how Facebook, Instagram, WhatsApp, React and Oculus have their merits. They can and often do bring people together. Make the world a better place. I don’t mean this sarcastically. Ok, I’m not personally so convinced of Oculus, I’m more of a real world person, but I’ll leave that for a later post. These platforms aren’t inherently bad, they bring lots of good to many people. The bad they bring sometimes merely reflects the bad that’s out there in the world. But it’s clear that Facebook’s role is often that of a megaphone, not just a mirror.

Some of the audience questions were along the lines “could we remove the bad parts of Facebook?” This is a tricky question, because of where most of the problems manifest. They aren’t in one team that messes things up, they are right in the business model that pays everyone’s salary. Removing the bad parts might not leave us with much left. There are also countless stories of people trying to “change the company from within”, which has now become a bit of a meme.

More legislative controls are expected, likely in the US and Europe and likely somewhere in the next 5 years or so. Maybe this will get us more of the good parts and less of the bad parts of Facebook.

Until, then, this is my personal list of things we can all do now:

refuse to work at Facebook; it’s like voting, your individual vote doesn’t matter, but millions of individual votes can push the world in a clear direction, in this case one where Facebook has a hard time finding employees
quit working at Facebook (I know, controversial), for the same reasons
stop or reduce usage of Facebook/Meta and its products (including, dare I say it, React)
help non-tech friends and family move away from Facebook
stop advertising on Facebook (some companies have)
help small business friends by building them a simple website outside Facebook’s walled garden
read up on patterns in tech companies, check out books like An Ugly Truth and Super Pumped (on Uber)

Wrapping up

In conclusion, the issue isn’t that Facebook has harmful content or makes profit, it’s that its leadership consistently decides to prioritise their profit over preventing harm. They know they have problems, but decide against fixing them and aren’t honest about this to the press. This is why we all need a lot less Facebook in our lives, and I urge you to join the movement.

Looking back, the time of Opera, Internet Explorer 8 and Blackberry felt more innocent. The monopolies felt less harmful. I, for one, am very curious how the world will look back at today’s Facebook in ten years time. Let’s hope their patterns will have changed for good.

Originally posted as Patterns on Hidde's blog.

[email protected]?subject=Reply%20to:%20Patterns">Reply via email

In person

2021-11-16T00:00:00Z

The applause seemed louder than usual. They were stoked, this community of European nerds, designers and lots of people in between. At last. After almost two years without Beyond Tellerrand conferences, Marc Thiele decided to make it work and run another event. It was great to see him back on stage, introducing speakers and more.

Of course, it was anything but a normal event. Not all regulars could or wanted to attend. Naturally, they were missed. Those who did attend, mostly local or local-ish, had to stick to the ‘2G+’ rule: to be vaccinated, recovered or PCR tested. I felt lucky I could be there, to attend a number of wonderful talks, meet folks in person and speak. I didn’t find the risk assessment easy… for myself, for others… but, given the circumstances, it seemed like the right call to attend.

The talks

Recordings of last week’s Beyond Tellerrand are already up on YouTube and Vimeo. Check out the event page for links: there is awesome content about variable fonts, quarantine life, sketching as a tool, the <head> tag and how it affects web performance, the attention economy, OAuth from a usability perspective, creative typography and how modern font tech allows for it, data visualisation and experiencing disability.

Recordings for all talks are available

I opened the second day with a full length talk just about semantics. Inspired by the Austrian-British philosopher Ludwig Wittgenstein, who equated meaning to use, I explained semantics is fundamentally about a system of meaning that is shared. Shared through a standard: HTML. This is how it differs from other examples of shared languages, like design systems and APIs. Through examples, I tried to show how semantic HTML affects end users and talked a little about gotchas (see the recording for more).

In person

It was special to me to speak at Beyond Tellerrand. Not only was it ten years after attending the first edition, it was also after over a year of just virtual talks. Virtual events are great. They have allowed me to speak in more places, without the travel. Last month I could attend W3C TPAC and Accessibility Toronto on the same day, while I also met my manager in Boston for a 1:1 and cooked family dinner at home. Which brings me to the downside… if you can be everywhere at once, are you really anywhere fully?

In virtual events, I’ve often not attended the whole thing, because I find that a lot harder while at my desk and at home. At my desk, there is also other work waiting. At home, there is family. I love my work, but picking between work and family is easy, I will pick family, unless I’ve actually travelled away.

In person, it felt easier to focus on just the event. It meant that I could bump into people in the hallways. Not literally, of course. I got more immediate feedback and much more time with attendees, organisers and fellow speakers. The feeling of being in an auditorium with others, laughing about the same jokes, enjoying the same beautiful typography on a huge screen, inpromptu ramen lunches… it’s all hard to replicate virtually.

Accessibility Club and Indie Web Camp

In the days after the conference, some of us gathered in the newly opened Zentralbibliothek, Düsseldorf’s public library. On Wednesday there was an Accessibility Club Meetup. I talked about opportunities for browsers to contribute to accessibility issues. Molly Watt shared her experiences as a deafblind user of technology and urged us to make less assumptions about and test more with users. Karl Groves warned us to not trust vendors of accessibility overlays. This was all livestreamed and it was awesome to watch Marc and Aaron setting up their elaborate streaming setup.

On Thursday, I left for home, but not before I had attended the informal yet important pre-event coffee session and the planning for that day’s Indie Web Camp. It was my first Indie Web Camp, and I had wanted to attend for a while. I decided to work on the Webmentions on this website. That afternoon, in my train back, I tweaked how likes and shares, the most common form of Webmention I receive here, are displayed. They now show all in one paragraph, rather than as individual comment-like entries. This cleaned up the comment section for most posts on this site, which was nice.

Summing up

This was fun, and I hope it can happen again in the not too distant future. In the next few weeks, I have some more virtual and hybrid events. Here’s to hoping that 2022 will bring more opportunities to safely gather in person with web friends, including those who live further away. Because, for one, I missed this.

Originally posted as In person on Hidde's blog.

[email protected]?subject=Reply%20to:%20In person">Reply via email

Meeting “2.2.2 Pause, Stop, Hide” with prefers-reduced-motion

2021-12-03T00:00:00Z

With prefers-reduced-motion, developers can create UIs that don’t move when users opt out. Could this feature be a way of meeting WCAG 2.2.2 Pause, Stop, Hide?

Rian recently asked this question in Fronteers Slack and I thought I would write up some thoughts around this for later reference. I will go into three things: what’s 2.2.2 about, how could using prefers-reduced-motion be a way to meet it and is that desirable?

What is 2.2.2 about?

Moving, blinking and scrolling content can be a barrier to:

people who cannot read text fast or track moving objects
people who use screen readers, this kind of content can cause trouble there
people who have attention deficit disorders

Success Criterion 2.2.2 says that for such content, there should be a “mechanism for the user to pause, stop, or hide it”. The exception is content that is considered “essential”, like when removing it would radically change the content or if this UI is really the only way to display the functionality. If this content auto-updates, a mechanism to set how often updates happen is also fine.

All of this is about content that moves regardless of user interaction. For content that moves when people “interact” (eg scroll or zoom), think parallax effects, this could badly effect people with vestibular disorders. 2.3.3 Animation from Interactions (Level AAA) is specifically about this interaction-triggered motion.

Is prefers-reduced-motion sufficient for 2.2.2 conformance?

What and how

These days, most operating systems let users indicate whether they want to see less motion.

On macOS, the setting is under Accessibility, Display, Reduce motion

This functionality exists for pretty much the same reasons as Success Criterion 2.2.2. In Media Queries, Level 5, CSS adds a way for web developers to respond to and honour the setting to prefer reduced motion.

In CSS, it works like this:

.thing {
  /* some rules */
}
@media (prefers-reduced-motion) {
  .thing { 
    /* some rules for if user
       prefers reduced motion*/
  }
}

In JavaScript, you can also read out the value for prefers-reduced-motion with matchMedia, and even add listen to its change event:

var query = window.matchMedia('(prefers-reduced-motion: reduce)');

query.addEventListener('change', () => {
  if (!query.matches) {
    /* some rules */
  } else {
    /* some rules for if user
       prefers reduced motion*/
  } 
}

Conformance

I would say a UI that has moving parts that would cause it to fail 2.2.2, could meet it if those moving parts are removed under the condition of prefers-reduced-motion being set to true. In practice, for this to work, a user would have to set this preference in their operating system and they use a browser that supports it.

The crucial part of the Success Criterion text, I think, is:

for [moving, blinking and scrolling content] there is a mechanism for the user to pause, stop, or hide it

(emphasis mine; exception and exact definition of the content this applies removed for clarity)

I feel setting ‘prefers reduced motion’ could count as such a mechanism, for most cases of moving content.

Is it “accessibility supported”?

In WCAG, there is this concept of ‘accessibility supported’, meaning that you can somewhat trust on platform features, but only if you’re certain they will work for most of your users. Like, if there was an amazing new HTML tag that allowed you to do very accessible tabs, but only one obscure browser can actually render it, that is not considered accessibility supported.

“Accessibility supported” requires two things to be true: it has to work in a user’s assistive technology and there are browsers, plugins or even paid user agents that support the feature (paid, as long as price and findability are same for users with and without disabilities). W3C and the WCAG authors (AGWG) only provide these rules, not a specification of what meets them or doesn’t meet them, so it’s up to the accessibility community to agree.

I believe this is a feature that doesn’t depend on assistive technology support as it lives in browsers, so I will deem that first clause to be not applicable and look just at the browser support. For ‘prefers-reduced-motion`, caniuse shows 93% of users are on browsers that support it. It is important to note that some screenreader users may be on older browsers, for a variety of reasons. Among respondents to WebAIM’s most recent screenreader user survey, Internet Explorer usage was 3.3%. To include even those users, one could use prefers-reduced-motion defensively.

I wrote this would be fine to meet WCAG in ‘most cases’. When is it not? Examples could be those when the ‘moving’ means the site adds new content, like in a stock ticker, as Jonathan Avila suggests on GitHub. Not adding that content would be undesirable, as it would make that content unavailable to users with the setting turned on.

Is this desirable?

If we want an accessible web, we shouldn’t just look for the bare minimum to conform. When I carry out accessibility conformance evaluations, measuring that minimum is what I consider my goal, but, of course, web accessibility is about more than such audits. People with disabilities should have equal usability and that requires best practices and user testing, in addition to standards conformance.

So, ‘is this desirable?’ is a usability question. Will people who need the setting actually discover, understand and use it? The setting can be in a variety of places. MDN has a list of settings that cause Firefox to honour prefers-reduced-motion, presumably these are similar for Chromium and Webkit based browsers. It seems likely to me that lots of people won’t find this setting. So it doesn’t just give control to end users, it also shifts the burden of knowing and using the setting to them. Operating systems can (and sometimes do) improve discoverability of features like these, though.

Generally, I love the idea of features like prefers-reduced-motion standardised primitives to accommodate specific user requirements. I think it’s better than every web developer inventing their own controls to meet the same user needs. In the case of 2.2.2, controls like pause buttons or duration settings. I love the idea that the platform offers generalised controls that aren’t just used on one specific website, but can be respected by all websites.

Similar features

After I published this post, Bram Duvigneau of the Dutch accessibility consultancy Firm Ground, sent me a note that included a few more web platform features that help meet WCAG criteria:

in most modern browsers, there is a global mute key. Might this mean websites don’t need to build their own mute buttons to meet 1.4.2 Audio Control?
also in most modern browsers, are controls to decrease and increase text size: we no longer expect websites to have their own buttons for this either

The ‘Mute this tab’ button in a Firefox tab

The mute and text sizing buttons are much easier to find in web browsers for users. Should browsers also expose a much easier to find ‘stop motion’ button whenever a website implements prefers-reduced-motion, so that a user is more explicitly presented with this option?

Summing up

As you can read, I’m a little torn on whether prefers-reduced-motion is a sufficient way to meet 2.2.2 Pause, Stop, Hide for specific cases of that criterion. In terms of conformance, I would say yes, this is acceptable (with exceptions). In terms of actual usability, which is what is most important, I’m torn as it only actually works if real users find this setting on their device.

Over to you! If you’re reading this, I would love to hear what you think!

Originally posted as Meeting “2.2.2 Pause, Stop, Hide” with prefers-reduced-motion on Hidde's blog.

[email protected]?subject=Reply%20to:%20Meeting “2.2.2 Pause, Stop, Hide” with prefers-reduced-motion">Reply via email

The better version of digital life is real life, not ‘the metaverse’

2021-12-04T00:00:00Z

In a Dutch podcast, I heard a prominent tech journalist praise Mark Zuckerberg’s recent Metaverse PR event: finally, the company had presented a grand vision and it looked so cool! In my own tech bubble on Twitter, I saw mostly memes to poke fun at the concept, the presentation and the presenter, and lots of insightful scrutiny.

The COVID pandemic has accelerated the move of work to digital spaces rather than physical ones. Metaverse-enthusiasts often claim that more Metaverse-tech can give us a much better version of digital life. I’m not sure about that.

Though it was refreshing, I will say I was disappointed by the tech journalist’s enthusiasm. Not because Mark Zuckerberg deserves the laughs, or because it somehow scratches an itch ito criticise people who are genuinely trying to make exciting new tech. I mean, maybe… but really, it is because Facebook’s actions prove time over time they require scrutiny. This corporation makes decisions that put their profit above the safety of both people and the societies they live in, and it plays innocent through a clever PR apparatus (see my post on An Ugly Truth). The US Congress and European Commission aren’t looking into their practices because they felt bored. It is because they capitalise on surveillance, hate and misinformation, all of which threaten the basic structures of democracy.

If Facebook (or Meta) claims they will prioritise security, interoperability and improving human relationships, as Zuckerberg did in interviews, such claims need scrutiny. Scrutiny from journalists, from software engineers, from activists and from trend watchers. This company has demonstrated on many occasions to be capable of mostly the opposite of security, the opposite of interoperability and the opposite of improving the quality of human relationships. What would Rohinga muslims or the White House staff think when they hear Zuckerberg say security matters to him? What about web developers who try to build interoperable web apps, only to find Facebook’s staff working on the React framework work around more than with web standards? What about the many societies that are driven apart by an effective machinery for medical and political misinformation? Will they feel their human to human relationships have improved?

As someone with family, friends and colleagues abroad, I have seen struggles with current digital spaces. They could improve by means of technology and better priorities. But should this be lead by the company whose technology and priorities worsened digital spaces so much?

And are more advanced digital environments the answer or does a better world already exist, as in, the real world? Mixing digital and real, as some Metaverse tech does, is super beneficial for corporations that see the web as a place to extract profit from. A Mixed Reality overlay adds not just fun or useful interactions, it adds another thing to measure. More data, for corporations like Facebook, means more profits.

Maybe I would be less sceptical if Zuckerberg had outlined in more detail how this would benefit the world first, or even demonstrate ways to guarantee the Metaverse won’t be just another layer of his data extraction machine. Of course, it is a free world and corporations can profit however they want. Including by building a data extraction machine and getting rich off that. Profit is fine, my company aims for profits too. It’s really Zuckerberg’s failure to address what could go wrong, given so much in his current enterprise has gone wrong, that tires me. It’s the combinaton of that data extraction machine for profit and the undesired impacts of it on society.

For a corporation wanting to extract data for profit, augmented reality is better than reality. For end users, reality itself, I mean, unaugmented reality, might be the better version of the mostly digitial lockdown life that many of us desire. First of all, it’s real, I mean, did you have a chance to experience life music after lockdowns? It’s nice, right? Secondly, it doesn’t require scary filming glasses or uncomfortable and nausea-inducing headsets. Thirdly, you have to worry less about whether your privacy is invaded. And if Facebook or Meta run things, you can be quite sure of that. I won’t be applying to one of the 50,000 ‘Metaverse jobs’ they said they’ll open in Europe.

Originally posted as The better version of digital life is real life, not ‘the metaverse’ on Hidde's blog.

[email protected]?subject=Reply%20to:%20The better version of digital life is real life, not ‘the metaverse’">Reply via email

How many people with disabilities use our site?

2021-12-05T00:00:00Z

When I talk to teams about web accessibility, often someone will ask how many people with disabilities use their site(s), or some variation of that question. It’s complicated, and other questions can be more helpful.

My standard answer usually includes that we can’t measure assistive technology usage for (good) privacy reasons, that our analytics won’t show customers that went to a more accessible competitor and that accessibility benefits everyone.

Accessibility ROI irrelevant (says… Apple!)

One other aspect though, let’s go into that straight away, is that looking for this data hints at trying to find return on investment. A counter question could be: what will we do with that data? Let’s say we get the number and deem it a very small percentage… whatever that is… equal access is still the right thing to aim for, it is still a human right and it is still required by law in most places. So, basically, our organisation has three good reasons to prioritise accessibility that exist regardless of a number of users with disabilities.

Or, as Apple CEO Tim Cook once told a shareholder:

When we work on making our devices accessible by the blind, I don’t consider the bloody ROI. When I think about doing the right thing, I don’t think about an ROI. If that’s a hard line for you, then you should get out of the stock.

(From: Apple’s Tim Cook gets feisty, funny and fiery at shareholders meeting, Los Angeles Times, 1 March 2014)

This makes sense for the web too. The web is all about accessibility, both of information and for end users.

Privacy trumps metrics

A web user’s need for privacy trumps our need for analytics. This is especially the case for people with disabilities, who rightly don’t want their disability to be one of your metrics. Standards organisations are careful not to add features to the Web Platform that allow such tracking, because it would invade individual user needs too much.

Your analytics don’t show market potential

Even if we could accurately measure how many people with disabilities used our site, it isn’t a very meaningful number. If our site is inaccessible to people who use voice control, chances are those people are shopping with our competitor instead. The reason they don’t show up in our numbers might be just that.

For the potential, we could look at the World Health Organisation’s Report on Disability, published in 2011. In a comprehensive chapter on demographics, they conclude 15-20% of the world’s population has a disability. These numbers aren’t exact, as countries have different methods of counting, but they give a reasonable estimate that we can work with.

Accessibility benefits everyone

Accessibility features on our site won’t benefit everyone all the time, that would be an exaggeration, but they often benefit many more people than just specific groups of people with disabilities. Dark mode is a feature some users need to avoid headaches or to read content, but many others still apply such settings, for a wide variety of reasons.

And it doesn’t just benefit a large parts of our user base, accessibility can also inspire innovation in our organisations. When an Italian inventor created the first typewriter for his blind friend, he invented a thing that is at the centre of what all of us do all day. Voice controlled software, audiobooks… the examples of things that were initially designed for people with disabilities but used by many more, are countless.

Conclusion

We probably don’t need to know how many people with disabilities use our sites, as regardless of what that number would be, we should want to build accessible sites, for many ethical, legal and business reasons.

Originally posted as How many people with disabilities use our site? on Hidde's blog.

[email protected]?subject=Reply%20to:%20How many people with disabilities use our site?">Reply via email

2021 in review

2021-12-28T00:00:00Z

Well, guess what, we’re nearing the end of the year! In this post I’ll share what I was up to this year, as well as some things I learned along the way.

As usual, my year wasn’t all highlights… like in 2020, 2019, 2018 and 2017, the lowlights are intentionally left out of this public post. Ok, let’s go!

Highlights

Work

Throughout the year, for W3C/WAI, I was involved in the launch of the redesigned WCAG-EM Report Tool, worked on a unified layout for the W3C’s accessibility guidance (like Techniques, Understanding and the ARIA Authoring Practices Guide) and did some work around accessibility of authoring tools in higher education, Epub and XR.

This year also was my last at the W3C/WAI. I won’t get into too much detail, but I can say I struggled with the leadership style and decision making process. I had wanted to drive more change from within. I had also wanted to do more to make accessibility more accessible, but the standards game seems easier to play for folks who have been in it longer. When my contract neared the end I decided not to extend. I am grateful for the opportunity though, and was able to learn a lot about standards, web accessibility and the web, and contribute to a wide range of interesting projects.

Besides my W3C work, I also did over 25 WCAG conformance audits, mostly for governments, and a couple of in-house workshops, including two for the teams building the Dutch national citizen’s authentication system (DigiD).

I also worked with Eleven Ways on an advisory project for the European Commission and a project on virtual event accessibility. Lastly, I just started a short stint with Mozilla, to help with some accessibility aspects of the upcoming MDN redesign.

In February, I will start a new job 🎉, which I am super stoked about. Like my role at the W3C, it focuses on outreach to developers and will let me continue to work on making it easier for developers to build things. I am excited, because it is at a product company that works on solving a very real and interesting problem, and it is very authoring tool related.

Speaking

This year included one in person event and I was so happy the covid-shaped stars aligned this time for me. I had recently had my vaccin, the European winter wave had not yet exploded and 2G applied.

The other talks I did were all remote:

Accelerating accessibility in a component based world at SimpleWebConf (June), JSConf India (November), BLD Conf (November) and Git Commit Show (November)
Could browsers fix more accessibility problems automatically at a11yTO (October), Accessibility Club Meetup (November) and Tech A11y Summit
More to give than just the div: semantics and how to get them right at Web Directions: Access All Areas (October) and Beyond Tellerrand (November)
Procuring accessible software for e-learning: how ATAG can help with my colleague Joshue O’Connor at WP Campus Online (September)

You can like and subscribe this stuff on YouTube should you wish to.

I also joined the Gebruiker Centraal (“User Centered”) podcast of the Dutch government (WCAG What?) and Ben Meyer’s Some Antics livestream (Audit Site for Accessibility).

Reading

I read 54 books this year. I created a website for this as I love judging books by their covers, now you can too on books.hiddedevries.nl. This is updated manually—if you want real time updates, add me on Goodreads.

Below are some books I particularly liked. They have in common that they are set in parts of the world I have travelled to and would have liked to return to if it wasn’t for the pandemic.

If I had your face by Frances Cha – this is about four women in Seoul and their lives, obsessions and friendships.
Fake accounts by Lauren Oyler – what if you find out your partner is actually a complot theorist with a secret Instagram account? Funny and smart satire of contemporary life, partially set in Berlin. Got very mixed comments on Goodreads.
Intimacies by Katie Kitamura – this book’s main character works at the International Criminal Court in The Hague—ok I have travelled there during the pandemic… it uses precise language, but also shows how much precision of language matters. There was a scene in which people buy old books just for the purpose of decorating their house.
Kafka on the shore by Haruki Murakami – I reread Kafka on the shore, set in Yamanashi and Takamatsu, Japan, and, like a lot of Murakami books, it involves a road trip, lots of music and lots of cats
Free food for millionaires by Min Jin Lee – set in New York, describes a college graduate plotting her future, describing both her generation and her parents, jumping between life’s different environments

Writing

I didn’t write a lot, but have not stopped posting either—this is the 20th post of this year. Things I wrote about included:

the “metaverse” and why real life is better – I guess I am sceptical of a lot of the ideas posed by Zuckerberg in this year’s Facebook event
numbers – I get asked a lot how many people have disabilities and I feel that’s the wrong metric
“normative’ in WCAG – a lot of my work this year focused around redesigning WCAG-related guidance for W3C/WAI, and part of my research showed users struggle with deciding which guidance is “required” to meet WCAG (spoiler: most of WCAG’s main text is, most other stuff isn’t)
components and what to look for – I love component systems and feel strongly they can contribute to a more accessible web. However, the opportunity they provide is neutral: if components contain barriers, they could make the web less accessible too, so we want to use components that repeat accessibility, not inaccessibility
I would love accessibility statements in App Stores and wrote about that

Cities

I stayed within the borders of The Netherlands for another year, with one exception: a short train ride across the Netherlands-Germany border for the first Beyond Tellerrand in 2 years.

Things I learned

Towards the end of the year I try to think about what I learned. A lot of this year’s was quite specific to myself, but these are some random learnings that might interest others:

One aspect that makes accessibility of XR tricky is that virtual worlds usually don’t have DOM nodes like web pages do. Accessibility trees are based on DOM nodes, without those XR worlds will need some other mechanism to define accessibility meta information (more about XR Accessibility User Requirements).
There is a standard for Epub accessibility, but none specifically for native app accessibility, eventhough some organisations in European Union Member States need their apps to be accessible since earlier this year.
I was late to the Eleventy party, but eh, Eleventy is nice. I released two Eleventy-based projects: my books site and a starter pack for WCAG reporting using Eleventy.
Open sourcing a thing can make it better! Months after I released my Eleventy WCAG Reporting thingy, friendly folks contributed translations into Portuguese, Finnish, German and Spanish. This is onlly a super small project, but it was nicer than not releasing it could have ever been.
Standardising design system components, as in, make common design system needs somehow part of the web platform, is fun and useful. It could mean the world to accessibility and developer experience. It’s also hard. I am trying to contribute to some of this through Open UI CG and I learn lots in the meetings and issues.
I found it helpful to apply at multiple companies when I looked for my next role. I wasn’t sure if I wanted to, at first, but was glad I did, as it let me talk to many different companies and gave me a lot more decision points to compare towards the end of the process.

Anyway, thanks so much for reading my blog this year and sharing posts with others. It means a lot to me. I wish you the best for 2022!

Originally posted as 2021 in review on Hidde's blog.

[email protected]?subject=Reply%20to:%202021 in review">Reply via email

Twitter needs manual language selection

2021-12-30T00:00:00Z

Lots of Twitterers speak languages that are not English. For people who read tweets that are not in English, it is important that these tweets are marked as such. I feel Twitter needs a feature for this.

It would be nice if, when writing a tweet, we could manually select which language the tweet is in, and that Twitter would use that information to set the appropriate lang attribute on our content:

Sharing a controversial opinion on CSS frameworks in the Dutch language

Twitter is an authoring tool, for which the Authoring Tool Accessibility Guidelines recommend that “accessible content production is possible” (Guideline B.1.2).

The `lang` attribute

Language attributes identify which language some web content is in. They are usually set on a page level, added to the HTML element:

Most developers don’t write these attributes often, the code often lives somewhere in a template that we don’t touch every day, or ever. But it’s an important attribute. Setting it correctly gets your page to pass one whole WCAG criterion (3.1.1 Language of page).

In some cases, we have to set language attributes on individual elements, too, like if some of our content is not in the page’s main language. On the website I built for the British-Taiwanese band Transition, we combine content in Mandarin with content in English on one page:

The Transition “Music” page

We picked en as the main language and set it on the <html> element. This meant we had to mark all Chinese content as zh, in this case zh-TW as it is specifically Mandarin as spoken in Taiwan. Of course, we could have written this the other way around, too. Usually we want to pick the language that’s most common on the page as the page’s language.

Setting a lang attribute on parts of a page is its own WCAG criterion, too (3.1.2 Language of parts), by the way.

The user need

Setting the language is important for end users, like:

people who use a screenreader to read out content on a page
people who use a braille display
people who end up seeing a default font (browsers can select these based on language)
people who use software to translate content
people who want to right click a word in our content to look it up in a dictionary
people who use user stylesheets

The author need

There is also an author need, both for people who write content and for web developers.

Content editors

People who write content may get browser-provided spellcheckers. They will work better if they know what the content’s language is. I think Twitter.com has somehow turned browser spellcheck off, but there may be Twitter clients or indeed other authoring tools where this is relevant.

Web developers

Language attributes are important for web developers, too, as it allows them to use the :lang() pseudo class in CSS more effectively.

Some CSS will behave differently based on languages. When you use hyphens: auto, the browser needs to look up words in a dictionary to apply hyphenation correctly. It has to know the language for this.

With appropriate language attributes, you can also use CSS features like writing modes and typographic properties more effectively. See Hui Jing Chen’s deep dive into CSS for internationalisation for more details.

Automating and `lang-maybe`

Identifying languages can be automated. In fact, Twitter does this. When they recognise a tweet’s language, they add the relevant lang attribute proactively. See for instance the European Commission chair’s multilingual tweets:

Twitter’s auto-added lang attributes in action

Yay! I think this is very cool (thanks ThainBBdl for pointing this out). The advances in natural language processing are really impressive.

Having said that, any automated system makes mistakes. Vadim Makeev shared:

Yes, sometimes they take my Russian tweets and render them as Bulgarian. It’s not just the lang, they also use some Cyrillic font variation that makes them harder to read.

It is safe to assume such mistakes will skew towards minority languages and miss subtleties that matter a lot to individual people, especially in areas where language is political.

On the one hand, I think it makes sense to deploy automated language identification. As there are a lot of users, Twitter can safely assume not everyone would set a language for all of their tweets. People might not know or care (insert sad face here), a fallback helps with that. On the other hand, if this tech exists, might it make more sense if a browser would deploy it rather than an individual website? Why not have the browser guess the content’s language, for every website and not just Twitter?

If browsers would do this, Twitter’s lang attributes may get in the way. They kind of give the impression that this information is author-provided. This makes me wonder, should there be a way for Twitter to say their declaration is a guess? lang-maybe?

Manual selection

Automated language detection probably works best if it complements manual selection. It could help provide a default choice or suggestion for manual selection, and work as a fallback. So, I’m still going to make the case for a method for users to specify a language manually.

A per-tweet manual language picker would be great as it can:

give willing authors more control to avoid issues
avoid that language identification benefits are only had by users of the majority languages that AI models are best trained for
let authors express their specific intent

Summing up

For non-English tweets to meet WCAG, they need to have their language declared with a lang atttribute. Twitter currently guesses languages, which is a great step in the right direction, but is likely of little help to speakers of minority languages. A manual selector would be a great way to complement the automation.

Originally posted as Twitter needs manual language selection on Hidde's blog.

[email protected]?subject=Reply%20to:%20Twitter needs manual language selection">Reply via email

The web doesn’t have version numbers

2022-01-03T00:00:00Z

Like ‘Web 2.0’, ‘web3’ is a marketing term. There is no versioning system for the web. There are also lots of exciting uses for the web and problems with it outside the realm of ‘web3’.

It’s the later half of the 2000s. People had been building websites and online services for a while. Suddenly, everyone started using the phrase ‘Web 2.0’. It didn’t have one one clear definition, like ‘carrot’ or ‘dentist’. It referred to a bunch of things at once. Websites with ‘user generated content’, users tagging their data, software as a service, async JavaScript, widgets and open (!) APIs that allowed for mashups: sites that displayed content from other sites. New companies had names with less vowels, like Tumblr and Flickr, and there was RSS on everything. ‘You’ was made TIME Person of the Year. I’ve been returning to some stuff from that time, and it’s been interesting.

Many of the things that fit the above description of ‘Web 2.0’ were useful, they often still are on today’s web. We lost some, we kept some. But if we’re fair, ‘Web 2.0’ wasn’t some new iteration, a new version of something that was different before. It was largely reuse of existing web tech, like HTTP and XML. Exciting reuse, for sure. But a lot of it already existed in non-commerical forms before the phrase ‘Web 2.0’. Not everyone knows, but the first web browser, WorldWideWeb, was meant to be both viewer and editor. That’s quite ‘user generated’, I would say. So, what did Web 2.0 mean? ‘Web 2.0 is, of course, a piece of jargon, nobody even knows what it means’, Sir Tim Berners-Lee commented in an interview with IBM at the time.

Like ‘Web 2.0’, ‘web3’, and I’m not sure what’s with the removed space and dot, or the lowercase ‘w’, is just a marketing phrase. Definitions of ‘web3’ seem to be all over the place. From what I gathered, it is a vision of a web that runs largely on the blockchain, in order to make ‘owning’ assets better for people who create them and people who purchase them, by cutting out middlemen. This vision is not to be confused with the Semantic Web, which was also called Web 3.0, and discussed years before (see an article from 2006).

Here’s the thing. There is no institution that regularly releases new versions of the web, and recently happily announced this one. Instead, the phrase ‘web3’ was coined in 2014 by a co-inventor of a blockchain technology and since used by crypto asset enthusiasts and certain venture capitalist firms, for what is, some argue, close to ponzi schemes and, in its current form, very environment unfriendly. It also puts vulnerable people at risk (see Molly White ‘s web3 is going great for examples of those claims).

I’ll keep my issues with ‘web3’ for a later post, for now I just wanted to make the point that it’s unfair to claim a version number for the web for a specific set of innovations you happen to like. There are many ways the web evolves. Sometimes they involve the kinds of technology that ‘web3’ adepts use, but usually they don’t. These are some web innovations I like:

New standards are written to harmonise how web tech works and invent new tech responsibly and across user agents, like CSS Grid Layout, WebAssembly and map/filter/reduce in JavaScript
New companies start useful services, like payment integration services and ‘content as data’ headless CMSes
Individuals start blogging on their personal sites, on which they own their content
Governments and organisations roll out reliable, useful and accessible authentication services (like DigiD)
Video conferencing companies bring their software to the browser
Adobe brought Photoshop to the browser
A couple of Dutch museums put all their entire catalogue of art online (eg Rijksmuseum, Stedelijk and Van Gogh Museum)

Maybe that list is a bit random, you probably have a list of your own. Many of these things are working just fine. I could personally go on and on about some very useful plans for the web. There are also lots of unsolved problems, like lack of web accessibility or Facebook’s business model. Cool things are planned for the web all the time and there are lots of problems that aren’t yet addressed. Most of the web is fine. At the same time, there are also plans and problems. Frankly, I don’t think we should use version numbers just to market a specific subset of plans and problems for the web. Especially not if that’s such a controversial subset.

Originally posted as The web doesn’t have version numbers on Hidde's blog.

[email protected]?subject=Reply%20to:%20The web doesn’t have version numbers">Reply via email

Joining Sanity

2022-01-07T00:00:00Z

Mid February I will start a new job: I am excited to join the developer relations team at Sanity!

I had my last day at W3C in October (look, my cool URI didn’t change) and set out to be mostly away from work for a couple of months. I guess I’m not great at this, as, besides another school lockdown here, I got fairly busy with existing projects. I did some WCAG audits, workshops, conference talks and… interviewing. I wanted to make sure to find the right place and took the time to do it. Having been a contractor for over a decade, it was my first time doing interviews, eh, ever.

My work at WAI taught me to consider the web in terms of systems like authoring/developer tools and user agents, as they impact the web in some very specific ways. It became clear to me I wanted my next role to be at a company that is heavily involved in somehow making the web better through tools like that. Whatever a better web looks like… more accessible, more secure, more privacy-aware… I got to talk to a number of different companies working on browsers, design system tooling, browser add-ons, web standards and content management tools. I could write about the job hunting process, but Mu-An already did that brilliantly.

The Sanity developer relations team made a great impression. The company has a cool product that solves some important problems, a friendly community (plus focus on keeping it healthy), lots of ecosystem, aaaand… there could be lots of new ecosystem possibilities. Sanity’s Year in 2021 blog post has a lot more detail on what Sanity is up to.

For the next few weeks, I will be finishing my current accessibility consulting projects with the Dutch government and Mozilla, go on holiday and then, get this new chapter started!

Originally posted as Joining Sanity on Hidde's blog.

[email protected]?subject=Reply%20to:%20Joining Sanity">Reply via email

Boolean attributes in HTML and ARIA: what's the difference?

2022-01-12T00:00:00Z

Some attributes in ARIA are boolean(-like). These attributes may seem a lot like boolean attributes in HTML, but there are some important differences to be aware of.

George Boole, the philosopher and mathematician who came up with a type of algebra that has just true and false as its variables

Boolean attributes in HTML

In HTML, some attributes are boolean attributes, which basically means they can be true or false. They are the case, or they are not the case. They compute to one, or they compute to zero. Examples of these attributes include checked, required, disabled and open.

Boolean attributes in HTML are true when they are present:

The presence of a boolean attribute on an element represents the true value, and the absence of the attribute represents the false value.

(From: HTML, Common microsyntaxes, Boolean attributes)

So, if a checkbox is checked, it has the checked attribute, otherwise it does not. The attribute, when present, can have any value, like checked="checked", though the HTML spec explicitly says we should not use true or false as attribute values for boolean attributes:

The values “true” and “false” are not allowed on boolean attributes. To represent a false value, the attribute has to be omitted altogether.

It would work though: the checked attribute works with any value, even checked="true" or checked="false" represents that the input is checked:

<!--  
  on first render, the following 
  checkboxes are in checked state 
-->
<input type="checkbox" checked="true" />
<input type="checkbox" checked="false" />
<input type="checkbox" checked="hello" />

 <!--  
  on first render, the following 
  checkboxes are not in checked state 
-->
<input type="checkbox" />

In some cases, browsers will help us manage the presence of these attributes. They don’t for checked, but they do for details/summary (the open attribute on the details element when its summary is expanded or collapsed). In other cases, the browser can’t manage presence or absence, like for the required attribute. Whether an element is set to required, is up to the author’s intention, the browser defaults to “not required”.

The attributes I discussed earlier are what specifications call ‘content attributes’, we write them in our markup. In JavaScript, we can also affect the truth value of these HTML attributes with so-called IDL attributes, for instance:

element.checked = true; // sets checked state to true
element.checked = 'checked'; // sets checked state to true
element.checked = 'foo'; // also sets checked state to true
element.checked = false; // sets checked state to false
element.checked = ''; // sets checked state to false

Boolean attributes in ARIA

In ARIA, there are also attributes that can be true or false, but their state is expressed differently. It is a different language than HTML, after all. HTML is the most common host for it, but ARIA can also be used in other languages, like XML and SVG.

As explained previously, HTML has the concept of boolean attributes. It also has the concept of keyword and enumerated attributes. These attributes can come with a fixed number of string values. When ARIA is used in HTML, we use these types of attributes. This means that when we say “boolean” in ARIA, we’re really talking about strings that happen to be use the words “true” or “false”.

According to the type mapping table in the WAI-ARIA 1.1 specification, there are three different attribute types in ARIA that explictly list ”true” and “false” as possible values:

attributes that are “boolean”, which accept only "true" or "false" (eg aria-busy, aria-multiline, aria-readonly)
attributes that accept "true", "false" and "undefined" (eg aria-hidden, aria-expanded, aria-grabbed, aria-selected)
“tristate” attributes, which accept ”true”, "false" or "mixed" (eg aria-checked, aria-pressed)

That’s not all, as there are also properties with different and larger sets of possible values:

aria-invalid (takes "grammar", "spelling", "false" and "true")
aria-haspopup (takes "true", "false", "listbox", "menu", "tree", "grid" and "dialog")
aria-current (takes "true", "false", "page", "step", "location", "date" and "time")

All of these fall into that “keyword and enumerated attributes” bracket, they take a nullable DOMString.

ARIA attributes can be set using setAttribute(). From ARIA 1.2, which is currently a “Candidate Recommendation Draft” (it’s like a Candidate Recommendation, but with significant updates made to it), ARIA attributes can be specified using IDL attributes, too, for instance:

element.ariaChecked = "true"; // sets `aria-checked` to true

Scott O’Hara wrote about this upcoming feature in his post New in ARIA 1.2: ARIA IDL attributes.

HTML vs ARIA booleans

So, for HTML boolean attributes it’s all about presence and absence, while in ARIA boolean attributes, the boolean state is expressed via "true" and "false" string values and there are bunch of attributes that take those strings and a couple more.

Some examples of these differences:

The absence of the checked boolean attribute maps to aria-checked="false" (unless it was modified, that is… so this mapping only applies in the elements default state)
The presence of the disabled attribute maps to aria-disabled="true"
The presence of the open attribute on details maps the state of its summary to aria-expanded="true", the absence of it maps it to aria-expanded="false"

Summary

So, there are boolean attributes and keyword and enumerated attributes in HTML. When ARIA booleans are used in HTML, they are of the latter type. They take one of two keywords: "true" or "false". There are also ARIA attributes that take "true" and "false", but also other keywords in addition. Those may look like booleans at first sight, but are not. That’s all, thanks for reading!

Originally posted as Boolean attributes in HTML and ARIA: what's the difference? on Hidde's blog.

[email protected]?subject=Reply%20to:%20Boolean attributes in HTML and ARIA: what's the difference?">Reply via email

Use Firefox with a dark theme without triggering dark themes on websites

2022-01-12T00:00:00Z

With prefers-color-scheme, web developers can provide styles specifically for dark or light mode. Recently, Firefox started to display dark mode specific styles to users who used a dark Firefox theme, even if they have their system set to light mode.

There is a flag in Firefox that determines whether dark/light preferences are taken from the browser or from the browser theme.

This is how you set it:

Go to about:config
Search layout.css.prefers-color-scheme.content-override
Set it to 0 to force dark mode, 1 to force light mode, 2 to set according to system’s colour setting or 3 to set according to browser theme colour

(via support.mozilla.org)

Personally, I feel respecting the system setting worked better. I hope it gets changed back. In the mean time, I hope this override helps.

Originally posted as Use Firefox with a dark theme without triggering dark themes on websites on Hidde's blog.

[email protected]?subject=Reply%20to:%20Use Firefox with a dark theme without triggering dark themes on websites">Reply via email

More to give than just the div: semantics and how to get them right

2022-01-23T00:00:00Z

One of the web’s killer features is that it comes with a language for shared semantics. When used right, HTML helps us build websites and apps that work for a broad range of users. Let’s look at what semantics are and how to get them right.

This post is a write-up of a new talk that I did in November at Web Directions and Beyond Tellerrand. A video is available if you prefer.

Semantics as shared meaning

Semantics, in the simplest defininition that I know of, is what stuff means. This isn’t just a thing on the web… for literally millennia philosophers have argued about what stuff means, going from Plato in ancient Greek to people like Wittgenstein, Quine and Davidson in the last century.

Some of the earliest theories of meaning are correspondence theories. They say the meaning of a word is the thing itself… so the meaning of the phrase “that glass of water” is that actual glass of water. If I want to say the glass if half full, you can verify if my claim is true by checking the contents of the actual glass. That’s somewhat straightforward.

The 20th century philosopher Ludwig Wittgenstein initially had a theory like that, but changed his mind towards the end of his life. He then, famously, concluded that the meaning of a word is not the thing it refers to, but its use in the language. Meaning equals use.

Wittgenstein and one of his most famous works: Philosphical Investigations

‘Meaning equals use’ is about how words are used day to day, in a community… if everyone uses ‘water’ as a word to talk about water, that’s what is meaningful. If some of us started using ‘bater’ instead of ‘water’, and we continue to do that, it works for us, like, we effectively exchange water using that word, that then starts to be meaningful. We have a shared understanding.

‘Meaning equals use’ is also Wittgenstein moving away from talking and theorising endlessly about words and their meaning. It doesn’t really matter, in many cases, what words mean, unless they are things that matter to a community of people.

So, basically, meaning requires that a group of people uses a phrase in the same way. Now what if you’re alone? Wittgenstein argued there can’t be a private language. In other words: there can only be meaning if it is shared. There’s an interesting parallel between that idea of shared meaning and the web, especially when it comes to web accessibility.

Shared meaning on the web

In a way, your design system is a shared language. It’s a collection of shared concepts, shared patterns, between people in your team, your organisation. There is meaning, because you all use the same words for stuff on your websites. Language plays a huge part, because design systems don’t work as well if developers, designers and content folks all use different terminology. It’s that alignment that matters, the fact that you’re using the same words to describe your patterns.

APIs are another example of shared semantics in practice… they’re a written contract about how a service will respond to requests with certain phrases, names.

Whatever framework you prefer… when you write code, the names of your components, you use a shared language. In the names of files, classes or functions, for instance.

Naming and what to call things depends on place and culture, too. When I first visited the US, I was surprised by the enormous size of a ‘small’ coffee… similarly, beers in Germany exist on a very different scale than they do in The Netherlands. The classification is different, or, you know, we use different categories.

Semantics is agreement about what things are, and this can be hard. There can be disagreements about meaning and classification. So, moving from philosophy back to technology… what does this mean on the web?

Semantics on the web

You could have lots of semantics on the web, too. With XML schemas, you can create your own language, for instance. If you want to mark up an invoice, you can invent your own tags for everything on the invoice. With an XSD file you can define your own schema and say what’s what in your world, which is helpful for validation and stuff.

Your own schemas!

Now, for accessibility, we don’t want a semantics specific to our needs… we need one, agreed-upon set. We have this: it’s HTML! HTML is a standard way for your website to declare semantics. It is standard in the sense that every website uses it. Any system that parses the web can make the same assumptions about what stuff is in HTML and what it means. Browsers, assistive technologies, add-ons… you name it!

To clarify a common confusion: HTML isn’t a way to declare what stuff looks like on the page… something may look like a button, but if it goes somewhere, the correct semantic is link… the anchor tag.

Why HTML matters

So, does HTML matter? Well, it certainly enables a lot.

A multi device web

As a shared system for semantics it enables a multi device web. The first WorldWideWeb server, multimedia browser and web editor ran on a NeXT machine, which looked like… well, just like what personal computers looked like 30 years ago.

This NeXT machine was used to develop and run the first WWW server, multimedia browser and web editor

It’s only thanks to HTML that the same web pages from those days can still display on today’s devices, and that one HTML structure can be served to desktops, tablets and refrigerators with different layouts. CSS can do this, only because of HTML. It’s pretty much what powers the responsive web.

Default stylesheets

Default stylesheets are another example: because we define page structure in HTML, browsers can come up with defaults for things like headers, so that even in documents that have no styles, there can be visual distinction. And this could go even beyond visual stylesheets… your car could speak websites to you and emphasise parts of a sentence that are marked up as needing more emphasis. Assistive technologies could do that too.

Navigate by heading

Or what about using structure to provide easier access? Screenreader users commonly browse using headings on a page… for instance in VoiceOver, one can go through a list of headings. That only works if they are marked up as headings.

Default behaviour

HTML enables default behaviour too, tied to semantics. If you say something is a button, by using a button tag, and place it in a form, it will submit that form by default.

Reader modes

Or what about reader modes? If pages have useful markup, like headings, lists and images, the heuristics of your browser’s reader mode can go ahead and render it better. This is important, because in 2021, websites often have intrusive ads, cookie consent mechanisms, paywalls and newsletter signup overlays… some websites collect them all. Reader modes are useful tools to deal with the web of today, they give users control.

Okay, so HTML is nice, it enables lots of things, given that we use its semantics correctly anyway. Of course, the elephant in the room is that not all websites get their HTML right. Some miss out of these advantages. This is why I feel it makes sense to hire for HTML expertise. For most developer roles, it’s not or hardly an issue in interviews or resume scans. It should be, HTML knowledge in your teams can save your organisation money… hire for this expertise or train developers.

Semantics in HTML

Ok, so what do semantics look like in practice? The HTML standard has a section about semantics, and it explains that semantics in HTML is in three places:

elements: you can wrap text in a heading element and boom, it has heading semantics
attributes: the controls attribute on a video marks it as a video that can be controlled.
attribute values, for instance you can distinguish between email and phone input fields with the type attribute, or between opened and closed details elements with the open attribute

Besides using semantic HTML elements, like button, you can also opt to use non-semantic HTML elements, like <div> and then add the semantics with a role attribute, in this case, role equals button, using something called WAI-ARIA. That’s not ideal, because it only adds the semantics for button. It doesn’t add all the other stuff browsers do when they encounter a button, like keyboard handling, submitting forms if they’re in a form with the default button type and the button cursor…

So, if possible, use the actual button element, it has the broadest support and comes with the most free built-in behavior.

How do semantics help practically?

In his post The practical value of semantic HTML, Bruce Lawson explains semantic HTML is ‘a posh term for choosing the right HTML element for the content’. It has observable practical benefits., he says. This is an essential point, and what I want to emphasise too. Adding semantics to a page is choosing the right elements for the content, which makes a page easier to use for a wide range of people on a wide range of technologies. Let’s look at some examples of those.

Headings

We’ll start with headings. If you use heading elements, that is h1, h2, h3 and so on, users can see those elements as headings when they use reader mode. That’s nice. You’re also creating what is essentially a table of contents for users of some assistive technologies.

When you use a Word processor you have this feature to generate a table of contents automatically… often used in documents like an academic thesis or a complex business proposal.

Buttons

Buttons, then… I mentioned them before. When you use a button element for any actions that users can perform on your page, or in your app, they can find it in the tab order, they can activate it with just their keyboard and they can even submit forms, depending on the button type. That even works when JS is disabled.

Lists

With lists, like ol, ordered list, ul, unordered list and dl, description lists, users of screenreaders can get information about the length of the list, and, again, users of reader mode are able to distinguish the list from regular content.

Input purpose

If you use the autocomplete attribute on inputs, you’re programmatically indicating what your input is for. Software can act on that information. For instance, browsers could autofill this content. This is very helpful for users who may have trouble typing or use an input method on which typing takes more time (you know, the kind of interface where you enter text letter by letter, like on tvs with your remote control). Assistive technologies can also announce the purpose when the user reaches the field, which can be helpful. Lastly, for improved cognitive accessibility, users can install plugins that insert icons for each of the fields, to make them easier to recognise.

Tables

If you’re using table elements, for instance if you have some data on your page, you’ll want to add a caption to describe what is in the table, to distinguish it from potential other tables on the page. But also use th elements for the headings and scope attributes on those the elements to say whether they apply to a column or a row. This is to ensure assistive tech can make sense of it.

There are a lot of tags available in HTML, each with their own advantages, many have implied semantics. To find out when to use what, use developers.whatwg.org. To learn about what to avoid, see Manuel Matuzovic’ excellent HTMHell.

Gotchas

Ok, so you’re following the HTML spec and avoiding the tragedies described on HTMHell, are you there yet? For a large part, yes. But there are some gotchas.

Even with the right intentions, the web platform may have some surprises. Sometimes, assistive tech uses heuristics to fix bad websites, which may affect even your good website. Let’s look at some of these gotchas.

CSS can reset semantics

The first relates to CSS. When you add CSS to your HTML, it can cause your intended semantics to reset.

The display property does this, as Adrian Roselli has documented in detail on his blog and elsewhere. Whenever you use display block, inline, grid, flex and contents on an element, that element can lose its semantics. This happens on elements including lists and tables. It’s especially bad on tables, because they can be complex. Though assistive technologies have mechanisms in place specifically built to navigate tables, those mechanisms rely on consistent and correctly marked up tables, with the right markup and with the right semantics.

Not only can these CSS properties can affect semantics, how they do differs per browser, some browsers drop more semantics than others and some may fix these problems, which I feel we can consider browser bugs mostly, in the future. Adrian’s post has some compatibility tables mapping properties to HTML elements and specific browsers,

Lists without bullets

Lists can also lose semantics if you undo their visual styling. This has to do with a tension that sometimes exists between on the one side, websites and how they are built, and, on the other side, assistive tech trying to give the right experience to end users. These kinds of things aren’t bugs, they are the result of a careful balancing act.

Because, really… what is a list? If you list a couple of ingredients on your recipe websites and visually display bullets, that is clearly a list. It looks like a list, it feels like a list, it needs list semantics.

Let’s say you have a list of products, maybe they are search results or a category view of some kind. Is that a list? I said list of products… but there are no bullet… some browsers argue that if there are no bullets, there is probably no list. Safari is one of them.

James Craig, who works for Apple, explained on Twitter that “listitis”, developers turning too many things into lists, was a commonly complained about phenomenon, by end users:

Lististis on the Web was one of our biggest complaints from VoiceOver users prior to the heuristic change.

(tweet from James Craig)

The decision was about the user’s experience, he explains. He feels the heuristics make sense, but also invites suggestions.

Nesting semantics

Nesting also matters when browsers determine the semantics for a specific element on a page. Sometimes, browsers will undo semantics when you nest unexpectedly.

One place I recently came across this at work, is when using a details element as an expand/collapse. With the summary element, you define the content that’s always there and acts as a toggle for the remaining content. Sometimes it can make sense for the toggle to also be a heading.

Let’s say your content is a recipe. Maybe you have one heading for ingredients and one heading for method. Having the headings makes this content easier to find for users of screenreaders, having the expand/collapse could make the content easier to digest for other users. Can we have this food and, ehm, eat it too?

It turns out, not really, at least not in all combinations of browsers and screenreaders. In JAWS, for instance, the headings are no longer headings when they are in the summary element, and I should thank my former colleague Daniel Montalvo for pointing me at this.

It kind of makes sense, a summary expands and collapses, it’s an action, a button, so how can it have those semantics, but heading semantics too? The spec says a summary element can contain phrasing content, which is, basically, just words, but it also says ‘optionally intermixed with heading content’, in other words, the spec says it’s ok to put headings in summary. It seems we can call this a bug of this specific screenreader. A screenreader trying to do the right thing and “unconfuse” what they think could be confusing.

That’s a common theme in many of these things. There are some more heuristics that screenreaders apply, that could somewhat mess with your intentions.

The future

So, we’ve looked at what semantics is, how it works on the web and what specifically can affect it on your websites or apps.

Let’s now have a look at the future. I’m interested in two questions:

does the web need more semantics, eg does the shared language of the web need to be expanded in the future?
do developers of the future still need to define semantics or can machines help?

More semantics

Let’s start with the first. As a matter of fact, our design systems commonly contain things that don’t exist as such in HTML, they don’t have their own elements… I’m thinking of common components like tabs and tooltips.

Sometimes we also build things that do exist, but not with the desired level of styleability, think components like select elements. What if we want the select semantics, but not that default UI?

The Open UI Community Group at the W3C tries to change this, or as it says on the Open UI homepage:

we hope to make it unnecessary to reinvent built-in UI controls

There are three goals to Open UI:

to document component names as they exist today. What are people building in their design systems? Again, trying to find where language is shared, common denominators.
to come up with a common language to describe UIs and design systems
to turn some of this into browser standards… wouldn’t it be cool if there were more built-in elements that are well-defined and follow common practices?

I believe this work to be quite a big deal… not just for semantics, but for web accessibility in general. With more defaults, and also better defaults, it will be easier for folks to build things that are accessible. That will greatly increase our chances of a web that is generally more accessible.

AI and semantics

Then one last thing to leave you with… the question whether Artificial Intelligence (AI) could guess semantics, so that we don’t need to rely on authors to get them right. I can tell you that personally I am sceptical… AI is notoriously bad at understanding intentions and context, which, as we’ve seen, are both at the core of what defining semantics is about.

There may be some low hanging fruit, things like lists are fairly easy to guess, but, thinking back of that button and links example earlier… how should a machine understand that that thing that looks like a button is actually a link? Author intentions are essential.

Having said that, I have heard friends at browsers say they are experimenting with recognising semantics in pages, with some success. I will be following this with a lot of interest.

Conclusion

Thanks for reading all the way to the end, or for skipping to the conclusion. I’ll summarise the three main points once more. Firstly, semantics only work if they are shared, so study and use the HTML standard. HTML is the shared language for semantics on the web and this is what browsers and assistive tech are most likely to build upon. Secondly, semantics on the web are beneficial in many ways, some may be unexpected. Lastly, beware of how CSS, ARIA and assistive tech can impact your semantics, and, ultimately, the end user.

So, how do you get semantics right? Basically, by figuring out what end users will experience for all of the HTML your write. For all the content that is not merely for styling. In fact, divs are fine for many things on your page. But if your page contains headings, links, buttons, form fields, tables, lists and navigations… marking them up in the right HTML tags makes your site easier to parse for browsers and, consequently, easier to browse for end users.

Originally posted as More to give than just the div: semantics and how to get them right on Hidde's blog.

[email protected]?subject=Reply%20to:%20More to give than just the div: semantics and how to get them right">Reply via email

Re: nuance in ARIA

2022-01-28T00:00:00Z

In a recent post, Dave Rupert wrote about how HTML is general and ARIA is specific. He explains that unlike HTML, in ARIA is quite specific.

This resonated with me. Of course, to use HTML, you’ll want to be specific about what you use, because semantics. But, as Dave writes, there is usually more than one way to do something. Between different ARIA roles, states and properties, there is more nuance.

One reason ARIA is more nuanced, is that the world of ARIA mimicks the world of assistive technologies, through platform accessibility APIs. Assistive technologies already exist, and they already interact with platform APIs in specific, defined ways. When web developers build interactions that assistive technologies are aware of, ARIA can be used to describe most of these specific interactions.

ARIA specifically distinguishes between menu items and links, or between alerts and alert dialogs, because operating systems and assistive technologies do. Technologies like voice control software, hardware switch controls and screenreaders rely on the roles, states and properties that are conveyed to them. Being specific helps them get it right. Whatever their ‘it’ is, there is a wide variety of tools that convey web content and parse accessibility meta data. Standardised nuance makes things more interoperable, reducing gaps between what websites want to do and what different assistive technologies are able and used to do. It also makes things more consistent for end users.

Because ARIA maps to the nuance of operating systems’ accessibility APIs, web developers have to understand those nuances too. Or… the nuance gets lost. In WCAG audits, I often find ARIA where the developer missed some of the nuances of specific ARIA concepts. I hear the same from other auditors, and, anecdotally, it feels to me that ARIA misunderstandings in real websites are quite common. To nobody’s fault, really, the nuance exists and it can be complex.

When developers misunderstand the nuances and specifics of ARIA, end users draw the short end of the stick. Which brings me to a closing question… what if there are ways to move the specifics and the nuance of ARIA towards browser code?

As Greg Whitworth tweeted the other day:

My personal goal is that the majority of web developers don’t have to touch ARIA for 80% scenarios. Thus devs will be delivering our users a more accessible and yet richer experience

Nicole Sullivan tweeted about this in October, too. Quoting from the middle of her thread (read the full thread, it is good):

I’m advocating for CSS & HTML that can swap from one tab to another.

Could we cover 80% of the use cases for tabs if we had a declarative way of building them? Then JS could handle the 20% of tabs that are so custom they can’t be declarative? Idk yet, but let’s try?

I’m also advocating for a11y to be built in. It’s beyond nonsense that every developer has to manage individual ARIA properties.

The ARIA part got over a 100 likes, it seems there is interest in this stuff!

I would love to see some of the current Open UI CG and CSS WG work lead to this. I’m thinking HTML elements that have ARIA baked in, and/or CSS properties that impact accessibility trees. You wouldn’t set ARIA as a developer, but if you would look at the afffected DOM nodes in the accessibility tree, you would find that the expected accessibility information is conveyed. This is, of course, easier said than done. Because web developers will have to indicate somewhere what it is they want. Browsers can’t magically make up the ‘nuance’ (but in some cases, they could cover quite a lot of ground).

As I understand it, ARIA attributes were once introduced as a temporary solution. Moving more ARIA specifics to browser code could reduce the surface for problematic ARIA in individual websites. The challenge, I guess, is to come up with ways to let developers express the same ‘ARIA nuance’, but in HTML and/or CSS, maybe by combining specific bits of nuance into easier to grasp primitives (this is non trivial; if it sounds like fun, join us in Open UI!).

Originally posted as Re: nuance in ARIA on Hidde's blog.

[email protected]?subject=Reply%20to:%20Re: nuance in ARIA">Reply via email

Menlo Park

2022-02-26T00:00:00Z

I’m in Menlo Park. Not only is a controversial social media platform headquartered here, it is also home to the (just opened) Guild Theatre, where Robert Glasper performed tonight.

I love it when people happily cross over the borders of their disciplines. Musicians are great at this. Robert Glasper’s music made it into the top 10 of multiple charts, because his music is in multiple genres: jazz, R&B and hiphop. And then probably some more. In 2012 he created the Black Radio album, and followed up with Black Radio 2 in 2013. Over the years he played with his quartet the Robert Glasper Experiment and the Robert Glasper Trio, and has done lots of awesome collaborations. He worked with legendary rappers like Q-Tip, Snoop Dogg and Kendrick Lamar, and played his own versions of anything from Radiohead (“I’m a reasonable man, get off my case”) to Miles Davis. I mean, why pick one specific genre and stick with it forever?

Many web developers cross between and learn about different parts of our industry, too. They might be specialists in web accessibility, security or the JavaScript ecosystem, but also learn and understand other parts. There are so many sub disciplines. Of course, nobody knows everything, that’s not realistic nor the goal. But expanding skills and knowledge widely is worthwile (also, eh, especially, outside the realm of tech). My favourite web developers are the curious ones, open to figure out how things fit together and learning new things. I feel curiosity and crossing disciplines can result in better products.

Glasper at The Guild Theatre, 25 February 2022

Anyway, I managed to get tickets, masked up and enjoyed the music! The concert was very good and memorable, both Glasper’s performance and the awesome MC who played “a couple of records” before the band got on stage. It was well worth the trip to Menlo Park. I did not take a selfie with the Meta logo.

Originally posted as Menlo Park on Hidde's blog.

[email protected]?subject=Reply%20to:%20Menlo Park">Reply via email

Photo blogging with Sanity and Eleventy

2022-03-23T00:00:00Z

After two years of being mostly inside, I developed an increasing desire to travel. I’m also a millennial developer in the age of social media, so I felt like I needed a way to share where I was going. In this post, I will show how I built a personal photo blog. My tools of choice: Sanity and Eleventy.

Disclaimer: I recently started working at Sanity, so I am biased. Of course, other authoring tools and content platforms exist too; use what works for you etc.

where.hiddedevries.nl

A wishlist

There are a lot of ways to share photos online, but what would I do if the proverbial sky was the limit? Here’s some things I wanted for my photo blog.

Control

Something I find particularly important on websites, especially when they have my personal content, is that I have control. Control over where the content would live was important, I wanted to be able to move my stuff to elsewhere. I wanted to decide what URLs looked like. I also wanted control over how my content was presented.

Works from a phone

Travel updates are particularly place and time specific. I usually find time to write updates while I’m still traveling, so the ability to compose on the go would be a must have. This could have different shapes and forms. The photo-taking would always be on the go, of course, phones and cameras are very portable. But I also wanted to publish photo content from a mobile device. In my case that meant not using git for content, but a CMS (!).

Can put location data to use

These days, most (phone) cameras can save location data into the image file: latitude, longitude and level. This is fairly privacy sensitive, so I would not always want to share it. On a photo blog though, for photos I picked, it seemed like a useful thing to add, especially since this would be data under my control.

Is a product instead of me

I didn’t want to be the product, I wanted to pay for storing my content, or at least store my data in a place that charges customers for storage.

Lives on a URL I control

To decrease reliance on specific systems, I desired to set this personal archive up with URLs that I control. This makes it possible for me to move my data to a different URL, without breaking The Web.

Has simple syndication

To ensure that people have an easy way to find new content, I also wanted to implement RSS, or Really Simply Syndication. It points RSS readers to my content, so that they can show it in their timeline.

Building blocks

Ok, so with that wishlist in mind, I started out building myself a photoblog using Sanity, Eleventy and Netlify. Except for Eleventy, these are commercial tools, but they have free tier quota that a personal photo blog will be unlikely to exceed. In any case, they meet the “I’m not the product” item on the wishlist.

Sanity

Let’s start with the Sanity part. As mentioned, I recently joined the Sanity team, and this project is my first deep dive into the product. Or products, really.

Sanity has multiple products that together form an ecosystem that can power your content creation and delivery process.

The first is an authoring tool, called Sanity Studio, that presents a UI that mirrors your content structure. If you have a recipe website, it can have fields for “ingredients”, “method” and “vegan-friendly”, if you are a concert venue, you may want fields for artists, genres and photography. You can have fields that are strings of text, dates or images, to name a few.

There is also a place to store content, called Content Lake, to which you can send data, using the Studio or using anything else that can do HTTP, like curl. This is where content is saved in the structure you define, and without storing any HTML. The Studio saves your stuff in real time, which also comes in handy if you work on content with multiple people simultaneously.

And then there is a query language called GROQ, that you can use to request precisely the content you need in your website (or any JSON file, also outside Sanity). It’s a little bit like GraphQL, for those familiar with that, Sanity supports that too (yay choice!). In my case, if I wanted to query photos, I could ask for them all, or request photos taken in a specific location or with a specific aspect ratio. I can then specify which data I want from that selection, such as the description or alternative text.

So, Sanity has a set of tools that each deal with a specific part of your content processes, covering the creation, storing and fetching of content. What it doesn’t offer is a front-end, this is by design.

Eleventy

For building front-end projects, I’m a huge fan of Eleventy, a Node tool that can create static websites. I love it for being unassuming and unopiniated. It is great for progressive enhancement, too, as it doesn’t ship with JavaScript in the runtime if you don’t ask it to. You feed it data, write templates and it will create HTML for you that you can host somewhere.

Eleventy makes it easy to set up an RSS feed with the RSS plugin, set up URLs however you like and output HTML that you have full control over, so that’s a few of my wishlist boxes checked.

Netlify

Which brings me to hosting. When Eleventy has built a folder of static HTML files and assets, we’ll need to put that folder somewhere to see it on the web. We’ll use Netlify for that, as it can conveniently integrate with GitHub as well as Sanity, i.e. do its thing when there are changes in code or content.

Process

With those tools, I built my personal photoblog. Below, I will go into some of the stages I went through from start to finish. I used a starter project, defined a content structure, ensured I could add photos, wrote a query to fetch my data, built a front-end to display that data and then set up automated deployments.

Starter projects

I got started using the Sanity / Eleventy starter project. These starter projects ‘magically’ set up everything you need for a Sanity project: the authoring tool, the data storage, a GitHub repo and some minimal starter code that shows how to query and then use the data you get returned. The starter project tool sets all this up for you and does the necessary plumbing to leave you with working development and production environments.

The three steps of this starter: connect Sanity, connect to GitHub and connect to Netlify. With these permissions, the starter script sets things up on behalf of you.

Magic and code, not everyone loves it. I might opt to set up each part manually, but it was nice to see the steps in action and have a working environment in minutes.

Content structure

With the setup out of the way, my next task was to figure out how to structure my content. After trying some different structures and ideas, I ended up with just two content types, Photo and Category. For categories, I wanted to save a name. For photos, I wanted to save an image including colour and location data, a text alternative, a title, a date and a Category.

In Sanity, content structure is defined in code, this is part of what my main image type lools like:

{
  name: 'mainImage',
  type: 'image',
  title: 'Image',
  options: {
    hotspot: true,
    metadata: [
      'location',
      'palette'
    ]
  },
  fields: [
    {
      name: 'alt',
      type: 'string',
      title: 'Alternative text',
      description: 'What\'s on this picture?',
      validation: Rule => Rule.error('You forgot to describe this image').required(),
      options: {
        isHighlighted: true
      }
    },
  ],

It has an image field with “hot spot”, so authors can say which part of the photo should be prioritised in case of cropping and it has a compulsory field for alternative text.

For images, Sanity strips out most metadata by default. In my case, I actually wanted to share location data, so I turned that on manually, adding location to the content structure. I also opted for Sanity to extract colours from uploaded images using the opt-in palette feature. For more information, see Sanity’s Image Metadata documentation.

Adding photos

The authoring tool is in your repo, too. You can run it on a local server, host it with Sanity or host it with any web hosting. It is “just” a Single Page App that does HTTP requests.

Editing a post on desktop and mobile

In my case, my wishlist said I wanted to do some of this on my phone, so I deployed my Sanity Studio on a URL, in my case on Netlify. I say “I deployed”, but the first Netlify deployment of my Studio was actually set up by the starter project. The Studio works on phones, because it has a responsive UI and not a lot of fluff that requires screen real estate. Sanity’s image upload component is a regular file upload, that, on my phone, was able to take input from my photo library as well as from the camera directly.

A common, Jamstacky way to host a blog or photo content would be to put the content in a git repository, probably using some combination of Markdown for content and Yaml for metadata. I do that for my Books, and it works ok for me. But for editing on the go, it is actually nice to have a CMS, not content in git. It saves from the trouble of finding a way to run or trigger add, commit and push commands from my cli-less mobile OS.

Data collection

As mentioned earlier, Sanity supports this query language called GROQ. There is a CSS-Tricks post on how to use GROQ on your data, but I’ll go through my query for content too.

GROQ queries can have these three parts:

the dataset with all your documents
a filter (which subset of documents you want)
a projection (the shape of the data from that subset)

Let’s look at an example that combines the first two parts. First, it requests all content in my dataset (*) , then it filters for data of the “post” type that has a slug and has a “published” date before now (so anything that’s not set to be published in the future):

*[_type == "post" && defined(slug) && publishedAt < now()]

Then, from that data, we can define a specific set that we need for the photo blog:

{
  _id,
  publishedAt,
  title,
  slug,
  mainImage {
    ..., 
    asset->
  }
}

This requests an object of a specific shape for each post that is returned. The _id is an internal property, publishedAt and title are the publish date and a title, the slug is a URL friendly string and mainImage has a pointer to where the image lives.

From the mainImage, we’re specifically requesting two things with the projection ({}):

First, we “spread” all the properties of the mainImage object with ..., a bit like the spread syntax in JavaScript.
Then, we also join in the reference found in asset->.

The thing is, my posts don’t contain the image data, they contain references to the image data. So if I had asked for asset, I would only get access to an ID that I could use to find the referenced asset. The good news is that I don’t actually need to find it myself, as with asset->, we’re getting the data of the referenced asset and use it right there. In other words, the properties that the image asset object had are returned in place.

A “reference” is an indexed pointer to another document that you can query. In this case, the relationship is between a post and an image. This works two ways. If you’re listing images, for each image, you can request the post it relates to. If you’re listing posts, you can request the image that it relates to.

Front-end

For the front-end, I’ve gone with a page that lists all photos and a simple header and footer. There are also individual pages for each photo.

Image URL fun

Sanity has a lot of features that you can access by manipulating your image’s URL. If you know the image URL, you can add parameters to request:

specific crops; I use this for square images on my index page
formats; I use “auto formats” so that the CDN returns webp’s to browsers that support them, yay performance
manipulated versions of your images, eg with different resolutions and sharpnesses

Photo-based header colours

On the single photo page, the background of the header has the colour of the most prominent colour in the photo. I was able to build this, because Sanity can return a palette object with a bunch of colour info, including the most prominent and a color that contrasts with it. In my template, I use the HEX value from this palette property to overwrite the CSS variable that the header’s color and background-color are set with.

In the (Nunjucks) template for a single photo, I have this HTML snippet:

<style>
body {
  --header-background-color: ; 
  --header-color: ;
}
</style>

For the header colour, my site’s main stylesheet has a custom property, as CSS’s built-in variables are called. With this snippet, I overwrite it. Custom properties in CSS take part in the cascade, CSS’s system to figure out which style to use when style rules compete. In this case, the definition in my main stylesheet and the one in this template compete, and the latter wins.

Blurry previews

Photos can take time to load, so I pondered displaying something while you’re waiting. I’ve never been a fan of spinners, or, unpopular opinion, skeletons, but I found Sanity can return a ‘blurhash’. This is a string that looks like this:

d79Z$I-o4:IoxaofR*WC00Io?GxtM{Rkt7s:~VxaNGRk

It can be converted into a very blurry and small image that is specifically useful to show while waiting for the full image. This is mostly useful for users on slower connections. I have left this out from the final site.

Deployment

Own URL

My personal site is hiddedevries.nl and I want to use where.hiddedevries.nl for this project. I set up my nameservers so that they point to Netlify, where I’m hosting the website. The site now mostly meets the “own your URL” requirement, and if I get unhappy with my current setup, I can move my data elsewhere.

One aspect where I don’t own my URLs though, is image assets. When I requested images with GROQ earlier, I got a URL of Sanity’s CDN. This has end user benefits, including that it can serve assets from the data centre that is closest to you, caching and, less of an issue with HTTP/2, allows for more more concurrent downloads by having a separate hostname. For full control and with the same benefits, you might want this on your own separate hostname too. I’m told this is currently only possible in Sanity’s enterprise plan. If it’s your thing, you could totally build some sort of proxy yourself, too.

Hooks

Our generated files from Eleventy are on Netlify and need to be deployed to Netlify. When is a good time? Probably when either the code, on GitHub, or the content, in Sanity, change. We can keep Netlify posted of changes in either using webhooks:

GitHub can tell Netlify about changes, these are set in the Netlify settings
Sanity has GROQ-powered webhooks: given a GROQ query on your content, whenever the queried set of data changes, it can perform a HTTP request to a URL (and yes, that can be a Netlify build hook’s URL)

Whenever either of these happen, Netlify will run my build process. The build process comes down to:

it grabs my latest data from Sanity (the response to my GROQ query, including photo URLs, metadata like titles, text alternatives, location and colour palette)
it runs Eleventy to combine the data with my photoblog HTML/CSS
it places the folder that Eleventy outputs on the server

Wrapping up

In this post, I’ve shown how I built a personal photo blog, managing content with Sanity, generating a static site with Eleventy and hosting that site on Netlify. That’s a lot of concerns, but I feel like they are separated in a sensible way, where each piece could be replaced by some other piece if needed.

I didn’t manage to check all of the boxes: uploading photos with location data in iOS and Android seems to be impossible, they are stripped upon uploading, probably for privacy (may be continued in another blog post). To have fun with location data, I will have to upload photos from desktop.

This was a fun learning experience, thanks for reading it, I hope it was helpful! You can look at the website at where.hiddedevries.nl. The code is on hidde/where-is-hidde, the schema for a post is in post.js.

Originally posted as Photo blogging with Sanity and Eleventy on Hidde's blog.

[email protected]?subject=Reply%20to:%20Photo blogging with Sanity and Eleventy">Reply via email

Common accessibility issues that you can fix today

2022-04-12T00:00:00Z

This week, WebAIM published their latest “WebAIM Million” report. It details accessibility issues they found when they tested the web's top million websites automatically. What is some low hanging fruit you could fix today?

For context, WebAIM, a non profit based out of Utah in the US, have done their ‘WebAIM Million’ project since 2019. They post an extensive analysis every year, looking at trends and improvements/decline in web accessibility over time. I find these posts very insightful and use them to inform my own workshops and outreach. It’s definitely recommended reading!

There are some caveats to be added with surveys based on automated accessibility testing. One is that ‘ease of detectability’ does not correlate with ‘impact on end users’. There are issues that are easy to detect and issues that impact end users most, these are not necessarily the same. Automated tests also cover only a small part of all accessibility, as some things aren’t detectable by machines (yet, or ever). I’m not suggesting this makes the survey less useful or good, but wanted to call it out explicitly. The ACT-Rules Community Group at the W3C works on harmonising test rules for things that are testable.

Ok, let’s look at the top issues and how developers, browsers and CMSes can take away barriers today. Some of these include ideas about what users can do (important caveat: none of this should be user responsibility, website owners should not expect users to use or know about these tools).

Low text contrast

There are cases where text colour and the background colour have a ratio lower than the threshold in WCAG (see also MDN on contrast).

Designers can check contrast manually install plugins (using a tool like Contrast Ratio) or install a plugin like Stark for Figma or Sketch.

Developers can use an automated contrast checker to make sure you avoid low contrast text. Run a checker like the one in Firefox Dev Tools Accessibility Panel or axe in CI/CD, or paste two colours into a manual tool like Contrast Ratio.

Designers and developers alike can use Polypane’s contrast checker that suggests accessible alternatives, which makes it a lot easier to not just find the issue, but also fix it while you’re at it.

Users could use a plugin like Fix Contrast to not be affected: it tweaks colours on the fly so that you don’t have to suffer low contrast text.

There are some discussions on new colour contrast algorithms for WCAG, but this is still under discussion and not ready any time soon.

Missing alternative text

When you create content, describe your images. In your CMS, on Twitter and even in GitHub issues: use that alternative text feature, so that users who can’t see the image can access the content in them. On platforms that don’t support alternative text, like Slack or mobile LinkedIn (!), you can describe images in text. If you choose a CMS or content platform, ensure it can handle alternative text or set it up to do so.

In the resulting HTML, you’ll want something like:

<!-- image with text -->
<img src="website-logo.png" alt="hiddedevries.nl" />

<!-- image with redundant content -->
<img src="hidde.png" alt="" /> 
<p>Photo of Hidde</p>

You can make your decisions on alternative text using the Alt Decision Tree, but basically the gist is that if you were to replace your image with a square, what would you write in the square for it to still be useful? Leaving it empty is an option if that’s the most useful alternative for the image. Like in the example above, there is a photo with a paragraph underneath that describes it. In this case, writing “Hidde” or “Photo of Hidde” in the alt attribute is redundant, it would be best to use an empty alt (but do leave the attribute in there, or some browsers will use the image URL as an alternative).

Users can use Microsoft Edge, which fills in missing alternatives. AI aren’t very good at intentions or context, but pretty much perfect at recognising text. Next time a news website posts an image of new covid rules with no alternatives (as the main Dutch news website used to do throughout the pandemic), users of Edge can follow along.

Empty links and buttons

When links, buttons or other interactive elements don’t have names, assistive technologies like screenreaders or voice controls have no way to uniquely refer to them. If it is to be interacted with, it needs a name.

Imagine the difference between a screenreader saying “here's 4 buttons: button, button, button and button”, versus “here's 4 buttons: publish content, delete content, change to draft, upload image”. In the first instance, you'd need to press them before you know what they do, in the second, it is clear what you're in for, with no further context needed.

Names are derived from text content, like the actual text that’s inside a button, or can be added through an attribute. See Naming things to improve accessibility for more detail or the spec that defines how controls get their names.

Developers need to ensure all controls they build (links, buttons, form fields, etc) have names, ideally that make sense out of context:

<!-- names that make sense out of context -->
<button>Submit form</button>
<button>Publish content</button>
<button>Expand filters</button>
<a href="//wikipedia.org">Wikipedia</a>
<a href="//twitter.com">Hidde on Twitter</a>

<!-- names that are confusing -->
<a href="/">click here</a><!-- avoid -->
<a href="/">read more</a><!-- avoid -->

<!-- names that are missing; avoid or add a name -->
<a href="//twitter.com/"><svg/></a><!-- avoid -->
<a href="//linkedin.com"><img src="" alt="" /></a><!-- avoid -->
<button><img/><button><!-- avoid -->

Browsers can sometimes derive names from nearby text, some do this when there is no text to derive a name from. This is not ideal, can lead to wrong and confusing guesses and be bad end user experience. The developer of this control will know best what the thing does and therefore how it should be named.

Missing form labels

Form labels kind of fall under naming things, as they name form elements specifically.

Developers can fix this by ensuring form fields have a <label> element of which the for attribute points to the id of the input/select/textarea , this also makes that clicking label moves the cursor to the input:

<!-- “for” and “id” are same, this connects them -->
<label for="field">Address</label>
<input id="field" />

They can also add an aria-label attribute to the input to name it that way (but be careful, ARIA labels don’t get translated well).

Missing languages

Proper language indication can get you a Pass on two (!) WCAG Success Criteria (3.1.1 and 3.1.2), and you only need to know one attribute for it.

Developers should ensure the <html> element has a lang attribute with the right language:

<!-- marks this document as 'in English -->
<html lang="en">

Sometimes this is forgotten as the <html> element lives in some template you never touch, but it’s not hard to do, so always double check that this attribute exists and is set to the right language.

If there is content on part the page that is in another language, mark that too, again, with a lang attribute on the relevant DOM node. When you pick a plugin for internationalisation, ensure it sets the lang s or makes it easy for you to do so.

CMSes can make sure that lang attributes are set and set correctly. Browsers can guess languages, but they aren’t always good at this, specifically when it comes to distinguishing dialects: they often matter a lot to people, less so to machines.

Wrapping up

These are some tips based on the most common issues that WebAIM Million 2022 identified. Let’s all put in the work to make sure we, our colleagues, our clients and our users avoid these issues. Like, actually. We need WCAG auditors to focus on higher hanging fruit, by fixing the lower hanging stuff for good.

If this is all new to you, hi, thanks for reading! I hope this helps and feel free to get in touch with questions. If you already knew all of this, please keep spreading the word, so that in next year’s survey, we’ll see steady improvements for the web at large.

Want to learn more about fixing low hanging fruit accessibility issues? In response to the same survey, Christian Heilmann blogged about how to fix accessibility issues using your browser

Originally posted as Common accessibility issues that you can fix today on Hidde's blog.

[email protected]?subject=Reply%20to:%20Common accessibility issues that you can fix today">Reply via email

The URLs are new

2022-04-15T00:00:00Z

This blog has had pretty long URLs for legacy reasons. Today I've made some updates to change that.

Redirects and RSS should all work, though some feed readers seem to surface old posts as unread, sorry for any inconvenience.

For context, this used to be my company's website. I only really ever updated the blog section, so I decided to make that the main thing. The old structure lasted just over 8 years and my hope is that the new one will break that record.

URLs are such a cool part of the web, especially if they're set up thoughtfully. Like traintimes.org.uk, where you can add /london/bristol to get times for trains from London to Bristol, and /9:00 to that if you want the ones that leave from 9am.

I don't know of ways to give blog URLs very thoughtful structures, there isn't a lot of structure in this blog anyway. Anne van Kesteren's classic post on how to do blogs has some good pointers, like where an archive should live.

New blog post URLs

On this blog, a post URL used to be something like:

hiddedevries.nl/en/blog/2022-04-02-my-post

It's now:

hidde.blog/my-post

The main changes are:

new host name, reducing lots of characters, easier to remember and put on slides
single language setup, removing the need for en
no more dates in the URL structure

I wasn't super sure about removing dates, so I asked on Twitter. I didn't have a specific reason for including dates before, it was a default of my CMS and I kind of liked it at the time.

Dates matter

A couple of people replied to my question that dates on blog posts are important to readers. Especially for blog posts that share technical advice, as they could go out of date.

Other reasons for including a date are:

a less messy file system, if you put posts into actual folders in the file system; this is moot if your routes are handled by some system
it can be helpful for blog owners that code to have the date as part of the file name
prevents naming collisions
it's nice for analytics
it's a default in a lot of blog software or a choice from the past
it provides context

But there are drawbacks too:

date is usually creation date, this could make posts seem old, while the author may be frequently keeping content up to date, this could be confusing
dates are really metadata, they don't belong in the URL
it's not as simple and readable

I've gone for simplicity. I do agree dates matter though, especially on tech posts, so I have the publication date in the post content near the title (I do use GitHub's <time-ago> Web Component to display it relatively). I also include dates when I make updates, though I add those at the end rather than near the title (I probably want to improve that).

That's all for today. I've also moved away from the CMS, so if you notice anything is broken, please do slide in my DMs or email my first name at hiddedevries.nl.

Originally posted as The URLs are new on Hidde's blog.

[email protected]?subject=Reply%20to:%20The URLs are new">Reply via email

Action, inaction and ‘cancel culture’

2022-05-06T00:00:00Z

The health and inclusiveness of a community can be affected by action, but also by inaction. In this post, I'll share some reflections on banning pretty much objectively bad content and on issues with the word ‘cancel culture’.

When a political party tries to attract voters with racism, sexism and homophobia, should all pages on their website be banned from a healthy, inclusive coder community? Last week I got into a discussion I didn't expect I would get into… it could be summarised as this question. (Spoiler alert: to me, the answer is yes).

In one of my communities, someone had shared a link to a blog post on the website of a controversial, far right political party that perpetuates all sorts of racism, sexism, homophobia and misinformation. Just like that, a link in the #general channel that all members join by default, for roughly 7000 people to see, who signed up to collaborate on and talk about code. The blog post itself didn't contain such things per se, but the party owns the website.

In short: I feel such a link should not be allowed on a healthy, inclusive coder community. Failing to moderate this content can make those marginalised by systemic racism, sexism and homophobia feel unwanted. It signals that this community has no specific problems with the link, at least not specific enough to ban it. It could unintendedly scare people away and send out a message about who belongs. Should a community prioritise people who want to share or say whatever they want or people who don't want to have racism, sexism or homophobia affect their daily lives?

My point is… healthy, inclusive communities do the work to make people, especially those who are marginalised, feel wanted. For so many reasons. Sure, banning the post and maybe even the poster could make the poster feel unwanted. That's not great. But… we've got to prioritise the marginalised over the marginalisers (after all, they did post the link).

Do I feel links to all political parties should be banned? No. What about the extreme left or the somewhat right, where does it end? I don't know, but in this case it was easy to tell as this was a party with years of controversies that reasonably go against community spirits. Community members and managers should speak out if they can, remove problematic content actively and reinforce principles. Because not doing that is a message too, and it reinforces something too.

‘Cancel culture’ is the wrong word

I ended up calling for moderation and got into some conversations after that. One person called my request an opinion. Challenging my inner pedant: non discrimination is part of human rights declarations that almost all of the world's countries have signed. A request to reduce discrimination isn't an opinion, it's an attempt to claim basic human rights that whole societies agree on. Except, maybe, in communities of human rights scepticists, but this wasn't one of those.

Others said moderation would be like ‘cancel culture’ or ‘censorship’. The book We need snowflakes by Hannah Jewell, which I happen to be currently reading, does a great job dissecting these frames and the people who use them. Very often, she explains, those who claim to be cancelled ostensibly still have their platforms, be it their job or their status.

The word ‘cancel culture’ is a red flag. When you hear it used, it's worthwile considering how it's employed to shift who the victim is. In The Netherlands, we recently had football club director Marc Overmars ‘cancelled’ for sending female staff photos of his genitals. The word ‘cancel culture’ suggests calling out wrongs is an activity people do for little more than their own entertainment, and that Overmars is now some kind of victim, rather than the women he had literal power over. He was hired in the same position by a Belgian football club weeks later and his Wikipedia page hardly mentions the event (it does have a list of honours). A more apt response would be to ask: how are the women doing?

I am getting carried away a bit, but let's also consider ‘censorship’. Again, paraphrasing Hannah Jewell's book: is one truly censored if no government put rules in place to limit their free speech? If one can still say whatever they want in plenty of other places? If they aren't arrested for what they did? The ‘censorship!1!’ exclaimers should compare what they're exclaiming about to actual censorship that sadly happens in various states around the world.

In healthy communities, asking someone to remove content is simply a request to stop their harm in a specific community. Because it happens to be a community that has a principle on whose feelings to prioritise. Because that matters.

Originally posted as Action, inaction and ‘cancel culture’ on Hidde's blog.

[email protected]?subject=Reply%20to:%20Action, inaction and ‘cancel culture’">Reply via email

Test in many browsers

2022-05-12T00:00:00Z

I use Firefox as my main browser, both for development and for just regular… browsing. Increasingly, core functionality of websites breaks for me, as, presumably, not all developers test in Firefox anymore.

Yesterday, for instance. I signed up for a conference and their signup form wouldn't submit. It relied on JavaScript, which borked in Firefox. Some ES feature was used that isn't supported in Firefox yet, with no feature checks or fallbacks. As forms have been part of the web for decades, in all browsers, my primary response was ‘hey this shouldn't have to be broken!’

Testing your work in Firefox matters. Right? Well, it does to me, like testing in lots of browsers and assistive tech does. When I shared this on Twitter, realising a little late that this point is controversial, I saw some themes in the responses.

Some said Firefox should test with their websites. They do, actually… Mozilla hosts and sponsors the web compat community which helps debug sites that work in one browser and not another and feeds into improving those browsers. This is really hard and complex work, I remember from hanging out some of the people working on this when I was at Mozilla (the stories…). I recommend Mike Taylor's talk about web compat at View Source 2019.

Others signalled they found it too much work. For a large part of my career, front-end development was all about making stuff work across browsers, because they weren't as well aligned as they are today. I, for one, am so happy to be past the years of needing multiple VMs to test versions of Internet Explorer. With tools like Browserstack and Browsersync, we've come a long way.

Lastly, some said it's ‘not worth it’ given Firefox's marketshare. To be honest, I hadn't checked Firefox's market share before I tweeted and did not realise how small it is today 😢. The percentage is small.

I guess I can understand the idea that organisations prioritise browser support by browser market share. But shouldn't we want browser diversity and browser engine diversity? (This nuance is nicely explained in Brian Kardell's What is actually a web browser?).

Yes, some of the web's smartest and nicest minds work on Chrome and Chromium, I have see them do great work improving the web and prioritise (mostly) the right things over and over. Increasingly so now that the Edge people are also working on making Chromium better. I'm a fan of their work and most of the time Google push the web forward in ways it would simply not have without them. But, as Tim Kadlec mentions in a blog post, they don't always.

It's in everyone's interest to not give one company a near monopoly over what the web can do through their browser, or a handful of companies through their engine (Microsoft Edge, Samsung Internet, Brave and many others also use Chromium). Various people wrote about this when Edge announced they would use Chromium. “No single company, let alone a user-tracking advertising giant, should control the internet”, said Jeffrey Zeldman in Browser diversity starts with us. Competition is about growing, wrote Rachel Nabors, in a post where she compares the browser ecoystem with the world's ecosystem. Hurting engine diversity hurts the web, explains Andre Garzia.

Less browser engines doesn't necessarily mean that all decision making power lies with one company, though. In Beyond Browser Vendors, Brian Kardell mentions the origin story of CSS Grid as an example: originally conceived by CSS co-inventors Bert Bos and Håkon Wium Lie, further worked on years later by Bert Bos, then picked up by Microsoft and ultimately paid for by Bloomberg to be implemented in Webkit and Chromium by teams from Igalia, a company that works on all major browsers and JavaScript engines. This is also how potential futures of the web can be decided.

In any case… I'm curious how thinking may have shifted over the last years. How do you think about browser testing in 2022?

Originally posted as Test in many browsers on Hidde's blog.

[email protected]?subject=Reply%20to:%20Test in many browsers">Reply via email

More common accessibility issues that you can fix today

2022-05-16T00:00:00Z

Last month, I wrote about fixing common accessibility issues. That post seems to have resonated with people, so I have written up five more fixes you could do to your codebase today. Let's go!

I have tried to make these as hands-on as possible. For each, you'll find a description of what the issue problem, how fixing it helps end users and which team member can take the lead on it.

In my last post, the issues were what WebAIM described as the top 5 isuses in their WebAIM Million project. This time, I have looked into accessibility audit reports I wrote and combined that with what Deque wrote about coverage and the numbers that 200OK took from public data about common issues across the Dutch government websites (taken from the register of accessibility statements).

Missing focus states

If an element on a page is focusable, it needs a focus state. This goes for all interactive elements:

a (if the href attribute is present), audio (if the controls attribute is present), button, details, embed, iframe, img (if the usemap attribute is present), input (if the type attribute is not in the Hidden state), label, select, textarea, video (if the controls attribute is present)

(from: HTML, Interactive content)

It also goes for as well for divs or other elements that have click and keyboard events (but best use buttons in those cases while you're at it; see below).

For all of these, designers can come up with a focused state (ideally this is one thing, eg an outline, that is the same for all elements on the site, so that it's easy to spot when focus moves). Developers can remove any outline: nones from their stylesheets (if you must undo default outlines, because you're using some other CSS property for outlines, best use outline-color: transparent instead so that it doesn't break in High Contrast Mode).

Browsers can also ship with a feature that forces focus indication, some do. Users could also use user styles, though no website owner should expect they will, it requires CSS knowledge and a plugin in most browsers these days.

More: Indicating focus to improve accessibility

Missing captions and transcriptions

When you publish how-to videos, vlogs, podcasts, basically anything that has audio and/or video, the content should be available as text, too.

My friend Darice de Cuba has written about how to create podcasts transcripts. Part of this applies to video, too. Captions and transcripts are created for end users with disabilities. They also benefit users who are learning your language and users who want to catch your content but are in public without headphones. Transcripts and captions can even benefit your SEO strategy.

One of my own videos with captions turned on (It's the markup that matters on YouTube)

Writing out all recorded content isn't necessarily something you could do today as it can take a bit of time, especially if you have lots of content. I still felt I could include this common issue here, because most teams don't do this themselves and outsource the work to specialised agencies. These are costs you can budget for. If there is too much current content, you could consider starting with future or most popular content?

Project managers can make sure captioning and transcribing are part of any project that includes audio or video. Developers can ensure the CMS has fields for transcripts and captions. Designers can design the UI to allow for full transcript display. Social media managers can produce caption any videos for LinkedIn or Twitter.

Invalid HTML

There used to be a time when websites would proudly display a badge that showed the current page was composed of valid HTML. These badges have disappeared from most websites, but validation is still a sound accessibility strategy.

The HTML of web pages is parsed by lots of tools, like browsers and assistive technologies, if the HTML is invalid it can lead to unexpected bugs. Simon Pieters' Idiosyncrasies of the HTML parser is a great book about this, especially if you want a deep dive into what could possibly go wrong.

Since HTML5, error handling is specified as part of HTML, which should improve unexpected bugs due to invalid HTML, but there are still plenty of accessibility problems you can find by validating your HTML. Did you accidentally nest a <button> inside of a <a>? The validator will call it out and help you prevent the myriad of problems that could cause.

So… developers and test automation engineers can ensure HTML validation is included in tests.

More: validator.nu that allows inputting HTML by URL, file upload or pasting is (can run from command line per instructions in README)

Headings that don't describe their section

In HTML, headings (h1-h6 elements) exist in the context of a section, they are supposed to describe the content that follows them. When I say section, I don't mean specifically content in a <section> (or other “sectioning content”), I mean more generically content that forms a logical part of a page, regardless of which HTML element used.

Descriptive headings are useful, because some users access headings in a page as a table of contents. For example, your one page band website could have a “Discography”, “Tickets” and “Merchandise” headings. Your search application could have a filters section with a “Filters” heading. Some websites useheading tags (h1-h6) to mark up text that's “just” bigger or bolder, which will break the experience for people who navigate by headings, as it will add entries into their navigation that don't describe sections.

Content designers can ensure headings describe sections, and that things that don't describe sections aren't marked up as headings. developers can ensure that if there are headings in their front-end components, that they describe content and don't just exist for style reasons.

Can't do all things with just a keyboard

Accordions, tabs, ‘toggletip’ triggers… if your page or app has things that users can click on, they should also be usable with just a keyboard.

Fixing this issue is great for people who can only use a keyboard, and for users with numerous other devices that may or may not be keyboard like (there's some examples in How people with disabilities use the web).

Often, this issue occurs when clickable elements are divs with a click handler. Developers can make sure they use a button element whenever things can be clicked (or a if it navigates to somewhere). Yes, you need some CSS to change the styling to your liking, but this is do-able, it makes it easier for you to get all of the web platform's buttonness in one package and, most importantly, your users will thank you.

Wrapping up

So, that's five more common accessibility issue that you could fix in your codebase today. I hope this is helpful to some readers. Should you still have questions about any of these, please feel free to contact me on Twitter (@hdv) or via email.

Originally posted as More common accessibility issues that you can fix today on Hidde's blog.

[email protected]?subject=Reply%20to:%20More common accessibility issues that you can fix today">Reply via email

Accessibility from different perspectives

2022-05-22T00:00:00Z

I worked in web accessibility in different setups: as a freelance developer specialised in accessibility, as a WCAG auditor and as a full time team member of the W3C's Web Accessibility Initiative. As a developer I would receive audit reports, as an auditor I would write them and as a WAI team member I would work on promoting and documenting the standards these audits are based on. An observation: in the developer role, advocating for accessibility can be the hardest in various ways.

Perspectives

Writing audit reports, a company would request in-depth feedback with the intent to fix stuff (ideally; sometimes it's just because the law says they have to 🤷). At WAI, I engaged with accessibility standards and practices on more of a meta level. When developing tools or resources, I never had to explain why I wanted videos to be captioned or have a visible focus indicator on the stuff we published, because everyone else on the team had worked with WCAG for years, often decades, and many had lived experienced to draw from.

In the developer role, I had more responsibilities than ensuring accessibility, I also had to make sure our assets didn't break under an updated Content-Security-Policy, fix a deployment pipeline or figure out with which templating language my client could use their design system most widely. And then there was accessibility, my main interest and priority. I mean, why have a web app if it's inaccessible… I would often do that work under the radar, sometimes because other developers in the team weren't interested or skilled in that particular area, sometimes because I felt it would take more time to get extra time for a thing than to just do the thing.

Accessibility and support

Accessibility is hard to do bottom up, I found. In some cases, especially when working for government and non profits, accessibility would explicitly be in the requirements and or I would specifically be hired for that expertise. This was great and gave something to work with. In other situations, it was much more of a challenge. Time would go into making a business case (I learned about WAI's business case page late), trying to get budget for external audits or screenreader licenses (procuring JAWS is no fun) and figuring out how to go about recruiting users with disabilities for user tests. And that's still the meta stuff.

When it comes to writing code as an accessibility specialised developer, you can ensure you follow lots of users with disabilities and accessibility specialists to try and learn about implementation issues early. You can find lots of good resources. My favourite are blog posts by developers and accessibility specialists who have tested a solution with users and go at length to describe all the ifs and buts you need to understand the nuance and compromise. But let's be honest, if you want to rely on the official documentation (normative or not) that is also used by browsers and assistive technologies, it can be pretty difficult to find out exactly what to do.

Gaps in documentation

There are systematic problems in accessibility standards documentation:

outdated examples are often not marked as outdated and hardly ever removed
it is not always clear if examples are ready to use or merely displays of how stuff ‘should work’ if all browsers and assistive technologies followed the standards (a problem ARIA Authoring Practices Guide has)
it's hard to find user-tested examples
the guidance can be scattered across many places

From the standards org perspective this is all explainable. There is a lot of work on few plates, the consensus process and organisational structure have, besides benefits, an impact on how responsibilities can be and are distributed. It's understandable, but has an effect. It impacts how effectively developers (and designers, content editors etc) can build accessible products. Even if from the standards side of things, you can only do so much to try and have standards that are implemented interoperably by browsers and assistive technology makers. There are relatively few people in the space who specialise in this.

Channeling one's inner developer

From the auditor's perspective, as well as from the standards org perspective, accessibility looks different. The system is, sadly, ableist and almost every website you look at has accessibility conformance and usability issues… it has often frustrated me and made me more cynical than I want to be. You write down the same issues over and over, knowing they are just a few lines of code. I always had to channel my inner developer again, and remember what it can be like. Yes, removing the line outline: none is trivial, and it's extremely ableist to keep it in, but what can a developer do if the QA and/or design departments flag it as a bug and they're the only one on the team who ‘gets’ this need. Let's not blame the developer, let's blame the ableist system we all operate in. Or, as Adrian Roselli recently said, ‘arm developers’ with useful feedback so that they are more enpowered to make the changes (being an auditor often puts one in this somewhat rewarding position).

I don't know where I'm going with this, but thinking about what I'd like to see for the web if I had a magic wand, I would want to see better accessibility documentation (clear, up to date and user tested), more engineering budget for compatibility between standards, browsers and assistive technologies and have legal requirements that make it so that serious organisations see accessibility like they see security and data protection. At least some if not all of these wishes are in progress, of course, in various places… they have been for years, I just wish ✨ change ✨ could be sooner.

Developer experience and user experience

Some say ‘user experience is more important than developer experience’, and I'm all for that sentiment. Of course. Web accessibility is all about users with disabilities. That's the point of it. Developers ‘just’ need to do the job.

But companies who make products they want developers to use effectively, like browsers, have dedicated developer experience teams to try and ensure that developers can use their stuff well. To try and set them up for success. In their case, that makes good business. Might we, as the accessibility field, also benefit from better developer experience (of web accessibility) to get to more widely spread user experience?

What if standards orgs hired content designers, like governments with similarly complex content do so successfully? Isn't explaining standards essential when making standards? In the majority of cases, an inaccessible pattern can be addressed in code, by developers. Might some focus on developer experience be a sensible means to an end? If it was less frustrating to find out how to build, say, a combobox, in practice not in theory, we would more easily get to the end goal: less frustrating experiences to end users.

Besides a focus on quality of documentation, I feel like we should keep the individual developer's perspective in mind, acknowledging they may have constraints beyond their control. We could contribute to fight those constraints by providing executives and team leads with the right tools too. We've got to set teams up for success. That way we all win.

Originally posted as Accessibility from different perspectives on Hidde's blog.

[email protected]?subject=Reply%20to:%20Accessibility from different perspectives">Reply via email

ATAG: the standard for accessibility of content creation

2022-05-29T00:00:00Z

ATAG is a set of guidelines for the accessibility of authoring tools. In this post I'll talk about what it is and why it matters.

Most people working on websites will be familiar with WCAG, the Web Content Accessibility Guidelines. There are two more related standards, one for user agents (like browsers) and one for authoring tools (like CMSes, WYSIWYG or Markdown editors, e-learning platforms and website creators). They work together: if we care about the accessibility of web content, we should also care about how it is created (in authoring tools) and displayed (in user agents).

“Web content” in accessibility standards refers to websites, apps and other content on the web. I like to think of it as the HTML that browsers serve to the user when they access your website or app. There isn't a definition for “web content” in WCAG, but there is one for “web content technologies”. From that definition we can draw that web content includes anything that is rendered by user agents, like HTML and SVGs.

Why ATAG matters

Better accessibility of content tools is critical for three reasons:

Everyone should be able to create content for the web, regardless of disability.
Authoring tools are in between the user and the HTML they create.
The authoring tool can have the unique ability to prevent inaccessibility.

Let's look at these reasons in a little more detail.

Content creation is for everyone

‘The web is for everyone’, as web inventor Tim Berners-Lee likes to say, applies as much to accessing websites as it does to creating them. His first browser had both viewing and editing capabilities, so clearly the web was always meant to be about both consumption and creation. Many of us love to create vlogs, set up online classes, publish recipes, tweet, make TikToks, create art… this should just work for people with or without disabilities. If content creation tools have barriers, that's everyone's loss.

The first web browser, “WorldWideWeb”, was also an editor.

In business, it would be illogical (and illegal) if you couldn't hire content professionals with disabilities, just because they can't use your content tools. In your company today, Harry from marketing might be able to use a mouse, but when he leaves his successor might only use keyboards.

Support for all of HTML

The second part to authoring tool accessibility is their ability to output accessible content. Imagine two tools to create bulleted lists. One does this with divs and images of bullets, the other uses the standard ul and li elements. The latter is what we need, and not just when dealing with lists, but for all kinds of markup:

tables with captions
videos with track elements and muted and autoplay attributes
fieldsets with legends
images with alt attributes
translated content with lang attributes

Not all tools let you create all or these structures, at which point they basically become the accessibility issue.

Authoring tools as accessibility assistants

Even cooler than outputting sensible and appropriate markup, authoring tools could provide hints. They could try to be a helpful “accessibility assistant”, by point our potential barriers when they notice you're creating them. For instance, if an authoring tool lets you pick a foreground and background colour, it could warn you when you pick two colours that have insufficient contrast.

ATAG recommends various ways of assisting with making content more accessible: accessible default components and templates, solid documentation and, as described above, suggestions and hints.

Who meets ATAG

At the time I am writing this, I am not aware of any authoring tools that meet 100% of ATAG, as in, all criteria at level A or AA. That doesn't mean all is lost, every bit helps and there are a lot of authoring tools that meet many bits of the standard.

With the ATAG Report Tool, people can create a report with specific details about which parts of ATAG they do or do not meet.

As described above, there are lots of good reasons to try and meet ATAG. It is a worthwhile pursuit for authoring tool makers and a worthwhile request for procuring departments to put in tenders.

What's in ATAG

There are two parts to the ATAG standard:

editing experience (part A): does the tool work for people with disabilities?
output (part B): does the tool output accessible content?

If you're still with me, I'd like to describe ATAG in a bit more detail. Like WCAG, ATAG has Principles, Guidelines and Success Criteria. In the following sections, I will discuss the Principles and Guidelines in my own words. Full and official wording is in the ATAG 2.0, published by the W3C. This is not legal advice.

Authoring tool UI meets accessibility guidelines

Web-based functionality is accessible:
The full editing experience conforms to WCAG 2.0 or other accessibility guidelines. (A.1.1)
Non-web-based functionality is accessible:
The interface conforms to platform-specific accessibility guidelines. (This one specifically applies to authoring tools that are not web-based, which was more common when ATAG came out) (A.1.2)

Editing UI is perceivable

Alternative content available to editors:
If there is anything visible that is not text, like icons, images or video, there is alternative text available. (A.2.1)
What's indicated visually in the UI can be programmatically determined:
Status indicators (like changes or spelling errors) and text properties (like italics or bold) are conveyed to users of assistive technologies. (A.2.2)

Editing UI operable

Works with keyboard:
Everything that can be done with a mouse, can just as easily be done with a keyboard, including drag and drop and drawing capabilities. There should be no keyboard traps. Keyboard usage should be efficient and easier to use than just with sequential access (for example: use WAI-ARIA landmarks or offer keyboard shortcuts). (A.3.1)
Enough time:
Time limits in the editor, like for auto-save, can be turned off or extended (some exceptions apply). (A.3.2)
Flashing content optional:
Flashing content, like videos, including previews of that kind of content, can be paused or turned off. (A.3.3)
Content can be navigated by structure:
Users can navigate quicker by structure, for example headings, lists or HTML elements. (A.3.4)
Content searchable:
Users can search in text content, results are focused when shown. If there are no matches, this is indicated. User can search in two directions (backwards and forwards). (A.3.5)
Supports display preferences:
If there are user settings for display, this only affects the editing view, not the output. If a content editor uses OS settings like high contrast mode or their own stylesheet, this does not break the editing experience. (A.3.6)
Previews are accessible:
When the tool shows a preview of the content, that preview is at least as accessible as in current browsers and other user agents. (A.3.7)

Editing UI is understandable

Helps editor prevent and correct mistakes:
The tool lets users undo changes and settings. (A.4.1)
(Accessibility) features documented:
The tool has documentation for all features, including accessibility features. (A.4.2)

Fully automatic processes produce accessible content

Generates accessible markup:
When the tool generates markup, that markup is accessible. If accesssibility information is required, like alternative texts, the content editor is prompted to provide that information. (B.1.1)
Preserves accessibility information:
If content is pasted from a word processor or converted from one format into another, any accessibility information is preserved. (B.1.2)

Supports producing accessible content

Accessible content production is possible:
If some options produce more accessible content than others, they are displayed more prominently. If properties and attributes can be set, those relevant for accessibility can also be set. (B.2.1)
Editors guided:
Editors are guided to produce accessible content. (B.2.2)
Text alternatives can be managed:
There is a tool for providing text alternatives to “non-text content”, like images, videos and data visualisation. (B.2.3)
Accessible templates available:
There are accessible templates available. If there is a repository of templates, it is easy to find the ones that prioritise accessibility. (B.2.4)
Accessible components/plug-ins available:
If any components or plugins are built-in to the tool, they are accessible. If there is a gallery of components or plug-ins, it indicates accessible options. (B.2.5)

Helps with improving the accessibility of existing content

Checks accessibility automatically:
Has built-in checks for common accessibility problems, for example a check to identify missing alternative text. (B.3.1)
Helps content editors fix problems:
Provides suggestions to content editor about accessibility problems. (B.3.2)

Promotes and integrates accessibility features

Accessibility features prominent:
Accessibility features are on by default and a prominent part of the editing workflow. Documentation shows examples of how to create accessible content, for instance with example markup or screenshots. (B.4.1)
Documentation promotes accessibility:
The tool provides suggestions to content editors about accessibility problems. (B.4.2)

Wrapping up

In summary, ATAG recommends two things:

a fully accessible authoring tool interface (basically, one that meets WCAG)
the possibility to produce accessible “web content” and help with that in the form of documentation, default templates and suggestions

The instructions are more detailed in the standard, but that's what it comes down to in most cases.

Though the standard is only met at most partially by most tools today, a wider landscape of ATAG-supporting tools would be fantastic for web accessibility (because it's easier when you do it earlier). Increasingly, authoring tool makers start to realise this and that is wonderful.

Originally posted as ATAG: the standard for accessibility of content creation on Hidde's blog.

[email protected]?subject=Reply%20to:%20ATAG: the standard for accessibility of content creation">Reply via email

How I built a dark mode toggle

2022-06-20T00:00:00Z

This site has had dark and light modes for a while, but it never offered any choice. If your system preference was “dark”, that's what you would get (unless you used fancy browser flags). Yesterday, I implemented a dark mode toggle, so that you can override that at your leisure. In this post I will talk about some of the choices I made along the way. Basically, it's a long winded way of saying why it took me so long.

This is fun to fiddle around with, but really, it seems to me that all websites have this requirement, so why isn't this built into browsers? In other words, I agree with Bramus Van Damme, dark mode toggles should be a browser feature. His post has more reasons: however you support light and dark modes, you will likely end up with code duplication somewhere, and toggles that live in developer land require JavaScript.

The choices

HTML

There are a lot of HTML elements that you can use to give users a choice between one out of many options. Radio buttons and <select>s come to mind. A checbox could be an option too… if there is only one option, checkboxes too allow just the one option.

I started out with radio buttons as I thought that was clever, and even ended up building the control all the way from coding a form a fieldset, legend and options. I went ahead to visually hide the control itself and then use the :checked pseudo class to only display the option that wasn't picked. In other words, when dark mode was on, the light mode option was visible and vice versa.

It's a whole form!

It must have been late, because only when I started testing this with keyboard, a sanity check I do with all controls, I realised it didn't feel right. With a keyboard, you would need arrow keys to pick the other option and that feels weird, especially for a control that is styled to not look like radio buttons. I guess the lesson is: never style elements too far from their original purpose.

I ended up going for just the one button element. To switch styles, I would need JavaScript either way, so I would not benefit from having a checkbox in this case. In Underengineered Toggles Too, Adrian Roselli explains that the button makes sense if the control only works with JavaScript (check; we need to toggle a class or attribute to apply the CSS), if it only has true or false states, not mixed (check; we allow either light or dark) and if flipping the control immediately performs an action (check; the color scheme changes straightaway). The great thing about a button element, just for the record, is that it comes with keyboard support built-in. No extra cost.

It's a button!

One button, like mine, does mean that users can't explicitly choose that they want my site to follow their browser or OS setting. In his post Your dark mode toggle is broken, Kilian Valkhof makes the case for including a “system” setting that would solve this very problem.

CSS

With CSS, I made the button look like not a button. I visually hid the text inside of it. I also added an SVG icon that I applied pointer-events: none to, so that clicks on the SVG would be registered as clicks on the button.

JavaScript

In script, I wanted a couple of cases to be covered. Let's walk through the various parts of the implementation.

First, I stored the button and the query to find out if a dark color scheme is preffered, and created an empty variable for the current theme:

var button = document.querySelector('.theme-selector');
var prefersDark =  window.matchMedia('(prefers-color-scheme: dark)');
var currentTheme;

I also added a function to set a theme, which adds an attribute to the html element and stores the preference in localStorage:

function setTheme(currentTheme) {
  var pressed = currentTheme === 'dark' ? 'true' : 'false';
	
  document.documentElement.setAttribute('data-theme-preference', currentTheme);
  localStorage.setItem('theme-preference', currentTheme);
}

Then I figured out what the theme should be. First I checked if there is something in localStorage, if not if there is a preference for dark mode, and if not, I set it to default to light mode:

if (localStorage.getItem('theme-preference')) {
  currentTheme = localStorage.getItem('theme-preference');
} else if (prefersDark.matches) {
  currentTheme = 'dark';
} else {
  // default
  currentTheme = 'light';
}

We also want ways to change the theme. First off, when the user clicks the button:

button.addEventListener('click', function(event) {
  currentTheme =  document.documentElement.getAttribute('data-theme-preference') === "dark" ? "light" : "dark";
		setTheme(currentTheme);
  });

Secondly, when the user changes their theme preference:

prefersDark.addEventListener('change', function(event) {
  currentTheme = event.matches ? 'dark' : 'light';
  setTheme(currentTheme);
});

(This listens to changes in the browser's MediaQueryList, which could change when the setting is changed in the browser or the OS).

In Firefox, you can pick light or dark mode, if you don't want it to just follow the system or your choice of Firefox theme. There is no per website setting at the time of writing.

ARIA

In my book, it's ideal to only use ARIA when it is for something that:

doesn't exist in HTML
brings a known benefit to end users

In this case, we're using a standard button element, which exists in HTML. But there is one detail about it that doesn't exist in HTML, which is that this is the type of button that toggles. We can add this by setting the aria-pressed with a "true" or "false" value.

This brings a known benefit to end users, specifically to users of screenreaders, who will now hear this is a toggle button. For toggle buttons, it is important that the content doesn't change. As the button text, I have used “Toggle dark mode”.

If we would update the label of the button from “Turn on light” to “Turn on dark”, we kind of have a toggle (as MDN suggests), but that way, it wouldn't be recognised by the browser and set in the accessibility tree to be a toggle, and, because of that, not announced as a toggle by screenreaders.

Compromises

Code duplication

In his post, Bramus explains that when you want to build a dark mode toggle, you will end up with duplicated CSS. That is, if you both want to see color changes support the prefers-color-mode media query, and the class or attribute that you're toggling with your toggle. I went for not supporting that media query directly in CSS. Instead, I rely on my script to set the right data attribute. This means that without JavaScript, users will only see the light mode, even if their system or browser setting is to use dark mode.

Honouring the system preference

As mentioned above, my toggle doesn't have a “do whatever the system does” setting. However, when you change the system setting, it will notice and use that system setting. That is, until you change your preference again, either via the toggle or the system setting.

Many themes

The toggle I ended up with can only swap between two states. Initially I had wanted it to work for any number of states, I mean, why not have lots of different themes between light and dark? It's tricky, because how do those two settings, that the media query currently supports checks for, map to my many themes? This may be something for future iterations, probably with some way to map two specific themes to be the browser's “light” and ”dark”.

Summing up

To build a dark mode toggle is an exercise full of compromises. There are many ways that, proverbially, lead to Rome, as you can read above. I was happy enough with the current result to ship it for now, but am more than open to feedback.

Originally posted as How I built a dark mode toggle on Hidde's blog.

[email protected]?subject=Reply%20to:%20How I built a dark mode toggle">Reply via email

“That's not accessible!” and other statements about accessibility

2022-06-30T00:00:00Z

“We're 100% accessible”, some digital products claim. “That solution is inaccessible”, an accessibility specialist might say. These sorts of statements almost suggest that web accessiblity is a binary thing. Is it though?

In this post, I'll talk about why it's most helpful to see a website's accessibility as a continuum (or, you know, multiple continua). Even then, in some contexts, it makes sense to pretend it is binary.

If you find this interesting, but want actionable advice, see also Adrian Roselli's post Things to Do Before Asking “Is This Accessible?”

It is a spectrum

The accessibility of a website is a spectrum, in terms of different disabilities that exist, in terms of timing and in terms of objective claims.

The goal of web accessibility is that people with disabilities can use the web. In other words, it is about people and maximising the portion of people who can use our UI well. There are people who can't move their arms, who use their screen zoomed in, whose vision is blurry, who control their computer with their voice, and so forth. Accessibility is about people with a wide range of disabilities, that sometimes overlap, too. Our UI could be accessible to most or all of these people, or to some, or to none. Most products are accessible to at least some people with disabilities. Many have specific barriers for users from specific groups. Some do really well at continuously identifying barriers and removing them. Some don't.

Second, it is about timing: today all podcasts on our site may be transcribed, tomorrow we may upload an episode without a transcript. Or launch a new campaign that was done by this agency that didn't take all accessibility requirements into account. It happens. Accessibility can't be solved once and then shipped, it's a continuous process of tracking potential barriers and removing them. “That site is accessible” is a statement that changes over time on websites where content changes.

Third, accessibility conformance testing is subjective to some extent. This isn't a bug in accessibility standards, it's more like a most reasonable choice… If we tried hard, we could invent success criteria that can be evaluated with 100% certainty, but then we would need many of them, they might go out of date fast and they might end up a lot less technology agnostic. The subjectivity serves a purpose, but it's there, and again, a reason that a claim like “this is accessible” is hard to make.

So, basically, there is a degree of subjectivity in determining whether something is accessible, because it matters to which user(s), when it is checked and what is checked. For that reason, a statement like “this is accessible” or “this is not accessible” is best taken with a pinch of salt.

Why pretend it's not

A claim of “great accessibility” is subjective, a bit like “great user experience” and “great design”. Especially when you view “meeting WCAG” as a minimum and aim much higher by doing regular user testing and following best practices beyond WCAG (see my other post about using a superset of WCAG). But sometimes it makes sense to try and make formal and objective-like claims about the accessibility of a website or set of websites. To publish reports that say things like “60% of webshops in Germany are inaccessible” or “Only 10% of online banking is accessible”. Those are usually based on automated tests and/or accessibility conformance reports that refer to standards like WCAG.

One example of when it makes sense to pretend accessibility is objective, is the effectiveness of policy. National governments and organisations like the European Commission want to have a more accessible web, they have this as a policy goal. For that to be more than dreams or empty statements, they need to make it practical and tangible. Their method of measuring success is, roughly speaking, to gather accessibility statements and conformance reports. On the one hand, this reduces the experiences of people with disabilities to checking boxes in a standard, on the other hand, this provides insights at scale, while maintaining a reasonably good representation of individual experiences.

WCAG is used as a way to make statements about websites. Combined with a method like WCAG-EM, a detailed process for evaluating conformance published by the W3C, governments can get some level of certainty.

As an example, The Dutch government has a register of over 3500 accessibility conformance statements. They are each about a specific website, to which a rating between A (“fully meets WCAG”) and D (“does not meet WCAG”) is assigned. Rating E means “statement is missing”. Other efforts include AllAble's accessibility statements research, looking at accessibility statements from public sector bodies in the United Kingdom.

Of course, this approach is not perfect. Individual organisations might be using an auditing agency that is biased or not very good at evaluating WCAG. Some might self-evaluate (generally not a good idea). Or a website could have serious accessibility issues that happen to not be captured by WCAG (it happens). But even with some of those caveats in mind, even if the data is not 100% objective (is data ever?), collecting information from a large set of websites is the best a government can do. Regular formal WCAG/ATAG audits is a great thing for companies and organisations to do too, though ideally that strategy is supplemented by regular user tests and review of best practices.

Wrapping up

In summary: yes, measuring web accessibility is somewhat subjective and claims like “X is accessible” or “X is inaccessible” are tricky. If someone makes such statements, grab a pinch of salt! But, having said that, it can be helpful to talk about accessibility as “meets the criteria in this standard” and “does not meet the criteria in this standard”. Governments do this to measure the success of their policies and companies can do it to have some measurement of their own success. That's mostly useful, even though user tests and best practices based on them are even more meaningful.

Originally posted as “That's not accessible!” and other statements about accessibility on Hidde's blog.

[email protected]?subject=Reply%20to:%20“That's not accessible!” and other statements about accessibility">Reply via email

Two talks about documentation

2022-07-01T00:00:00Z

In two recent conference talks, I learned about making better documentation. First, I heard Adrienne Tacke focus on the documentation's content, explaining how to make it more usable and effective. Then I saw Rich Harris go into how to build a documentation environment, showing a way to approach documentation of projects with a server-side components.

Both talks resonated with me. Good documentation is the backbone of every software project (and also crucial elsewhere, including for web standards like WCAG). For software companies there are countless business reasons to invest in documentation, and for anyone else, yes, improving documentation is still rewarding in many ways.

Types of documentation

To clarify what we're talking about here, Daniele Procida's Diátaxis framework for technical documentation, which I found out about in Rich's talk, identifies four types of documentation:

tutorials, to teach people how to use the thing in the first place
how-to guides, to teach an experienced user how to do specific things with your tool
explanation, to give a high level overview of concepts in your tool
reference documentation, to provide matter-of-fact information about functions, APIs etc, to be consulted not read; can be automatically generated

Adrienne's and Rich's talks focused mostly on the first two: tutorials and how-tos.

Be concise and valuable

In her talk, Documentation: the missing pieces, Adrienne went into some very common problems in documentation. She showed how documentation can be unclear and unhelpful, and then went on to show how to be concise and valuable instead. The whole talk is a must watch, but here are some highlights:

be more explicit, by expanding acronyms (they can depend on context and not all acronyms are familiar to everyone) and by using the German naming convention (if you can be more explicit in a variable name, do it)
be aware of the steps in what you are teaching and avoid skipping steps at all times; this is another moment of stepping (no pun intended) into the shoes of the reader of your documentation, they don't know your project as well as you do, so you want to be explicit and list all gotchas
avoid surprises, always tell readers what they will need to make their way through the tutorial (prerequisities, dependencies, paid plans, time)
focus on the thing you want folks to learn and help abstract the unrelated setup and configuration stuff away, by creating a starter app, Docker container or sandboxed environment, anything that isn't core to the thing you're currently teaching, but still needs to exist in order for the reader to get started

Interactive tutorials with a server-side component

In his recent JS Nation talk (start at 40s to avoid the crypto advertisement edited into the video 🥲), Rich explained tutorials are essential, as they actually show users what to do, but they are often overlooked. He showed Learn Knockout, a very early example of a tutorial he loved, and which the Svelte Tutorial was later inspired by, and others, like Lit tutorial, that follow the same model.

For the documentation of Svelte and SvelteKit, the frameworks he created, Rich used four principles:

create a sandboxed environment, so that it is safe to make mistakes
help muscle memory by disabling copy/paste (controversial!)
provide a way to get straight to the solution if you're stuck (Rich calls this “panic button”)
meet users where they are (in Svelte/SvelteKit's case: the browser)

Sandboxes for “full stack” projects need both a client and a server component. Some services provide a way to access a virtual server from a sandbox (like CodeSandbox Containers), but they have authentication barriers, to avoid abuse (like bitcoin mining) and can come with some latency, Rich explained. Then he found that on Stackblitz, the server is, rather impressively, ran inside the browser by compiling Node to WebAssembly and running that inside the browser's security sandbox (this is called WebContainers). And that wasn't enough: as he found a StackBlitz environment is made for coding, not learning, Rich teamed up with the StackBlitz team to have some kind of headless version of StackBlitz in order to create what's now in beta as learn.svelte.dev.

Summing up

While these talks were about different aspects of documentation, the speakers were equally determined to ensure that users of their documentation would actually learn the thing easily. It's not easy, neither when creating the content, nor in technically setting up the environment, but it can clearly make a difference.

Originally posted as Two talks about documentation on Hidde's blog.

[email protected]?subject=Reply%20to:%20Two talks about documentation">Reply via email

Two levels of customising

2022-07-04T00:00:00Z

The proposed <selectlist> will have powerful styling options and full control over the different parts. In other words, there would be not one, but two levels of customisation. In this post, we'll look at what they are and when they are useful.

<selectlist>, you ask? It's a proposed new HTML element that is like <select>, but fully customisable. Why? Because so many people are building their own selects, from scratch or with libraries, and that should be easier to do. With accessible defaults where possible and by leaving the parts that browsers are good at to the browser (like knowing where to position it, to place it on the top layer or to automatically dismiss it when appropriate (‘light dismiss’)).

For context, <selectlist> is a proposal by the Open UI Community Group. This group was founded to study common components and controls that people build on the web (in design systems, see the component name matrix), and suggest Web Platform features to make it easier to build such controls. Think new HTML elements, CSS features or APIs, as well as things that surface across HTML, CSS and JS.

<selectlist> doesn't ‘exist’ just yet, it is an idea that is being prototyped in Chromium, with other browser engines currently not opposed, but also not implementing it (as far as I'm aware). While you would't use it in projects yet, you can experiment with it in Chrome or Edge Canary with Experimental Web Platform Features flag on, and file issues if something doesn't work as expected or desired. For brevity, this post will refer to it as if it exists, to avoid saying ‘would’ in every sentence.

The anatomy of a `<selectlist>`

The <selectlist> element, as currently prototyped, is a lot like the <select> element that we've had for years. We can use it in a form, users can select an option out of many and their choice becomes part of the data that we process.

But where a <select> comes with free built-in styles that we can't change, <selectlist> consists of some explicitly designed parts that can be changed (more on that a later). Often, the browser built-in styles of a <select> are just fine, sometimes they are not.

In Sanity's Portable Text editor, the user can choose text types. Each option is styled like something of that type is commonly styled, and there is some shadows, rounded corners and arrows that a regular <select> can't have.

The parts are:

select, the root element, wrapping/containing all the parts
button, the toggle/button the user activates to open the options
listbox, the part that is toggled, it wraps the options
optgroup, a part that we can optionally use to group related options together
option, an actual choice, a value that a user can pick
selected-value, the element that displays the currently selected value

(from: Anatomy of the selectmenu)

When using regular <select>s, it is possible to make the button part look however we want. In some browsers, we can also apply some specific styles to options, like background colours.

With <selectlist>, these parts are not just parts in the colloquial sense, they are <part>s in the Web Component sense, meaning that they exist as elements in the shadow tree of the component. Consequently, all of these parts can be changed.

There are two levels to that: the first is to write CSS, where we can use all the power CSS has to offer, the second is to completely replace the DOM structure to what we want or need.

Option 1: CSS

In the <selectlist> prototype, the options are part of the (light) DOM like they are in a <select> element, which means we can target them with CSS (and unlike with <select>, our styles will actually get applied).

elements in HTML, and styles applies by targeting with option--h1, option--h2 as the selector, plus a preview. " /> You could even give each option its own style! See Codepen (view in Canary with Experimental Web Platform Features flag on)

This is the most basic example of styling a selectmenu: you apply CSS to the options, like you would to any other HTML element.

The other parts of the selectmenu are targeted differently: we'll use a ::part() selector referencing the respective part name.

Deprecation warning: this is currently under discussion; the final implementation will likely use elements and not ::part() to select parts of a selectlist

For example, to style the button:

selectmenu::part(button) {
  // add any button styles
}

(Codepen of example with styled options)

To style other parts, you use that part's name instead, for instance ::part(listbox). Just last week, a resolution was passed to also expose the arrow as a part, to allow for easy styling or icon-replacing (part name to be decided).

In case you, like me, had not used the ::part selector, it is part (no pun intended) of the CSS Shadow Parts module.

For background: Web Components can have a light and a shadow DOM. The light DOM is part of the DOM like anything else and can be styled, but the shadow DOM is internal to the element. This a bit like public and private functions. For styling purposes, the CSS Shadow Parts module states that the creator of a Web Component can choose to expose parts of their shadow DOM by names. Developers provide a list of parts (element names) to be exposed, and then the elements can be targeted through ::part(partname). With <selectlist>, we get a browser built in Web Component that has parts exposed (except for option, which is in the light DOM).

This is huge… I mean, being able to throw CSS at the different parts of a selectmenu unlocks a lot of possibilities. Many of us will likely just use it to round some corners, add some shadows, maybe a little color or typography. And that's fine, we never could unless we built or loaded a library for custom selects.

I'm excited about being able to add a few finishing touches to selects, alone. But CSS has numerous powerful features, so that's only the surface. With all of CSS at our fingertips, custom selectmenu styles are probably going to be used in more interesting ways than we can think of now.

Option 2: full control by replacing parts

If we need more than ‘just’ styles, it is also possible to replace entire parts with whatever we like. For instance, we could write our own button entirely, and tell the browser to use that instead.

Replacing a part is done with slots. Let's say we created a button with markup of our choice:

<button>select option</button>

We can then tell the browser that, actually, we want this to be what the button part is, adding slot="button" and behavior="button":

Deprecation warning: this will probably not work this way in the final implementation

<button 
  slot="button" 
  behavior="button"
>select option</button>

(Codepen of example with replaced button part)

Now, the button will be what's used for the part called ‘button’ (as it is slotted into the right place with slot) and get the browser's select button behavior and accessibility accomodations (set through behavior). We could do the same for the other parts.

We could also do this in JavaScript, with Element.attachShadow(), so that the markup we want to use can live in our JS, and we only need one HTML element at the point of usage rather than one plus a few more for slotting.

But wait… if we're replacing all the parts with our own things, isn't this just like rolling our own selects entirely? Well, yes, it is the advanced option, and usually CSS should suffice. But even if we replace some or many parts, the selectmenu would still get a bunch of things from the browser for free, like positioning, being on the top layer and light dismiss, features that would be hard to impossible to code in JavaScript.

Accessibility risk: avoid unexpected nests

There is an important accessibility risk to be aware of for folks planning to replace parts in their selectmenus. Browsers and assistive technologies have certain expectations about what HTML is and does. If we divert from those expectations, we risk causing real problems for end users, which could include controls becoming unusable.

One example is what would happen if we would nest an interactive element like a link or button inside an option. Maybe one of our options has a tooltip? All of this should be avoided, at least for the time being (as far as I understand, this may change when secondary actions become a thing, see also w3c/aria#1440). The reason is: assistive technologies expect just text inside of options, not controls, so this would break badly and it could mean users wouldn't find those buttons or links, or wouldn't be able to interact with them. For this reason, it is strongly recommended to avoid interactive elements inside of options, i.e. do not add links or buttons in options.

Summing up

In this post, we looked at two ways to customise the parts of a selectmenu element. We can use CSS, which should cover a large amount of use cases and offer flexibility and room for creativity. Or we can replace entire parts with whatever we would like, the more advanced option that has accessibility risks if not thoroughly checked against specs and implementations. For a lot of the use cases that I see in design systems I have worked on, I feel CSS alone will cover all the needs. And it will do so very elegantly, often in literally a few lines of code.

Again, this is all in the future, the element is just being tested out. But, it may well be that this same pattern of having both CSS and parts-replacement for control customisation will come to other Open UI work, too. Generally, I am a fan of this layered approach. As a developer, I like the principle of being able to make things as simple or complex as I want.

If you want to see more demos, the Microsoft Edge team has built a series of cool <selectlist> demos, when these were published it was still called <selectmenu> (as they note, pushing the limits and some with accessibility issues). You can see and play with these, using Edge or Chrome Canary with Experimental Web Platform Features turned on. These demos include a lot of part replacements, too. If you have feedback, want to follow this work more closely or chime in, head to Open UI issues on GitHub or join us on the Open UI Discord community.

Originally posted as Two levels of customising on Hidde's blog.

[email protected]?subject=Reply%20to:%20Two levels of customising ">Reply via email

With :focus-visible, you can have focus styles when it makes sense

2022-07-21T00:00:00Z

Focus outlines are a great way to improve accessibility. They are traditionally set with the :focus pseudo class. That still works, but with :focus-visible we have a new way to only show focus styles when they make sense. How does that work?

The :focus-visible pseudo class has been in the works for over seven years and we recently got to a situation where it is now in stable versions of all modern browsers: Chrome/Edge (from 86), Safari (from 15.4) and Firefox (from 85).

What is `focus-visible` anyway?

The thing is, :focus-visible isn't a “indicate focus only to keyboard users” pseudo class, it is “indicate focus when the browser thinks it's right, based on some heuristics”.

“When it is right”, what does that even mean? Well, it has to do with when browsers decide to show their default outline. For example, most browsers show an outline when you press a button with a keyboard, but they don't when you click a button with a mouse. In other words, focus styles in browsers only show sometimes, in specific cases. The :focus-visible pseudo class is meant to match those cases.

This makes :focus-visible very different from :focus, which matches whatever the currently focused element is, regardless of whether it makes sense to highlight it or not. That's why you might see the styles you applied through :focus even if you click on something with a mouse, a behavior that could leave users confused and causes some developers to turn off highlights completely (but friends don't let friends do this, you would not do cursor: none either).

From CSS Selectors, Level 4, 9.4:

[:focus-visible allows] authors to change the appearance of the focus indicator without changing when a focus indicator appears.

So it lets you target the cases where browsers would normally apply focus styles, and, importantly, it excludes the cases where browsers don't paint their default outline, for instance when the user clicks on a thing with a mouse.

Consequently, browsers apply :focus-visible styles to more non-mouse cases than just keyboard users. Which cases are they?
There are lots of devices that are keyboard-like, as Eric Bailey explains in Focusing on focus styles:

Wands, sticks, switches, sip and puff devices, voice recognition, and eye tracking technology can all create input in a digital system. These devices will identify a content area and activate it. This is similar to how you can hit the tab key on a keyboard and the next cell in a spreadsheet will be highlighted, indicating that it has been moved to and is ready to be edited.

Some of these technologies present themselves as keyboards (like braille displays), they could fall under the focus-visible umbrella, others (like voice control) are more mouse-like and may not trigger these heuristics. Some assistive technologies also come with their own highlighting, like VoiceOver on iOS and the macOS Switch Control UI.

Pointers vs non-pointers

An example (non-normative) in the specification for :focus-visible suggests that :focus-visible should apply to interactions “via keyboard or some other non-pointing device”. This made me wonder what the exact difference is between a pointing device and a non-pointing device. The Pointer Events specification has some answers (thanks Bramus!).

Basically, there are input methods that can do mouse clicks and input methods that aren't really a mouse but can simulate mouse clicks, like touchscreens and pen input. Pointer Events tries to abstract all of those input methods into a new concept called “pointer”.

The definition of a pointer in that specification:

A hardware agnostic representation of input devices that can target a specific coordinate (or set of coordinates) on a screen, such as a mouse, pen, or touch contact.

I haven't found a definition for non-pointer devices, like keyboards, but my best bet at a description would be: non-pointing devices are devices that let you step between the different interactive parts of a user interface. Others also call it “sequential navigation”.

Examples of non-pointer or sequential navigation:

TAB/shift + TAB or arrow keys when you use a keyboard
gestures when using VoiceOver on iOS, you flick between the different elements
item mode in switch control (see Milan Patel's switch control demo, item mode demo at 3:59, note switch control has a pointer mode too, which Milan mentions he finds easier)

For the sake of completeless, there is also the concept of “spatial navigation”. This is similar to sequential navigation, but you don't just go back and forward—you can go up and down too, like when you select something to watch on a streaming service on your TV.

Input methods differ and overlap

Even with this distinction between pointing devices and non-pointing devices, none of this is very binary. There are users who always use a keyboard or users who never do, but most people will be somewhere in between. They could be switching between a mouse and a keyboard in one browser session, or use devices that allow for multiple input methods. Someone could connect a bluetooth keyboard to until-then touch-only tablet. Switch Control in iOS has both a point mode and an item mode.

And even if you could detect every type of device, people are not the same. You likely have users who use a mouse, but still benefit from seeing what currently has focus: users with low vision and users with cognitive disabilities.

In a comment discussing focus-visible, Jonathan Avila shares how he switches between modalities:

I often switch between input modalities such as by clicking and dragging off a button to set focus somewhere then use the keyboard to navigate from there. I may click on a radio button and then use arrows to select other radio buttons. I will switch between touch, mouse, keyboard, and many other settings such as large text, screen reader, or zoom depending on the situation.

The cool thing about :focus-visible is that it allows browsers to be smart about when to show focus styles. Browsers won't just hop into visible focus mode when you press any key, it takes things like using command/control + key combos into account, as Alice Boxhall explains in a recent Igalia Chats episode. The heuristics develop over time, too.

Ok, so what now?

This post turned out a little longer than I intended, but what I've tried to capture is what I started with: that and why :focus-visible is more than a way to show focus styles just to keyboard users.

If you want to hear more about :focus-visible from people who worked on this, the aforementioned recent Igalia Chats episode with Brian Kardell, Alice Boxhall and Rob Dodson covers some of the history and evolution.

Originally posted as With :focus-visible, you can have focus styles when it makes sense on Hidde's blog.

[email protected]?subject=Reply%20to:%20With :focus-visible, you can have focus styles when it makes sense">Reply via email

Individual climate action: small steps matter

2022-07-28T00:00:00Z

We need bigger steps to combat the climate emergency, but small steps matter too. This week Dave shared he feels climate action falls on consumers too much, rather than large companies and governments. Michelle responded that as tech workers, “we have the power to push for for change”, that we can “extend reach of our actions far beyond ourselves”. Matthias added that we all do something, “even if it feels like we are the only person doing it, it will make a difference.” Great posts.

Like Michelle and Matthias, I feel we can make a difference. I agree that we can use our privilege as tech workers, and that we can do individual things, even if small. I also agree with Dave—companies and governments need to facilitate these individual actions much better. Companies could provide more sustainable defaults, governments could have more tax incentives for sustainability. I say “more”, as both of these things continue to happen and the pace increases. Eating plant-based has been challenging for years, today it is trivial, even at fast-food chains known for their meat. The European Commission has negotiating climate action too slowly for decades, but recently launched a Green New Deal, spending trillions of euros on concrete targets (see also Delivering the European Green Deal).

Like most people, I'm a hypocrite when it comes to climate action. I haven't eaten meat for decades, but hey, I eat eggs and dairy sometimes, which can be as bad in terms of climate impact. I use trains for transport mostly, but hey, I still fly for work and family visits sometimes, multiple times a year. I try and buy stuff secondhand, but hey, my current shiny phone was bought new. I buy most produce directly from local farmers through Rechtstreex, but hey, I occassionally enjoy avocados and bananas that are flown in from very far away. I don't use plastic bags, but I gave my children diapers made of plastic.

What about governments? The Dutch government recently announced to invest billions in expanding the power network so that more solar panels can be connected, but they also still subsidise gas and oil. They have started charging companies for their CO2 emissions, but currently still charge lower VAT on meat than on plant-based alternatives.

Or companies? Shell will build Europe's biggest hydrogen plant, which is nice, but I don't even want to get started on how they've undermined climate agreements for decades and continue with fossil fuels on an enormous scale (Follow This buys Shell shares to then use shareholder privileges to demand greener policy).

Still, like Matthias said, we need to look at the good things that are happening, and encourage more good things. From governments, from companies and from ourselves. Small steps matter. In a country with millions of voters, one vote seems like nothing. But each vote ends up as a part of the election results. If we all stay home, nothing happens.

It may seem rational to find hypocrisy in my actions, or the government's actions, or those of companies. You'll probably find stuff quickly. But even if I'm inclined to, I don't want to be a cynic about climate action. I'd rather err or the side of being overly naive. Sometimes change is slow and complex, I want to keep the focus on making it work, not on looking for hypocrisy. So I'll continue to do my things. I'll also continue to expect companies and governments to act. In fact, they need to do more and do it faster, and this will impact what I buy and vote. It adds up if all of us buy and vote the right things, especially in countries where small parties can have impact.

Originally posted as Individual climate action: small steps matter on Hidde's blog.

[email protected]?subject=Reply%20to:%20Individual climate action: small steps matter">Reply via email

Keyboard shortcuts need modifier keys

2022-08-05T00:00:00Z

One way to make a UI on the web keyboard accessible is to ensure parity between input methods: that things that can be clicked, can also be activated with just a keyboard. In addition, you can also introduce keyboard shortcuts for common actions. If you do, ensure they require a modifier key, like ⌃ Ctrl or ⌘ Cmd.

Understanding 2.1.4

In WCAG, the standard used to check if websites are accessible, there is a specific Success Criterion for keyboard shortcuts, which got added in version 2.1. From the criterion text:

If a keyboard shortcut is implemented in content using only letter (including upper- and lower-case letters), punctuation, number, or symbol characters, then at least one of the following is true: (…)

In other words: do not use keyboard shortcuts that are just a one letter character (or multiple of those). After the quoted part, exceptions are listed where such a keyboard shortcut would be ok, we'll get to those later.

Let's first try and get a little more explicit. Basically, you could do shortcuts that are a single key, like, ‘press N to open a new document’. Or your shortcuts could be in the form of ⌘ Cmd + something or ⌃ Ctrl + something, requiring a modifier key. This Success Criterion basically says ‘don't do the single key thing, always have a modifier‘ (again, with exceptions, see below).

This criterion removes frustration for speech input users, who control their screen with their voice. Their software listens for words or sentences, but also for shortcuts. The issue is that shortcuts that don't use modifier keys could get activated up when the user didn't mean to.

An example from the Understanding document:

For example, Kim's email software uses common keyboard shortcuts to navigate ("k"), archive ("y") and mute messages ("m"). Her coworker enters her office and says "Hey Kim" and her microphone picks that up. The Y of "hey" archives the current message. K in "Kim" moves down one conversation and M mutes a message or thread.

(From: Understanding 2.1.4, Intent; adapted to be shorter)

The criterion also improves the experience for people who are prone to accidentally hit keys, like users with fine motor skill related impairments.

So basically, the issue with these “unmodified” shortcuts, is that it is harder for software to establish if the user actually wanted to trigger the shortcut. The use of modifier keys is an established pattern that captures this user intent, you would not press those and another key accidentally.

What about `/`?

When I was testing a website recently, I found that / was used as a keyboard shortcut. I wasn't a 100% sure if this was a WCAG failure per se. The Success Criterion text says keyboard shortcuts should not consist of just letter, punctuation, number of symbol characters. Is / any of those four things? Letters and numbers I know, but what exactly does the full set of punctuation and symbol characters look like? Why doesn't WCAG include a list?

Well, there are two answers to that:

it's complicated; there are lots of languages and writing systems and it would be easy to forget a punctuation or symbol character… or even a letter of number, CJK languages have tens of thousands of characters
what is really meant here is any character that prints something on the screen

That last answer is what Marjon from the accessibility consultancy Firm Ground replied when I asked about my confusion on Twitter. She linked to the WCAG Technique document (yup, not normative), where “all number, letter, sign and punctuation keys” are summarised as “printing characters”. That checks out. I'll take this interpretation: / is a printing character and should not be used as a shortcut on its own.

Exceptions

I promised to get back to the exceptions that are in the Success Criterion text. It says you can use single characters without modifier keys as shortcuts:

if it the shortcut can be turned off in settings
if the UI lets users remap the shortcut… so it's / by default, but users can go to the settings of your app and remap it to be ⌃ Ctrl + /
if the shortcut works only when the relevant component has focus, for instance when you're in a countries select menu and press the T to jump straight to Taiwan (that way, it doesn't interfere)

The remapping option can get tricky if your interface has a lot of shortcuts. The popular email web app that allegedly was used as inspiration for this Success Criterion has a very large number of unmodified shortcuts, so many that it runs into the case where there aren't enough characters to remap them all.

Summing up

Keyboard shortcuts are most accessible when they include modifier keys like ⌃ Ctrl or ⌘ Cmd, so that they don't frustrate voice input users and users with fine motor impairments. If your interface has shortcuts that are just one or more “printing characters”, any character that prints something on the screen, best combine them with modifiers.

Originally posted as Keyboard shortcuts need modifier keys on Hidde's blog.

[email protected]?subject=Reply%20to:%20Keyboard shortcuts need modifier keys">Reply via email

How I use Twitter

2022-08-19T00:00:00Z

I like Twitter. When I joined just over 15 years ago (!) I genuinely did not expect the hype to last more than a year. But what did I know? It still does a good job of letting me follow very short content from a list of people I pick. I like Twitter as a remote worker. As someone with many interests. I love being able to interact directly with people whose work I look up to, people who say interesting things or post excellent dad jokes. People with specific areas of interest that I want to stay informed about. People whose books, music, journalism or conference talks I enjoyed.

Twitter is great for all those things, but it also has downsides. I'm sure those who read this are aware… it's a walled garden, the company has been too slow banning certain violence inciting politicans, there is lots of harrassment, there are still massive spam and bot issues, the obsession over metrics like follow counts, the verification system that seems biased (like, why is Jen Simmons not verified?), the self proclaimed experts, its anxiety inducing effects and so on. I have tried switching to alternatives that work on solutions for some of those things, but always returned for various reasons. I guess I do like it on Twitter.

Tweaking Twitter

Though I net enjoy my time on Twitter, I would have left years ago if I couldn't make these modifications:

'Current topics' hidden, when I use the web version (using Better Twitter). Where I live, this section is a gateway to mostly fascist voices, terrible takes and disinformation . It seems bad actors simply take over any popular hashtags, so this may be hard to fix, but for me it means I don't want to see it.
Ads blocked: because they aren't I'll admit I don't believe there is such thing as relevant ads. Even people who do will likely agree that mismatches happen, in my case crypto ads served to me, a forever crypto sceptic. Please let me pay for the service. On desktop I use an ad blocker, on mobile a paid app that has no ads.
Tweets auto-deleted: maybe I would like an archive of my thoughts, but not one that is public, on a centralised platform. It seems like too much risk to keep them around. I use Semipheral to do this somewhat selectively.
People auto-muted: there isn't sufficient time in life to interact with trolls, bullies and cryptobots, tools like Blockparty are instrumental to automating some of the muting and blocking that makes Twitter more liveable.
Time limited: I'm not always great at this one, but I try to avoid looking at Twitter most of the day, this platform is best enjoyed for a limited amount of time per day. I've sometimes done multi-week breaks too.

Tweaking my tweets

I also try to be better at tweeting.

As a rule, I try not to complain about products or services. If a train company didn't treat me well, that's not my followers' problem. In general, I try to limit complaining. I don't find it very easy, as I love complaining, but I am convinced it doesn't contribute that much.

I also try to ensure my timeline is accessible. That means I add alternative text with every image and don't retweet images without alternative text. I also avoid ASCII art memes and bold or italic unicode characters (like the ones Twitalics converts to, a tool that actually comes with an accessibility warning). Lastly, I capitalise usernames and hashtags so that screenreaders are more likely to pronounce them in a way that makes sense, for instance #CSSDay instead of #cssday. This doesn't always make a difference, but sometimes can,
like in this example where the capitals cause a pause between CSS and Day where I tested.

Another thing I recently tried to do more of is whenever I feel I have something to say, I plan for writing it on this blog and just linking out to it from Twitter. That way I can mitigate the walled garden issue a bit, by putting my content in my a garden that I control.

I'm sure there are lots of ways to use Twitter that I haven't made a habit (like, I hear some use lists extensively). How do you use Twitter?

Originally posted as How I use Twitter on Hidde's blog.

[email protected]?subject=Reply%20to:%20How I use Twitter">Reply via email

Re: AI for content creation

2022-08-30T00:00:00Z

Morten described a possible feature, maybe even reality, in which AI-generated content is rampant. But when we start to employ machine learning for content creation, we start to regard content as a means more than an end. In that process, won't we lose what's worth caring about?

In his post, Morten explains he sees three types of AI-generated content emerge. The first two, AI-curated content (it helps assemble content and provide you with what it thinks is the most relevant), and AI-assisted content creation (it contributes to content creation) are a thing now. The third, AI-synthesised content, will likely become a thing in the future. Morten's post gives a great overview of what to expect.

It reminded me of a project I did in university about automating the arts. My conclusion: we can write code to generate creative works, but code or models can't capture intentions, experiences or beliefs. This requires human input, therefore creating art (or content) requires human input, was my reasoning. There are nuanced differences between AI, machine learning, big data and bots, but in this post I won't go into them.

When I want to find a recipe for pizza dough on the web, I would consider myself lucky if I could get ahold of a blog post from someone who cares passionately about the right kind of dough, who maybe ran an artisan pizza kitchen in Naples for the past 30 years or has a background in baking. ‘Dream on’, you think. Well, these people exist on the web and the web is awesome for being an open platform that anyone with a passion can write on. I don't want to find text produced just because someone saw “pizza dough” is a common search phrase and a potential for top result ad money to be extracted. The passion that drives them isn't the pizza dough—that's fine, but it makes their content less relevant to me. Similarly, I also don't want to find text generated by a machine learning model. It can't possibly bring the knowledge and experience I'm hoping for.

When I write an email or reply, I try to put what I want to convey into words that I choose. I might choose to include an inside joke that me and the recipient share, fit in an appropriate cultural reference, be extremely polite, or terribly rude. I mean, my intentions and attitude are in that interaction. I don't want Google or LinkedIn or others to suggest what to reply, to reinforce reminiscences of the historical content they trained their machine learning models with. It dehumanises my conversation. Its suggestion may or may not align with my intentions.

When I listen to music, I can be touched by the experiences and world views that inspired the artist. Whether you're into the Eagles, Eels or Ella Fitzgerald, their songs capture things that machine learning systems can't because the artists have attitudes. Robots don't love and they don't have opinions. Maybe they can come up with interesting rhythms and melodies, or utter sentences like “I love you”, but the association of their work with intentions and memories needs humans.

When I read a newspaper, the order of pages, the focus a layout provides and the choice of photography… they are decided by human beings who have a lot of experience. People who work as a journalist after being a professional sports player for decades. People who followed politics for decades and therefore understand which scandal is worth extra attention. People who can make bold choices based on their world views. Bots don't have world views. Algorithmic prioritisation of content isn't as good as prioritisation by humans, even if it gets close. See also algorithmic timelines on social media versus human-curated lists and contextualisation.

When I have a consumer issue, I want to talk to a human representative of the company. Someone who has the authority to make decisions. Who can take us on the shortest path to a mutually satisfactory solution. Did you ever see a chat bot provide more than a repeat of the data it has been fed? Did you see a chat bot make enquiries with empathy? Lack of empathy isn't a bug in bots that we just haven't fixed yet, it arguably isn't empathy if it isn't human-to-human (ok maybe animals can be part of this equation).

All these examples lead me to think: the human side of data isn't measurable or computable. The human side of art, content or communication is not just a different side of the same coin, it's a bigger coin. There is more to reality than data can capture, like lived experiences from actual people and intentions and beliefs. Propositional attitudes that robots can only pretend to have.

Basically, I'm worried about overestimating how many human capacities machine learning can take over. At the same time, I don't think machine learning is useless. Quite the opposite, it is fantastic. I love it that computers are getting better at automated captions, translation or even generating images based on prompts. The latter may create a whole new level of art where artists use it as a material for their creations (see also AI is your new design material by Josh Clarke). Medical applications where machine learning notices abnormalities that a human might miss. Audio recognition engines that will tell you what song is playing. Email spam filters that save us all a lot of time. It's all super valuable and genuinely impressive. And a lot of these use cases don't need lived experiences, intentions or beliefs to be incredibly useful.

Originally posted as Re: AI for content creation on Hidde's blog.

[email protected]?subject=Reply%20to:%20Re: AI for content creation">Reply via email

What's new in WCAG 2.2?

2022-09-06T00:00:00Z

WCAG 2.2 is the next version of the Web Content Accessibility Guidelines, published 5 October 2023. It includes all of WCAG 2.1, minus 4.1.1 Parsing, plus nine new criteria. Of those, six are in Level A + AA, the most commonly tested combination of levels.

Let's look at how you could meet the new Level A + AA criteria (note: this is just my summary and interpretation, for the official specification and wording, refer to WCAG 2.2):

Focus Not Obscured (Minimum) (2.4.11, AA): don't obscure the element that has focus (eg with sticky headers/footers or modals)
Dragging Movements (2.5.7, AA): when some action in your UI requires dragging, ensure the same action can also be performed without dragging (with a “single pointer”). Example: a map that can be dragged to move around, but also offers buttons to move up, down, left and right.
Target Size (Minimum) (2.5.8, AA): ensure that things you can click (or otherwise “point”, eg using pen, touch etc), are more than the specified minimum size, unless there's enough distance, it's inline or the small size is “essential”
Consistent Help (3.2.6, A): if your page/app contains help options, they are in the same order across pages (unless user zooms/turns device; these kinds of user-initiated changes are excepted)
Redundant Entry (3.3.7, A): avoid that users have to enter the same information twice, instead auto-populate or allow previous input to be selected. Some exceptions apply.
Accessible Authentication (Minimum) (3.3.8, AA): if your auth requires a “cognitive function test” (user has to remember, manipulate or transcribe), offer a way without such a test, or allow for assistance (eg support password managers, don't block copy/paste)

One SC was removed: Parsing (4.1.1). It existed because assistive technologies had to parse HTML, but they no longer do so directly.

Notably, the new SC Focus Appearance (2.4.13), that was initially put in Level AA, is going to be Level AAA. It has requirements for what focus styles look like, regarding contrast, size of the contrasting area and contrast of adjacent colors (this one may be the most tricky and “at risk”, but there's a lot of examples in Understanding Focus Appearance)

An overview of the new criteria, including examples of how they are useful to real people can be found on What's new in WCAG 2.2.

Originally posted as What's new in WCAG 2.2? on Hidde's blog.

[email protected]?subject=Reply%20to:%20What's new in WCAG 2.2?">Reply via email

The last dConstruct

2022-09-10T00:00:00Z

The last dConstruct is a wrap! Jeremy did a great job curating a day that was (loosely) themed around “design transformation”. Here's my writeup of the day.

How does content survive 100 years?

When designing Flickr, George Oates tried to design a “context for interaction, not just an application”. It worked. Flickr allowed people to post content and connect it through tags, comments and more. Today, the site has 50 billion pictures posted by millions of people, making it, in Jason Scott's words, “a world heritage site”. Archivists may have kilometres of underground storage where they keep historical records, a site like Flickr is unique, as so many people contributed to it. For future generations, the sheer amount of visual data could give away a lot about life today. But Flickr isn't a given. Changing owners a few times, the site was almost killed and all content deleted. Now, at Flickr Foundation, George thinks about keeping this content for the future. And by future, she means the next 100 years. Long term preservation most likely needs selection, George clarified, maybe by letting users mark specific photos of theirs as keepworthy. Maybe it needs printing after all, as we are not sure if JPGs or PDFs are still readable in a 100 years. And how do we preserve a picture that is part of a network, if we can only preserve part of that network? How does this wealth of content survive economic forces and corporate whimsey?

George's team mapping out 100 years

These questions made me worry about the content I create online: blog posts, tweets, videos… it's on my personal website that I'm most sure there won't be corporate whimsey, but it's also unlikely to survive when I'm not around to pay the hosting bills. Should I update my testament?

The fun part of writing is the research

Lauren Beukes is a best-selling author. She travels a lot and said she actually enjoys the all this research more than the actual writing. On these trips, Lauren talks to a lot of people, from detectives in Detroit to teenage theatre geeks. She learns from their perspectives, takes in their sometimes horrifying stories and learns how they are treated by the system. Part of what a novelist does, she explained, is asking “what if?”.

Transformation through type

Type designer and calligrapher Seb Lester showed how a typeface he started designing on a train, came out 8 months later and started getting used. It was on washing powder, sky scrapers and olympic games branding. “When a typeface goes out in the world”, Seb explained, “a little bit of you goes out in the world”. The font was everywhere, but hardly anyone had heard of him (he said). Until he started publishing letter forms and calligraphy on social media. Seb's calligraphy videos and a cheeky comment in an interview in Salon got him jobs designing visuals for rocket scientists and Apple. His videos of lettering in progress are extremely soothing to watch, transforming from what seems like a few scribbles into beautiful works of art. Seb's stories were a reminder that success is very much a combination of two things: you want to “work hard”, “find your passion” and “believe in yourself” on the one hand, and be lucky and get noticed by the right people at the right time on the other. That last part is out of your hands, so you can only really try to do the first.

TFW NASA takes note

Design to make the world better

Daniel Burka has been a designer for a long time. He worked on the Firefox brand for Mozilla, which was interesting because of open source and their mission. He worked on Digg, which was interesting because of their scale. He worked on a game called Glitch, which was interesting because the creators of Flickr were involved, and Glitch became Slack). And then he worked at Google Ventures, where he met a number of companies working on life sciences related products. Then he came to realise that while designers in Silicon Valley are often in a very comfortable position, a lot of the world isn't well designed. This resonated with me: some of our largest's design budgets are used to solve trivial problems, like yet another food delivery service. Education, healthcare, financial services… they are long-term and hard problems. Highly regulated, too, and not very used to having designers on their teams. Daniel ended up working on Resolve to Save Lives, where he makes software that makes it easier to register data about high blood pressure patients. This sort of data saves lives by making it easier to get patients to return regularly. But clinicians want to spend time on patients, not data entry. The technological layer needs to be very light, to be effective.

Beware of tech utopians

In technology we trust. So much, that the Paris climate agreement—essential to humanity's survival on earth—is based on the assumption that technological inventions will be available. Techno-utopianism is not new, Sarah Angliss explained. She told us about Muriel Howorth, who was an amateur nuclear scientist who reckoned that if radiation could be used for atomic bombs, it could be used for atomic gardening. Howorth wanted to use “atom-blasted” seeds to grow a giant vegetable. Sarah also discussed an experiment in which fluoride, which is toxic in high quantities, was added to a city's water supply, with high expectations around improving the citizen's dental health, and “saxton spanglish”, a phonetic and somewhat controversial method of teaching children English. It reminded me of pinyin, that is sometimes used to teach non-native speakers Mandarin Chinese and also controversial for oversimplification and making proper learning harder. They are all attempts to transform through design, that are a little too utopian. Maybe another modern day equivalent, besides climate tech optimism, is that once so popular social network that frantically tries to make the ‘metaverse’ work, or even that we try and sprinkle machine learning on everything, even where it doesn't necessarily make sense (see AI for content creation). Yes, it could work, but it could not.

Computers need to get better at togetherness

Matt Webb talked about reinventing the workplace. One major reinvention was when the personal computer made its debut (see also: the setup). Here's some utopianism that did end up well. Screens, documents, text processing, the mouse: the mission to put a computer on every desk (and Douglas Engelbart's “mother of all demos”) completely reshaped what offices looked like. Speaking of design transformation! Matt noted how, fascinatingly, much of the history of computing is about furniture design. I didn't know Herman Miller worked with Doug Engelbart's team to invent furniture to go along with their machines. Is the office done? Not really, as in 2022 we increasingly find ourselves working together from different locations. The current state of “togetherness” is lacking, Matt explained. We can be in virtual rooms together, but it isn't as good as it could be. For instance, they don't have a window out—you can't see who's approaching the space. There is little of the serendipity you might find in a physical office. With Sparkle, Matt works on a Zoom replacement, a tool that aims to facilitate togetherness better. As a remote worker, and as someone who isn't sure Big Tech has the solution for us, I will be following this work.

Moonlander with applause-controlled lasers

Lasers: they are fascinating. Seb Lee-Delisle showed us how he took animations outside of the projected screen to kick off Smashing Conference in Oxford, displayed love for the NHS onto their Brighton building during the pandemic and displayed laser fireworks that people could interact with. It's impressive, really, how much even one laser can do, let alone the over 30 in different strengths that he currently owns. Seb had the arcade game Moonlander (I had to look it up) projected on the wall with lasers, so that we could all try and safely land a moon lander by affecting the vehicle's thrust with our applause.

Everyone perceives differently

Anil Seth concluded the day with a talk about perception. Questions about how we perceive the world outside and our own bodies have puzzled philosohopers for millennia. Today, neuroscientists try to confirm through experiments that we don't perceive the world directly, showing some of these philosophers were correct. Sensory input, Anil explained, is constantly processed by our brain—it fills in the gaps based on what it remembers of the past and predicts of the future. Seb's lasers had just demonstrated that: when he made his laser move in a circle, we perceived a static circle, not that movement. Just like a film is really 60 different images per second… our brain causes us to perceive it as a film. Anil drew an interesting parallel between perception (“controlled hallucination”) and halluccination (“uncontrolled perception”). This constant interpretation of input by individual brains implies what Anil calls “perceptual diversity”, everyone perceives differently. In an art installation called Dream Machine, participants' perception is triggered and then recorded in the form of drawings afterwards.

Wrapping up

There was a bit of design transformation in each of these talks. We were rightly warned about tech utopianism. Design and technology can't transform everything, yet some speakers shared their plans to transform. They (re)defined what it means to perceive ourselves, collaborate on screens or keep content available over a long stretch of time. Some speakers were right in the process of transforming. They talked about turning a series of penstrokes into art, lasers into fireworks, human experiences into novels and patient data collection into a minimal effort task.

A lot of our work in web design and technology has a power to transform and that is wonderful, especially when we manage to be intentional about the how and why. With that, I'll conclude this write up of the last dConstruct. If it piqued your curiosity, word goes that audio of the full event was recorded. It will be added to the dConstruct Archive in due time. For now, thanks Clearleft for another excellent event.

Originally posted as The last dConstruct on Hidde's blog.

[email protected]?subject=Reply%20to:%20The last dConstruct">Reply via email

Better accessible names

2022-09-13T00:00:00Z

OK, you've added an accessible name to your control. Maybe you've used aria-label, <label> or some other way to name a control. Now you wonder: what makes a name good, effective or useful?

I wrote about why accessible names matter and where to add them before. In this post, I will go into how to make the actual names more user friendly. These tips are all from an underappreciated piece of content that I love: the Composing Effective and User-Friendly Accessible Names section of the ARIA Authoring Practices Guide. All credits go to the authors, I'm just adding context and examples.

Function over form

An accessible name is used by assistive technologies to refer to things on a web page. For instance, if you use voice control, you could say the accessible name of a particular control to activate it. If you use a screenreader, it is the name that gets read out when you get to the control, or when you pull up a list of controls (eg a list of links on the page).

Because of how we use accessible names, we want to keep them functional and avoid naming controls after what they look like. Ideally, you do this in the imperative form, that makes it easiest to quickly grasp what a thing is going to do.

Examples:

“Open navigation” works better than “Hamburger” and “More options” better than “Kebab”
“Next slide” works better than “Arrow right” or “Right pointing triangle”
“Save document” works better than “Floppy disk”

Most unique part first

In a series of names, like a set of buttons, links, etc, start with the most unique part of the name. This makes it easier to distinguish them.

Let's say you list a bunch of albums and want to include “album” in each name. Most unique first means you say “Midnight Marauders - Album”, “To Pimp A Butterfly - Album” etc, rather than “Album - Midnight Marauders”, “Album - To Pimp A Butterfly”.

Or you have actions for a link: “Edit link”, “Copy link” and “Share link” work better than “Link edit”, “Link copy” and “Link share”.

This even applies to the <title> of web pages: if you're repeating your company name in it, leave it for last and list what's unique about the page first. Technically not an accessible name, but the same naming advice happens to apply.

Be concise

Keep a name to the most important 1-3 words, prefer brevity.

No roles as part of the name

Things that have names in your page will (or should) have roles too. The browser will derive the role for you, whether you've set it explicitly (e.g. role="button") or it comes for free with the element (e.g. <button>). If you add the role, for instance the word ‘button’, to the name, that is redundant and this can be annoying for users.

Examples:

use “Close” instead of “Close button”
use “Main” instead of “Main nav”
use “Save” instead of “Save button”

Keep names unique

Imagine you work in a school and all your students are named “Alice”. It would be hard to address them… this is the same for the names of controls and components in your page, especially for users who use mostly these names to browse the page.

Examples:

instead of an overview page that shows news items with “read more” links, use the title of each news item as the link name
instead of saying “click here”, use the name of the page you're linking too, for instance: “See also: [name of the page]”

Sentences aren't names

The last tip in the document is: start names with a capital letter, for better pronounciation in some screenreaders, and don't end with a period, because a name is not a sentence.

I'm not sure if this is the type that this tip is originally referring to, but one example of setences in accessible names is this: a card that has a title, a description and a picture, that is clickable as a whole, implemented by wrapping it all in one <a> element. I've seen this in the wild. It is often problematic, because it creates names that are way too long and confusing. My recommendation would be to do this instead: pick a string that is a more useful (and concise) name and make that the <a>. Then solve the clickability issue with CSS.

Wrapping up

Before I wrap up, I want to assure you that you don't need to use ARIA to provide names, even if this information is part of the ARIA Authoring Practices. Text content in the appropriate HTML elements (<label>, <legend>, <caption>, <button>, <a>) works perfectly fine too. An added benefit is that when you provide visible names with these HTML elements, they can be used by more users, including people who don't use assistive technologies and people collaborating with assistive technology users.

That's all. As mentioned above, these tips are from Composing Effective and User-Friendly Accessible Names in the W3C's ARIA Authoring Practices. That specific page has a lot more tips and also covers accessible descriptions, name and description calculation, per-role guidance on whether you need a name, lots of gotchas and various coding techniques for adding names. Happy naming!

Originally posted as Better accessible names on Hidde's blog.

[email protected]?subject=Reply%20to:%20Better accessible names">Reply via email

2.4.11 Focus Appearance adds more complexity to WCAG than we should want

2022-09-24T00:00:00Z

Like many people, I have been monitoring the creation of WCAG 2.2, the upcoming new version of the Web Content Accessibility Guidelines. Nine new Sucess Criteria are proposed. One particularly worries me: 2.4.11: Focus Appearance.

Focus Appearance builds on two existing WCAG criteria that affect focus indicators: that users can see which element has focus (2.4.7), and that focus styles have sufficient contrast (1.4.11). Focus indication is essential for a wide range of users, including users who browse by keyboard or zoom in. For an introduction to why focus indication matters, see my post on indicating focus.

What's new about 2.4.11 is adds more requirements for what the indicator looks like:

an element with focus needs to have sufficient contrast with its non-focused state
an element with focus needs to have sufficient contrast with its surroundings
the focus indicator needs to either be a solid line (so not dotted or dashed), or have a certain level or thickness (in which it can be dotted or dashed)

It's a clever new criterion, that addresses important user needs that were previously unaddressed. The Working Group clearly put a lot of research and thought into it. This is hard to do, as co-chair Alastair Campbell mentions in a GitHub issue:

what makes a visible focus indicator is not particularly straightforward

This is the crux of why this isn't trivial to solve and I appreciate everyone's efforts on the proposed Success Criterion. I know the text has had revisions and improvements after people have flagged complexity issues. Still, I'm sorry the Success Criterion as it stands now has me worried.

“Focus Appearance” is “at risk” of being removed from the final version of WCAG 2.2. My vote would be to drastically change it (again) or remove it entirely. Firstly, the requirements are complex to apply or teach. Secondly, browsers, OSes or assistive technologies could guarantee focus appearance better (and I feel it would be easier to talk to them than to convince all of the world's web developers).

Why I hesitate about including 2.4.11

Complex to apply

I expect Focus Appearance would be hard to apply, because the Success Criterion text has a lot of complexity. It is full of clauses and sub clauses. It often includes “and” (8 times), “or” (7 times) and “non”/“not” (4 times). There are two ways to meet it (you can choose one or both), and there are two exceptions and three notes. All in all, it's a lot to grasp.

The wording requires knowledge of a lot of specialised terminology, especially in the “area of the focus indicator” part. It may be that I am a non-native English speaker, but I had to look up what a “perimeter” is. The Oxford Dictionary of English states:

the continuous line forming the boundary of a closed geometrical figure

WCAG 2.2 makes this definition more specific to the web by defining “perimeter” as ”continuous line forming the boundary of a shape not including shared pixels, or the minimum bounding box, whichever is shortest”.

In this, “minimum bounding box” has its own definition:

the smallest enclosing rectangle aligned to the horizontal axis within which all the points of a shape lie

And because it is about web content, another clause is added:

For components which wrap onto multiple lines as part of a sentence or block of text (such as hypertext links), the bounding box is based on how the component would appear on a single line.

This is a lot to take in and it seems easy to misunderstand. There are so many sub definitions needed. One could easily misinterpret the concepts of a bounding box, the perimeter,“shared pixels”, “CSS pixels” (ok, that's already used in Reflow and Target Size) and apply the whole SC wrongly.

This makes 2.4.11 Focus Appearance very different from other criteria, like Non-Text Content or Keyboard. Accessibility specialists will know there are indeed lots of ways not to meet those requirements, but the general idea of how to comply is easier to grasp. Very few people will need to look up what a keyboard or text is.

Admittedly, there are easy ways to comply with the proposed Focus Appearance, too. One is to have a solid outline with a minimal offset of 1px that has sufficient contrast (3 : 1) with its background, as James Edwards explains in New Success Criteria in WCAG 2.2.

Complex to teach

As someone who sometimes teaches WCAG to teams, I also worry about the complexity of 2.4.11. I could teach the ‘easy way’ described above, that doesn't seem too complex to teach. But if I would try to teach the whole Success Criterion with all the requirements, exceptions and notes and also cover what the Understanding document explains, I fear I won't get it across.

“But teaching is your job, Hidde!”, you might say. Yes. And I could probably make it work, but it would take class time that I would like to spend on other barriers, and there is still the risk the information sticks with participants less because of the complexity. There will also be people trying to apply this Success Criterion on their own.

Leave it to browsers

We can't just leave all of our problems to browsers to fix. But if I had any say in it, browsers should fix any accessibility problems they are able to fix. That way, end users have to rely less on individual web developers to make good choices. I feel focus indication is a great example of that: the browser knows what has focus, users want to know it, web developers could fail to add a good indicator. So why rely on web developers?

In a discussion on relying on browsers for focus indication, the Working Group concluded that browsers don't do sufficient default focus indication today, so if we want accessible websites, we need to require it through WCAG. If browsers start to do it later, the requirement could be removed or moved to a different level then. A chicken and egg situation, basically, but with one of them more likely to materialise (I'm not super sure which, to be honest).

A second argument is that web designers are in a better position to design an appropriate indicator, one that fits well with the rest of the site's design. But it's unlikely those designers can take into account user needs as well as a browser could with settings. Some users may prefer an indicator they can see move from one element to another, some may want a very high contrast indicator, some may want it more subtle (see also Rain's comment mentioning high visible focus indicator from a COGA perspective). A browser could provide options. We wouldn't want individual websites to start offering focus indication choosers, right?

Forced focus indication already exists in various forms through OS settings, assistive technologies (like VoiceOver) and even some (buried away) browser settings (in Chrome). There is a bunch of browser plugins and bookmarklets that force focus indication, too. So we've got forced visibility. Forced “good appearance”, however, is not fully in browsers and harder to implement, of course. It would need to account for all the things 2.4.11 requires, like sufficient contrast with surroundings (the browser/add-on/plugin would need to make it work with any background) and sufficient contrast with non-focused state.

I get the idea of putting this on developers before full browser support exists, but it does feel a bit like solving all problems with one (conformance-shaped) hammer. It also doesn't apply when developers simply don't meet WCAG. Yes, there are human rights, ethics and laws, but we know they are violated a lot today. I fear this will only be more common when the requirements are too complex.

How to make it less complex

I know WCAG 2.2 is close to its last standardisation stages, so I'm sorry to bring this up now. I also don't want to just say ‘don't include 2.4.11’. Let me describe a possible way to make the situation less complex for developers, evaluators and teachers, by replacing Focus Appearance with multiple Success Criteria:

Focus Distance to require a minimum offset between the focused element and its outline
Focus Solid to require solid, unless a minimum thickness is used

These two on their own seem a lot less complex to apply, test and teach. As minimum contrast and visibility are already covered in other Success Criteria, these two criteria between them would make focus indication much better for low vision users, while not adding the complexity 2.4.11 adds.

Conclusion

The proposed Focus Appearance criterion does a great job at capturing which problems end users have around focus into requirements. But it lacks understandability for users of the standard: people who make websites, people who evaluate accessibility conformance, developers of testing tools, et cetera.

It may seem reasonable to say those understandability concerns are secondary to the ability of end users to use the web. Of course they are. But if there is too much complexity in WCAG wording and mathematics, I worry the web won't actually get better for end users. We'll lose the people who need follow the recommendations. This is already an issue with current requirements, as shown by the many “WCAG in plain words” derivatives and checklists that exist. The original source gets plenty of “appropriate requirements love”, it could use content design love.

I'm sorry, but I feel WCAG 2.2 is better off without 2.4.11. Even after some iterations, it (still) adds more complexity than we should want WCAG to have. It's difficult to apply and teach. It may end up like Terms and Conditions: factually correct, but commonly skipped over. That would be problematic in this case, and mean not considering important end user needs.

My ideal resolution would be (I know, easier said than done): sit down with browser makers and improve the focus indication game structurally together. Meanwhile, people who make websites can prioritise the 86 other WCAG Sucess Criteria (rather than implementing 2.4.11 until browsers are ready). Focus indicators are a core need web users have, it needs better appearance and likely choice in appearance, let's bring the research from AGWG into (browser) practice.

Originally posted as 2.4.11 Focus Appearance adds more complexity to WCAG than we should want on Hidde's blog.

[email protected]?subject=Reply%20to:%202.4.11 Focus Appearance adds more complexity to WCAG than we should want">Reply via email

Do we need an Interop for assistive technologies?

2022-10-30T00:00:00Z

I'm so happy about what Interop 2022 is doing for web compatibility in general. It made me think: what if we had something similar, but accessibility-specific, focused on compatibility between our code, assistive technologies and browsers? Excitingly, ARIA-AT pretty much has that goal.

Interop 2022 is great

In the Interop 2022 effort, all major browser vendors, browser engineers and other stakeholders agreed “to solve the top browsers compatibility issues identified by web developers” in one year. I danced a little when I saw that. I mean, they align their priorities between them and web developers get a say in what the priorities are. Excellent.

Subgrid, <dialog> and scroll-snap are tremendous features, but consistently cross-browser supported subgrid, <dialog> and scroll snap (and more) are the real deal. Because browser compatibility issues can be quite the nuisance. They make web development harder and more expensive. Web developers end up with a choice between either supporting less browsers or adding hacks and more bloated code. Either option likely trickles down to the experience of end users.

Unrecommendable web platform features

As an accessibility specialist, I spend some of my time giving advice on how to code accessible UI components. From time to time, I want to recommend a thing, but I don't, because of bugs or inconsistencies somewhere between browsers and assistive technologies.

I asked on Twitter what people's top issues were:

If you could fix 3 bugs in assistive tech or browsers, to make building accessible UI components more straightforward, what would they be?

Some responses that came in, all browser focused:

display properties (still) break default semantics (thanks Adrian Roselli for all his work documenting the issues in detail)
the HTML video player has keyboard accessibility, focus management and screenreader issues in various browsers (see also: Scott Vinkle's post How accessible is the HTML video player? from 2019)
aria-controls is not or weirdly supported by screenreaders
The expanded state of details/summary is not communicated to users of screenreaders in Firefox if the arrow is hidden (as documented by Scott O'Hara in The details and summary elements, again). That's a problem: conveying status to assistive technologies is a core feature of functionality that does visual expanding and collapsing
aria-owns is not supported in Safari (see also: Diego Haz' demo)
Default field validation cannot zoom

Having these issues open for so long hurts web accessibility:

developers who aren't aware may think that by using the platform they get accessibility by default and unknowingly build something inaccessibly
developers who are aware may end up adding all sorts of hacky code to fix the issue on their end, which could lead to maintainability issues in the long term and makes accessibility unnecessarily hard
developers generally will have a greater chance of shipping inaccessible interfaces

On Twitter, people also replied with other interesting ways browsers could improve accessibility, like a browser implemention of “skip to <main>” (as Léonie suggested) or even to any landmark (as Curtis said).

And then there are issues around what browsers do, but (some) accessibility specialists disagree with, like that <dialog>'s focus trap can escape to the browser chrome. I've heard from developers whose accessibility consultants recommended them not to use <dialog in the first place and that's an issue.

I believe in personal responsibility when it comes to building a more accessible web. Teams need to test their work and ensure accessibility. But at the same time, change in the primitives (like browsers and CMSes) is needed and can improve a lot of accessibility at once. All of the above issues are most easily solved by browsers, not individual web developers (see also my earlier post, More accessible defaults, please).

ARIA-AT

If we look beyond just browsers and focus on assistive technologies, an interesting project comes to mind. The W3C's ARIA-AT Community Group has the goal to ensure “assistive technologies work with web code in predictable ways”. The group works on interoperability in four ways (taken from their homepage):

write tests; they help ensure alignment between how assistive technologies behave, and with that, what users can expect
run tests across different assistive technologies (currently focused on screenreaders, including JAWS, NVDA and VoiceOver)
build consensus in the industry
enable scalable automated testing (for which they are writing a standard, see the AT Driver explainer)

The ARIA-AT explainer video explains why this is so important: “there are hundreds of interpretation issues between screenreaders,” and “the way screenreaders and browsers interpret web code changes all the time”.

I am very excited for this project, it will be super cool to see the test results pop up in places like the ARIA Authoring Practices Guide.

Summing up

It would be great for the web to see browsers prioritise accessibility bugs and align between them on the accessibility aspects of current features like <dialog>, <video>, form validation and aria-controls. Either as part of the regular Interop program, or separately. At the same time, returning to the question I started with: yes, more interop between assistive technologies would be very welcome. Improving how assistive technologies interpret our code is a fantastic goal—I'm excited for the impact ARIA-AT will have.

Originally posted as Do we need an Interop for assistive technologies? on Hidde's blog.

[email protected]?subject=Reply%20to:%20Do we need an Interop for assistive technologies?">Reply via email

Is this the last exodus from Twitter?

2022-11-06T00:00:00Z

There have been reasons to leave Twitter since its inception. But it's increasingly compelling to post somewhere else.

Why read about what random people do all day? In the spring of 2007, I wasn't sure why I would join Twitter. All the cool web folks at that year's SXSW Interactive had started using (and hyping) it. I worked at a small web agency at the time. My colleagues convinced me, I think. So I made an account on this new website that had just one text field with the question ‘What are you doing?’.

When I started, I mostly bored my readers with facts like “I drank a cup of tea” or “waiting for a bus”. Mentions and retweets didn't exist yet. For the first, maybe, 5 years, my account was private and I had way under 100 followers. I tweeted mostly in Dutch, even in Frisian sometimes. There was a generous API so you could trivially display tweets on your own site. There were local in-person Twitter meetups, at least where I live, to hang out with Twitter folks, including one that had Dries Roelvink perform.

Twitter homepage in 2007, the logo was a piece of art

In the years after, the platform expanded beyond the web developer crowd and interesting journalists, authors, musicians came. I used the platform more and more to follow folks I saw speak at conferences. Over the years I found a collection of hundreds of people whose stuff I really enjoyed reading. On web development, but also other interests. Some posted often, others occassionally. Either way, I learned so much from the tweets, links to other sites, discussions and what not. More people started following me too, and I managed to develop real friendships. My DMs got busier too. Twitter, the platform got useful new features, but ultimately, it's the people that attracted me to the platform and people that kept me on there.

Yet, there were always compelling reasons to leave. The platform and tweets became more engagement-focused, the Twittersphere started to attract (and reward) grifters. The algorithmic timeline was introduced, although that could be turned off.

Abuse also increased, especially for minorities on the platform. Under Jack Dorsey's leadership, Twitter systematically failed to act on reports of racist, homophobic and misogynist accounts, it made Twitter more dangerous to anyone not a cis white male, even got users in physical danger. Some of that was described in a 2018 Amnesty International report on Twitter called “A toxic place for women”, a document full of details on how the company failed to respect women's rights.

And then there was the risk of making content on a platform that you don't control. My friend Manuel got permanently suspended, for reasons unknown to him. I can only imagine what it was like for him to lose access, just like that. A lot of us tried to change the minds of “@TwitterSupport”, but until today, it wasn't resolved. For a lot of folks this situation was a wake up call to reconsider where they post. I realised my new ambition was to like, Zach, take ownership of my tweets.

Last week, I still didn't feel like leaving the platform just because the new owner was an arrogant troll with world views orthogonal to mine. I imagine more services I use have unpleasant owners. Last time I tried Mastodon, I didn't stay. The thing is, I don't even think I really believe in decentralised social networks, I would rather have all my friends in one pub than spread across pubs. I will probably find out I'm wrong about this, as the web at large was designed to be decentralised and it is one of the charms of it and arguably what made it so successful.

But then that new owner fired Twitter's entire accessibility team, its ethical AI team and large parts of trust and safety folks working on problems that have very real life consequences (like meddling in elections, spreading of conspiracy theories, hate crimes, impersonation), he unfolded plans for a new ‘Verified’ program that made the feature for sale rather than for security and then he recklessly and cruelly fired half of the staff (and seems to be trying to get some back)… it's chaos!

So I decided to go ahead and hang out elsewhere, at least to put my content there. That other place is ‘the Fediverse’, and it has a different focus:

the Fediverse is different: it isn’t trying to glue your eyeballs to the screen, and it’s harder for things to go viral. There is less media, fewer memes, no advertising. And there are humans explicitly in the loop: Mastodon instances are moderated on an instance-by-instance basis — and should an instance descend into a hellscape, it may find itself defederated. But because of all of this, there is also less opportunism, less trolling, less dunking on your enemies, less nastiness. So it also feels more relaxing, more earnest — and easier to put down.

(from Bryan Cantrill's Twitter, when the wall came down)

Maybe the decentralisation aspect could actually work. It's a bit like email.

It seems like the new owner and his behaviour is driving people in my bubble away from Twitter, towards the Fediverse, personal blogs, RSS and other platforms. Probably mostly in that bubble, but maybe it is a wider thing, time will have to tell. It's probably not the last exodus.

I didn't suddenly stop caring about the people I follow on Twitter, I understand not everyone wants to leave, so I will also stay on Twitter for the foreseable future. To catch up on tweets, to DM and to share posts like this one. But for the next while, I plan to hang around on Mastodon more.

Originally posted as Is this the last exodus from Twitter? on Hidde's blog.

[email protected]?subject=Reply%20to:%20Is this the last exodus from Twitter?">Reply via email

Dialogs and popovers seem similar. How are they different?

2022-11-08T00:00:00Z

Web platform concepts can sometimes be quite different, yet seem very similar. Semantics, behaviours and characteristics can be tricky to distinguish. In addition to the <dialog> element, HTML now has a popover attribute. This post goes into the differences between dialogs, popovers, overlays and disclosure widgets. We'll also look at what it means when an element is modal. All somewhat related concepts that can seem very similar. At least they did to me. Let's dive in!

(If this is too long, I did a 40 minute talk version at All Day Hey and a 7 minute version at JS Nation (don't believe the ‘AI’ summary on that page))

In this post

Introduction
The characteristics (modality, light vs explicit dismiss, top layer presence, backdrop, constrained focus, keyboard dismissable/collapsible)
The main patterns (dialogs, popovers, overlays, disclosure widgets)
FAQ
Summing up

popover is available:

Chrome (116) and Edge (115)
Safari (17)
Firefox (125)

You can use it in production (there is popover polyfill), but be sure to test it well, it is new and there may be issues with support, including accessibility support.

Introduction

The thing with words is that not everyone uses them the same everywhere. The words in this post are no different. As a long time contractor I changed environments on the regular—phrases changed when I worked in different teams, companies, countries and even years (see also older resources, like the WHATWG wiki on dialogs). Meanings change over time, also in the world in general… this is normal! But in the case of these components, interpretation differences can lead to bad user experience.

A lot of the concepts I'll discuss in this post originated in operating systems: see Apple's Human Interface Guidelines, Microsoft's “Win32” guidelines (old) and Controls for Windows apps (newer). If we compare those with patterns in ARIA Authoring Practices Guide, we'll find similarities. Some similarities are on the surface, they just look the same. Others are similar for users of assistive technologies: the ergonomics of some ARIA components are designed to be similar to the corresponding operating system ergonomics, for better or for worse.

But OS-level guidelines or ARIA Authoring Practices (APG) aren't the best place for web developers to look for implementation guidance. OS-level guidelines are for OS-es, APG is to demo how to use ARIA (not how well it is supported).

For clarity, throughout this post, I will refer to the concepts of dialog, modality and popovers as they exist on the web, in languages like HTML, CSS and ARIA (note: popovers don't exist yet, just as a proposal). My definitions are meant to align with the relevant web specifications, they may be slightly different from what is used in other places and in individual teams.

Below, we'll start with characteristics that components can have, like modality, light dismiss, top layer presence and backdrops. Then we'll talk about what we get when these characteristics are used together in a website or web app: dialogs, popovers, overlays and disclosures. Hopefully, when we discuss the characteristics in detail first, it is easier to distinguish the components themselves.

The characteristics

Modality / inertness

Some design systems have a component named “modal”, but modality is more of a characteristic than a component itself.

So what does it mean for an element to be modal? Basically, when a modal component is open, it is the only thing that is not inert. Only the modal content can be interacted with, the rest of the page or application is made inert. Inert content is content that users cannot interact with. It is only really there visually, but you cannot Tab to it, click it, scroll it or access the content via assistive technologies.

Elements that are not modal are called non-modal or modeless.

In this example, the dimmed background suggests a choice between accepting and refusing cookies has to be made before any other interaction can happen. (Note: on actual website, scrolling the background still works, it shouldn't)

Not everyone likes modality—as a UI concept, they are very disruptive. Use the pattern sparsely, only when disrupting is very much necessary. If you want to ask the user “Are you sure you want to delete all that?”, go ahead and make it disruptive. If you want to promote your newsletter sign-up or advertising, the disruption is unlikely to be appreciated.

In terms of implementation, you will need to make everything except your modal element inert. The <dialog> element (used with showModal()) does this for and would be the best to use.

If you cannot use <dialog> or are looking at an older code base that doesn't, here's an example of distinguishing between modal and inert content:

<body>
  <div class="modal" role="dialog">
    <!-- modal content -->
  </div>
  <div class="everything-else" inert>
    <!-- everything else -->
  </div>
</body>

The gist of it is that one element is modal and everything else inert: unavailable to any user or technology. As today, not all users will be on a browser that supports inert, best use the inert polyfill. Without inert or its polyfill, you would need to add aria-hidden="true" to the content outside of the modal (to make it unavailable for assistive technologies) and tabindex="-1" to any interactive elements that are not in the modal.

Just trapping focus in an element or adding a backdrop does not make it truly modal. With a focus trap, you only make the rest of the content unavailable via a keyboard. With a backdrop, you only make it unavailable visually.

Light vs explicit dismiss

Another aspect to consider is how users dismiss a component and whether that is affected by other elements: this can be via explicit dismiss or light dismiss.

With ‘explicit dismiss’, a component allows a user to dismiss it, for instance via a close button and the Escape key (when in doubt, best add both).

Explicit dismiss: if I don't want to send this tweet, I can press the close button or Escape to dismiss the dialog I'm presented with

With ‘light dismiss’, a component disappears automatically on certain conditions, like when users scroll, interact with something else or click outside of the component. Light dismiss doesn't happen when the user Tabs out of the element by default (but developers can add it if needed, see the discussion in openui/open-ui#415 for more details).

Light dismiss: if the font picker is open and I click in the text that I'm editing, the font picker will close automatically

Light dismiss is something we can already build in JavaScript today, a lot of websites have components that light dismiss. But with the popover attribute, the browser would do it for you (if you use popover="auto").

Top layer presence

By default, if multiple elements are positioned in the same location, they are painted by the browser in DOM order. The element that is first in the DOM is painted first, each subsequent element on top of the previous and the last one in the DOM is painted last, at the top. With the z-index property in CSS you can deviate from the default on a case by case basis. You basically decide your own layer order. This feature is defined in an appendix to CSS 2.1 called the Elaborate description of Stacking Contexts.

The top layer (as of July 2023, part of CSS's Positioned Layout Module, Level 4) is painted after the painting process described above, and the stuff within it is therefore on top of everything else. The top layer is not new in the web platform, but the ability for developers to promote elements to it is. Web pages have just one top layer. Within the top layer, elements are painted in the order they are added to the top layer (so shuffling them around involves adding/readding them).

Sometimes, developers add components just before the closing </body> tag to try and ensure that they are painted above other things (given nothing has a z-index > 0). The top layer introduces a new way to allow elements to be on top of everything else, regardless of where they are in the DOM or their z-index.

Another benefit of the top layer has to do with overflow. If your popup is in an element with overflow: hidden, that will cut it off. If it is promoted to the top layer, no cutting off will take place.

A downside of an element being in the top layer, is that it can't be positioned relative to things in the main document. I believe this is something modal dialogs usually don't need, but popovers would need a lot of the time. See also: Positioning anchored popovers.

Backdrop

In some cases, it makes sense for elements to have a backdrop. A backdrop usually serves as a visual cue that conveys content behind it is unavailable for interactions. Sometimes, it can be used as a way to help the user focus.

The ::backdrop pseudo element can be applied to top layer elements. It allows you to style the backdrop in any way you want.

Constrained focus

Sometimes focus is constrained to (or trapped in) a specific element, meaning that if focus is in this element and you press Tab or Shift + Tab, you will never go to elements outside of the element. This characteristic is also known as a “keyboard focus trap”. It is a side-effect of making everything else inert (which <dialog> does for you). (Note: trapping focus in an element does not make that element modal, but if it is truly modal, focus cannot be moved outside of it, because nothing outside of it is focusable).

Focus traps should be temporary until the element it applies to is closed or dismissed (they would fail WCAG 2.1.2 if it is not temporary and has no way to escape with a keyboard).

Keyboard dismissable/collapsible

If content can be dismissed or collapsed, users should also be able to dismiss or collapse it with just a keyboard.

When content can be dismissed, a common pattern is that pressing the Escape key dismisses the content. Usually dismissal is restricted to happen only when the user is focused on something inside of the component to close. If there are multiple things to close, like with nested components, you would press Escape multiple times and closing would happen component by component from most inner to most outer element.

When content can be collapsed, keyboard users should be able to use the same button that mouse users click to collapse content.

The main patterns

Let's look at some common patterns and how to distinguish between them.

Dialogs

What is it

A dialog is a component in a web page or app that usually contains an action or some task to perform (see: <dialog> in HTML specification). It is usually not part of the natural flow of other content, for that reason it can (and usually does) cover other content. MDN describes it as a “subwindow”, ARIA Authoring Practices defines it as a “window overlaid on either the primary window or another dialog window”.

A dialog is often displayed when users need to be made aware of something or when they need to choose. Do you want to continue, yes or no? If you want to open a new file, what shall we do with your current file, save or delete? How do you want to crop this image, where is the hot spot?

Browser dialogs / confirm()

Canonically, dialogs are a lot like window.confirm(), window.alert() and window.prompt(), which the HTML specification lists under ‘simple dialogs’. But unlike these browser built-in dialogs, custom dialogs offer more flexibility—you get to put whichever content and styling you want inside of them.

Dialogs have a role of dialog, which the browser will assign automatically for you when you use the <dialog> element.

You can also create dialogs with ARIA: apply role="dialog" to an element (like <div>). If it is a modal dialog, add aria-modal="true" when it shows, and remove it when it is dismissed. You will need to do all the modality work yourself (focus trap, making rest of content inert, etc). Note: aria-modal is not supported in IE11 (which may still be in use among your assistive technology users), there are issues with aria-modal in VoiceOver and it seems unsupported in Narrator.

You can put a form with method="dialog" in a dialog. This form will close its dialog when submitted.

Examples

Modal dialog: add a link; nothing behind it can be interacted with while this modal dialog is open.

Non modal dialog: while this chat widget is open, I can still access the forms and content underneath.

Characteristics

Dialogs can be modal (<dialog> when shown with dialog.showModal()) or non modal (<dialog> when shown with dialog.show()). To avoid quirks, you will want to choose which of the two your dialog is, and only call one of these methods per dialog.

When <dialog>s are modal, the browser will treat the content outside of the dialog as inert, and prevent keyboard focus from reaching web content outside of the dialog (if you use role="dialog", you have to do this yourself). If a <dialog> is not modal, the other content is not treated as inert. This makes modal dialogs a lot more disruptive, so use them only when you have to. You usually don't want to interrupt or disrupt a user's flow.

Dialogs are in the top layer only if they are modal (and only if the <dialog> element is used; other elements with role="dialog" will not go to the top layer).

Dialogs must have an accessible name (see WAI-ARIA 1.2, dialog role). Associate your dialog with the visible heading or message (if brief) using aria-labelledby on the <dialog> / <div role="dialog">. You could also use aria-label, but associating with visible text is ideal, because it creates parity between what folks see and what assistive tech call stuff.

WAI-ARIA specifies that when you're using role="dialog", you should include at least one focusable element and move focus to one of the focusable elements when it opens.

Browsers will close modal dialogs when users press Escape. Non-modal dialogs don't get this default behaviour, developers can add it where it makes sense.

Alert dialogs

WAI-ARIA defines a specific type of dialog, which is called “alert dialog”. It is meant for dialogs that contain a brief, important message. Their function is to alert the user—the browser will do that by firing a system alert event to accessibility APIs. They are the ARIA-equivalent of the browser alert() dialogs we discussed above.

Examples

After you didn't interact with your online banking environment for 10 minutes, an alert dialog shows and says you will log out in 5 minutes, unless you press “Continue my session”
You're editing some important content and accidentally press Command + W, the shortcut to close the current tab. An alert dialog appears to ask if you really want to “Leave” now or perhaps “Save your changes” first.

Characteristics

Alert dialogs are always modal and have their focus trapped. They also require an accessible name. Like with dialogs, if there is a visible title, associate the title's id with the alert dialog's aria-labelledby attribute. If not, aria-label can also be added to an alert dialog.

Popovers

What is it

Popover is a set of behaviors that can be added to any element through the popover attribute (like tabindex or contenteditable). It is specified in HTML and there is a polyfill (why is it an attribute and not an element?).

The popover attribute is meant for UI components that are:

on top of other page content
not always visible (eg just when they are relevant), also described as “short lived” or “ephemeral”
usually displayed one at the time

As opposed to <dialog>s, a popover doesn't come with a built-in role (this is partly why it is an attribute and not an element), you pick your own role. It can take on any role that makes sense, or none at all. Sometimes popovers could be (modeless) dialogs, in that case you could use <dialog popover>.

The popover attribute is planned to allow for two values, each of which give a slightly different set of characteristics:

popover=auto: light dismisses; when it opens, it force-closes other popovers and hints (except its anchestors); it or its anchestor would usually receive focus
popover=manual: explicit dismiss (via timer, close button or some other script); when it opens, it does not force close anything

(More types may follow)

Full screen content also forces popovers of the “auto” type to close.

Examples

An example of a popover is the listbox that shows when a select is opened (conceptually for <select> and literally for <selectmenu> as it is currently implemented in Chromium).

These are some common examples of components with popover behaviours:

Datepickers / calendar widgets
Tooltips and toggletips
Teaching UI (e.g. to point out parts of your interface when it is first shown)
Action menus (see example below), using role="menu"

There are also popovers that users need to dismiss or that automatically dismiss (like toasts).

So yes, there are lots of different UI patterns that can have “popover” behaviour as a requirement. This is why popover is proposed not as one HTML element, but as an attribute that is meant to be used with an HTML and/or role that is most suitable for that pattern. For an action menu, that's a <div role="menu" popover>. A tooltip could be <div role="tooltip" popover> (depending on context and what it is). In any case: each of these patterns has its own UX expectations.

This menu with image options is a popover. It disappears when you click outside of it.

Twitter's alternative text feature is another example of a popover (implementation has accessibility issues)

Characteristics

Popovers are not modal. This is another major difference between popovers and dialogs. For this reason, it will be rare (but not impossible) for them to have a backdrop or focus trap.

Popovers can have ‘light dismiss’ behaviour, meaning they close by themselves, except when they are of the “manual” type. Manual popovers could be things like a “toast” notification that is dismissed via a timer or manual button.

Popovers, even if rare, can have a backdrop, which obscures content outside of it. This does not make the popover modal—as mentioned, popovers are non-modal. My recommendation is that if you're considering adding a backdrop to your popover, to also consider ”oh wait, maybe this is a modal dialog instead”. It might well be. Having said that, there is a handful of use cases for popovers with backdrops that are not modal.

Popovers can have focus trapped in them, for instance in complex widgets where you want to avoid that people accidentally tab out of the widget. A focus trap does not make a popover modal, as users can still access everything else on the page, it is just something that can improve usability in certain cases.

A “toast” notification that dismisses automatically after a couple of seconds and also has a close button in case you want it to go away now (most toasts just disappear, that's also fine; in either case their contents should be conveyed to assistive tech).

Popovers also can be opened, closed and toggled without JavaScript: with a <button> in HTML and the popovertarget attribute that points to the popover's ID, the browser can take care of showing, hiding and toggling.

An example:

<button 
  type="button" 
  popovertarget="datepicker"
>Pick date</button>
<dialog popover id="datepicker"></dialog>

In this case, the dialog is turned into a popover with the popover attribute, which adds the popover behaviours. The button will toggle the popover, because the popover's ID matches the button's popovertarget attribute.

The button can also be set op to just show or just hide, in this case use popovertargetaction with show or hide (the toggle value exists too, and is the default).

To open the popover when the page loads, set defaultopen on the popover. This is useful for teaching UI.

To move focus to a popover when it opens, set the autofocus attribute on the popover itself, or an element within it. Normally, this attribute sets focus on page load. But if it is used on or within popovers, it only sets focus when the popover is shown (this can be on page load if defaultopen is used).

To position a popover, a very exciting proposal called CSS Anchor Positioning is in the works. As far as I understand it today, it would allow us popovers that automagically position in the most suitable place, avoiding collisions with the edge of the window. A bit like the Popper library does today, but built into the browser.

If focus management, positioning, JavaScript-less toggling and light dismiss weren't enough, there is also a proposal for popovers to be transitionable using CSS, between [popover] and [popover]:popover-open (of course, you'll want to adhere to your users' motion settings using prefers-reduced-motion).

Overlays

Overlays are more of a characteristic than a component on their own. Often, when developers talk about overlays, they mean dialogs that are modal. In a literal sense, overlays are things that lay on top of other things. Popovers and dialogs can both overlay other things.

Disclosure widgets

What are they

Elements that show and hide things are often called ‘disclosure widget’, as Adrian Roselli describes in his post about various kinds popover-like controls. Almost everything in this post is a subset of disclosure widgets… as in, they are pretty much all things that can be shown and hidden. Adrian describes disclosure widgets in more detail in his post Disclosure widgets.

Disclosure widgets exist in HTML as <details>/<summary>, but can also be built with <div> and the appropriate ARIA attributes. This isn't entirely the same. In Details/summary, again, Scott O'Hara suggests that this is more consistent:

If your goal is to create an absolutely consistent disclosure widget behavior across browsers, i.e., ensuring that all <summary>s are exposed as expand/collapse buttons, then you’d be better off creating your own using JavaScript and the necessary ARIA attributes.

But, he adds, your ARIA disclosure widget won't have some of the features <details>/<summary> brings, like in-page search (Chromium triggers a <details>'s element open state when an in-page search query is found in its content).

There isn't a specific role for disclosure widgets, but there is the aria-expanded attribute for triggers and aria-controls to connect triggers with the element they trigger. When using <details/summary, <dialog> and (in the future) popover, browsers take care of setting up these kinds of accessibility properties for you.

Examples

a Frequently Asked Questions section where the answers are collapsed and you can expand them from the questions
tables in which individual rows can be expanded (See Adrian Roselli's Table with Expando Rows)
“Toggle tips”, like an “info” button that displays next to complex terminology to open a tooltip that explains the word
“meganav” style navigation where the main navigation items open more navigations

The show/hide functionality of sections within a category (displayed on the right) are a disclosure widget

Characteristics

There are a lot of different things that qualify as disclosure widgets. What they have in common is that they consist of two parts: one is a triggering element, the other is the triggered element.

Disclosure widgets do not trap focus, have no backdrops and are not modal. They are usually dismissed or collapsed with their trigger or a close-specific button.

FAQs

Where should focus move?

When a modal dialog opens, keyboard focus should move to the default action. If there's a form, it is probably the first form field. If there is multiple buttons, it could be the one that is least destructive, like if there's “Cancel” and “Confirm” button, a sensible default would be “Cancel”.

When a modal dialog closes: if the user triggered it, move focus back to the trigger. The browser does this automatically for <dialog>s. For popovers, it only does in cases “where it makes sense” (see the Popover Explainer). If the user did not trigger it, move it to an appropriate position earlier in the DOM.

For all other components (non-modal dialogs, popovers or disclosures), expected focus management differs case by case. The Popover Explainer's section on focus describes some of such cases.

Are all popovers dialogs?

Let's distinguish between three things we could mean by “dialog”:

the <dialog> element, an element with a built-in dialog role and dialog behaviours and possiblities (like, you can run show() and showModal() methods on it)
elements with role="dialog": the role attribute with the dialog value gives this a dialog role, but other than that, it comes with nothing, you would have to add your own behaviours to it
the word “dialog”: in your design system documentation, or in any casual conversation about components, you could be referring to dialogs and they could be none or one of the above

Sometimes, popovers use the <dialog> element or elements with a role="dialog". But not all of them. For instance, listboxes, menus, tooltips, grids, lists of links could all be components that require popover behaviours, but not the dialog role or the <dialog> element.

Are all dialogs popovers?

No, only non-modal dialogs are conceptually popovers (you can implement them with <dialog>/role="dialog" today). When the popover feature is stable and well-supported in browsers, it makes sense to use <dialog popover>, and would be the way to go if you want your non-modal dialog to appear in the top layer and leverage browser-provided light dismiss. In contrast, modal dialogs don't share the set of characteristics popovers have.

I'm building an X, should it be modal?

It depends. The question to ask is: is this component something that is the only thing your user may pay attention when it is open?

Country selector

You are building a check-out form for your online shop. In one of the fields, the user need to select a country. They eventually have to, because it is a required field. Still, while they select the country, they may scroll to something else, or decide to pop to the credit card stuff first. Maybe they need to read the label to check if you need country of birth or residence. This is best non-modal, because the user may want to look at other things.

Definition popover

You are building a toggle tip that can show definitions for complex words in your content. When the definition icon is clicked, it opens. Your user may want to scroll away or read other content or do other stuff. It is best to keep this non-modal.

Game over

The user has played some levels of your game, but they've lost and are now “game over”. They can't continue. It's really over and there's a dialog to tell them. There's no other thing they can interact with than this dialog. Modal it is.

Tracking consent

You are building a dialog that asks users if they want to agree that you track them. Your visitor is in an area where the law makes it illegal for you to do so without permission. In this case, there is no point in interacting with anything but the permission screen, so it would make sense to make it modal.

Fly-out navigation

You are building a “fly-out navigation”. It opens on the side of the viewport and is positioned on top of other content while it is open. When the user opens it, is this the only thing they want to see? This one is tricky, I feel modal could work, non-modal could work too.

Summing up / conclusions

OK, so, in summary: modality of a component is a state in which only that component can be used. When something is modal, everything else is inert: blocked from access in any way, unfocusable and usually obscured with a backdrop. Making something modal is a substantial decision, it should be used sparingly. Dialogs can be modal or non-modal (also called modeless). popovers are being proposed by Open UI as a new way to build non-modal dialogs with a specific set of behaviours and characteristics, like top layer presence, JS-less toggleability and browser-provided light dismiss. Unlike <dialog>, a popover does not have a built-in role: as a developer, you can add the popover attribute to the semantically most relevant element (see my other post on which role to use with your popover).

Most of the UI patterns that are mentioned in this post fall under the definition of overlays: content that can lay on top of other content (all dialogs and popovers). A lot also fall under the definition of disclosures, when they are patterns where one thing opens another thing.

That's all! Yes, I wrote this whole long post about definitions, only to conclude a lot of these are indeed different words for the same patterns. But there's nuance. Hopefully this post has helped you more clearly distinguish some of these patterns.

My experience at Modern Frontends Live

2022-11-19T00:00:00Z

This isn't a post I wanted to write, but alas, sometimes not staying silent matters. This week I spoke at Modern Frontends Live in London. I was disappointed to see the organiser lied and misrepresented what they offered, as it impacted attendees, speakers and sponsors that were involved (financially and mentally).

I didn't want to name names either, but my judgment after interacting with her and a number of people I trust, I fear Gen Ashley, the organiser, might try it again, potentially under a different event name and/or try to hide what happened. To inform other attendees, sponsors and speakers, I want to be sure to share my experience.

Below I'll list the misrepresentations that I found specifically problematic. Other writeups are available from Jo Franchetti, Cassie Evans, Kent C. Dodds, Todd Libby, Chris Perry, Mike Hartington, JD Hillen, Dylan Beattie, Niamh McCooey and Kilian Valkhof. There is also a video reflection from Tejas Kumar. Again, I don't think any of us intend to “pile on”, but speaking out matters, it shows that the issues aren't just one person's perspective.

First, some context (that shaped my thoughts on conferencing). I have been involved with Fronteers Conference for 5 years (until 2013), anything from sitting at registration and holding mics to curation, team chairing and organiser handbook author (writing down what PPK and Krijn largely shaped). I was also involved with CSS Day and Performance Now to help out with practical stuff like registration. I've also given over 50 talks. Long story short, I do notice stuff at events sometimes.

Second, not everything about the event was bad. I'm grateful the organisers put me in a decent hotel, served a tasty speaker's dinner and were friendly and treated me mostly with respect (but, for completeness, also broke promises to me, and treated others badly). I actually had a good time meeting friends, some for the first time. As a lot of my work is virtual, it was great to have lots of interesting conversations and relating to developers (my job is in developer relations), and to finally meet some of the Open UI and other W3C groups in person.

Wildly exaggerated attendee numbers

The conference website showed (and therefore promised) '3000+' attendees. There were a few hundred, to my best estimation. I asked Gen and the people manning the registration desk various times what the number of actual attendees was. She tried to dodge this question, said there were about 1000 tickets of which a number was free tickets, but she didn't know how many were attending as not everyone showed up.

Screenshot of the homepage taken on 19 November 2022, the day after the conference

Conference registration systems show numbers and these badges are sent to a printing company. Health and safety people and catering need to know these numbers too. It seems nearly impossible to not know how many badges or you have.

Either way, a few hundred is not a little bit less than 3000, it is 5-10% of what was promised.

It's okay if ticket sales don't go as expected. It's not okay to stay silent about it and have everyone only find out on the event day. A few hundred is a small-ish event, 3000 is a huge event. Sponsors count on numbers to make their spend worthwhile, attendees count on numbers to estimate with how many people they could network. As a speaker, I need correct numbers to decide too, as there are a lot of events and me and my employer (if it's for work) are mindful about where we go. I don't mind speaking to 10 or 1000 people, but the number is one of the things I use to decide, especially when considerable travel time is involved.

Payment taken for a non-existent livestream

Livestream tickets were sold, but there were not cameras. These tickets (£42) were still on sale during the event, while there were no cameras. It was framed as ‘technical issues’. I've seen a lot of livestream-related technical issues, but they usually involve at least the presence of cameras.

I found out while attending a session and accidentally scrolling my Twitter timeline, as one does. People had paid for a stream, got no information regarding how to access it. Friends wondered if there were even cameras. I looked around in the room, noticed none. Asked the technician, confirmed there were none in that room. I felt a little sick, assuming there must be a misunderstanding, left the room (sorry speaker) and went to check all other rooms. No cameras.

Then I confronted Gen. She laughed at the idea that people had assumed cameras were needed for a livestream. Why did we assume such a thing, she wondered, and said they had planned to livestream with Streamyard. Maybe a possibility in theory, but it was halfway the first day and it hadn't happened yet, nor did I as a speaker receive instructions around setting that up (and anyone I checked with had not either).

It's ok if the livestream you planned fails or even if the camera team you hired all got covid on the day. It's not okay to not communicate about that, or promise videos, as this tweet suggests they did:

Just got an email. “Due to technical issues, we will not be streaming live, unless it gets fixed soon.”

If not resolved, We will share recordings at a later date”

Posted by @ukF1dev on November 17 2022

To my knowledge, after a lot of pressure the organiser have promised the people who bought a ticket a refund and a free ticket to “next year's event”.

Broken travel arrangement promises

Some speakers were not paid for travel, others were promised. Some paid thousands from their own pockets. I can personally say two hotel nights were covered for me by the conference. Travel reimbursement was promised to be paid before the event, after many reminders I am still waiting for that.

Update (23 November 2023): it's a week after the event started and I've received reimbursement for my travel costs.

I firmly believe an event should pay speakers' travel expenses as a minimum. Getting there and staying there should be paid from the conference budget, because speakers are an essential part of the event. They attract attendees and spend a lot of time to prepare, speak and attend. Exceptions could include events that are free to attend or that are (actually, like, really) community driven. I love those events and am usually happy to make time for them. Exceptions should not include events that charge attendees in the hundreds and sponsors in the thousands.

Somewhat controversially and socialistically, I feel this should apply equally between speakers, and also apply to speakers who work for very rich employers. This helps avoid power imbalance in a couple of ways. I know some organisers take speakers whose employer pays the travel and it helps with the budget, and I get that, events can be very costly.

It's okay if you don't want to pay any of the speaker's travel expenses, but do it fairly. It's also okay if you get so much email that you miss one of a speaker's three reminders, but communication is important. In my case they kept sending me emails and DMs to ask me to boost their event, but meanwhile ignored my requests to pay what they promised to pay.

Venue represented wrongly

Under a “The venue” heading, the website showed an enormous wall to wall screen and a very large audience. This isn't what the venue looked like. I understand a marketing website wants to persuade, but the gap between what this photo shows and the actual main room is too large. Was I naive to assume this reflected reality? I don't know, the screens at View Source (2019) in Amsterdam or JSConfEU (2019) in Berlin were a bit like the one shown on this photo. It's quite large for a developer conference, but it happens.

Another screenshot of the homepage taken on 19 November 2022, the day after the conference

In her post, Jo Franchetti describes the venue in more detail.

Conclusion

Organising events is hard, lonely and stressful. I have a lot of respect for conference organisers, I have done it myself (not without many mistakes, believe me) and have friends who do still do it. So, by default, I cut organisers a lot of slack and have a lot of understanding for the many ways it could go wrong in. I believe in good intentions, generally anyway. I am also grateful for the things the conference did do right, thanks for that.

There were red flags from the start (from the accessibility and front-end of the website to the lack of communication), but those did not stop me from going. The issues that emerged during the event did make me regret somewhat, but all I could do then is still try to enjoy it and deliver interesting content for the attendees that paid to come.

The specific issues I've put in this post cross the line between honest mistakes and bad behaviour. They cross the line, because they consistute fraud (the livestream) and because they impact attendees, sponsors and speakers. The front-end community doesn't deserve this, and I'm worried for people new to the industry, who get may assume this is normal or ok. It's not normal. In the last year I've spoken at a number of events that had a very high bar to make it great for attendees, sponsors and speakers (shoutout to Beyond Tellerrand, JSConf Budapest and State of the Browser).

In any case, if you were at the event, I encourage you to speak up, too.

Originally posted as My experience at Modern Frontends Live on Hidde's blog.

[email protected]?subject=Reply%20to:%20My experience at Modern Frontends Live">Reply via email

ACT Rules CG published implementations

2022-12-05T00:00:00Z

The ACT Rules Community Group (CG) writes testing rules for accessibility standards conformance. In the process, they find consensus in interpretation issues. This week, the CG published an “Implementations” page that shows these rules are not used in just one place, but in many: from manual methodologies to semi-automated (axe DevTools) and automated (axe-core, Alfa, Qualweb and more) tools.

Before going into why this is great, I will give some context. Accessibility standards like WCAG define criteria to conform with, they help makers of websites understand what a web without barriers means in practice. For instance, in WCAG, it means colours have sufficient contrast, pages have titles, buttons have names, and so on. In WAI-ARIA, it means elements with a cell role must be contained in or owned by an element with the row role, to name just one example. These, and all other requirements (“MUST”s) in standards, are testable requirements. This makes testing basically the process of finding out if you meet the standards (you, a product, a browser, a tool, an assistive technology, etc). It is a great lens to view accessibility through. and definitely a lens I use a lot when teaching.

But if you ever speak about the same issue with multiple accessibility specialists, you'll find that there can be differences in interpretation of these standards (see also: The Accessibility Interpretation Problem by Glenda Sims and Wilco Fiers). One way to avoid interpretation issues would probably be to have thousands of success criteria WCAG that allow for zero interpretation, but that imaginary world would be a much worse world. Instead, agreeing on how to test might be the best option we have.

The ACT Rules Community Group brings together makers of tools and other stakeholders to make testing accessibility standards more consistent, by finding agreement. They then write rules according to a format they specified. The rules that apply specifically to WCAG are also reviewed by AGWG, the group that produces WCAG.

This is tedious work and I, for one, am very pleased to see these rules now have implementations across different methodologies and tools. We'll probably see them more and more in the wild (I know I will in some tools I use). Congrats, Community Group, and keep up the great work!

Originally posted as ACT Rules CG published implementations on Hidde's blog.

[email protected]?subject=Reply%20to:%20ACT Rules CG published implementations">Reply via email

Mostly on Mastodon

2022-12-12T00:00:00Z

I'm mostly on Mastodon now (I'm @hdv). What I mean by that I try and keep up with what people share on their Mastodon timeline and no longer do so on Twitter.

In the past weeks, I've gone to “mostly Mastodon” from “partially Mastodon and partially Twitter”. I did join a Twitter Space and still post every now and then, but it feels increasingly uncomfortable. I also monitor DMs, but will give out iMessage/LINE/Signal info to any mutual who wants a better way to contact me.

I wrote about reasons to leave Twitter earlier, new reasons pile up:

a lot of the people I care about are now on Mastodon or stopped posting on Twitter (yay)
quality matters more than quantity
Mastodon has open ways to syndicate your content (it's been long since Twitter had open APIs)
Twitter is mostly ChatGPT screenshots these days anyway (only partially kidding)
the new owner tweets a lot about “woke” as if it is a bad thing
the new owner doesn't seem to understand basic concepts like truth and free speech, but, and this is my main issue, continues to make bold claims about them, while running and making decisions about Twitter
the new owner spreads misinformation including about public health, again, while running and making decisions about Twitter

So, I'm mostly not spending time on Twitter.

I'm mostly on Mastodon, instead. What does that mean? I post there primarily and only occassionally (and manually) cross-post to Twitter. I consciously choose Mastodon when engaging with cross-posted tweets, sometimes this means looking up a toot-version of a tweet, which is a bit of a nuisance, but fine. I've put my Mastodon presence on slide decks instead or in addition to Twitter, and added it to the footer of posts.

Maybe you wonder why I don't just go, why I share all this? Touché. Well, it's been a non trivial decision for me, after decades on Twitter and making lots of connections there, the start of many professional and not-so-professional relationships and friendships. I can imagine it's the same for you. If you're reading this and are still mostly on Twitter, may I ask you to consider spending more time on Mastodon? It isn't as hard to use as sceptics make it out to be. Together we impact which place is more worthwhile.

Originally posted as Mostly on Mastodon on Hidde's blog.

[email protected]?subject=Reply%20to:%20Mostly on Mastodon">Reply via email

2022 in review

2022-12-26T00:00:00Z

With only a few days left 2022, I wanted to review some of my 2022, including speaking, reading, music, writing and travel. Let's go!

Note: like in 2021, 2020, 2019, 2018 and 2017, in this public post I mostly sum up “highlights“, stuff I liked about the year etc. Of course, life is more complex and less structured than posts like this make it out to be.

Work

From February, I started working full time at Sanity.io, we focus on making content management pleasant for everyone involved. I'm in the developer relations team, with a focus on things like documentation, starters, videos and workshops. The problems are intriguing, they are both technical (like real time multiplayer content editing) and organisational (like cross functional collaboration). I'm enjoying being in a place where I can learn a lot and contribute a lot of my experience at the same time. I feel lucky with great colleagues. Some things we released this year: Sanity Studio v3 (customisable SPA to edit content), GROQ 1.0 (language to query content) and an /accessibility page following an accessibility review of Sanity Studio.

This year I did only minimal accessibility consulting. including reviews and presentations for UWV, a Dutch governmental organisation focused on employment and unemployment, DigiD, the Dutch digital government identity and MDN/Mozilla.

I am also still involved in Open UI CG, where I try to learn and contribute: I scribe sometimes, join discussions where I can and talk about the work at events. This year, we got a lot done on <selectmenu> and popover. See my posts on customisable selects and dialogs vs popovers.

Speaking

This year had many more in person events, and I have loved speaking in person at JSConf in Budapest, EuroIA in Marseille and State of the Browser in London. Most talks were about accessibility, some about CSS, HTML and content.

In 2023 I want to talk about the nitty gritty of building popovers and the power of systems that use composability as design principle (see the Speaking page).

These are the talks I did in 2022:

The Next Web on why that's not “Web3” for SendCloud (remote)
A toolkit for web accessibility on the “toolkit” edition of Beyond Tellerrand's Stay Curious event (where Stephanie presented her awesome toolkit for CSS) (remote)
It's the markup that matters at JSConf Budapest and Modern Front-ends Live
Shifting left, or: making accessibility easier by doing it earlier at DevOps Amsterdam (remote), the Sanity July meetup (remote) and State of the Browser
Editor experiences that your team will love, a workshop, at React India (remote) and React Summit Amsterdam (remote)
More to give than just the div: semantics and how to get them right at Frontmania
Your CMS is an accessibility assistant at IAAP-EU (remote)
Cross-functional collaboration for structured content, a workshop at EuroIA and Structured Content Conference, developed by my colleague Carrie Hane, co-facilitated by my colleague Simeon Griggs
Styling selects? You've got options!, a lightning talk at CSS Day + CSS Café

Reading

In total, I read about 30 books this year, still a mix of physical, ebooks and audiobooks.

On technology, I loved Blockchain chicken farm by Xiaowei Wang. “Hustle culture” isn't just a Silicon Valley thing, it's there in rural China. From “e-commerce villages” that solely focus on producing for Taobao to free range chicken on the blockchain (of course it added no value). Awesome mix of technology, travels, encounters, food and how the world and life works from an original thinker. Original thinking was also in Ways of being by James Bridle, about artificial intelligence, ecology and the relationship between the humans and the ‘more than human’ world. He critiques the idea that the world, all of the world, can be computed and represented in data points. He shows why that would be a limited way of thinking. It's a little vague sometimes, according to Cory Doctorow that's because the book argues against crisp articulations themselves.

Two books I liked about identity and cultures were Takeaway and If I surivive you. Takeaway by Angela Hui is about what it's like to grow up in rural Wales when your parents run a takeaway. Often entertaining, often touching tale of family relationships, finding identy and racial abuse. Food is a central theme too, the recipe each chapter ends with was a nice touch. I found If I survive you, by James Escoffery, a very well written collection of short stories about a Jamaican family in America, about existing between two cultures, capitalism and being black in America.

I also thoroughly enjoyed Erasmus: dwarsdenker a biography of the philosopher/theologician Erasmus (in Dutch). Didn't know Erasmus spent lots of time begging patrons to fund him, so that he could write, travelled a lot (UK, Germany, Belgium and France, by horse and ship), got ‘jobs’ in the church that came with a livelong salary without requiring him to actually do the job (this was a thing at the time, Erasmus had his in Aldington, UK and Kortrijk, Belgium) and Erasmus had criticasters who published their criticisms anonymously and circulated lists of criticisms on his New Testament, mixed with gossip about his life and history. Glad we don't do any of that anymore. Oh wait…

Music

This year I listened a lot to:

Kendrick Lamar's new album Mr Morale and the Big Steppers, which was my first introduction to his music and got me ready to explore all the earlier albums that everyone had been raving about. A colleague recommended the Dissect podcast, which explains To Pimp a Butterfly track by track in hour long episodes.
Nubya Garcia's Source remix album: saw her live in Rotterdam and have had her Tiny Desk and BBC Proms (posted last month) gigs on repeat
WIES, Froukje, Joost Klein and Hang Youth: there has been a resurge in Dutch artists performing in Dutch (English has been more common), loved the Bandje pun on the Dutch Prime Minister's dismissive attitude towards the performing arts and ‘Met je Ako ideologie’ on getting one's world view from the train station's best selling non fiction (not making this up)
Robert Glasper's Black Radio 3 was my favourite album, where jazz and hiphop meet. Beautiful spoken word on a Radiohead-esque melody in the opening track and lots of collaborations with people like Esparanza Spalding and A Tribe Called Quest's Q-Tip (on one track) throughout.

Writing

I finally added some more useful categories to this blog, moved to a veey short domain (it's just hidde.blog) and published about 30 posts this year. I'm most happy with:

Dialogs, modals and popovers seem different: how are they different: a deep dive into these common patterns, with many thanks to Adrian Roselli and Scott O'Hara for their review help
“That's not accessible!” and other statements about accessibility
ATAG: the standard for the accessibility of content creation, I learned a lot about ATAG while I was at W3C and this was my personal plain language version
The web doesn't have version numbers, the industry continued to surprise me with its dreams of making everything about money and ‘on’ an inefficient database (I'm also feel the ‘metaverse’ is a non-sensical investment)

Cities

San Francisco, Budapest, Düsseldorf, Cologne, Oslo, Paris, Marseille, London (5 times), Brighton, Antwerp, Lille, various towns in Normandy and Taipei.

It's especially been nice to meet international internet friends in person, many for the first time, like Nicole, Tantek, Yulia, Vadim, HJ, Adam, Una, Gift, Adrian, Manjula, Ana, Jeremy, Michelle, Mu-An, Bruce, Andy, Sophie, Léonie, Anuradha, Jhey and Patrick. Plus almost all of my colleagues.

Conclusion

That's all for this year, thanks all for reading my posts, liking subcribing, disagreeing via email, everything! If you've posted a year in review, let me know, I'd love to read it!

Originally posted as 2022 in review on Hidde's blog.

[email protected]?subject=Reply%20to:%202022 in review">Reply via email

Data-informed flex-grow for illustration purposes

2023-01-13T00:00:00Z

I have this web page to display the books I've read. Book covers often bring back memories and it's been great to scroll past them on my own page. It's also an opportunity to play around with book data. This week, I added a bit of page count-based visualisation for fun.

This is what it looks like: rectangles with colours based on book covers. Each relates to a specific book, and its size is based on that book's page count.

What's flex-grow?

Flex grow is part of the CSS's flex layout mode. When you add display: flex to a HTML element, it becomes a flex container, and with that, its direct children become flex items. Flex items behave differently from block or inline level children. The difference is that flex items can be layed out in a specific direction (horizontal or vertical) and sized flexibly. This system is called “flexible layout box model” or simply flexbox. It comes with sensible defaults as well as full control via a range of properties.

One of those properties is flex-grow. This is what it does:

[flex-grow] specifies the flex grow factor, which determines how much the flex item will grow relative to the rest of the flex items in the flex container when positive free space is distributed

(from: CSS Flexible Box Layout Module Level 1)

So let's say you have ten spans in div, where the div is a flex container and the spans flex items:

If you want one to proportionally take up double the space and another to take up triple the space, you'll give them a flex-grow value of 2 or 3, respectively:

/* item 2 */
span:nth-child(2) {
  flex-grow: 2; /* takes up double */
  background: crimson;
}

/* item 6 */
span:nth-child(6) {
  flex-grow: 3; /* takes up triple */
  background: cornflowerblue;
}

The others will then each take up one part of the remaining space (as if set to 1):

The specification recommends generally using flex instead of flex-grow. This shorthand can take three numbers: a flex-grow factor (how much should it be able to grow), flex-shrink factor (how much should it be able to shrink) and a flex-basis factor (what size should we start with before applying grow or shrink factors.

We can also give flex just one positive number, to use that number as flex-grow, and a default of “1” as flex-shrink and “0” as the basis (meaning no initial space is assigned, all of the size is a result from the grow or shrink factor). In our case, we'll use that flex shorthand, it's a sensible default.

Flex-grow for widths, aspect ratio for heights

My sites displays, like, 50 books for a given year. Each with a different amount of pages. Some are just over 100 pages, others are over 500. I wanted to use that number as the flex-grow factor. This means some books claim space of 113, others claim 514:

[a-113-page-book] {
  flex: 113;
}

[a-514-page-book] { 
	flex: 514;
}

So that will claim 113 worth of space for the one book and 514 worth of space for the other. I used little magic for this, I just applied an inline style attribute to each book in my template (Nunjucks), setting flex dynamically. When they all have a number, they all take a proportion, and when all the numbers are similar amounts, you'll see that the size they take up is quite similar, except for a few outliers.

As mentioned above, these numbers represent a proportion of the total available space. You might wonder: which space? Flexbox can work in horizontal and vertical direction. Or, really, in inline and block direction, where inline is the direction in which inline elements appear (like em, strong) and block the direction in which block-level elements appear (eg paragraphs and headings).

Flexbox only takes space in one direction. For my illustration, I used the default, which is the inline direction or flex-flow: row (this is shorthand for a flex-direction: row and flex-wrap: nowrap). This means my flex-grow values are about a proportion of “inline” space, in my site's case, this means horizontal space.

I also want each book to take up some vertical space, as with only a width, we would not actually see anything. I could set a fixed height (in fact, I did that for the screenshot above). But in this case, I want the height to have a fixed relationship to the width. The aspect-ratio property in CSS is made for that: if an item has a size in one dimension, the browser figures out what the other dimension's size needs to be to meet a ratio you provide. In this case, the browser finds a height based on the width that it calculated for our proportion.

Ok, so let's add an aspect ratio:

.book {
  /* flex: [set for this book as inline style] */
  aspect-ratio: 1 / 4;
}

I also added a background-color that I have available in my template (it's a piece of image metadata that I get for free from Sanity).

Oh, but wait… they still have the same height! That's because by default, items are aligned to ”stretch”, they take up all available space in the opposite direction (block if items flow in inline direction, inline if items flow in block direction). When items stretch, remaining space is assigned back to them. In this case, that means they'll get the same height. Often super useful and quite hard to do pre-flexbox. But in this case, we don't want that, so we'll use align-items to set our items to align at the “end” (also can be set to “start”, “center” and “baseline”):

What the books looks like for different values of align-items

In my case, I also added a max-width to avoid extreme outliers and I addded opposite rotate transforms to even and odd items for funs:

.book {
  transform: rotate(-2deg);
}
.book:nth-child(odd) {
  transform: rotate(2deg);
}

This works with grids too

When I shared this, Vasilis rightly noted you could pull the same trick with grids. If you add display: grid to an element it becomes a grid container and its children grid items. That sounds a lot like flexbox, but the main difference is that sizing isn't done from the items, it is done from the container. For a grid, you define columns (and/or rows) that have a size. The fr is one of the units you can use for this, it's short for “fraction”. Pretty much like proportions in flexbox, fr will let you set column/row size that is a proportion of the available space. If you set all your columns with fr, each one will be a proportion of all available space in the relevant direction.

Summing up

I usually use flexbox with much lower numbers, often under 10. But it turns out, it works fine with larger numbers, too. I have not done extensive performance testing with this though, there may be issues if used for larger sites with more complex data.

Originally posted as Data-informed flex-grow for illustration purposes on Hidde's blog.

[email protected]?subject=Reply%20to:%20Data-informed flex-grow for illustration purposes">Reply via email

Browser built-in search and ATAG A.3.5.1

2023-01-27T00:00:00Z

The Authoring Tool Accessibility Guidelines (ATAG) are guidelines for tools that create web content. While reviewing this week, I wondered if the Text Search criterion (A.3.5.1) is met as soon as users can use browser built-in search. You know, Ctrl/⌘ + F. Turns out: yes, if the tool is browser-based and the UI contains all the necessary content in a way that CTRL+F can find it.

Let's look into a bit more detail. The criterion requires that text content in editing views can be searched:

A.3.5.1 Text Search: If the authoring tool provides an editing-view of text-based content, then the editing-view enables text search, such that all of the following are true: (Level AA)

(a) All Editable Text: Any text content that is editable by the editing-view is searchable (including alternative content); and
(b) Match: Matching results can be presented to authors and given focus; and
(c) No Match: Authors are informed when no results are found; and
(d) Two-way: The search can be made forwards or backwards.

(From: ATAG 2.0)

True accessibility depends on a combination of factors: browsers, authoring tools, web developers and users—they can all affect how accessible something is. ATAG is about authoring tools specifically, so my initial thinking was that for an authoring tool to meet this criterion, it would need to build in a text search functionality.

However, reading the clauses, it sounded a lot like what Ctrl + F/Cmd + F in browsers already facilitate. Great news for authoring tools that are browser-based (sorry for those that are not). Browser built-in search finds all visible text in a page (as well invisible text in details/summary browsers), matching results are presented, “no match” is indicated and search works two ways. It doesn't find alternative text of rendered images, but if you have text input for alternative text, it finds the contents of that.

In Chromium, when the “hidden” part of a details/summary contains the word you search for, it goes to open state (this is per spec, but Firefox and Safari don't do this yet)

Note: in screenreaders, the experience of in page search is not ideal. I have not tested extensively and am not a screenreader user myself, but quick tests in VoiceOver + Safari and VoiceOver + Firefox indicated to me that one can't trivially move focus to a result that is found and “no match” is not announced, it needs cursor movement to find. This seems not ideal, but again, I am not a screenreader user and may be missing something.

All in all, the in-browser seems to satisfy the requirements. Lack of matches is indicated (though not announced) and matches can be given focus (though the browser doesn't do it; not sure how that would work either as the matches will most likely not be focusable elements so that would be a bit hacky and it would not solely have advantages). These caveats are accessibility issues. I feel they'd be best addressed in browser code, not individual websites/apps, so that the solution is consistent.

Ok, so if the browser built-in search meets the criteria, let's return to the question I started with: should an authoring tool merely make sure it works with built-in search, or should it implement its own in-page search?

The unanimous answer I got from various experts: yes, in this case the browser built-in is sufficient to meet the criterion. It also seems reasonably user friendly and likely better than some tool-specific in-page search (but note the caveats in this post, especially that all alternative text would need to be there as visible text). Of course, most authoring tools have more search tools available, e.g. to let users search across all the content they can author. In today's world, they seem like an essential way to complement in-page search, especially as a lot of authoring tools aren't really page-based anymore.

Originally posted as Browser built-in search and ATAG A.3.5.1 on Hidde's blog.

[email protected]?subject=Reply%20to:%20Browser built-in search and ATAG A.3.5.1">Reply via email

200

2023-02-14T00:00:00Z

It's meta blogging time, because this is my 200th post. Vanity metrics, I know, but sometimes you've got to celebrate milestones. Even the merely numerical ones. When I wrote my 150th post two years ago, I described why I blog and what about. This time, I want to focus on how I do it and look at the subjects of the last 50.

A lot of posts start on my phone

There are plenty of tools for writing. Fancy physical notebooks, favourite text editors, and what not. I do use both, but usually I start a post on my phone. It somehow is my least distracting device, and very portable. My setup is that I have iA Writer, which I love for its radical simplicity and advanced typography, on my phone and computers. I've got a couple of folders that are synced through iCloud, including for posts and talk ideas. They are literally folders—iA Writer just picks them up and displays them as folders in their UI. When I start a post, I create a file. Sometimes it stays around for days, weeks or months, sometimes I finish a draft in half an hour.

When the post is almost ready, I'll usually do another round on a computer. This is essential if the post needs images or code examples, sometimes I can skip it if a post is just text. This is usually also the time when I start adding it into my website and reach out to people for feedback, if it's the kind of post that very much needs review.

Having my posts exist in a cloud service has been a game changer, because it means I can blog when inspiration strikes. When I used to go swimming, I would sometimes think up a blog post while in the water and write up a quick structure of first draft in the changing room or the cafe nearby. Sometimes I revise a draft when I sit on a tram or bus, or add some more examples when I arrived early for an appointment. Sometimes I return to it on a computer, then a phone, then a tablet.

As for the format: I use Markdown processed by Eleventy. I am aware of the disadvantages, but this is a one-person-who is-a-developer-and-very-comfy-in-a-text-editor blog kind of use case. Still, I am pondering re-introducing a CMS so that it can manage images and history in a way that doesn't involve me committing into git (who needs commits for typos?) or compressing images by hand.

Getting the words flowing

A friend asked how I manage to write on this blog regularly, alongside other responsibilities. I don't know the secret, but I can offer two thoughts.

Firstly, my writing is usually a way to clarify my thinking, it sort of defragments thoughts, if that makes sense. It doesn't really add much to the time I would need for defragmenting thoughts anyway, if anything it speeds that process up. If I spiral in circles about a subject, jotting my thoughts down helps me get out of that spiral. Sometimes the result is I find out I was very wrong, sometimes I get to a post I deem worthy of publishing and often I end up somewhere in between.

Secondly, I try and add ideas to drafts when they come up. Like, I had a file with ‘200’ in it for a while that eventually got a few bullets and then became this post. When I feel like making a thread on social media, I force myself to make a draft post here instead. Occassionally, like when I haven't written for a while, I'll go through the drafts. There isn't really a magic trick here either, it's a habit if anything. And I guess it helps words come to me naturally, like numbers do for others.

Thirdly, a bonus one: it helps me to keep things very simple and stay away from tweaking too many things (eg I only switched tech stack once in 15 years and kept the design roughly the same). I won't say I'm not tempted, I mean it is fun to try out new things and this blog is definitely a playground for me to test new Web Platform features, but I try and focus on the posts.

My 50 most recent posts

The cool thing about having your own blog is that it doesn't need to have a theme per se. Mine follows some of my interests and things I care about: the web, components and accessibility.

On web platform features, I wrote about spicy sections (out of date now as I updated my site and there are some different ideas and solutions for tabs on the web), selectmenu and dialogs.

As I used Eleventy more, I wrote about using it for WCAG reports and for photo blogging.

A lot of my posts were also about web accessibility, like this primer on ATAG, two posts about low-hanging fruit issues (part 1, part 2) , what's new in WCAG 2.2 and the names section of ARIA. These posts usually start because I had to give some advice in an accessibility audit report I wrote, or because I couldn't find a blog post sized answer to a question I personally had.

I also covered some events, like dConstruct 2022, documentation talks at JSConf and JSNation, Beyond Tellerrand 2021 and an on-stage interview with Cecilia Kang on her fascinating book An Ugly Truth. These kinds of posts help me process what I learned at the event. While I write, I usually look up URLs speakers mentioned or try out features they discussed, so it's a bit of experiencing the whole thing twice.

This year, I hope to write more about CSS and other UI features in the browser. I did one post about using flex-grow for my book site, but want to dive deeper into subjects like scroll snapping, container queries and toggles. Even if Manuel has already covered every single CSS subject ever in the last few months (congrats, my friend!). I also want to cover design systems and Web Components more. I have some other subjects in mind too, and am open to suggestions too, just leave a comment or slide in my DMs. Thanks for reading my blog!

Originally posted as 200 on Hidde's blog.

[email protected]?subject=Reply%20to:%20200">Reply via email

My ideal accessible components resource is holistic, well tested and easy to use

2023-03-08T00:00:00Z

It would be easier to have an accessible web if all we did with it was publish documents. Blobs of text, images here and there. But modern sites (or “applications”) do a lot more than documents. Often for better, sometimes for worse. To improve accessibility of the web as it is today, I feel we dearly need accessibility guidance that is holistic, well tested and easy to use.

Web sites or applications often come with menus, tooltips, dialogs, drag and drop, tabs and emoji pickers. Some say this is unnecessary and argue interfaces must be simpler. Sometimes they are right—a lot of interfaces can benefit from being simpler. Yet, complex UI components are often genuinely helpful to users. Like, it's good if not all information is always visible at the same time. Hiding less important stuff in less prominent places can help hierarchy. It can be good if, instead of selecting a city from a <select> of thousands, there's some comboboxing going on. ‘No that's an input!’, you say… yeah, maybe, but it could be important for the business to have a city chosen out of a predefined list of options. And that can give certainties that are beneficial to users too.

So, complex UI patterns (widgets, components, etc) are sometimes needed. A lot of sites have them, for reasons ranging from good to bad. A lot of organisations hand-build these components as part of a design system effort, to make their investments reusable. Reusable components can have a huge impact on accessibilility. Because reuse means repetition: of good patterns, bad patterns, accessible patterns, inaccessible patterns… the stakes are high!

Over the years I've seen and heard a lot of developers talk about building components. I heard them speak about the developer experience of building these components. When I was working on guidance at WAI, I listened extra carefully. From what I gathered, many actually want to truly invest in the quality of their components, including the accessibility of those components. But the official guidance they can find is lacking: WCAG's supporting documents are often unclear (with reading levels, for what they are worth, up to professor grade), unpractical (a lot more words than concrete advice) and outdated (eg still recommending the title attribute). WCAG still works best for the web as a series of documents.

In other words, to better match the realities of people making websites, I feel the W3C's accessibility guidance should be more holistic, well-tested and easy to use.

Holistic

The closest to a guide on building accessible components is the ARIA Authoring Practices Guide (“APG”). It's a super useful resource for finding how to build components with ARIA, but it isn't “holistic”.

By holistic advice, I mean advice that considers the reader within their entire environment as a developer. Advice that builds on the best that can be done with HTML, CSS, JavaScript, WAI-ARIA and SVG (technologies websites commonly rely upon). The WAI-ARIA Authoring Practices Guide isn't holistic in that sense: it focuses on patterns built with ARIA only. From developer-who-wants-advice or user-who-needs-a-good-experience perspectives, that's not ideal. As accessibility specialists learn again and again, WAI-ARIA isn't what makes components accessible, it's merely one of the languages (ok, an ontology) that can help us build accessibly (see also: the first rule of ARIA). I don't mean to say any of these specificiations is inherently better, I mean the most accessible component is always some combination of these specs.

If that's the case, you may wonder, why does APG focus on ARIA only? There's no bad intent here… I think it is simply because it is written by a subgroup of the ARIA Working Group. That Working Group specifies ARIA and it has a deliverable to show how to use it. This makes good sense. But again, it isn't ideal if the intention is guidance that helps developers build the very best for users with disabilities (which I think is the goal we should really want to optimise for). Nobody seems to have that as a deliverable.

There is a W3C/WAI resource that is holistic in the way I described: WAI Tutorials. Shoutout to the great work of Eric Eggert and EOWG! It's a good resource, but it did not get expanded or updated much after the initial release.

There are resources outside of W3C/WAI that I can recommend, such as:

Sarah Higley's posts on tooltips and custom selects
Sara Soueidan on icon buttons and custom checkboxes/radiobuttons
Accessible Components by Scott O'Hara
Adrian Roselli's “Under-Engineered” series
A complete guide to accessible front-end components by Vitaly Friedman

Well tested

Web accessibility ultimately is about whether people can use a thing. Some friends in the accessibility community like to emphasise that it's about people, not meeting standards. I get that sentiment, but there's a false dichotomy at play: making the web more usable for people with disabilities is a central goal for accessibility standards at organisations like W3C/WAI) They are a means to the same end. Either way, web accessibility is all about people. So, yes, user testing matters. We've got to find out which specific patterns are mostly to work well for people.

While it's essential and beneficial to involve people with disabilities in user tests, there can be challenges:

just like one single user doesn't speak for all users, one person with a disability doesn't speak for everyone with that disability; you'll want larger samples;
there are many disabilities; sometimes people with different disabilities could even have “competing” needs. For instance, high contrast benefits some, but could constitute a barrier to others;
it may be more difficult to recruit users with disabilities and ensure the group you recruit for a given project is the right group in terms of what you want to test;

My friend Peter has documented some of his approach to testing with disabled users and WAI itself has a great page on involving users with disabilities too. Others have blogged about their user testing efforts: Fable tested Loom's video clipping functionality and the GOV.UK Design System team documented what they found testing conditionally revealing questions. These posts show there is a lot of nuance in determining if a complex pattern is accessible. But they also show this nuance can be described and help inform people.

As an aside: another aspect of testing guidance for accessible components is how well they perform across different browsers and assistive technologies. Bocoup, Meta and others are doing great work in this area in the ARIA-AT effort: they define tests (over a thousand drafted), but also pioneer ways to test assistive technologies automatically. I believe the plan is (was?) to show the results of this project next to code examples, which is great.

Easy to use

‘Developer experience’ is a phrase sometimes frowned upon, especially when contrasted with user experience. If we had to choose between them, of course, user experience would be the first choice. But the choice isn't binary like that. If the stars are aligned, one can lead to the other. Companies that make developer-focused products (like CMSes, versioning control, authentication, payment providers, databases etc) usually have a dedicated “developer experience” department that ensures developers can use the product well. Among other things, they try to reduce friction.

Friction could result in income loss for these companies. If the tool constantly displays unhelpful error messages, has code examples that are tricky to follow or documentation that is out of date, developers might look for a different tool. And the opposite is true too: if this payment provider makes it super easy to implement secure payments, a developer will likely want to use it again.

Friction could also cause a product to be “used wrong”. For instance, large groups of developers easily got started with this cool new authentication product, but the docs were so unclear that they missed important security steps? Or, in a CI/CD product, developers manage to get started quickly, but a majority does it in a way that uses way too many resources, because the example projects do? If the company charges overages unexpectedly, it may upset customers, if it doesn't, it could end up costing the company too much.

I'll admit it is a bit of a stretch: what if both of these frictions are at play with accessibility standards? And instead of looking for different standards, developers choose the “easier” route of inaccessibility? This could happen in places where leadership or organisational procedures don't enforce accessibility. They'll get away with it. It could also happen in places that do have a mature accessibility program or even a handful of accessibility-minded individual developers. If the most accessible solution isn't easy to learn (e.g. they get lost between different kinds of guidance), it could still result in inaccessibility, even with the best intentions.

I believe effective accessibility guidance answers “how easy will this make it for people to get it right”, and probably also ”how will this avoid that people take the wrong turn”.

Some examples of what could constitute good developer experience (dreaming aloud here):

easy to copy examples that closely match real-world components people are building, like privacy setting banners and comboboxes (just to name two examples of major barriers I saw blind users encounters in a user test)
full example projects for some popular frameworks and languages, eg here's how to build an accessible blog with Next.js, or how to report errors in a form in vanilla JS + 5 popular frameworks
a specific focus on eliminating inconsistencies in documentation (“boring” work, maybe, but inconsistencies inevitably creep into any set of content—the more inconsistencies are avoided, the more effective documentation is)

While these examples are developer focused, the same kind of focus could be applied other roles like quality assurance and design (see also Roles involved in accessibility, which is a great document, though still in draft status).

I suspect many people with disabilities among us have a mental list or accessibility barriere they encounter most often. Many who do regular accessibility audits will have a list of things they find often. Many developers will have a list of components they are unsure how to build accessibly. Et cetera, et cetera. If I had a magic wand, I would try and put all of these people in one room.

In summary

In this post, I've tried to lay out what my ideal accessibility guidance looks like. The gist of it is: make it easier for people to get accessibility right. And the opposite, too: make it harder to get it wrong. I feel the closer we can get to that, the more accessible interfaces can become. I think this is the way to go: guidance that is holistic, well-tested and optimised for developer experience (or, more broadly, the experience of anyone touching web projects in a way that can make or break accessibility).

And to be clear, this is not an invite for people to care less or circumvent the responsibilities and duties they have. Accessibility needs to be part of one's MVP. But it is an invite for people to rethink our collective efforts in improving web accessibility: WCAG 3.0 may not be it, the world may benefit more from better guidance than from better testing methodologies.

My expectations are probably a tad unrealistic. I probably missed my chance to try and materialise them more when I worked for WAI. Yet, I hope the perspective is helpful to some. Get in touch if you have thoughts!

Originally posted as My ideal accessible components resource is holistic, well tested and easy to use on Hidde's blog.

[email protected]?subject=Reply%20to:%20My ideal accessible components resource is holistic, well tested and easy to use">Reply via email

Neither artificial, nor intelligent

2023-03-30T00:00:00Z

Large Language Models (LLMs) and tools based on them (like ChatGPT) are all some in tech talk about today. I struggle with the optimism I see from businesses, the haphazard deployment of these systems and the seemingly ever-expanding boundaries of what we are prepared to call “artificially intelligent”. I mean, they bring interesting capabilities, but arguably they are neither artificial, nor intelligent.

Let me start with where I'm coming from. In 2008 I started studying for a degree called Cognitive Artificial Intelligence. Of a number of Dutch universities offering degrees in artificial intelligence, mine was the one most focused on psychology and philosophy. Others were more geared towards linguistics and/or computer science. We had courses all across these different fields, as well as mathematics. This made it super interesting. Case in point: I learned then that artificial intelligence, as a field, isn't easily defined. It comprises a lot of things. It attracts people with a wide range of interests. And it has all sorts of applications, from physical robots to neural networks and natural language processing. Towards the end of the first year, I realised I had different interests (primarily in philosophy) and skills (not a programmer by heart, or a mathematician, and my grades and a BSA agreed). I ended up switching to philosophy full time, specialised in AI, language and ethics (of course, philosophy is great for generalists, too).

Fast-forward almost 15 years… my knowledge at this point is a bit rusty, but I am not less interested in the subject. Today, there is a lot of hype around Language Models (LMs), a specific technique in the field of “artifical intelligence”, which Emily Bender and colleagues define as ‘systems trained on string prediction tasks’ in their paper ‘On the dangers of stochastic parrots: can language models be too big?’ (one of the co-authors was Timnit Gebru, who had to leave her AI ethics position at Google over it). Hype isn't new in tech, and many recognise the patterns in vague and overly optimistic thoughtleadership (‘$thing is a bit like when the printing press was invented’, ‘if you don't pivot your business to $thing ASAP, you'll miss out’). Beyond the hype, it's essential to calm down and understand two things: do LLMs actually constitute AI and are what sort of downsides could they pose to people?

Artificial intelligence, in one of its earliest definitions, is the study of things that are in language indistinguishable from humans. In 1950, Alan Turing famously proposed an imitation game as a test for this indistinguishability. More generally, AIs are systems that think or act like humans, or that think or act rationally. According to many, including OpenAI, the company behind ChatGPT and Whisper, large language models are AI. But that's a company: a non-profit with a for-profit subsidiary—of course they would say that.

Not artificial

In one sense, “artificial” in “AI” means non-human. And yes, of course, LLMs are non-human. But they aren't artificial in the sense that their knowledge has clear, non-artificial origins: the input data that they are trained with.

OpenAI stopped disclosing openly where they get their data since GPT-3 (how Orwellian). But it is clear that they gather data from all over the public web, places like Reddit and Wikipedia. Earlier they used filtered data
from Common Crawl.

First, there is the long term consequences for quality. If this tooling results in more large scale flooding the web with AI generated content, and it uses the contents of that same web to continue training the models, it could result in a “misinformation shitshow”. It also seems like a source that can dry up once people stop asking questions on the web to interact directly with ChatGPT.

Second, it seems questionable to build off the fruits of other people's work. I don't mean off your employees, that's just capitalism—I mean other people that you scrape input data from without their permission. It was controversial when search engines took the work from journalists, this is that on steroids.

Not intelligent

What about intelligence? Does it make sense to call LLMs and the tools based on them intelligent?

Alan Turing

Alan Turing suggested (again, in 1950) that machines can be said to think if they manage to trick humans such that ‘an average interrogator will not have more than 70 per cent chance of making the right identification after five minutes of questioning’. So maybe he would have regarded ChatGPT as intelligent? I guess someone familiar with ChatGPT's weaknesses could easily ask the right questions and identify it as non-human within minutes. But maybe it's good enough already to fool average interrogators? And a web flooded with LLM-generated content would probably fool (and annoy) us all.

Still, I don't think we can call bots that use LLMs intelligent, because they lack intentions, values and a sense of the world. The sentences systems like ChatGPT generate today merely do a very good job at pretending.

The Stochastic Parrots paper (SP) explains why pretending works:

our perception of natural language text, regardless of how it was generated, is mediated by our own linguistic competence

(SP, 616)

We merely interpret LLMs as coherent, meaningful and intentional, but it's really an illusion:

an LM is a system for haphazardly stitching together sequences of linguistic forms it has observed in its vast training data, according to probabilistic information about how they combine, but without any reference to meaning: a stochastic parrot.

(SP, 617)

They can make it seem like you are in a discussion with an intelligent person, but let's be real, you aren't. The system's replies to your chat prompt aren't the result of understanding or learning (even if the technical term for the process of training these models is ‘deep learning’).

But GPT-4 can pass standardised exams! Isn't that intelligent? Arvind Narayanan and Sayash Kapoor explain the challenge of standardised exams happens to be one large language models are good at by nature:

professional exams, especially the bar exam, notoriously overemphasize subject-matter knowledge and underemphasize real-world skills, which are far harder to measure in a standardized, computer-administered way

Still great innovation?

I am not too sure. I don't want to spoil any party or take away useful tools from people, but I am pretty worried about large scale commercial adoption of LLMs for content creation. It's not just that people can now more easily flood the web with content they don't care about just to increase their own search engine positions. Or that the biases in the real world can now propagate and replicate faster with less scrutiny (see SP 613, which shows how this works and suggests more investment in curating and documenting training data). Or that criminals use LLMs to commit crimes. Or that people may use it for medical advice and the advice is incorrect. In Taxonomy of Risks Posed by Language Models, 21 risks are identified. It's lots of things like that, where the balance is off between what's useful, meaningful, sensible and ethical for all on the one hand, and what can generate money for the few on the other. Yes, both sides of that balance can exist at the same time, but money often impacts decisions.

And that, lastly, can lead to increased inequity. Monetarily, e.g. what if your doctor's clinic offers consults with an AI by default, but you can press 1 to pay €50 to speak to a human (as Felienne Hermans warned Volkskrant readers last week)? And also in terms of the effect of computing on climate change: most large language models benefit those who have the most, while their effect (on climate change) threatens marginalised communities (see SP 612).

Wrapping up

I am generally very excited about applications of AI at large, like in cancer diagnosis, machine translation, maps and accessibility. And even of capabilities that LLMs and tools based on them bring. This is a field that can genuinely make the world better in many ways. But it's super important to look beyond the hype and into the pitfalls. As a lot of my feed naturally have optimist technologists, I have consciously added many more critical journalists, scientists and thinkers to my social feeds. If this piques your interest, one place to start could be the Distributed AI Research Institute (DAIR) on Mastodon. I also recommend the Stochastic Parrots paper (and/or the NYMag feature on Emily Bender's work). If you have any recommend reading or watching, please do toot or email.

Originally posted as Neither artificial, nor intelligent on Hidde's blog.

[email protected]?subject=Reply%20to:%20Neither artificial, nor intelligent">Reply via email

Back to freelance

2023-05-10T00:00:00Z

I have returned to working as an independent front-end / accessibility / devrel person. My first project will be at the Dutch government's NL Design System team.

Leaving Sanity

I recently left Sanity, where I worked in the developer relations team. After doing some “developer relations”-like work at the W3C/WAI, this was my first full-time role in the space. I loved the variety: I could create tutorial videos, improve onboarding, facilitate content design workshops, help with meetups, inspire people to structure their content (more abstract than HTML) and just generally try to make complex stuff easier to understand. Among people I liked and bonded well with… how lucky I got!

It was also an opportunity for me to leave accessibility as my primary focus, at least for a while, and broaden my horizons. Well, leave accessibility as my primary focus… though my manager at WAI had warned me about this, calling it a bit of a Hotel California situation. He was, of course, correct. At Sanity, I did spend more time in the React community, learned lots about modern tooling and challenges like real-time content management. But I also ended up as the resident accessibility go-to person and did a preliminary accessibility conformance evaluation of the core product. It was appreciated, and I, in turn, appreciated having curious and dedicated colleagues to work with.

New beginnings

Having said that, my job at Sanity stopped existing. After some explorations, I'm going back to be a freelancer / independent. I've worked in that capacity for about 15 years, it feels like a comfort zone. I also have a very exciting project to start with, that manages to combine a number of my previous interests: developer relations, web accessibility and designs systems.

NL Design System

This month, I'm joining the NL Design System core team. This project doesn't just create a design system for use by Dutch government, it creates a space for collaboration on front-end components in the open. This is the sensible thing to do, because there are a lot of Dutch government websites and services (in the tens of thousands). Many of those have their own design systems, suppliers and ways of working. But they all need to meet the same accessibility standards and there is a lot of overlap in user experience needs. Collaboration in these areas should be super beneficial. Of course, it comes with challenges, too, and the team is ready… well, as far as one can be.

The NL Design System website

I'm looking forward to help with:

accessibility: of components, in documentation (I have opinions) and in applying standards well
developer relations: technical writing, outreach between the core team and collaborating teams (current or future), improving the product based on developer feedback

This is a team that people have wanted for a long time serving needs that have gone unserved for a long time, too. There's a lot of realism to be had, because, of course, one design system or team cannot magically make all the websites better, but I strongly believe in design systems (and specifically this project) as a multiplier for accessibility efforts. I am, in other words, thrilled to become part of this particular team.

Workshops / talks

In addition, I will continue to do full day workshops and other public speaking about the web and web accessibility. Two things in particular:

a full-day workshop called “Accessibility for design system teams”, which I've started to deliver to in-house teams that are keen to use their design system as a way to increase accessibility in their product(s) and want to understand what that means in theory and practice
a talk on popovers and dialogs that I'll present at various conferences this year, the first one at CSS Day in Amsterdam, which is pretty much my favourite front-end event

Workshopping at Sanoma Learning

Audits

Lastly, I also plan to do a small amount of accessibility conformance audits, focused on helping teams figure out which accessibility barriers their site has and how to fix them (I call this issue oriented reporting) (and sorry, that also means I will probably say no to teams whose only goal is a report).

Wrapping up

That's all. I hope my new freelance life will also allow me to do some more blogging on this website. The drafts folder isn't the issue, I guess 😁. For now, thanks for reading!

Originally posted as Back to freelance on Hidde's blog.

[email protected]?subject=Reply%20to:%20Back to freelance">Reply via email

Semantics and the popover attribute: which role to use when?

2023-05-16T00:00:00Z

With the new popover attribute in HTML, we can put elements in the top layer and allow them to disappear with ‘light dismiss’. This attribute adds behaviour, not semantics: you're supposed to add your own role when it makes sense. In this post, we'll look at different roles that could make sense for your popover-behaved elements.

Semantics?

Accessibility semantics are roles, states and properties that are exposed by by browsers for many HTML features, and then passed on to assistive technologies.

The ‘role’ of an element establishes what kind of element it is. Roles are built-in (‘implicit’) to some elements: a h1 has the heading role, an a has the link role and so forth. Roles can also be added with a role attribute explicitly. For some roles, that is the only way: there exists no corresponding element. If there's an element and a value for ‘role’, it doesn't really matter for end users which you use, but generally you don't want to overwrite implicit role. As mentioned, your user's browser or assistive technology may use the role to provide a UI. For instance, a screenreader may generate a list of links or headings, a reader mode may render list items with bullets.

Popovers have no default role

Whenever we add the popover attribute to an element, it continues to be that element semantically, just with some specific behaviours. Menus remain menus, dialogs remain dialogs, and so on. The popover attribute does not change an element's role. It's a bit like the contenteditable attribute in that sense. In addition to choosing that you want the popover behaviour, you need to decide if you add a role and, if so, which role.

The most basic example of a popover:

<button 
  type="button" 
  popovertarget="my-popover">
    Toggle popover
</button>
<div popover id="my-popover">
  ... 
</div>

This is how it works:

the div will be invisible on page load, because it has a popover attribute and popovers are closed on page load by default
the div will also be toggleable via the button, as the button points to the div's ID in its popovertarget attribute

Potential roles for your popover

Let's now look at common roles for popovers: menu, dialog and listbox, and consider what to do about tooltips.

Menus: the `menu` role

Let's start with menus. The menu role is what you'd use when your component offers a list of choices to the user, specifically choices that are actions. (Note: menu is not for a list of links, like a navigation, it is only for a list of actions).

A menu with popover behaviour can be built with a menu role:

<button 
  type="button" 
  popovertarget="my-menu">
    Toggle menu
</button>
<div role="menu" popover id="my-menu">
    <button 
      onclick="doThing()" 
      role="menuitem" 
      tabindex="-1" 
      autofocus>Do thing</button>
    <button 
      onclick="doAnotherThing()" 
      role="menuitem"
      tabindex="-1">Do another thing</button>
  … 
</div>

In a menu widget, there are also some keyboard and focus expectations. For instance, that users can use their arrow keys to cycle through the different buttons. As a developer, this is something you'd add with JavaScript yourself. The first button is focused when it opens (hence autofocus), the second and after would get focused moved to them when they're the next one and an arrow key is pressed (hence tabindex="-1": this takes the buttons out of tab order, because you make them reachable with arrow keys instead).

(Note: The menu role is not to be confused with the menu element, which has a list role and is “a semantic alternative to <ul>”)

Examples of when you would use role="menu":

Your CMS manages a list of authors. The user can open a menu for each author with some actions (each action has a menuitem role)

You're building a word processor. The “File” menu is a menu, the options (New, Open, etc) are menuitems._

Dialogs: the `dialog` role

A dialog role is what you add when an element is like a smaller window on top of the main web page. It can block interaction with the rest of the page or leave the rest of the page as it is, either way it is somewhat separate from the page, both in purpose and visually.

The <dialog> element implicitly has a dialog role, and comes with dialog methods and behaviours (like you can run element.showModal() to show it as a modal). You can also add the dialog role manually with role="dialog", but then you have to add the behaviours manually too.

A dialog with popover behaviour can be built like this:

<button 
  type="button" 
  popovertarget="my-dialog">
    Toggle dialog
</button>
<dialog id="my-dialog" popover>
  ... 
</dialog>

You see, there's no explicit role attribute, because the dialog role comes with the <dialog> element.

If not using a button with popovertarget, you could open this dialog with script using the showPopover() method that works on any element that is a popover (by having a popover attribute present).

Note: because this specific popover example uses the <dialog> element, two other methods are also available (through the HTMLDialogElement): show() and showModal(). They have slightly different behaviours than showPopover() would. I recommend against using these two methods on dialogs that are popovers. In other words, if you're inclined to use them, you probably don't want the popover attribute, as that attribute's purpose would basically be defeated by show()/showModal() (also, in some cases you might get a console error if you try to run showModal() on a popover). Popover is really for non-modal dialogs; see also my post on dialogs vs popovers).

Other examples of elements that could have popover behaviour and a dialog role are:

teaching UI
pickers, like for a date, multiple dates, prices
“mega navs” and other large navigational structures that cover a lot of the page (note: these should not use role="menu", a navigation with links is semantically different from a menu with buttons)

A dialog that allows the user to specify their travel group and amount of bicycles

A dialog that teaches what the audio player is for

A “meganav” that covers other content (note: this is a dialog, not a menu)

Listboxes / autocompletes: the `listbox` role

A listbox is for elements where the user gets to choose from one or more options, like a <select>. They can exist as single select (user can select one option) or multi select (user can select multiple options).

Listboxes are often part of an autocomplete or combobox widget, they are the part that contains the actual options. Like in this example:

Select menus also use listboxes to allow users to pick an option from a list

For instance, in the following example, there is a component that pops over the page's content. It contains filter and sorting buttons, as well as a listbox with actual options. The element with popover is probably a dialog (and you could give it a dialog role), while the element that contains options would need a role of listbox:

A listbox as part of a combobox

Tooltips/toggletips: `tooltip` (with caveats) or `dialog`

In their simplest form, tooltips are like the title element in HTML, that browers display on hover. These browser built-in tooltips are problematic in many ways, including that in most browsers, there is no way to get to the contents of title with just a keyboard. Let's call them “plain text tooltips”. They are often customised by developers, for instance to change their visual styles (currently from scratch, maybe via CSS in the future).

Plain text tooltips that display on hover or focus of a triggering element, which they describe

Sometimes they are also found underneath input fields, to explain what that input does or what is expected, like some of Scott O'Hara's custom tooltips examples.

These custom “plain text tooltips” are what the tooltip role seems to be meant for. Note that role="tooltip" doesn't do much in terms of screen reader announcements as Sarah Higley explains in Tooltips in the time of WCAG 2.1, though there are cases where ARIA-provided labels and descriptions don't work across browsers and assistive technologies without the role (if they aren't interactive, iframe or img elements and also don't have a landmark or widget role). What is useful for accessibility of that kind of tooltip, going beyond roles for a moment: use aria-describedby to link up a tooltip that describes a thing with that thing, and never place essential content in them. Also ensure that the tooltip (1) stays visible when its content is hovered, (2) is dismissable (with Escape) and (3) persists until hover/focus removed, dismissed or irrelevant (all required to meet WCAG 1.4.13).

My advice would be that whenever tooltips contain more than just plain text, a non-modal dialog would be more appropriate (even if elements with tooltip role were apparently meant to also allow for interactive elements). Non-modal dialog tooltips could contain semantic elements (like a heading) or interactive elements (like a link or a button). In most cases it would be best to display them on click instead of hover + focus, in which case they are really “toggletips”. Of course, if there is interactive content, that also means you'll want to consider focus order.

Conclusion

In this post, we've covered some of the most common semantics you could choose to use with the popover behaviour: menu, dialog and listbox, plus looked at using tooltip for plain text tooltips or dialog for tooltips that contain anything more than plain text. Are you building components that don't really fall into any of these categories? I'm curious to learn more, slide in my DMs or email!

Originally posted as Semantics and the popover attribute: which role to use when? on Hidde's blog.

[email protected]?subject=Reply%20to:%20Semantics and the popover attribute: which role to use when?">Reply via email

Positioning anchored popovers

2023-06-12T00:00:00Z

Popovers are commonly positioned relative to their invoker (if they have one). When we use the popover attribute, anchoring is tricky, as these popovers are in the top layer, away from the context of their invoker. What options do we have?

Basically, there are two ways to position popovers: one you can use today and one that will be available in the future. I'll detail them below, but first, let's look at why we can't use absolute positioning relative to a container shared by the invoker and the popover.

Not all popovers are anchored, but I expect anchored popovers to be among the most common ones. For popovers that are not anchored, such as toast-like elements, “bottom sheets” or keyboard-triggered command palettes, these positioning constraints do not apply.

Examples of anchored popovers: map toggletip (Extinction Rebellion), date picker (European Sleeper), colour picker (Microsoft Word web app)

Top layer elements lose their positioning context

One of the unique characteristics of popovers (again, the ones made with the popover attribute, not just any popover from a design system), is that they get upgraded to the top layer. The top layer is a feature drafted in CSS Positioning, Level 4. The top layer is a layer adjacent to the main document, basically like a bit like a sibling of <html>.

Some specifics on the top layer:

It's above all z-indexes in your document, top layer elements can't use z-index. Instead, elements are stacked in the order they are added to the top layer.
As developers, we can't put elements in the top layer directly, as it is browser controlled. We can only use certain elements and APIs that then trigger the browser to move an element to the top layer: the Full Screen API, <dialog>s with showModal() and popover'ed elements, currently.
Top layer elements, quoting the specification, “don't lay out normally based on their position in the document”.

When I positioned my first popover, I tried (and failed): I put both the popover and its invoking element in one element with position: relative. Then I applied position: absolute to the popover, which I hoped would let me position relative to the container. It didn't, and I think the last item above explains why.

In summary, elements lose their position context when they are upgraded to the top layer. And that's okay, we have other options.

Option 1: position yourself (manually or with a library)

The first option is to position the popover yourself, with script. Because the fact that the top layer element doesn't know about the non-top layer element's position in CSS, doesn't mean you can't store the invoker's position and calculate a position for the popover itself.

There are some specifics to keep in mind, just like with popovers that are built without the popover attribute: what happens when there's no space or when the popover is near the window? Numerous libraries can help with this, such as Floating UI, an evolution of the infamous Popper library.

Let's look at a minimal example using Floating UI. It assumes you have a popover in your HTML that is connected to a button using popovertarget:

<button popovertarget="p">Toggle popover</button>
<div id="p" popover>… popover contents go here</div>

By default, browsers show the open popover in the center of the viewport:

The popover is centered

The reason that this happens is that the UA stylesheet applies margin: auto to popovers. This will reassign any whitespace around the popover equally to all sides as margins. That checks out: if there's the same amount of whitespace left and right, it element will effectively be in the center horizontally (same for top and bottom, but vertically).

For anchored popovers, we want the popover to be near the button that invoked it, not in the center. Let's look at a minimal code example.

In your JavaScript, first import the computePosition function from @floating-ui:

import { computePosition } from '@floating-ui/dom';

Then, find the popover:

const popover = document.querySelector('[popover]');

Popovers have a toggle event, just like the <details> element, which we'll listen to:

popover.addEventListener('toggle', positionPopover);

In our positionPopover function, we'll find the invoker, and then, if the newState property of the event is open, we'll run the computePosition function and set the results of its computation as inline styles.

function positionPopover(event) {
  const invoker = document.querySelector(`[popovertarget="${popover.getAttribute('id')}"`);

  if (event.newState === 'open') {
    computePosition(invoker, popover).then(({x, y}) => {
      Object.assign(popover.style, {
        left: `${x}px`,
        top: `${y}px`,
      });
    });
  }
}

To make this work, I also applied these two style declarations to the popover:

margin: 0, because the UA's auto margin's whitespace gets included in the calculation, with 0 we remove that whitespace
position: absolute, because popovers get position: fixed from the user agent stylesheet and I don't want that on popovers that are anchored to a button

It then looks something like this:

See it in action: Codepen: Positioning a popover with Floating UI.

In the Codepen, I also use some Floating UI config to position the popover from the left. In reality, you probably want to use more of Floating UI's features, to deal with things like resizing (see their tutorial).

Option 2: with Anchor Positioning

To make all of this a whole lot easier (and leave the maths to the browser), a new CSS specification is on the way: Anchor Positioning, Level 1. It exists so that:

a positioned element can size and position itself relative to one or more "anchor elements" elsewhere on the page

This, as they say, is rad, because it will let the browser do your sizing and positioning maths (~~even automatically~~- update 4 May 2024: looks like automatic anchoring was removed). It is also exciting, because it doesn't care where your elements are. They can be anywhere in your DOM. And, important for popovers, it also works across the top layer and root element.

Though popovers would get implicit anchoring, you can connect a popover with its invoker via CSS. To find out how all of this works in practice, I recommend Jhey Tompkins's great explainer on Chrome Developers (but note it's currently somewhat outdated, the editor's draft spec changed since that post, and has new editors). Roman Komarov covers his experiments and some interesting use cases in Future CSS: Anchor Positioning, and also wrote Anchor Positioning on 12 days of web.

The Anchor Positioning spec was recently updated, and is currently in the process of being implemented in browsers, hence the Option 1 in this article. But, excitingly, it is in the works. Chromium has already issued an intent to ship anchor positioning, and so did Mozilla/Gecko. The recent updates are still pending TAG review.

Wrapping up

So, in summary: if your popover needs to be anchored to something, like a button or a form field, you can't “just” use absolute positioning. Instead, you can use JavaScript (today), or, excitingly, anchor positioning (in the near-ish future, an Editor's Draft in CSS was published last year and a new version of that with new editors was released in April 2024.

Originally posted as Positioning anchored popovers on Hidde's blog.

[email protected]?subject=Reply%20to:%20Positioning anchored popovers">Reply via email

Joining CSSWG

2023-07-21T00:00:00Z

This week I joined the CSS Working Group (CSSWG) as an Invited Expert. I'm super grateful for this chance to try and make myself useful in a group whose outputs shaped so much of my professional interests (they make CSS!).

I'm somewhat nervous about this, but also not completely new to CSS or web standards. My background with CSS is that I've been a long time fanboy of the language, and a keen follower of new developments through events (9 times CSS Day attendee of which 2 as a speaker). The CSSWG folks I've met so far are very friendly, no exceptions. My background with standards is that I've participated in the Open UI Community Group for just over two years, and worked as W3C Staff to promote accessibility standards, help simplify developer documentation and build standard-related tooling like the ATAG and WCAG-EM Report Tools. As such, I am experienced with some of the W3C process.

Despite not being completely new, I've yet to figure out my focus and where I could help. The CSSWG does a daunting amount of work (see the charter), and there are certain specs and features I'm especially interested in, like the ones close to Open UI. I think I will start with attending the telecons, listen and learn. Ultimately, I hope to make myself actually useful, maybe help with demos and content (like explainers or explanatory blog posts or talks), or by sharing a web developer's perspective. And opinions, maybe!

I'm excited for this opportunity, many thanks to Tantek, Miriam and others for their encouragement. I look forward to involve in standards outside accessibility and, yeah, try and make myself useful 🙃

Originally posted as Joining CSSWG on Hidde's blog.

[email protected]?subject=Reply%20to:%20Joining CSSWG">Reply via email

“AI” content and user centered design

2023-07-28T00:00:00Z

Large language models (LLMs), like ChatGPT and Bard, can be used to generate sentences based on statistical likeliness. While the results of these tools can look very impressive (they're designed to), I can't think of cases where the use of LLM-generated content actually improves an end user's experience. Even if not all of the time, LLM output is often nonsensical, false, unclear and boring. Hence, when organisations force LLM-output on users instead of paying people to create their content, they don't center users.

User centered design means we make the user our main concern when we design. When I recently told a friend about this concept, explaining my new job is at a government department focused on centering users, they laughed in surprise. “This is a thing?”, they asked. “What else would you make the main concern when you design?” It made little sense to them that users had to be specifically centered.

If you work in tech, you probably saw projects center other things than users. Business needs, the profit margin, search engines, that one designer's personal preference, the desire to look as cool as a tech brand you love… and so on. Sadly, projects center them instead of users all the time. Most arguments I heard for using LLMs in the content production process quoted at least one of these non-user-centric reasons.

Organisations are starting to use or at least experiment with LLMs to create content for web projects. The hype is real and I worry that, by increasing nonsense, falsehoods and boredom, LLM-generated content is going to worsen user experiences across the board. Why force this content on users? And what about the impact of LLM-generated content beyond individual websites and user experiences: it's also going to pollute the web as a whole and make search worse (as well as itself).

None of this is new, we've had robot-like interactions way before LLMs. When the tax office sends a letter that means you need to pay or receive money, that information is often buried in civil servant speak. When Silicon Valley startup founders announce they were bought, they will mention their “incredible journey”. When lawyers describe employment, customer service phone lines pronounce “your call is important to us” (a great read, BTW)… this is all to say that, even without LLMs, we're used to people that sound more robotic and less human. They speak a lingo.

Lingo gets in the way of clarity. Not just because it feels impersonal and boring, it is also made-up, however brilliantly our prompts will be ‘engineered’. Yes, even if it's sourced—or stolen, in many cases—from original content. That makes it like the lingo humans produce, but much worse. Sure, LLM-generated content could give users clarity, except in a way that's only helpful if the user already knows a lot about the thing that is clarified (so that they can spot falsehoods). This is the crux and why the practical applicability of LLMs isn't nearly as wide as their makers claim.

I can see how a doctor's practice / government department / bank / school could save money and time by putting a chatbot between themselves and the people. There are benefits to one-click-content-creation for organisations. But I don't see how end users could benefit, at all. Who would prefer reading convincing-but-potentially-false chatbot-advice to a conversation with their doctor (or force the bot on others). Zooming out from specific use cases to the wider ecosystem… aren't even those who shrug at ideals like centering humans worried that LLMs-generated content wipes out the very “value” capitalists wants to extract from the web (by enshittification)? I certainly hope so.

Addendum: I didn't know writing this post that OpenAI's CEO Sam Altman literally wrote he looked forward to “AI medical advisors for people who can't afford care”. From his thread on 19 February 2023:

the adaptation to a world deeply integrated with AI tools is probably going to happen pretty quickly; the benefits (and fun!) have too much upside.

these tools will help us be more productive (can't wait to spend less time doing email!), healthier (AI medical advisors for people who can’t afford care), smarter (students using ChatGPT to learn), and more entertained (AI memes lolol).

(…)

we think showing these tools to the world early, while still somewhat broken, is critical if we are going to have sufficient input and repeated efforts to get it right. the level of individual empowerment coming is wonderful, but not without serious challenges.

He talks about “individual empowerment [that] is wonderful”, I think it's incredibly dystopian.

Originally posted as “AI” content and user centered design on Hidde's blog.

[email protected]?subject=Reply%20to:%20“AI” content and user centered design">Reply via email

It's pretty rude of OpenAI to make their use of your content opt-out

2023-08-14T00:00:00Z

OpenAI, the company that makes ChatGPT, now offers a way for websites to opt out of its crawler. By default, it will just use web content as it sees fit. How rude!

The opt-out works by adding a Disallow directive for the GPTBot User Agent in your robots.txt. The GPTBot docs say:

Allowing GPTBot to access your site can help AI models become more accurate and improve their general capabilities and safety.

I get the goal of optimising AI models for accuracy and capabilities, but I don't see why it would be ok for these “AI” companies to just take whatever content they want. Maybe your local bakery's goal is to sell tastier croissants. Reasonable goal. Now, can they steal croissants from other companies that make tasty croissants, unless those companies opt out? I guess few people would answer ‘yes’?

Google previously got into legal trouble for their somewhat dubious practice of displaying headlines and snippers from newspaper's articles. It seems reasonable to reuse content when referring to it, at least headlines, most websites do that. Google does it with sources displayed and has links to the original. ChatGPT has neither, which makes their stealing (or reusing) especially problematic.

Taking other people's writing should be an opt-in and probably paid for (even if makers of AI don't think so). The fact that this needs to be said and isn't, say, the status quo, tells me that companies like OpenAI don't see much value in writing or writers. To deploy this software in the way they have, shows a fundamental misunderstanding of the value of arts. As someone who loves reading and writing, that concerns me. OpenAI have enormous funds that they choose to spend on things and not other things.

It is in the very nature of LLMs that very large amounts of content are needed for them to be trained. Opt-in makes that difficult, because it would mean not having a lot of the training content required for the product's functioning. Payment makes that expensive, because if it's lots of content, that means it would cost lots of money. But hey, such difficulties and costs aren't the problem of content writers. OpenAI's use of opt-out instead of opt-in unjustifyably makes it their problem.

For that reason alone, I think the only fair LLMs would the ones trained on ‘own’ content, like a documentation site that offers a chatbot-route into its content in addition to the main affair (an approach that is still risky for numerous other reasons).

Originally posted as It's pretty rude of OpenAI to make their use of your content opt-out on Hidde's blog.

[email protected]?subject=Reply%20to:%20It's pretty rude of OpenAI to make their use of your content opt-out">Reply via email

Co-organising Design Systems Week 2023

2023-08-25T00:00:00Z

For the Dutch government, I'm co-organising the third edition of a virtual week-long design systems event, as part of my role in the NL Design System core team. Will it be interesting? Yes!

At NL Design System, we work with a lot of government teams to ultimately try and make a “greatest hits” of their components. Heavily simplified: we want to find the best front-end components/guidelines/examples in use across government, test them (for accessibility and usability) and then publish them for wide reuse. That's a long, but (hopefully) very fruitful journey, that can result in widely-agreed upon solutions and avoidance of some common design system pitfalls.

That's not really how design systems used to work. Design systems came a long way from pattern libraries for developers who need to copy/paste HTML to much better thought-out systems with communication and support protocols, advanced theming, versioning and solid accessibility guidelines. Over time, the promises we make have probably also evolved.

Promises vs reality

My favourite promise of design systems is the opportunity to try and do high quality front-end work and then spread the result across lots of projects. So, like, you could get the component right and build it accessibly, with a usable API, excellent guidance, and so fort. Good things you could then spread around. Other promises of design systems include cost savings through efficiency and improved user experience through consistency. But realistically, promises remain promises until they are realised (as those who work on design system teams will probably be well familiar with).

That's not to say designs system promises are too good to be true. They do often come true. Just look at what some teams out there are doing! But there's a lot to say about approaches, benefits and potential pitfalls for design systems teams. How does everyone do it? Because while the work could be made to sound easy, it often isn't. This is partly why we're organising Design Systems Week (the third edition this year): we want to hear from others about their successes, learnings and challenges. Or… peak inside other teams, basically. And when I say “we”… I should say the team already ran two editions, I'm just helping out with the third.

Design Systems Week

So, Design Systems Week 2023 is coming, in the first week of October! The program is starting to shape up nicely. We'll have speakers from across the Dutch government, such as the Chamber of Commerce and various city governments. New in this year's edition is that we also wanted to hear from people from outside the Netherlands, in government and private sector.

So far, we've announced (among others):

Inayaili León from GitHub on DesignOps
Joe Lanman from GOV.UK on their Prototype Kit
Daniëlle Rameau from Sanoma Learning on Design Systems as a way to get accessibility right (in Dutch)
David Darnes from NordHealth on Web Components (what works and what doesn't)
Mu-An Chiou from Taiwan Design System on design systems as public infrastructure
Aleksandr Beliaev from Estonia Design System on the design system of the first digital society

And there's a few more coming that I can't wait for the team to announce.

We know people are busy and don't necessarily have time to watch virtual events all day, so we've designed the sessions to be 20-25 minute “snacks” that you can catch between meetings (live via Teams (government), or watch via the published records afterwards).

I'm really looking forward to this. If you want to join us, you can sign up for individual sessions or check out the main event page.

Originally posted as Co-organising Design Systems Week 2023 on Hidde's blog.

[email protected]?subject=Reply%20to:%20Co-organising Design Systems Week 2023">Reply via email

Ableist interactions

2023-09-16T00:00:00Z

This week, a product launched and claimed to generate “production ready” code. But it also generates code with accessibility problems, which contradicts “production ready”. When someone called this out publicly, a community showed itself from its worst side. What can we learn?

I'll state again, I wrote this to share learnings around community respondes to a concern about accessibility issues. Because these kinds of replies are common and it's useful to have context. I don't want to add fuel to the issue, which is why I left out links to individual tweets and people.

I do want to call out Vercel, a business with a large voice in the developer community, which I do at the end of the post.

The “production ready” claim

I’ll start by elaborating on my first point. “Has accessibility issues” contradicts “production ready”, for three reasons:

equal access to information is a human right
most organisations have legal requirements to make accessible products
it can cost companies money if people can’t use their products (you wouldn’t stop every fifth customer from entering your shop).

I will note it was an “alpha” launch, but the words “production ready” were used and not nuanced (not in marketing and not in the actual tool; a warning banner could go a long way). Fair enough, maybe they want to look at accessibility later (a personal pet peeve though: I recommend shifting left instead, doing accessibility earlier is easier).

The company could have made different choices. If it is known that accessibility is problematic, maybe the product could have come with a checklist that helps people avoid some of the most common issues? Or some kind of warning or banner that explains nuances the “production ready” line? These are choices to be made, to balance between what makes the product look less good and what harms end users.

Ableism

Many of the responses were ableist: they discriminate or contain social prejudice against people with physical or mental disabilities. A key point to make here is: don't feel offended if you or your comment is called ableist. Instead, listen and learn (seriously, it's an opportunity). The system is ableist, on top of which individuals make comments that can be called ableist. We (as a people) need to identify and break down that system, but also, people can individually learn: everyone has a degree of ableism (like they have some degree sexism and racism). I know I do. I've been learning about accessibility for about 15 years and still learn new things all the time (same for sexism, or racism, etc, these are all things need regular introspection; and they are related, see also intersectionality).

Learning from the responses

Below, I'll list some responses I found problematic, and try and explain why. I'm hoping this is helpful for people who want to understand better why accessibility is critical, and why accessibility specialists point this out.

“can’t expect them to make everything perfect, especially in the alpha release” - I think it's fair to have expectations from a company that is a large voice in the web development community
“Here's a better framing”, “Why the agressive tone?”, “Why are these people so insufferable? (…)” - this shifts the question about accessibility to one about how the person asking for equality phrases their feedback (this is tone policing, a common derailment tactic)
“🤮 being an insufferable dick to well-meaning, well-intentioned people is not going to work for your cause, no matter how good of a cause it is” - this seems to suggest that inaccessibility is ok as long as the intentions are good (that is ableist; equal access cannot be bought off by good intentions only. It is actual equality that is required)
“Paying a six figure engineer to add features only 1% of your user base needs only makes profit sense after, idk, 100K active users? [screenshot of ChatGPT to prove the number]” - it’s not only about profit sense, it’s also about ethical sense and legal sense. If you want to focus on profit only: about 20% of people has a disability (says WHO). Also, almost all people will develop disabilities in some form throughout their life while they age.
‘You are complaining about a WYSIWYG editor not being accessible to the blind---do you make similar complains about sunsets and VR headsets?’ and ‘I don't think anyone using this site needs accessibility’- this is a fundamental misunderstanding of how people with disabilities use the web. Yes, blind people use WYSIWYG editors (and so do people with other disabilities, which is why creators of these tools care, see the accessibility initiatives for tools like TinyMCE). See also Apple's videos on Sady Paulson, who uses Switch Control to edit videos or on how people use tools like Door Detection and Voice Control.
‘Then what is the argument for accessibility, if not screen readers or search engine crawlers?’ - again, there are many more ways people with disabilities use the web, and beyond permanent disabilities (as mentioned, about 20% of people), there are people with temporary impairments (from broken arms to word) and situational impairments

Some responses were particularly hostile and personal. “I'm shocked that you're unemployed ..🤯🤯😅”, “Okay, Karen”, “(…) She wants attention”, “No matter how much you shame Vercel, they don't want you. They never will”, “Go accessibility pimp else where (sic) and pretend that others give a shit”, “[you are] being an insufferable dick”. These are all unacceptable personal attacks.

If you work at Vercel (this was relating the v0 product), please consider speaking up (silence speaks too) and/or talking with your community about how accessibility is viewed and how people in the community interact. The quotes in this post are all real quotes, from people defending Vercel. To his credit, the CEO gave the right example with his response (”Thanks for the feedback”)

Wrapping up

So, in summary: the “production ready” claim and lack of nuance about what that means is problematic. Pointing it out got responses I'd call ableist, plus a few responses that were plain hostile. All of this reflects badly on the community.

It's not new that accessibility advocates get hostile responses to reasonable requests (or when doing their job). But it's been a while since I've seen so many of those responses, so I wanted to take the opportunity to write down some common misunderstandings.

Originally posted as Ableist interactions on Hidde's blog.

[email protected]?subject=Reply%20to:%20Ableist interactions">Reply via email

Answers to common (web) accessibility questions

2023-11-02T00:00:00Z

Inspired by Chris Coyier' Answers to common (web) design questions, which was inspired by Dan Mall's earlier post, here's list of common accessibility questions.

Should I use links or buttons?

Yes.

Links if it takes the user somewhere, buttons if it performs an action. Also buttons if the action is submitting a form (even if the user is then taken somewhere). Trying to avoid nuance in this post, but here's some nuance around buttons and links.

Do we have users with disabilities?

Yes.

It's unlikely you know every single one of your users and exactly how they use the web. It's even more unlikely that the the group and the people within it stays exactly the same forever.

What's an accessibility conformance audit?

Someone will find out for every of the 56 Success Criteria in WCAG whether your site meets it or not (counting version 2.2, Level A + AA). Ideally, they also explain what the issues are and how to fix them (so that you can do it). This is also called a conformance evaluation.

Who should “do” accessibility in our team?

Everyone. Content folks, developers, designers and product managers all have accessibility tasks to do.

What are some quick tests I can do?

Use your UI with Tab / Shift Tab on a keyboard (check settings if on a Mac), can you reach everything without a mouse? Does the order make sense?

Click on labels for form fields, they should focus the field they are a label of.

Check if your videos and audio (podcasts?) have captions / transcripts.

Is accessibility ever done?

No. It's a continuous process, even if your audit says you meet all Success Criteria today, it's common to stop meeting it. Websites change. You'll want to continuously monitor accessibility, just like with security and privacy.

Do we have legal obligations to make our products accessible?

Very likely. Also if you're not government (for instance, see European Accessibility Act).

There are policies and laws all around the world.

Is it all my website's fault?

No, some problems can be solved by browsers, assistive technologies and/or authoring tools.

WCAG 3.0 will be released soon, right?

Not likely. The goals are good and I've long supported them (still do), but it will be many years for this to be a real thing, WCAG 3.0 is still in a very early phase. The colour algorithm that's being considered for it is interesting to already try and meet as it better meets user needs than current WCAG algo.

Will “AI” improve accessibility?

Machine learning can be a great tool for automating part of the captioning process in lots of languages, and various other things.

But it's unlikely LLMs, often called “AI”, will output accessible code. To train such an LLM, an enormous set of very accessible code would need to exist (it doesn't). Component-building and accessibility semantics also require intentionality, which these systems specifically aren't good at.

Is the Axe / Page Insights score all that matters? Or the WCAG audit result?

No. Any system that scores your site and returns some number (including WCAG audits) does not fully describe your accessibility situation. Accessibility is, ultimately, about people and whether they can use your site. It's about recognising, then removing barriers. Metrics can help in various ways, but they are not the end goal. And the most easily measureable is not necessarily the most impactful.

More detailed accessibility posts can be found elsewhere on this blog.

Originally posted as Answers to common (web) accessibility questions on Hidde's blog.

[email protected]?subject=Reply%20to:%20Answers to common (web) accessibility questions">Reply via email

2023 in review

2023-12-24T00:00:00Z

Wait, what, it's only a week until 2024? Time for what has become a yearly tradition… in this post, I'll review some of my 2023 in work, conferences, reading, writing, listening, music and learnings.

Note: like my posts about 2022, 2021, 2020, 2019, 2018 and 2017, this post is mostly ‘highlights’, lowlights left out intentionally.

Work

The work year was different than usual: my full time job (first in 10 years or so) ceased to exist and I switched back to freelancing.

Freelancing

In July I joined the NL Design System team (almost) full time. We support a community of web specialists from across the Dutch government to create open-source components and guidelines for all. I joined as an accessibility and developer relations specialist. Now I'm PR/communications lead, with still some time for accessibility (but none for devrel). The project is very much up my ally. I really like the colleagues. I also feel fortunate to bring my experience into this team. And, of course, just as fortunate to have made it once again into a team where I get to learn lots from the others (and all of the design system, government, accessibility and development experience between them).

Outside of NL Design System, I did some in-house workshops, talks about the web and web accessibility, and the occasional WCAG audit.

Volunteering

I continued in Open UI CG, mostly scribing, learning and then conveying some of the work to developer audiences in blog posts and talks. It's still one of my favourite meetings of the week.

Other volunteering didn't work so well. I joined the marketing team of my local solar energy community, made plans but found no time to properly work on them and left. I also joined the CSS WG as an Invited Expert, a long time dream come true. But so far, I only managed to join one meeting and only marginally kept up with emails and issues. Let's say between when I said yes and when it was official, a lot changed at work and I wanted to spend more time with family. I hope they don't revoke my status just yet and hope to start prioritising my WG involvement sometime in 2024.

Conferences

Last year, as the popover attribute started to make its way into browsers, I hoped I would do a talk about the nitty gritty of building popovers (repeating the phrasing I used last year). That happened. I wrote that talk and took it to a number of events. In addition, I made a new talk called “ARIA, The Good Parts” and did a 10 minute rant for the IAAP-EU called “Will tools save us?”.

At CSS Day, I met the hotel cat once again

All my talks in 2023:

Shifting left: making accessibility easier, by doing it earlier at a11yTalks (online)
“Dialog dilemmas and modal mischief: a deep dive into popovers and how to build them”, I like long names, what can I say? This popover talk happened at JSNation (Amsterdam) (7 minute edition, with transcript), CSS Day (Amsterdam), Front Conference (Zurich), HalfStack (Vienna), Covent of Wisdom (Eindhoven) and React Advanced (London)
“ARIA: the good parts” at Paris Web (Paris, obvs), NDC (Porto) and WeAreDevelopers (online)
“Will tools save us” - introduction to a panel for IAAP-EU's celebration of the 3rd anniversary of the Web Accessibility Directive (Brussels)

I also attended Beyond Tellerrand in Düsseldorf and State of the Browser in London.

Reading

I read a bit less than in the last year, most of them while on holiday or travel (see: full reading list if you like book covers). These are some books I can recommend:

Just Human by Arielle Silverman (auto biography), in which she shares her own experience being blind within the context of society, from the moment she was born to the age of 36. Learned a few things about the workings of ableism.
Make me one dimensional by Sang Young Park (novel). Murder mystery, friendships and growing up.
Doe zelf normaal by Maxim Februari (non-fiction), on the role of “datafication” in society. Original, clear, funny at times, witty.
Le Perfezioni (De perfecties) by Vincenzo Latronico (novel). On gentrification, Berlin, millenials.
Tomorrow and tomorrow and tomorrow by Gabrielle Zevin (novel). The videogame industry, sudden success, weird relationships. Was told this is ‘a TikTok sensation’, but won't let that ruin my feelings about the book or my liking it. Consumed this as an audiobook on a few long drives.
Binge by Douglas Coupland (short stories), 60 (!) stories, loved most of them, easy to read in between other tasks.

Music

Saw more live music than in the year before (yay, thanks to babysitters and being more ready for their help as a family). I got lucky that the artists I listened to also toured near me on the right dates, so I got to see:

Little Simz, at North Sea Jazz. Was spectacular. Would have loved a full band, vocals etc, but even without that it was great. I was introduced to her No Thank You album, worked my way back through Sometimes I Might Be An Introvert and Grey Area, and now I'm all in Stillness in Wonderland, it was a fantastic musical rabbit hole.
James Blake, at 070. I don't understand how he makes music (how do synthesisers work?), but the new album is great and sounded excellent live. Some fans knew it was birthday, so we all sang.
Esperanza Spalding, also at North Sea Jazz. I'd not heard of the fairly sexist song ‘Girl Talk’, but the way she performed it with Fred Hersch was awesome (see Girl Talk on YouTube).

I also listened a lot to De Jeugd van Tegenwoordig, Sault, Sef, WIES, Massive Attack and Typhoon.

I made a live music log to track concerts publicly (inspired by Vasilis).

Writing

Including this one, I wrote 15 posts this year, some lengthier than others. Less than usual. There's a bunch of drafts that I'm looking forward to finish!
Of this year's posts, most shared were an FAQ on accessibility and one on ableism in the Vercel community.

Most sceptical were a few posts I wrote about ‘AI’, where I said that opt-out is rude, ‘AI’ content isn't user centered and LLMs are not artificial, nor intelligent.

Cities

I stayed in Taipei, Kaohsiung, Düsseldorf, Porto (2x), Berlin, Zurich, Vienna, Paris, Brussels, London (3x), Bristol and Porto.

I wanted and was able to do a lot of this year's conference travel by trains, twice by night train. The latter aren't cheap if you want some comfort (I went for beds), but very pleasant and lower in emissions than flights would have been.

Saw hot air balloons in Bristol

Learnings

Some random things I learned this year, in no particular order.

Social media doesn't need algorithms for that real community feel. I still like it on Mastodon and still mostly left Twitter and Bluesky. I still use Instagram (to follow artists) and LinkedIn (to follow a random mix of people that never came to Mastodon).
A lot about electric cars (and probably still too little). Quite the rabbit hole, but I bought one, so that I can stop buying petrol. I didn't want to buy one without researching some ins and outs.
In git: to fix commits further back than the very last one, by doing fixup commits and autosquashing them. I hope I won't forget.
Lots of words in Mandarin (~1000). I had some formal courses, but midway this year I started Duolingo (add me!). It uses simplified Chinese characters (not traditional) and Taiwanese friends and family scold me for that. But honestly, the upsides outweigh the downsides for me.
Fresh YouTube accounts (I set one up for work) recommend even more extreme-right content than my many-years-old one does. I wish I could turn recommendations off altogether.
Conference speakers are actually just humans.
Lots of things about government departments and how they work together and the meanings of very specific acronyms.

Wrapping up

Thanks for reading, hope there's useful recommendations in this post. If you're still reading let me end with my best wishes to you for the new year, see you in the next!

Originally posted as 2023 in review on Hidde's blog.

[email protected]?subject=Reply%20to:%202023 in review">Reply via email

Clippy returned (as an unnecessary “AI”)

2024-01-06T00:00:00Z

In the nineties, Clippy lived inside the Microsoft Office suite. It was an avatar of an actual paperclip that would interrupt your writing with tips. Did it provide lots of value? I can't remember. I recall there were good easter eggs. But I don't think it really fixed our productivity in some groundbreaking way. A cute relic of the past, in a time where a lot less people were using computers daily.

Fast forward to this week. I used the current version of Microsoft Word, on the web, to write a thing for work. I wrote a headline. Let's say it was “Marketing 2024”. You won't believe what happened next. A blue circle appeared next to the headline. When I hovered over it, it asked me if I wanted it to insert an image. “An image?”, I thought, somewhat surprised. Was this what the future looked like? Did Clippy return? It certainly got in the way of my writing. When I obliged, it put in a random image that felt very marketing-plan-y. It also showed me a gallery of other images for me to pick instead.

A blue dot appears. When clicked, it inserts an image into the writing flow

It left me with lots of feelings, the main one being how unnecessary all of this was. All that computing power!

The “AI” feature I described assists with images, but Microsoft are rolling out Copilot across many of their products. It can also write new text, or improve existing text in ways you specify, the kinds of features we've seen large language models provide. Copilot is a clever name, and a clever framing of what these chatbots can do: they're not the main driver, that's you as a user, but they can be there alongside you.

And yet, I'm not convinced these features are helpful. They interrupt a flow, the actual content production. And they're actively pushed onto users, from in-software notifications to promotional webinars. If that push is successful, everyone in the world will have to put up with the fruits of these features. It's to be seen what those fruits are: content that is better, content that is more superfluous or a bit of both?

User need?

Do these features empower users? They appear to, from the onset. Of course, a lot of the world's marketing plans look very similar, people probably already copy pasted them from one another or used boilerplates. This just makes recycling old ideas available through a different interface. It makes it easier to make something to that seems ok.

But ultimately, is it the right kind of support? Personally, I want software to push me not towards reusing what exists, but away from that (and that's harder). Whether I'm producing a plan or hefty biography, push me towards thinking critically about the work, rather than offering a quick way out.

To be fair, Word has some features today that help you improve content, but mostly to correct style, grammar and punctuation (nice!). Well, and, I'm not making this up, to help remove “sensitive geopolitical references”.

I did ok on formality and sensitive political references

Writing as trying to discover something new

When I write or (publicly) talk, I hope to write or say something that is relatively unique. Obviously, I don't have the illusion I actually do, unique things are rare, everyone's always iterating upon the work of others. But to at least try to find a new perspective is the point of most writing (if it's meant for reading or convincing). That's what we're all trying to do, right?

Whether it's marketing copy, a techy blog post, a stage play or a philosophical treaty, would anyone set out to produce something similar to what already exists? Would the stage play sell tickets if it sounded like the same old? Would your product sell if you use the same copy as your competitor? (Ok, that last one happens all the time)

Discovering new ways is central to creativity. When Miles Davis recorded his groundbreaking album Kind of blue, he gave musicians scales and melody lines, and asked them to improvise. They hardly practiced and did not know the music inside out before they started. Herbie Hancock explains this made the whole album a lot more spontaneous:

Miles' idea was that… he wanted to capture the spirit of discovery in the music. (…) He wants to capture discovering the music on the record.

(in: The making of Kind of Blue, 6:22)

I recommend that video, it's full of people who understand music and this music in particular. They try and explain some of the creativity of this particular piece.

Of course, most writing doesn't have to yield a creative masterpiece. But it's probably that sense of discovery where, like making music, writing gets most interesting. For writers and for readers. More than recycling old and making grammatical and stylistic improvements (quite useful), writing assistants could drive us in the direction of discovery more.

Unnecessary “AI”

It's not just for fun that I'm calling “unnecessary” on this feature (and who am I to judge, or, frankly, who do I think I am?). This is feature that people probably worked on hard and that some users may find very useful. But still, it's worth considering the need. Large language models, that most “AI” features are based on, cost a lot of computing power, both training them and running them. The training also involves a lot of (underpaid) labour of people, who classify content to make the magic work. And then there's all the knock-on effects on society of having harms perpetuated and being stuck with lots of content that nobody thought was worth writing in the first place.

We've got to think about whether or not the features we build with this are actually useful, actually unnecessary or somewhere in between. We don't have to add “AI” to every product, even in an industry where we see investors push for that, we can choose to do otherwise. (</man-yelling-at-cloud>). One company stood out thinking about this especially carefully in the last while: iA wrote Writing with AI.

Originally posted as Clippy returned (as an unnecessary “AI”) on Hidde's blog.

[email protected]?subject=Reply%20to:%20Clippy returned (as an unnecessary “AI”)">Reply via email

Sharing links

2024-01-12T00:00:00Z

The amount of content on the web is so large, that it's tricky to find the stuff worth reading. One of my strategies is to follow people I trust and read what they share. For anyone with interests similar to mine, I've opened a Links section on this website, too (with it's own RSS feed).

My plan is to publish no more than a couple of links per day (if any). They will mostly be related to technology and/or ethics. I have taken inspiration from many others, like Jeremy's Links section. Mu-An inspired me to use Shortcuts as a tool to create links and notes.

Why?

The reason I want to publish links on this site is mostly for selfish reasons. I've posted links on social media for a long time, but in the black box of algorithms, it's hard to recover them after time passes. I want to at least try and have some sort of system for organising and archive my interests (tags… I'm adding tags).

I also want to try and experiment with shorter, quicker posts.

How: low treshold publishing with a Shortcut

I read mostly on the go, when on public transport or waiting for an appointment. This means I usually am not logged into a CMS or near a computer where I can do version control. This site doesn't use a CMS, but I have (Markdown) files in version control that I populate a static site from. To appear on my site, links shared would ultimately need to exist as Markdown files in a specific folder.

This is what I wanted for my link sharing system:

Very minimal effort
Should work on all devices
Should draft a note with both currently selected text and a link to the page, named after that page
Should also include the current date in the draft and let me title the note
Should place my draft somewhere that I can move to my site quickly

What I ended up with is an Apple Shortcut that takes the current text selection, page name and page URL on a given page in Safari and creates a blob of text with current date, selection and link prefilled. When I run it while in Safari, a popup opens with something like this prefilled:

--- 
tags: []
date: 2024-01-10
---

> // Selected text

(From: [Name of the page](link to the page))

I can then write some context around the link, optionally add a comma-separated list of tags and then save the file. The filename becomes YYYY-MM-DD-.md, where I can write a title for the post after the date. My site generator grabs that title from the file name.

At the time of writing, I haven't figured out how to then get this file in git, so I save it in a specific folder, requiring me to manually drag it into my site whenever I do reach a computer. That works fine for now, I don't write that many anyway.

Summing up

I'm looking forward to continue doing this for a while, and hope the low treshold publishing will make it so easy that I actually will. Check out /links to find out what I've posted so far.

Originally posted as Sharing links on Hidde's blog.

[email protected]?subject=Reply%20to:%20Sharing links">Reply via email

“AI” and accessible front-end components: is the nuance generatable?

2024-03-01T00:00:00Z

Companies are rushing to add generated AI capabilities to their products. Some promise to produce front-end components for you. Is that even possible, given the nature of accessibility and the nature of generative AI? And is it desirable?

The short answer is no, to both questions. The risk: that our rush to technlogical solutions comes at the expense of users.

To find out why, let's consider: how is the process of building an accessible component different between humans and machines? And what are the ethics of our tendency to reach for technological solutions?

The human approach

Let's look at the differences in process first. A human who writes accessible front-end code, writes (mostly) HTML elements and attributes based on:

their understanding of specs and how they work together (including HTML and WAI-ARIA)
what they intend to convey
what they know about how assistive technologies interpet the code they write
knowledge of browser and assistive technology support
looking up the syntax and applying it correctly

(Leaving aside all the useful templating languages and orchestration libraries)

So they translate what they or their designer counterparts want to exist into something that works according to those intentions in a browser. Intentions are a key word here. Conveying author intentions accurately and understanding user needs is essential to accessibility.

They are likely also involved in writing CSS for things like colours, typography and spacing, which can all affect whether websites have barriers for users. And add JS for interactive stuff, managing state(s) and more.

The machine approach

A tool that generates code using language models basically predicts lines of code based on statistical likelihood, a bit like an autocomplete. If the output happens to be high quality, that's, in principal, coincidental. A systems' success rate can be (and is usually) increased by training models specifically with very good examples. In some cases, systems get very close to high quality, because they have enormous amounts of training data. For accessibility, this data is hard to get by—most of the web has accessibility problems: what we can see in the automated tests of the WebAIM Million is just the tip of the proverbial iceberg.

While humans map intentions to interactive content and apply their understanding in the process, LLMs don't have intentions or understanding. They just output blobs of text that matches some input best. I think this is fascinating, impressive and often akin to magic. And the output can look (and sometimes be) production ready and high quality. But it's unsurprising that the output can also contain problems. And as reasonable web developers, we've got to look at the problems we create.

To make this more concrete, let's look at v0, Vercel's LLM-based code generator product that the Vercel CEO announced as:

v0.dev produces the kind of production-grade code that we'd want to ship in our own @vercel products.

(From: tweet by Guillermo Rauch, 12:15 AM · Sep 15, 2023)

I mention this specifically, because I think claims like “production-ready” are an overestimation of the technology and an undervaluation of the need for humans. Which has real-world effects on people.

When I read “production-grade”, I read “accessible”. I had a brief look at the first six components in the ”featured“ section of v0, I found WCAG violations and accessibility barriers in each.

Examples of barriers in each

in math learning app example: buttons marked up as links, progress indication that was only visual with no text alternative, heading marked up as div
In kanban board example: list of items not marked up as list, column headers with low contrast, overlapping text on zoom
in accessibility helper example: overrides existing shortcuts, icons not marked as decorative
in terminal UI: buttons not marked up as buttons
in pricing table: icons not marked up as decorative, button with insufficient contrast
in music player example: various buttons not marked up as buttons, some buttons not available with just keyboard, buttons without accessible names

This isn't a full conformance audit, I just listed the first few things that stood out. I don't mean this as an attack, I just want to show exactly how common accessibility issues in LLM output are.

You might say it's not all terrible, and that's true. I also found lots of markup that makes things accessible, for instance headings that are useful to navigate in various tools, good contrasts and useful + valid ARIA. But that same level of accessibility often exists on websites that didn't involve LLMs. Lots of websites have fairly useful headings, good contrast on many elements and valid ARIA. It's the bits where those things aren't in place where web UIs create barriers for people with disabilities. It's the nuance that matters.

The self-confidence issue

In Can generative AI help write accessible code?, Léonie Watson looks at the output of three other generative AI tools (ChatGPT, Bard and Fix My Code). Like me, she found things that weren't terrible, things that were actually helpful and things that constituted accessibility issues. But Léonie points out a different problem: these tools thend to present themselves as authoritative. Regardless of whether they are. She explains:

Other than the generic statements about the need to check its responses, none of these generative AI tools gives any hint that their answers may not be correct or provides any recommended resources for checking".

In contrast, most good blog posts and resources about accessible coding have a lot of nuance in them. They usually can't recommend one authoritative solution that is guaranteed to work at all times (what definition of “work” would they use?). And that reflects making accessible interfaces in general. It involves rabbit holes. There are generally multiple ways and multiple least bad outcomes to balance between.

Ok, but can LLMs at least be partially useful?

Maybe the problem of authoritativeness could be solved. We could tune these tools to output responses that don't present as mansplainy know-alls. But that still leaves us with other problems: inaccessible suggestions, lack of intention and understanding and lack of innovation.

Falsehoods and hallucinations

LLMs give inaccessible suggestions, as demonstrated in the examples I shared above and in the examples in Léonie's post. If these falsehoods are a consequence of training data, that could be improved with different training data (emphasis on “in theory”). But it's also due to “hallucinations”, a problem inherent to the tech that research shows is inevitable. They make wrong stuff up. Output may be nonsensical. At the expense of users. That can't possibly be an improvement to the status quo: even without “AI” there are plenty of accessibility tips on the web with specific bugs or issues, automating the addition of falsehoods and hallucinations to the mix seems absurd.

Lack of intentions

LLM tools don't have intentions, and intentions are necessary for (most) “accessible coding”. In his post Why doesn't AI work for producing accessible code, Alastair Campbell explains accessibility is not an average. That makes it incompatible with statistical methods to make suggestions.

Lack of innovation

While there are lots of open source component libraries, many UI patterns and their implications haven't been invented yet. Their assumptions dearly need testing. Relying on LLMs for suggestions means relying on (remixed) existing knowledge, so it's unsuitable for making new patterns accessible.

These three reasons make me wonder: are LLMs useful at all in assisting us in building accessible front-end components? If there is a use, it's probably in helping developers discover resources that do contain nuance, not in code suggestions. Maybe there are also uses outside of component code, but that's for another post (see also Aaron Gustafson's Opportunities for AI in Accessibility).

The focus

Probably something for a post on its own, but I feel I should mention here: a focus on trying to find a “fix” or “solution” for accessibility constitutes a misunderstanding of what accessibility is about. When we make websites, the onus is on us to make them accessible. If we want to try and outsource that work to a tool (that we can't trust), we put the onus on disabled users (see also: disability dongles).

As Adrian Rosellli wrote in AI will not fix accessibility, accessibility is about outcomes, not outputs:

Accessibility is about people. (…) When we target output versus outcomes, we are failing our friends, our family, our community, and our future selves. We are excluding fellow humans while we try to absolve ourselves of responsibility. (…)

Eric Bailey posted:

Thinking AI will "solve" accessibility is a bad frame stemming from a technoableist mindset.

The industry seems to me hoping for a magic, binary solution (…) Personally, I'd look to the social model of disability for guidance here: what exactly are we looking to "fix" and why?

In summary

Is the nuance that accessibility usually needs generatable? I think not. Not reliably, anyway. If you take away one thing from this post, I hope it's this warning: LLM-based tools can't be the magic bullet for writing accessible component code that they promise to be. Because nuance, understanding and conveying intent are inherent to accessibility, LLMs cannot be of great help with the accessibility of component code. In addition, they hallucinate inevitably and tend to pose as authoritative while outputting (occassional, but real) falsehoods. The latter can be dangerous and is likely to come at the expense of users.

My suggestion to developers who want help building accessible components? Use a design system that's well tested with people, that is well documented, and that (at least) attempts to capture the nuance. Or get involved in building one. Not everyone wants to do this nuanced and precise work, not every organisation has the budget. That's fine, but let's not suggest it can be automated away, magically. Let's value the human effort that can make web products actually great.

Originally posted as “AI” and accessible front-end components: is the nuance generatable? on Hidde's blog.

[email protected]?subject=Reply%20to:%20“AI” and accessible front-end components: is the nuance generatable?">Reply via email

Breadcrumbs, buttons and buy-in: Patterns Day 3

2024-03-08T00:00:00Z

Yesterday I spent all day in a cinema full of design system nerds. Why? To attend Patterns Day 3. Eight speakers shared their knowledge: some zoomed out to see the bigger picture, others zoomed in on the nitty-gritty.

It was nice to be at another Patterns Day, after I attended the first and missed the second. Thanks Clearleft and especially Jeremy Keith for putting it together. In this post, I'll share my takeaways from the talks, in four themes: the design system practice, accessibility, the technical nitty-gritty, and communication.

The day's venue: the Duke of York's cinema

The design system practice

Design system veteran Jina Anne, inventor of design tokens, opened the day with a reflection on over a decade of design systems (“how many times can I design a button in my career?”) and a look at the future. She proposed we find a balance between standardisation and what she called “intelligent personalisation”.

On the other hand, we aren't really done yet. There are so many complex UX patterns that can be solved more elegantly, as Vitaly Friedman showed. His hobbies include browsing postal office, governmental and e-commerce websites. He looks at the UIs they invent (so that we don't have to). Vitaly showed us more breadcrumbs than was necessary, including some that, interestingly, have feature-parity with meganavs.

Yolijn van der Kolk, product manager (and my colleague) at NL Design System, presented a unique way of approaching the design system practice: the “relay model”. It assigns four statuses to components and guidelines, which change over time on their road to standardisation. It allows innovation and collaboration from teams with wildly different needs in wildly different organisations. The statuses go from sharing a need (“Help Wanted”), to materialising it with a common architecture and guidelines (“Community”), to proposing it for real-life feedback (“Candidate”), to ultimately standardising an uncontroversial and well-tested version of it (”Hall of Fame”).

Jeremy Keith hosted the event

The technical nitty gritty

Two talks focused on design problems that can be solved with clever technical solutions: theming (through design tokens) and typography (through modular scales with modern CSS).

Débora Ornellas, who worked at Lego (haven't we all used the analogy?), shared a number of great recommendations around using design tokens: to use readily available open source products instead of inventing your own, publish tokens as packages and version them and avoid migration fatigue by reducing breaking changes.

Richard Rutter of Clearleft introduced us to typographic scales, which, he explained, are like musical scales. I liked how, after he talked about jazz for a bit, the venue played jazz in the break after his talk. He showed that contrast (eg in size) between elements is essential for good typography: it helps readers understand information hierarchy. How much depends on various factors, like screen size, but to avoid having to maintain many different scales, he proposed a typographic scale that avoids breakpoints, by using modern CSS features like clamp() (or a CSS locks based alternative if you don't want to risk failing WCAG 1.4.4). I suggest checking out Utopia to see both strategies in action.

Accessibility, magic and the design system

The power of design systems is that they can make it easier to repeat good things, such as well-engineered components. And they can repeat accessibility, but there is a lot of nuance, because that won't work magically.

Geri Reid (seriously, more conference organisers should invite Geri!) warned us about the notion that a design system will “fix” the accessibility of whichever system consumes it. Sounds like magic, and too good to be true? Yup, because what will inevitably happen, Geri explained, is that teams start using the “accessible” components to make inaccessible things. Yup, I have definitely seen this over and over.

To mitigate this risk of “wrong usage”, she explained, we need design systems to not just deliver components, but set standards and do education, too. At which point the design system can actually help build more accessible sites. For instance, if components contain ARIA, it's essential that the consumers of those components know how to configure that ARIA. In other words, design systems need very good documentation. Which brings me to the last theme: common understanding and why it matters.

Mitigating misunderstandings with better communication

The theme that stood out to me on the day: design system teams commonly have to deal with misunderstandings. Good communication is important. What a cliché, you might say, that's like anyone in any job. Yes, but it's specifically true for our field: design systems force collaboration between such a broad range of people. That includes similar-discipline-collaboration, like between designer and developer. Débora explained what can happen if they don't work together closely, or if breaking changes aren't communicated timely.

But it's also about wider collaboration: a design system team also needs to make sense to other departments, that have specific requirements and norms. Including those that don't really grasp all the technical details of front-end componentisation, like marketing or (non-web) brand teams, or the people who can help sponsor or promote the project. Samantha Fanning from UCL focused on this in her talk on “design system buy-in”, which she had a lot of useful tips about. She recommended to involve other departments early to do “co-design” rather than presenting (and surprising) them with a finished product. She also shared how it helped her to add design system work as extra scope onto existing projects, rather than setting up a design system specific project.

In her talk, Mary Goldservant of the Financial Times, also touched on the importance of communication. She shared how they got feedback from stakeholders and manage expectations, while working on a large update to Origami, the Financial Times' brilliantly named design system, that includes lots of changes, like multi-brand and multi-platform support.

Wrapping up

It was nice to hang out with so many like-minded folks and learn from them. A lot of the challenges, tools and ideas resonated. Once again, I've realised our problems aren't unique and many of us are in similar struggles, just in slightly different ways.

Originally posted as Breadcrumbs, buttons and buy-in: Patterns Day 3 on Hidde's blog.

[email protected]?subject=Reply%20to:%20Breadcrumbs, buttons and buy-in: Patterns Day 3">Reply via email

On popover accessibility: what the browser does and doesn’t do

2024-03-21T00:00:00Z

One of the premises of the new popover attribute is that it comes with general accessibility considerations “built in”. What does “built in accessibility” actually mean for browsers that support popover?

NOTE: except for this note, this whole post was co-written with Scott O’Hara (thanks Scott!). See also Scott's post, popover accessibility. Whether you're a developer, designer or accessibility specialist, hearing “accessibility is built in” probably makes you want to know what exactly is built-in. For popover, this actually changed quite a bit over time, after discussions at Open UI and with WHATWG. At first, the plan was to introduce a popup element with built-in roles. Later, an attribute ended up making more sense (more on that in the post). For that attribute, and thanks to the great effort of Scott and others, some “accessibility guardrails” have now emerged. And they shipped in most browsers. I hope this post helps you understand better what accessibility is “built-in” when you use popover, and what is not.

In this post

Accessibility semantics
What browsers do (aria-expanded, aria-details, group, keyboard accessibility)
What browsers don't do
Conclusion

Accessibility semantics

The “built-in” accessibility of popover is in the addition of guardrails: browsers try to improve accessibility where they can. These guardrails exist mostly in the form of browsers augmenting accessibility semantics. Before we get into what those guardrails are, let's clarify what that term means.

Many features of HTML have some amount of accessibility semantics associated with them - e.g., roles, states and properties. This is information that a web page exposes, which browsers then pass on to platform accessibility APIs. They do this, so that assistive technologies can build UIs around them (see: How accessibility trees inform assistive tech). These semantics are sometimes baked into native HTML elements. For instance, headings and lists have implicit roles (heading and list, respectively). Other elements, like the checkbox input type, have an implicit role as well as additional states and properties. Developers can use HTML elements with such “built-in” semantics. But they can also set, overwrite and augment accessibility semantics more directly in their HTML structure, using WAI-ARIA.

The thing with the popover attribute is that it doesn’t have a built-in role. After all, it’s not an element. Its purpose is to only add “popover behaviour”, as discussed in Popover semantics. In that sense, popover is a bit like tabindex or contenteditable. These attributes also add behaviour: tabability and editability behaviours, respectively.

A major reason for this choice is that there are a number of components that exhibit popover behaviours. Examples include menus, “toast” messages, sub-navigation lists of links and tooltips. You can use popover on a specific element, then it will get that element's role. Or you can use it with a generic element, and add a role that best matches what you are building.

So, while the default role is ‘generally’ not handled by the attribute (more on that later), there are other semantics (properties and states) that the attribute will expose. Browsers can take care of those with some degree of confidence.

What browsers do

There are two semantics that the browser should take care of when you use popover, and its associated popovertarget attribute. Additionally, there is some keyboard focus behaviour that may also be handled automatically, depending on the type of popover you are using.

The `aria-expanded` state

First, aria-expanded. This state is exposed on the element that invokes the popover, currently limited to buttons (for a variety of reasons that would require a whole other article to talk about - so this is all you get right now). When a popover is invoked by / associated with a button with the popovertarget attribute, the browser will automatically convey whether the popover is in the expanded (rendered) state, or if it is in the collapsed (hidden) state. This is implemented in Edge, Chrome, Firefox and Safari.

For the following example, the ‘heyo’ button will automatically convey whether its associated popover list is in the expanded or collapsed state, based on whether the popover list is invoked as a popover.

<button popovertarget=p>
  Heyo
</button>

…

<ul 
  aria-label="Heyo subpages" 
  id=p 
  popover
></ul>

Note: the state won’t be applied if script, rather than the declarative attribute, does the opening on click of any button (or any other element). Needless to say: it also doesn’t work if there isn’t an invoking button, for instance, and script invokes this popover (because in that case, there isn’t any expanding going on). Additionally, if you force open your popover using CSS display block, then it will not be rendered as a popover - and thus the button will still communicate that the “popover” is in the collapsed state. Also, if you’re doing that - forcing your popover open with CSS - maybe you have some things you need to reconsider with your UI.

The `aria-details` relationship

When the popover doesn’t immediately follow its invoking button in the accessibility tree, browsers are supposed to create an aria-details relationship on the popover’s invoking button with its associated popover. At the time of writing, this is implemented in Chrome, Edge and Firefox.

For instance, in the following markup snippet an implicit aria-details relationship will be made with the button that invokes the popover, because the button and the popover are not immediate siblings in the accessibility tree.

<button popovertarget=foo>something</button>

<p>...</p>

<div role=whatever popover id=foo>...</div>

Similarly, an aria-details relationship will be made with the next markup snippet too, because even though the popover and its invoking button are siblings, the popover is a previous sibling to the invoking element, and it might not be understood which element is the popover, because it doesn’t immediately follow the element that invoked it.

<div role=whatever popover id=foo>...</div>

<button popovertarget=foo>something</button>

In contrast, the next two examples have no aria-details association because that would be unnecessary. For the first, the popover is the immediate next sibling in the accessibility tree (note divs are generic and often ignored when they do not provide information important to accessibility). For the second, the button is a descendant of the popover, so browsers do not need to tell users that the button they are interacting with is about the context they are within. That’d be silly.

<!--  
  example 1: 
  popover immediate sibling in acc tree 
-->
<button popovertarget=m>something</button>
<div class=presentational-styles-only>
  …
  <div role=menu popover id=m>...</div>
</div>

<!-- 
  example 2:
  button descendant of popoover
-->

<dialog popover id=d>
  <button popovertarget=d>close</button>
  …
</dialog>

For more information on how aria-details works, check out the details in the ARIA spec.

Note: aria-details is often confused with aria-describedby. That makes sense, “details” and “descriptions” are very similar. However, these two properties expose different information. aria-describedby takes the associated element’s content, flattens it into a single text string, and exposes that as the ‘description’ or ‘hint’ of the element which the attribute is specified. In contrast, aria-details only informs a user that there is additional information about the current element. That might not seem useful, until you know that screen readers largely provide quick-keys to navigate to and from that associated element which provides the details.

At the time of writing, navigating into the referenced content using quick-keys is supported by JAWS and NVDA (release notes), but not VoiceOver.

Here’s a quick demo of that with JAWS 2023 in Edge 124. JAWS lets us jump to the details content if we press Alt + Ins + D:

In NVDA (2023.3.4), tested with Edge 124, it works slightly differently: when you press the shortcut (NVDA + D), we don't jump to the details content, but it is read out after the shortcut is pressed:

(see demo on CodePen; note: announcements and shortcuts depend on the user's settings, versions, etc)

In the following demo, you can see how the aria-details relationship works between popovers and their invokers (in JAWS 2023 with Edge 124):

(video contains screenshot of code, see demo on CodePen)

In summary: the aria-details association is not announced by JAWS when we focus the invoking button for the first time. This is because the corresponding popover is hidden, so the association isn't made yet. After we open the popover, JAWS announces the button's “has details” association while it is open, to hear it we navigate away and back. This is also how it works in NVDA, which, in addition, also requires you to switch to forms mode to actually hear the relationship announced.

Warning: even if the aria-details association is implemented, it may not be completely ironed out in how the UX behaves for people. For instance, there isn't currently a way for users to find out about the details relationship once it is established, like when the popover opened. It requires for the user to move away from the button and return to it, at which point the relationship is announced. Maybe it would be helpful if the browser would fire some kind of event, to let AT like JAWS know that an element representing details has appeared.

We mention this not to deter you from using popover or to indicate that anyone is doing something “wrong” here. Rather, this is a relatively new feature that people still need to figure out some of the UX kinks around. Feedback is welcome, and to help ensure the best UX is provided, please reach out to the necessary browsers / AT with your thoughts.

The `group` role

As mentioned above, popover can be used on any element, including elements that don’t have a built-in role, like div. But even without a role, it’s likely that the contents of a popover form some kind of meaningful whole. This is why in Chrome, Edge and Firefox, a role of group is automatically added to popovers if they would otherwise have no role, or a role of generic (for instance, divs and spans).

The group role is added, so that assistive technology can have the option to expose the boundaries of the popover that is being displayed. This can be important to users, because a popover is a behavior and visual treatment of its content. How is one to know where such content begins or ends if it doesn’t have boundaries to expose?

It’s important to know that an unnamed group is often ignored by screen readers. This is because otherwise the Internet would be riddled with unhelpful “group” announcements. (See also why Webkit made the decision to remove list semantics from lists that have been styled to not look like lists. These topics are related). Here though, it again comes down to what assistive technology wants to do. By exposing the group role for the popover, now the element can be named by authors, which will force the group role to be exposed in most cases. Then, if AT decided they want to do something special for popover groups, they now have the opportunity to do so.

Keyboard accessibility

One more aspect of “built-in accessibility” that browsers do for your popover, is take care of some keyboard behaviors.

Moving focus back to invoking element

Edge/Chrome, Firefox and Safari will all return focus to the invoking element when you close the popover (only if you are inside of it). This is useful, because if focus was on an element inside the popover, the default would be to return focus to the start of the document. Various groups of users would get lost, increasingly so on pages with a lot of content. Moving focus back to the invoking element helps ensure people can quickly return to what they were doing, rather than spending time having to re-navigate to where they think they were last.

Popover content in tab order

Desktop browsers also do something else: they add the popover content into the tab order just after the invoking button. Even if that’s not where the popover is in the DOM.

Imagine this DOM structure:

<button popovertarget=p>Open popover</button>

<p>content… content… <a href="#">link 1</a></p>

<p>content… content… <a href="#">link 2</a></p>

<div popover id="p"><a href="#">link 3</a></div>

When the popover opens, and you press Tab, you might think you’d jump to “link 1”, the next interactive element in the DOM. Except, in desktop browsers, you will jump to “link 3” instead. The browser basically moves the popover content’s position in tab order to just after its invoking button. This takes it out of its expected position in the tab order. That improves the user experience, because it is likely that upon opening the popover, users will want to interact with its contents.

Keep in mind: browsers adjust the Tab order for instances like this, but they don't adjust the placement of the content in the accessibility tree. This is why the aria-details association was implemented. This special Tab order behavior helps ensure logical focus order for keyboard accessibility. However, we should still strive to make sure our popovers come after the invoking element in the DOM.

But since there will be times where the exact location of the popover in the DOM may be out of one’s control, this behavior is still quite welcome. For instance, if the popover happens to be far away in the DOM, having to go through the rest of the document before reaching the popover would be a nuisance. It would be highly unexpected and unwanted to have to navigate through all other focusable elements in the DOM, prior to the popover one just opened. WCAG 2.4.3 Focus Order requires focusable elements to receive focus in an order that “preserves meaning and operability”. This special browser Tab restructuring helps ensure that requirement can be met.

What browsers don’t do

We can keep this one short: the browser will not do anything apart from the behaviours listed above. Browsers will not add behaviors based on which elements you use or which role you add to them. The popover attribute is merely a first step for us to build new components.

Conclusion

The popover attribute provides a starting point for building popover-like interactions on the web. Browsers don't magically make your components accessible, that's not a thing. But there are some specific keyboard behaviours included with popover, as well as these semantics:

In specific cases, browsers set the aria-expanded state and/or set the aria-details relationship on the invoker.
Browsers apply the group role to the popover content if it doesn’t have a role of its own, so that assistive technologies can expose their boundaries.

Browser support note: at the time of writing, Safari only sets aria-expanded, not aria-details. It also doesn't add a group role fallback.

Originally posted as On popover accessibility: what the browser does and doesn’t do on Hidde's blog.

[email protected]?subject=Reply%20to:%20On popover accessibility: what the browser does and doesn’t do">Reply via email

On authoring tools in EN 301 549

2024-04-10T00:00:00Z

Today I was at the IAAP-EU event in Paris, where we spent a morning workshopping and clarifying parts of EN 301 549, the procurement standard that is used in the Web Accessibility Directive.

I managed to get a spot in the group that focused on 11.8, the part of EN 301 549 that focuses on authoring tools. In this post, I'll share some insights from that session.

This post was written, as always, in personal capacity. And sorry, I don't have an HTML link for EN 301 549 (there isn't one currently, but there is a PDF).

What actually are authoring tools?

When my job was to promote the use of ATAG, I used to say authoring tools are “tools that create web content”. In EN 301 549, they are defined more broadly, beyond web:

software that can be used to create or modify content

(from EN 301 549, chapter 3: Definition of terms, symbols and abbreviations)

In other words, this definition includes web content as well as non-web content. The EN defines “non-web content” as “not a web page, not embedded in any web pages or used in the rendering or functioning of the page”. Examples of such content includes PDFs, Word documents and EPUB files. There's also a W3C document specifically about accessibility of “non-web content”, WCAG2ICT (which is informative, not normative) .

EN 301 549's authoring tool definition is followed by three notes, that all demonstrate the extent to which these tools exist:

authoring tools can have multiple users collaborating on content (this makes me think of tools like Sanity Studio or Google Docs where lots of people can edit content at the same time)
authoring tools could be a collection of multiple applications. For instance, some content goes through multiple applications before end-users access it
authoring tools could produce content that's used or modified later

In our group we quickly realised that there are indeed a lot of different authoring tools. The most obvious one is Content Management Systems (CMSes). Others that people mentioned are social media, online forums, video editing tools, WYSIWYG editors, and email clients. ATAG at a glance also mentions Learning Management Systems, blogs and wikis. It's a broad category, there are a lot of tools that can make (web) content.

The ATAG reference

ATAG, the Authoring Tool Accessibility Guidelines, is the standard that provides recommendations for both making authoring tools themselves accessible (part A), as well as the content they produce (part B). See my earlier post ATAG: the standard for content creation for an overview.

Conforming with EN 301 549 requires that all of our web pages meet all of WCAG (up to Level AA, see EN 301 549, clause 9.6). But it doesn't require ATAG. ATAG is merely mentioned as something that is worth reading for “those […] who want to go beyond [EN 301 549]” (in 11.8.0). In other words, there is no normative requirement to read it, let alone to apply it.

Still, some CMSes do. For instance, Drupal supports ATAG (part A and B) from version 8. Joomla, Wagtail and Craft CMS also have done a lot of work towards improving accessibility, see the W3C's List of authoring tools that support accessibility.

However, that doesn't mean ATAG isn't an incredibly useful standard for people who make and use authoring tools. In fact, it is. In 11.8.2 to 11.8.5, some ATAG requirements are explicitly added. These clauses are requirements, because they use “shall”, which in ETSI standards implies a “mandatory requirement” (say their drafting rules).

Note: that EN 301 549 requires these things, doesn't mean the law in European countries does. These laws often refer to specific parts of the EN, or refer to EN 301 549 specifically in relation to web content.

Note 2: clause 48 of the Web Accessibility Directive is interesting. It includes various points I'd love to see member states adopt:

“EU member states should promote the use of authoring tools that allow better implementation of the accessibility requirements set out in this Directive”
recommendation to “[publish] a list of compatible authoring tools” (as suggestions, so not requiring them specifically)
recommendation to “fund their development”

11.8.2: “enable” and “guide”

Out of the authoring tool requirements, we talked most about 11.8.2. It says:

Authoring tools shall enable and guide the production of content that conforms to clauses 9 (Web content) or 10 (Non-Web content) as applicable.

The key words to me are enable and guide. My personal interpretation of what that means, and maybe partially what I want it to mean:

enable: that tools have, for all types of content they can produce, functionality to create any necessary accessibility aspects for that type of content. For instance, if they let you add an image, they need to let you add a text alternative. There's a lot of grey area, because some very complex images might require linked descriptions that don't fit as alternative text. And what about types of content that the tool creator users aren't supposed to create? LinkedIn might say it only lets users create plain text with links, not headings. Is the fact that users will try and add faux bold text and whitespace instead of headings LinkedIn's fault or the user's?
guide: that tools tell authors about accessibility issues and help them get it right. I would love for more authoring tools to do this (see also my pledge in Your CMS is an accessibility assistant). Let authoring tools guide authors to more accessible content, this should have a large multiplier with fewer barriers across the web as a result.

What I like about the “guide” part especially: it addresses problems where they surface first. It lets authors fix accessibility problems before they ship to production, if the authoring tool guides them.

Other requirements

We didn't get to the other clauses, but they are interesting too:

preservation of accessibility information in transformation: a real example I dealt with: if you turn HTML into PDFs with PrinceXML, it's tricky to get it to take the text alternatives from your images and embed them correctly into the PDF.
repair assistance: there are CMSes already that tell authors when they're about to choose a new colour that would cause contrast issues (like WordPress' editor). Again, this lets authors fix problems before they exist in the produced content. Drupal has a list of modules that may improve accessibility.
templates: when templates are available, accessible ones should be available. Again, a focus on making accessible templates could have a huge multiplier effect, as they could be reused in many different places. WordPress has a list of accessibility themes

Summing up

It was fun to dive into one of the requirements specifically, and my hope is for two things. First, I'd find it useful for there to be more extended guidance on these clauses. They are fairly minimal and more concrete examples would help. Second, the testability could improve. What makes a template an accessible template (one that meets WCAG?), what sort of assistance is sufficient, and what sort of “guiding the author” is? And then my last open question would be: when does an authoring tool fall into or outside of the scope of the organisation trying to comply with EN 301 549? Is this when they use an authoring tool or only when they create one? To be continued!

Originally posted as On authoring tools in EN 301 549 on Hidde's blog.

[email protected]?subject=Reply%20to:%20On authoring tools in EN 301 549">Reply via email

Comparing design systems to find the best qualities

2024-08-10T00:00:00Z

It's not easy to build very good UI components. A global effort to try and find the best qualities of components would be a great opportunity to improve components everywhere.

Aren't design systems ultimately a quest to collect the best UI practices across an organisation? Or across multiple organisations, or for anyone in general. This kind of work brings excellent opportunities to improve quality across some scope, organisationally or more widely. And if we do that, why not try and aim for the widest possible scope and go global? In A Global Design System, Brad Frost suggests this:

let’s redirect that rallying cry outside of any individual organizations’ walls and apply it to the world at large.

I can only agree with that. With so many design systems out there, it makes a lot of sense to look at the commonalities between them.

As Brad mentions, we've been doing this at Open UI. The goal of this group is to make it easier for developers to build and style UI controls on the web, by improving the web technologies and standards that they are built with. So far, this lead to features like popover (in Baseline today) and styleable selects (in active development).

How a global design system might work

Brad suggested in his post that we could work towards “common library containing common UI components”, with code and designs and documentation. In his follow up, Greg Whitworth suggests to create a test suite. I like how concrete these ideas are, and I am sure they will help tonnes of developers make better components. But what if we look at this idea more a more abstract way?

There are clearly teams who just want to use concrete components, as-is. But in my work and conversations, I hear demand for something else: to have a way to validate what is good. A lot of teams want to build their own components and systems. Or they have to, because of their organisation's specific constraints.

Finding qualities

To me, it seems a lot of developers want acceptance criteria and holistic guidance, rather than built components. There's a lot of example components already, why not try and collect what's already built and seek consensus about what qualities components need?

I'm thinking things like:

this is how an autocomplete-y combobox should convey new results were filtered
this is the most user friendly keyboard behavior for switching between tabs
this type of buttons needs an active verb as the name

This is information that is relatively hard to find, especially for more rare components, and especially in a format that developers can trust to base their decision making on.

In my ideal world, a global design system isn't primarily concerned with making a set of components. Instead, it would focus on finding the best qualities of components. What are the qualities they must have, in order to be solid, accessible, internationalisable, privacy-friendly, secure component?

Benefits

With this approach, these qualities can become checks for everyone who wants to make these components themselves. And at the same time, they can be checks for everyone who wants to quality-assure or accessibility-assess websites that use these patterns. (Plus, folks could still build an example library of components that adhere to the qualities; but I think there are always going to be multiple ways).

Defining qualities rather than concrete components also helps with another problem we've seen at Open UI a lot: that there are many ways that lead to Rome. For example, there are many ways to build a tab. With qualities, we would avoid the search for the true one way to do something. Instead, we could deem multiple implementations of tabs “ok”. The Org X tab is cool, the Org Y is wildly different, but it is also cool, the Org Z tab is… hm, not great, because it lacks a, b and c.

Lastly, it would help with the myth of the accessible component. There is only so much we can build in, there will always be acccessibility considerations that depend on usage (see my talk on built-in accessibility). Both how you use of the component and the context you use it in determine whether the experience is accessible or not. There's no “use this component and your thing will be accessible“. Paraphrasing Scott O'Hara: a component is accessible until you use it somewhere.

What global comparisons unlock

Aren't we lucky that we're now in a phase of design systems that there are a lot to compare between? Comparing different design systems can unlock a number of things, but these are some things I find particularly interesting:

finding components based on real use cases: if we look at components that already exist, we know someone had a use for them
finding the best names: naming things is hard, and bringing many design systems together bubbles up which names resonate best with people (see the component matrix and component.gallery)
getting closer to ‘accessible patterns’: there are lots of things that can make a given pattern more or less accessible; if we bring together patterns from many places, we can document more use cases, more ways people (end users) might use this pattern (accessibility is largely about how people use the web), and more aspects their accessibility specialists have talked about

Each of these is, in its own way, a benefit of including diverse perspectives. Which is what the W3C has been doing for almost (this year!) 30 years.

A national global design system

Brian Kardell shared his idea for moving components through stages. In it, he says:

[a component] would undergo wide review and get some kind of 'verification stamps' for each kind (a11y, i18n, etc).

He suggests folks submit components, that then get reviewed, which will lead to a catalog of components that have been checked and for which everyone can publicly see how many of the checks they meet.

I liked a lot about this proposal and feel it will be fruitful to primarily focus on checks. I also noticed some similarities to what we're doing at NL Design System, a project I'm involved in for the Dutch government, so I wanted to end this post with describing a bit about our process.

At NL Design System, different governmental organisations collaborate on defining the best components, patterns and guidelines. The core team, that I'm a part of, facilitates this collaboration. It may end up being a kind of national global design system, a standard for building good digital government services.

Relay Model

So how do we work? Each organisation in our community has their own design system. In principle, they use a shared architecture, build components that meet their own needs and open source them under the same license. Components that seem suitable for standardisation are put on a track that we call “Relay Model” (see also this excellent presentation on the Relay Model (Dutch, English subtitles available) by my colleague Yolijn van der Kolk).

In relay racing competitions, runners take a baton and hand it over to the next person. With our Relay Model for components, different people can take a component to different stages.

(Note: there are patterns and guidelines too, but here I'll focus on components specifically.)

In this process, components (their “blueprint”, eg “Button”) can have one of four statuses:

“Help Wanted“: there is agreement on the rationale for the component, organisation(s) that need this can build it.
“Community”: the component exists in one or more organisations, meets a set of acceptance criteria and uses the shared architecture. Each organisation can build it with the bells and whistles they need.
“Candidate”: the component meets more acceptance criteria, including strict accessibility and usability tests, and is deemed ready to become the standard, we solicit real-life feedback in a request for comments period. It is stripped of elements that are too organisation-specific.
“Hall of Fame”: the component is stable, not controversial, and has “guarantees” around reusability, accessibility, usability and stability. This is where a “button” becomes “nl-button”.

There's also two more informal statuses: components that are likely to have just the one use case for one organisation, one-offs, are deemed “Snowflake”, and components that are unlikely to result in accessible, user-friendly components are deemed “Discouraged”.

During any time, components can exist in multiple organisations, so City X, Government Agency Y and Province Z could all have a Button that meet their needs. The “Hall of Fame” Button is the common denominator version of it, where we've tried to remove all the org-specific stuff and stick with features that multiple organisations need. User research is an essential part of all this and we encourage organisations to share theirs as open source Markdown.

Benefits we see include:

legitimacy: based on the needs of specific organisations and their use cases
credibility: the components aren't the result of one person or team's opinions; a combination of wide feedback, user research and collaboration are essential in the journey; “blessing a component” is a largely shared responsibility
open approval process: the criteria and process for moving to the next stage are open (see the GitHub project board for Help Wanted), anyone can steward a component to the next stage, then pass on they if they wanted to
living standard: teams should always be able to innovate. If they need an extra component or variation, they can always make it available as “Community” even when a similar component already exists in the current “Hall of Fame” standard

We're currently stewarding components through the first stages, and don't have a “Hall of Fame” yet. But the process already demonstrates value today, for everyone involved: teams are using one another's components and are benefiting from each other's perspectives, accessibility knowledge and user research.

Summing up

In conclusion: I think there's a lot of value in trying to find which qualities make for very good components, using a standardisation-like process that involves a broad range of stakeholders and avoids blessing-by-a-few. In my ideal world, this can bring us to a place where web developers can get more confidence in how to make their components very good. Recent conversations within Open UI make me hopeful we'll get closer to that.

Originally posted as Comparing design systems to find the best qualities on Hidde's blog.

[email protected]?subject=Reply%20to:%20Comparing design systems to find the best qualities">Reply via email

The open web, MIDI and assistive tech: State of the Browser 2024

2024-09-15T00:00:00Z

Yesterday, I was at State of the Browser in London. It was great to catch up with friends and make new ones, and the talks were once again very well curated. In this post, I'll share some notes from the day and the takeaways that stood out to me the most.

The Barbican tube station

Think about funding the web ecosystem

Stephanie Stimac kicked us off with a brilliant talk on how to fund the critical infrastructure that is the web ecosystem. We couldn't browse the web without browsers, and they wouldn't exist without engines, that are hard to make, and to fund. In the current model, browsers get large amounts of money from search deals. For instance, in 2021, Google paid almost 20 billion (not a typo) to Apple to make its search engine the default (but a US federal judge ruled that such payments unlawfully limit competition). It's a lot of money, but as that money goes primarily to the browser companies, not the engines, and may go away if search deals are deemed illegal, we need to think about new ways to fund browser engines, Stephanie urged us. They could include donation based systems, tax breaks or a Web Levy. For more context, see Stephanie's slides and in the comments of w3c/breakouts-day-2024#20.

Participate in accessibility standards

Next up was fashion designer and web accessibility advocate Steve Faulkner. He shared some of his own web standards stories and gave practical tips around how to participate. Without naming (many) names, Steve very accurately explained some of the different types you'll find in standards meetings: there are well-meaning, argumentative, axe to grind, practical, clueless, old school, helpful, true-believing, revisionist and lurking type of people. There are a number of ways people do participate: you can file issues (like in w3c/wcag), comment on issues, file PRs, comment on PRs, join a Community Group or join a Working Group. Only for that very last one, you actually need to represent a W3C Member. What you do need to do, Steve warned, is to know when you don't know. It's fine to just listen before having strong opinions. Now, starting to participate can be hard and/or daunting, so to anyone reading this: feel free to slide in my DM/email, we can (always) use more perspectives.

Different types

Advocate for the open web

Stuart Langridge shared the story of how he and others at Open Web Advocacy ended up talking to regulators about anti-competitive behaviour in our industry, including the fact that iOS doesn't allow for other browsers than Safari. Their work has had an enormous impact, as it helped regulators understand the nitty gritty details of what they were regulators. “The web is ours”, Stuart said and anyone who believes the same can join and help out at Open Web Advocacy, or do their own advocacy for an open web. Amen to that!

Make impact

Gayle Ngozi shared how the non-profit Code your Future works with refugees and disadvantaged people to get skills in software engineering to close the gap between them and the job market, specifically in the tech industry. She said we can all make impact by contributing stuff like laptops, time by teaching and/or opportunities by working together to launch new tech careers.

Make little web components

Personal website innovator David Darnes finally explained the inner workings of that cool button on his site that announces his name spoken by different people every time you press it. He didn't cover why it has a bias towards his father's recording, but it was very interesting nonetheless. There's one component that upgrades the standard <audio> element to be a fancy button, another that randomises the source used and one more that makes the playing state available as an attribute so that it can be used in styles. Are Web Components just for little bits? No, Dave showed that it's also used in fairly complex applications he worked on, including at Nordhealth, that has both Nuxt and Django apps using the same components. The technology, Dave said, works so well because is versatile and forgiving.

Make standards open

Katie Fenn is a huge Daft Punk fan, so she used her talk slot to play their “Around the world” with web technologies: the WebMIDI and WebAudio APIs specifically. MIDI is a technology and technical standard specced in the 80s that allows you to pass messages and information between musical instruments, like notes and special effects. Because it was, just like the W3C's web standards, completely open and royalty-free, it's changed music production forever, especially electronic music: yay open standards. You should watch this talk when it comes out. I can't wait to go play with the MIDI-enabled devices in my home.

Synthesisers!

Automate more of assistive technology support testing

Lola Odelola showed how web standards work happens by using the ARIA-AT program (and ghost detection 👻) as an example. Many developers will be familiar with the ARIA Authoring Practices Guide. I am very happy for this to exist, but also see gaps in user testing (do real users actually; understand how to use the patterns?) and AT testing (do the patterns work in AT and is that consistent?). ARIA-AT, Lola showed, addresses the latter, and does so really well: there is a Selenium-like protocol called AT Driver to automatically test how the ARIA patterns work in different assistive technologies, with lots of reports as a result. Loved hearing Lola talk about this important project, that I hope can be built out further.

Use fluid scales

Richard Ruttter showed us how to use fluid scales for typography and spacing, I feel inspired to go and try that out on this website when I get a chance. See also what I wrote about that talk at Patterns Day.

Summing up

It was a lovely day, with great talks and conversations. One of the recurring themes was how much extreme capitalism affects the ecosystem we all clearly share a love for, we learned about various concrete ways in which this is at play. At the same time, we shouldn't forget to focus on what is valuable in and of itself: making music, fun buttons and UIs that include everyone. Priorities matter!

Originally posted as The open web, MIDI and assistive tech: State of the Browser 2024 on Hidde's blog.

[email protected]?subject=Reply%20to:%20The open web, MIDI and assistive tech: State of the Browser 2024">Reply via email

Trains are offices

2024-11-29T00:00:00Z

Taking the train for work travel can cost more time than going by car or plane. But it's one of the most energy efficient ways to travel, and I get this weird productivity boost from them.

Note that you can absolutely also chill out, read, sleep or listen to music on trains. I like that too, sometimes. But this post is about when I use train time to work. In Europe.

Enjoy the benefits

As mentioned in the intro, a major reason for my traveling by train is the low environmental impact (relatively, and apart from not traveling). I travel a lot for work, so my impact is relatively high, especially when I don't manage to avoid planes. Despite doubts about effectiveness of compensation, I do compensate in various ways, but it still doesn't feel great, avoiding is ideal.

Trains also offer a productivity boost. If you're forced to be in a seat, on a connection too unstable to take work calls, this presents an opportunity. An opportunity to get things done (no I am not for hire as a productivity coach).

gitI don't know what it is about trains, but I really find the time flies when I have something specific to write, code, or design. Trains have proven themselves as great offices to me. I don't know if I can convince my bookkeeper that train tickets are in fact office rental costs, but do you see how they can feel like that?

There are some more benefits to trains:

good views. Depending on your route and time of travel, there's always plenty to see outside. Sunrise and sunset are particularly nice.
arrival in central locations. European train stations are usually close to where the fun happens.
less checks. Within Schengen, international trains usually don't have border checks or luggage checks, so there's a lot less hassle and queuing, you can show up and go.

Embrace the caveats

Things can go wrong, too. Like with any kind of travel.

Delays

If your international train has stopovers, delays can be a headache. Especially between train companies. Plan for stopover time and consider flexible tickets for onward journeys. And stay calm: it happens. Also, in Europe, you have lots of rights re train delays and will have travelled partially for free when delays happen.

Data

Large parts of Europe don't have stable mobile data, especially outside cities. Or, depending on your plan, you don't get a great connection roaming. Have some of your work available offline so that poor connection doesn't interrupt you. Know which web apps to trust (the progressively enhanced parts of GitHub are the best).

Power

Not all power outlets will work, so I follow the ‘ABC’ rule: Always be charging when you have the opportunity, so that batteries are full and ready to go when you don't.

In conclusion

Trains are nice, and their benefits outweigh the caveats, especially if you anticipate those in advance. I'm curious if people have found other benefits or caveats regarding taking the train for work. What's exciting you or holding you back? Feel feel to reply by email or via Mastodon or Bluesky.

Originally posted as Trains are offices on Hidde's blog.

[email protected]?subject=Reply%20to:%20Trains are offices">Reply via email

Turn off AI features by default (to reduce their climate impact)

2024-11-30T00:00:00Z

Generative AI features have a large climate impact and water consumption. We can weigh that impact against those features' benefits, but what if they are left unused? If lots of people don't in fact use the thing? That seems like lots of avoidable waste. Which matters, we're in a climate emergency and we're dangerously far from that 1.5 degrees target.

I know, we all want people to use features we build, but it is safe to assume they often don't. For my business, I use a lot of very beautiful self service portals that I only ever log in to, to download a PDF that my accountant needs. The beautifully considered UI, fancy spinners and clever copywriting are there, but if I'm honest, I mostly ignore them (sorry).

Is that ok? A button in your app that your user doesn't press, wastes little energy. But if your app automatically generates summaries, captions or suggestions, and the user didn't want or use that functionality, a lot of energy and water was wasted. While serving no purpose. It's that combo of waste and purposelessness that we should avoid at all times.

Wait, that's absurd, you say. Does this really happen? Yeah, I come across it all the time, and it's not just because I'm somewhat of a luddite myself.

Features I didn't use

Some examples of AI features that ran on my behalf just in the past week, but that I didn't use:

Loom's transcripts and automated titles and descriptions. They show up almost instantly after upload. I always remove them, they fail to get the point across, which I want to do pointedly to save colleagues reviewing a video time.
Parabol's automated summary of team retrospectives: it emailed us key points, some incorrect. While we had written them down correctly already.
Notion's AI assistance that shows up whenever you press ‘Space’. Ok, granted, it only runs once you've actually typed a prompt, but it's a good example for this post, as it's one of those I hear many people want to turn off, and you can only do that “on Enterprise“, according to this Reddit topic dedicated to turning that feature off.

Of course, these features are not redundant if users benefit from them. But let's be real, oftentimes users didn't want to generate anything. It happened anyway, and was unsolicited. They will probably discard of the output. In those cases, the energy-intensive feature was redundant. And that's an issue, as we don't have redundant energy.

Meanwhile, most major tech companies announced they are letting go of their net-zero goals. Some have bought nuclear power plants to cater for their energy needs (see Microsoft's plans with the Three Mile Island plant). This confirms to me that we don't have abundant energy. Maybe one day, but not today.

An ethical web

Is this ethical? The W3C's Ethical Web Principles have a specific principle that applies here: 2.9 The web is an environmentally sustainable platform.

It suggests new technologies should not harm the environment:

We will endeavor not to do further harm to the environment when we introduce new technologies to the web (…)

and recognises people who benefit are not always those who are harmed:

and keep in mind that people most affected by the environmental consequences of new technologies may not be those who benefit from the features introduced.

If a feature is useful for some, but indirectly causes the energy or water bills to go up for others, we're breaking this Ethical Web Principle.

Conclusion

So, I'm just a guy sitting behind a keyboard, begging anyone including generative AI features: only put them to work when users indicate they want that to happen. That's also going to turn out cheaper when OpenAI increase their rates, which is likely as investors are going to want returns. Why not consider leaving out that new LLM-powered feature in the first place: not everything needs to be “artificially intelligent”, sometimes a bunch of if statements make a killer feature (dude, that's so paternalistic and you're oversimplifying the realities of software engineering, you say… yeah, sorry, I'm trying to react to the overcomplexification that also happens).

Do you have other examples of software that forced LLM generated content on you? Let me know and I'll add them to the post.

What I got up to in 2024

2024-12-29T00:00:00Z

It's only a few days until 2025. That means one thing: it is time for my yearly tradition of reviewing… some of my year. I'll cover work, conferences, reading, writing and music.

This will inevitably sound cheesy, but I am once again genuinely grateful for the opportunities I got… there were fun projects at work, I got to see some of my dearest artists live and I got to share knowledge and opinions at events among some of my favourite peers. At the same time, the last few months have, honestly, been intense, and I am looking forward to take a few breaks in January.

I also can't not mention politics. I saw a number of sad elections results. I saw people chose to vote, basically, against other people. It was heartbreaking to see people vote against women, against trans people, against people who crossed borders, and also against the odds for humans to inhabit this planet… and some major tech leaders chose to embrace, encourage or cheerlead that. Booh.

Some say one should focus on things one can impact. I'm not always good at that, but I'll do it now, by sharing a bit more about my year in terms of projects, conferences, reading and listening.

Projects

I spent most of my time on two projects for the Dutch government: NL Design System and the digital accessibility (standards) team at Logius.

At NL Design System, I got to organise another Design Systems Week, and worked on accessibility testing, guidance for forms and WCAG (both in Dutch), communication strategy, events and our website. At Logius, I worked on growing our participation in international standards discussions, specifically accessibility standards like WCAG and EN 301 539, at W3C and ETSI. It's been really cool to get back into familiar groups and join new ones (like the TC and JTB; yes I learned new abbreviations why).

Next year I'm increasing my time for standards at Logius, which, sadly, also means I'm leaving the NL Design System team.

From February, I'll have some availability for new projects, too: ~2 days/week to work on accessibility, frontend and/or design systems, do get in touch if you can use help.

Conferences

It's been a very busy and very fun year in conferences (I recommend going to conferences, for all reasons Sophie outlines in her post You should go to conferences).

Some talks I liked:

The art of reflection by Imran Afzal at All Day Hey
Feminism in programming language design (start at 20:50) by Felienne Hermans at Joy of Coding
The many lives of a notification by Sarah Highley at Accessibility Toronto

I loved speaking at a number of them, too. I got to meet new people in the industry and hang out with friends. Even if it is nerve wracking at times, it gives me a lot of energy.

Creativity, art and AI

In October, I presented a new talk called Creativity cannot be computed at Beyond Tellerrand in Berlin. I talked about what's great about arts and creativity, in the context of our industry's tendency to leave stuff to computers. I love computers and art both, but we've got to prioritise. Some of this has been in my head for the last decade, and I loved to hear how it resonated with people in conversations after (maybe partially because I can't seem to shut up about it, sorry to all affected). I plan to write more about art and AI on my blog, but you can already read along with the slides or watch the video.

Acccessibility

Another new talk was Built-in accessibility: blessing or curse, which combined some of my earlier talks on tooling, browsers and CMSes with what I learned about design systems at NL Design System, all to uncover a general theme: that building in accessibility is not a one size fits all solution, but when done right, can be a sound part of your accessibility strategy. I gave this talk at A11y Club Amsterdam and at Accessibility Toronto.

Popovers

Earlier in the year, I did the most northern iteration of my popover talk (video) at All Day Hey in Leeds. I was very happy how it turned out and it was great to visit this city and this event that I had heard so many good things about.

My shortest talks were at Joy of Coding in my home town of Rotterdam, where I spent 5 minutes rambling about software and accessibility, and Mozilla's performance.sync() meetup in Amsterdam, where I talked about Open UI and reducing bundle size.

In the next year, I'd like to talk about web sustainability more, and continue to cover accessibility, design systems and AI/art.

Reading

I read some books this year, two of my favourites were:

Character limit: how Elon Musk destroyed Twitter; a lot of the shocking facts in this book were public knowledge already, but Ryan Mac and Kate Conger did a wonderful job telling how the events unfolded, the details make one fear a world in which Elon Musk has any influence.
Against technoableism: : seeing people with disabilities as an “inspiration” or needy of technological “fixes” is problematic, this book explains why.

These blog posts from others are among favourites this year:

Coming Home by Mandy Brown
Generative AI is for the idea guys by Rach Smith
The Dilemmas You'll Face When Creating a Component Library by Andrico Karoulla
We have a content quality problem, not a content quantity problem by Cory Dransfeldt

Music

Three albums that came out in 2024 that I liked:

Odyssey by Nubya Garcia (jazz saxophone with orchestral arrangements, vocals and more).
Lives Outgrown by Beth Gibbons (of Portishead fame, it grew on me).
Drop 7 by Little Simz (hip hop, it feels more free and experimental than her previous work).
IJsland by Abel & Sef (Dutch punk hip hop that I loved almost instantly).

In live music, it was a good year… I stayed on top of who's touring and ticket acquisition, and managed to see many faves. Most liked: IJSLAND, Massive Attack and Robert Glasper. I also made a point of going to see stuff when traveling, a tradition I hope to keep, though it gets expensive when traveling outside of Europe and its subsidised cultural venues.

In music making: I am picking up playing piano again and have joined a choir, which has been on of my best decisions, it is so much fun. As usual, I should have listened to a friend's advice earlier.

Writing

With 10 posts in total, I didn't write as much on this blog in 2024. I don't know which were most read, but these got some good feedback:

On popover accessibility: what the browser does and doesn't do (co-written with Scott O'Hara)
“AI” and accessible front-end components: is the nuance generatable?

Cities

Outside The Netherlands, I spent time in Duisburg, Berlin, Taipei, Tainan, Kaohsiung, Brighton, Antwerp, Paris, Leeds, London, Bad Schandau, Brussels, Los Angeles, Toronto, Liverpool, Vienna.

Self study

I did a bunch of self-study:

Josh Comeau's The Joy of React. It was indeed joyful, and the most down to earth overview of React I've seen so far.
the IAAP certification exams. I'm now a CPWA, which is both WAS and CPACC. I have more to say about this, maybe some other time or 1:1.
I worked with Melinda on specific parts of my public speaking, I would absolutely recommend her to anyone looking to learn.

Wrapping up

I wanted to write up some resolutions for the next year, but I ran out of time. I guess I'll leave it, as a resolution itself, for the next year. If you're reading this, I wish you all the best for the new year!

Originally posted as What I got up to in 2024 on Hidde's blog.

[email protected]?subject=Reply%20to:%20What I got up to in 2024">Reply via email

Hidde's blog

Styleguides for better front-ends

Style guides for better front-ends

World Usability Day in Bristol

Dan Klyn: practical abstraction

Alistair Duggin: the BBC’s accessible olympics website

Andrea Resmini: cross channel experiences

Mark Boulton's grid system design workshop

Types of grids

Terminology

On hanging lines

On gutters

On DNA of grids

Designing a grid system

Putting it into practice

Handheld 2013: the web's structure, expectations and data poetry

The conference

Some talks I loved

The long web

How to call your client an idiot without being fired

Data poetry

And more…

Unobtrusive icons

Icons preceding descriptive links

Icons with descriptive fallbacks

Text as the most basic alternative

Meeting the TAG

The TAG?

The meeting

Archeology

DRM

Web Components

URLs

Embedded video in responsive lay-outs

Forcing an aspect ratio-respecting height

Extra step for WordPress users

Notes

State of the Browser 2014

Fernando Campo & Borja Salguero – Firefox OS: not only promises

Recent improvements

Ideas behind Firefox OS

Andreas Bovens – Intro to @viewport & other new Responsive Web Design CSS features

1. @viewports

Not a standard

2. Resolution media queries

4. Viewport percentage widths/heights

Ruth John – Browsers at play

VJ’ing with CSS Animations and WebAudio API

Jake Archibald – Network connectivity: optional

Service workers

What the web can do vs what apps can do

Martin Beeby – High-performance web platform

Yoav Weiss – Brace yourselves – responsive images are coming

vs srcset

picture 2.0

The sizes attribute, variable widths

Dan Donald – What it means to be flexible

Chris Heilmann – Open web apps

Q&A

Q: How will HTTP2 change any of the thinking about responsive web design thinking?

Q: How can we be a web industry that women don’t feel alieniated in?

Q: Everyone keeps talking about “the web platform“, what is a platform and should we want the web to be a “platform”?

Q: How can we make the web platform a better platform for games?

Q: How will Web Components change the way we work on the web?

Q: What is the future state of deep linking from web apps? And into web apps?

Conclusion

Keeping it simple

Museums Get Mobile!

Andy Budd – Responsive design is easy

Designing for changing museum audiences in-gallery and online

Ivan Teage

Frankly green + webb

Léonie Watson

Making responsive design a reality: accessibility and content strategies and commissioning content strategies

Andrew Lewis – thinking holistically about mobile-responsive services

Dan Goodwin – Collaborative discovery: commissioning a big web project when you’re not sure what you want

Shelley Mannion – Learning from mobile experiences in museums

Conclusion

Responsive Day Out 2 - the squishening

Part 1: Stephen Hay, Sally Jenkinson and Ida Aalen

The `sizes` attribute, variable widths