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.

Reply via email

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.

Reply via email

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.

Reply via email

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.

Reply via email

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.

Reply via email