Declaring Page Language—and Declaring Changes in Language
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:
- a push on screen readers to improve detection of changes in language (always try to let software do the job); and
- 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
- it comes without alternatives to doing it on an HTML level (like an HTTP header as with page language);
- it means more markup (minimalist: always prefer less); and
- 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.
I’m Jens, and I’m an engineering lead and author. I’ve worked as a technical lead for Google, I’m close to W3C and WHATWG, and I write and review books for O’Reilly. I love trying things, sometimes including philosophy, art, and adventure. Here on meiert.com I share some of my views and experiences.
If you have a question or suggestion about what I write, please leave a comment (if available) or a message. Thank you!
Maybe this is interesting to you, too:
- Next: Making the Web Developer’s Pilgrimage
- Previous: Comparing Page Language Declaration Setups in Screen Readers
- More under Web Development, or from 2021
- Most popular posts
Looking for a way to comment? Comments have been disabled, unfortunately.
Get a good look at web development? Try The Web Development Glossary (2020). With explanations and definitions for literally thousands of terms from Web Development and related fields, building on Wikipedia as well as the MDN Web Docs. Available at Apple Books, Kobo, Google Play Books, and Leanpub.