Declaring Page Language—and Declaring Changes in Language

Published on September 29, 2021, filed under Development (RSS feed for all categories).

This is a follow-up for Comparing Page Language Declaration Setups in Screen Readers. It’s not required to read that article first, but it does give context.

When just testing language handling of HTML pages in screen readers, I didn’t observe particular issues around the declaration of page language; but there were some around unmarked changes in language: Popular screen readers didn’t seem to pick these up.

For example, if I add an unmarked German expression here, like ein Ausdruck auf Deutsch, a screen reader is likely to pronounce it in English. It would not detect and read it in German (yet).

Quick note: None of this is new—I’m using recent tests to share observations and thoughts.

Focus on Changes in Language

From what we may be able to tell from the page language test this issue looks like the bigger problem of the two. Fixing it may need two things:

1. a push on screen readers to improve detection of changes in language (always try to let software do the job); and
2. a shift of attention from declaration of page language to marking up changes in language.

No matter how hard the problem, we benefit from pushing on software solving problems for us. How we talk about these and other accessibility problems is what has on more than one occasion worried me: We promote solutions that require millions of site owners, developers, and editors to take action, rather than focusing on the handful of vendors in the respective space to solve the problems there, as much as possible. (This is a generalization and a simplification, but I observe more pressure on developers than on vendors. I strongly believe this needs to change, because focusing on vendors is more efficient and more reliable.)

But for the second part, our attention, this may be a bigger necessity for us than the requirement to put lang on every html start tag. This probably needs more focus.

Minimal HTML and Marking up Changes in Language

Not to argue against it, but I still like to submit what problems I see with marking up changes in language as an HTML minimalist. What makes declaration of changes in language ugly is that

1. it comes without alternatives to doing it on an HTML level (like an HTTP header as with page language);
2. it means more markup (minimalist: always prefer less); and
3. it requires more discipline to set up and maintain than declaring page language.

❧ The point is that marking up changes in language looks like an issue in need of more attention than the declaration of page language; and it suggests to start with a hard push on the vendor side, to limit the effect markup solutions have on site owners, developers, and editors, as well as the code they produce.

I’m curious about other perspectives; either here, while the comments are open, or in response to this post’s tweet. Thank you.

Many thanks to Thomas Steiner for reviewing this post.

About Me

I’m Jens (long: Jens Oliver Meiert), and I’m a frontend engineering leader and tech author/publisher. I’ve worked as a technical lead for companies like Google and as an engineering manager for companies like Miro, I’m a contributor to several web standards, and I write and review books for O’Reilly and Frontend Dogma.

I love trying things, not only in web development (and engineering management), but also in other areas like philosophy. Here on meiert.com I share some of my experiences and views. (Please be critical, interpret charitably, and give feedback.)