Reading List

The most recent articles from a list of feeds I subscribe to.

Twitter needs manual language selection

hiddedevries.nl Blog

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:

screenshot of tweet creation widget with a set language button; the tweet says in Dutch that I would like to share my opinion on using clasnames for everything 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: 

<html lang="en">

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:

website screenshot, there is English text with Chinese text alongside of it, and links to YouTube videos 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:

three tweets by Ursula von der Leyen, in French, German and English with dev tools open and each tweet pointing to the lang attribute in the markup 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.

The post Twitter needs manual language selection was first posted on hiddedevries.nl blog | Reply via email

Twitter needs manual language selection

hiddedevries.nl Blog

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:

screenshot of tweet creation widget with a set language button; the tweet says in Dutch that I would like to share my opinion on using clasnames for everything 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:

website screenshot, there is English text with Chinese text alongside of it, and links to YouTube videos 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:

three tweets by Ursula von der Leyen, in French, German and English with dev tools open and each tweet pointing to the lang attribute in the markup 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.

Reply via email

2021 in review

hiddedevries.nl Blog

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:

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!

The post 2021 in review was first posted on hiddedevries.nl blog | Reply via email

2021 in review

hiddedevries.nl Blog

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:

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.

Reply via email

How many people with disabilities use our site?

hiddedevries.nl Blog

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.

The post How many people with disabilities use our site? was first posted on hiddedevries.nl blog | Reply via email