search

w3c / wcag

Web Content Accessibility Guidelines
https://w3c.github.io/wcag/guidelines/22/
Other
1.09k stars 243 forks source link

Hidden content in bi-lingual websites #3884

Open guyhickling opened 3 months ago

guyhickling commented 3 months ago

A problem frequently arises on websites when whole pages, or portions of content, are translated into another human language. For instance, English websites of UK government agencies are always expected, due to the Wales/England relationship, to be translated into Welsh as well. Some agencies don’t go the whole hog and convert the whole website, but do collect some of their more important content into a few Welsh pages. The same happens in Canadian government websites which provide French versions for Quebec, and vice versa. And I expect (though I haven’t checked this) that Belgium has a lot of its websites in French and German. Similarly for numerous other bi-lingual countries. What almost invariably happens in such translated sites is that the visible text is translated, but any hidden texts are left untranslated. This includes (but I have probably missed some things): • alt texts • aria-label attributes • any texts hidden by CSS for screen readers • aria-roledescription attributes • the element in the <head> section • the <title> elements of svg elements • title attributes of iframes</p> <p>The problem arises mainly, I think, because no one among the developers marking up these translations thinks about the hidden stuff – and that in turn is because the WCAG doesn’t mention it! Government websites in all the countries I’ve mentioned, and many others, try to be WCAG compliant, but the people concerned in the work (designers and developers) just don’t think beyond that, and don’t realise how screen reader users experience the page. If the WCAG were to mention it, people would do it.</p> <p>So, I propose that a new success criteria be added to the WCAG, one that is generic enough to cover all kinds of text and attributes, in all situations of multiple languages. It should not even mention “translation”, to be totally generic. Something like:</p> <p>“Any hidden (non-visible) content in a portion of content is in the same human language as is used for the visible content. Exceptions to this are permitted: a) when a small visible item is in a language different from the content around it for linguistic reasons, but it would not make sense for associated text for assistive technology users to also be in that language, and b) when the available underlying technology cannot create a hidden item in the required language.”</p> <p>The related understanding document should then show the same list of items as I show above, describing it as a “non-exhaustive list” to allow for anything else, to clarify what we are expecting developers to do. (And it would also need to state that the exception (b) does not mean that the alternative texts can be omitted completely, only that they need not be translated into the other language.)</p> <p>The above would cover both the cases of entire pages translated, and of portions of a page being translated. It would also cover cases where a page holds content in one language in half the page, and in a second language in the other half. The exception (a) allows for a foreign language phrase, or a single sentence, to be used without translating an attached attribute, so the attached attribute would remain in the same language that is used for all the other screen reader texts on the page.</p> <p>I am aware that it was not the intention to go beyond update 2.2, but this language problem is far too common. I strongly advocate that this should not wait for WCAG 3 to appear in the future, but should be added into a new WCAG 2.3 update now, because the modern proliferation of language translations, in many countries, make this an urgent need. I frequently have to audit Welsh page translations created for public sector organisations and agencies in the UK, and I almost never (I only ever saw one site do it right) see these screen reader items translated. This also happens a lot in other bi-lingual countries so, to me, it seems important enough to consider making one more 2.x update for. I think if it is sufficiently generically worded, then it should not be difficult to quickly arrive at a suitable wording for such an SC, working from the above suggestion as a start. And if we close some of these outstanding loopholes now, that will be less new work to go into WCAG3?</p> <p>NB: A GitHub issue has been raised specifically for similar issues with video audio descriptions and captions in a different language to the video audio track (see #3873). However, they are relatively rare (I think?) whereas this basic problem of screen reader alternative texts Is very common indeed. So I suggest this SC to cover all hidden, screen reader text. I don’t think it should also cover captions and audio descriptions and transcriptions, I think they would be better in a separate SC - also for a 2.3 update I suggest. </p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/patrickhlauke"><img src="https://avatars.githubusercontent.com/u/895831?v=4" />patrickhlauke</a> commented <strong> 3 months ago</strong> </div> <div class="markdown-body"> <p>you <strong>can</strong> currently fail this for not marking up the change in natural language, if you need something right now to hang this on</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/guyhickling"><img src="https://avatars.githubusercontent.com/u/30391059?v=4" />guyhickling</a> commented <strong> 3 months ago</strong> </div> <div class="markdown-body"> <p>Thank you. However lang attributes aren’t really part of this, I’m assuming they are hopefully all present and correct so nothing to hang anything on. This is about giving Web pages translated from English into in German (for example) to German users, but leaving their blind people to have to listen to alternative texts in English, which they may not even understand.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/patrickhlauke"><img src="https://avatars.githubusercontent.com/u/895831?v=4" />patrickhlauke</a> commented <strong> 3 months ago</strong> </div> <div class="markdown-body"> <p>if there's a change of language on the <code>img</code> element for its alt, and the devs <em>haven't</em> explicitly marked the change of natural language on the element, it's a failure. i doubt they currently have the page with <code>lang=de</code> and the image has explicit <code>lang=en</code> ... so they can be failed on that. sure, if they then fix the technical aspect by adding the language attribute, it's then technically valid. but more likely this can be used as the "hook" to make them actually fix the underlying mismatch of languages.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/JAWS-test"><img src="https://avatars.githubusercontent.com/u/52748763?v=4" />JAWS-test</a> commented <strong> 3 months ago</strong> </div> <div class="markdown-body"> <p>@guyhickling The problem does not only occur in multilingual countries, but actually everywhere. Most of the world's frameworks are in English and most of the world's websites are built with frameworks. So what happens when web developers build a site with a framework? They only adapt the visible labels to the local language, they usually don't notice the others (e.g. aria-label on graphical buttons). These then remain in English. I always judge this as a violation of 2.4.6, because a foreign language label is not meaningful. It is also a violation of 3.1.2, because of course the language change is never marked.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/mbgower"><img src="https://avatars.githubusercontent.com/u/14298245?v=4" />mbgower</a> commented <strong> 3 months ago</strong> </div> <div class="markdown-body"> <p>thanks for this issue. It is related to #3873 and based on working group discussion about that at our last meeting, I am hoping to come up with language and an approach that tackles both situations.</p> <p>Note that there is no plan for 2.3, but we have also added this concept to 3.0 considerations <a href="https://github.com/w3c/wcag/wiki/WCAG-3-parking-lot-considerations-from-2.x">https://github.com/w3c/wcag/wiki/WCAG-3-parking-lot-considerations-from-2.x</a></p> </div> </div> <div class="page-bar-simple"> </div> <div class="footer"> <ul class="body"> <li>© <script> document.write(new Date().getFullYear()) </script> Githubissues.</li> <li>Githubissues is a development platform for aggregating issues.</li> </ul> </div> <script src="https://cdn.jsdelivr.net/npm/jquery@3.5.1/dist/jquery.min.js"></script> <script src="/githubissues/assets/js.js"></script> <script src="/githubissues/assets/markdown.js"></script> <script src="https://cdn.jsdelivr.net/gh/highlightjs/cdn-release@11.4.0/build/highlight.min.js"></script> <script src="https://cdn.jsdelivr.net/gh/highlightjs/cdn-release@11.4.0/build/languages/go.min.js"></script> <script> hljs.highlightAll(); </script> </body> </html>