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.

Reply via email

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.

Reply via email

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.

Reply via email

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.

Reply via email

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.

Reply via email