W3C

Results of Questionnaire Review of WCAG 3 Pronunciation of Text

The results of this questionnaire are available to anybody.

This questionnaire was open from 2022-06-09 to 2022-06-14.

21 answers have been received.

Jump to results for question:

  1. Add Changes to Natural Language Outcome as Exploratory
  2. Add HTML lang attribute indicates the language of text Method
  3. Naming
  4. Pronunciation of Text Outcome
  5. HTML lang attribute method

1. Add Changes to Natural Language Outcome as Exploratory

Please review the "Changes to Natural Language" outcome.

The Test Reliability subgroup has written the "Changes to Natural Language" outcome, which is part of the new "Pronunciation of Text" guideline. This outcome is proposed as WCAG 3's equivalent to WCAG 2 success criterion 3.1.1 language of page, and 3.1.2 language of parts.

The subgroup has tried to address recent comments from AGWG, and requests the outcome be added as exploratory to the WCAG 3.0 Editors Draft. Do you:

Summary

ChoiceAll responders
Results
I approve this outcome to be added to the WCAG 3 editor's draft as exploratory 7
I approve this outcome to be added to the WCAG 3 editor's as exploratory with the following editor's notes (list items that need to be addressed before the content moves to Developmental in the comments)
Something else 5

Details

Responder Add Changes to Natural Language Outcome as ExploratoryComments
Wilco Fiers
Suzanne Taylor
Isabel Holdsworth
Jonathan Avila
Shawn Lauriat
Jennifer Delisi
Todd Libby
Sarah Horton
Mary Jo Mueller
Ian Kersey I approve this outcome to be added to the WCAG 3 editor's draft as exploratory
Gundula Niemann Something else I do not feel comfortable with the wording in several points:
The outcome is referred to as "changes in natural language", while the intended outcome is a correct pronounciation according to the natural language.
The request only refers to 'blocks as text', which implies that headers, table cell entries and other text which is not a block of text do not fall under this rule. (I do not like this idea).

Next, it still remains unclear whether the rule implies to request from assistive technologies to implement correct pronounciation rules.
Oliver Keim Something else Does the future text of "Pronunciation of Text" (currently 404) not automatically expose the underlying need the speech output agent is required to change the language when another language (than the current) is detected while announcing texts/pieces of text/blocks of text?
Michael Gower Something else I still believe this wording conflates multiple considerations. As per my prior comments, what a specific AT implements should not be the responsibility of authors. What we should control is that the author has properly marked up the language of the page as well as passages that use a different language.
Francis Storr I approve this outcome to be added to the WCAG 3 editor's draft as exploratory
Shawn Thompson I approve this outcome to be added to the WCAG 3 editor's draft as exploratory
Makoto Ueki Something else Is the guideline "Pronunciation of Text" available to check what is written in it?

If this outcome relates to guideline "Pronunciation of Text" and the guidelines is equivalent to "3.1.1 language of page" and "3.1.2 language of parts" in WCAG, the guideline name should be "Language of page" or something.

There is "3.1.6 Pronunciation" in WCAG 2 which addresses different issue.

For example, many Japanese Kanji characters have multiple ways of "reading" (rather than "pronunciation"). Giving the reading of the words written in Kanji characters allows both sighted users and screen readers to read the characters/words correctly.

But this issue have nothing to do with the HTML lang attribute.

We also need to check how "3.1.6 Pronunciation" will be migrated. Then we might need to rethink the guideline title.
Jeanne F Spellman I approve this outcome to be added to the WCAG 3 editor's draft as exploratory Since the intent of the outcome is being misinterpreted, the Test Reliability group recommends rewording the outcome so it is clear that we are talking about author responsibility, not AT responsibility. We propose: "Authors mark up their content so that assistive technologies using text to speech can pronounce blocks of text in their natural language."

Please see Wilco's response in results for question #4.

We defined "blocks of text" to provide an objective way to determine a minimum requirement when a language change is required. Changing language for the word "croissant" reduces the accessibility for a screen reader user because of the lag in changing language packs. This could change in the future as AT improves, but for now, changing by word is excessive, and "pieces of text" cannot be objectively defined. Is it 3 words, is it 4 words? What is a piece of text? A block can be defined, and note that the definition does include headings and table cell entries. See Block of Text definition -> https://www.w3.org/WAI/GL/WCAG3/2022/methods/html-lang-attribute/#block-of-text-def

Bruce Bailey I approve this outcome to be added to the WCAG 3 editor's draft as exploratory I very much like the presentation!
John Foliot I approve this outcome to be added to the WCAG 3 editor's draft as exploratory
Gregg Vanderheiden Something else this is misnamed. are we changing language or are we ensuring proper pronunciation

this is also a requirement on the user agent -- so should go in a USER AGENT requirements section rather than a Content section.

this looks like an outcome with two provisions -- 1) an author requirement and 2) a user agent (AT) requirement

don't include until cleaned up
Laura Carlson I approve this outcome to be added to the WCAG 3 editor's draft as exploratory

2. Add HTML lang attribute indicates the language of text Method

Please review the proposed HTML lang attribute indicates the language of text Method.

This is a method for the "Changes to Natural Language" outcome from question 1, and is reviewed by AGWG for the first time. Do you:

Summary

ChoiceAll responders
Results
I approve this outcome to be added to the WCAG 3 editor's draft as exploratory 6
I approve this outcome to be added to the WCAG 3 editor's draft as exploratory with the following editor's notes (list items that need to be addressed before the content moves to Developmental in the comments) 3
Something else 2

Details

Responder Add HTML lang attribute indicates the language of text MethodComments
Wilco Fiers
Suzanne Taylor
Isabel Holdsworth
Jonathan Avila
Shawn Lauriat
Jennifer Delisi
Todd Libby
Sarah Horton
Mary Jo Mueller
Ian Kersey I approve this outcome to be added to the WCAG 3 editor's draft as exploratory
Gundula Niemann I approve this outcome to be added to the WCAG 3 editor's draft as exploratory with the following editor's notes (list items that need to be addressed before the content moves to Developmental in the comments) In the introduction it says: "The attribute value must match the natural language of the page title element. "
rather the default language should.
An English text might contain a German sentence (or a French one) or a Japanese word, for example. As a consequence, a correct language attribute would not match the title in those cases.

In addition, the requirement should not only talk about blocks of text, but all kinds of text. rather talk about 'piece of text'.

Links which I assume point to the Glossary don't lead to the glossary entries.
Oliver Keim I approve this outcome to be added to the WCAG 3 editor's draft as exploratory with the following editor's notes (list items that need to be addressed before the content moves to Developmental in the comments) Is the lang attribute only target for a block (like <p>)? The lang switch might be required even within input field content, label texts, etc.
Michael Gower Something else As per my prior comments, the approach appears to perpetuate -- even further distort -- the poor division between objective and subjective tests.
Francis Storr I approve this outcome to be added to the WCAG 3 editor's draft as exploratory
Shawn Thompson I approve this outcome to be added to the WCAG 3 editor's draft as exploratory with the following editor's notes (list items that need to be addressed before the content moves to Developmental in the comments) It states: "Changes in language must be indicated using the `lang` attribute on the closest parent element."

Does that mean if there is many `div` elements surrounding the element with the text in a different language, the condition would fail if it is not the "closest parent element"?

```
<html lang="en">
<h1>This is an example</h1>
<div lang="fr">
<div>
<p>Je suis le pamplemousse.</p>
</div>
</div>
</html>
```

If so would something like this fail also?

```
<html lang="en">
<h1>This is a shopping list in French</h1>
<ul lang="fr">
<li>article de la liste d'achats 1</li>
<li>article de la liste d'achats 2</li>
<li>article de la liste d'achats 3</li>
<li>article de la liste d'achats 4</li>
</ul>
</html>
```

The closest parent element of the other language text is the `li` but it is not the element with the `lang` attribute on it.
Makoto Ueki Something else In the "introduction" tab, in the "When to use and what to do" section, it reads "The attribute value must match the natural language of the page title element."

For Japanese websites, it is not always true. There can be page titles in English for Japanese web pages, such as "Welcome!", "Thank you!" or the names of products, services, shops, restaurants, whatever.

For instance, how about "The attribute value must match the natural language used for most of the view." instead?
Jeanne F Spellman I approve this outcome to be added to the WCAG 3 editor's draft as exploratory Test Reliability group agrees with Gundula's concern about the Introduction instructions: We recommend a change "Ensure that the HTML element has a lang attribute indicating the default natural language of the page. Changes in language must be indicated using the lang attribute on the closest parent element.The lang attribute value must use a valid language tag, for example lang="en" indicates the language as English. "
Bruce Bailey I approve this outcome to be added to the WCAG 3 editor's draft as exploratory Very nice!
John Foliot I approve this outcome to be added to the WCAG 3 editor's draft as exploratory
Gregg Vanderheiden I approve this outcome to be added to the WCAG 3 editor's draft as exploratory I have other concerns but they can come later in discussions for later stage
Laura Carlson

3. Naming

Several people raised concern about the guideline name "Pronunciation of text." If you are concerned, please suggest an alternate name in the comments field.

Details

Responder Naming
Wilco Fiers
Suzanne Taylor
Isabel Holdsworth
Jonathan Avila
Shawn Lauriat
Jennifer Delisi
Todd Libby
Sarah Horton
Mary Jo Mueller
Ian Kersey
Gundula Niemann I understand that the guidelineis not about how assistive technology actually pronounce a text, but about declaring text as being of a specific language appropriately.

I suggest:
"recognition of text language"
or "Declaration of text language"
or simply "Language of Text"
Oliver Keim
Michael Gower Until we sort out (or at least I understand) why the AT and author responsibilities continue to be combined, it's hard to make suggestions.
Francis Storr
Shawn Thompson
Makoto Ueki "Language of text", "Specify Language", "Identification of language" ....
Jeanne F Spellman There will be many outcomes for Pronunciation of Text. We will coordinate with APA to incorporate their work into Pronunciation.
Bruce Bailey Is there are fuller guideline, or is all we have is the name?

I agree that this guideline name is not great. Maybe just "Pronunciation"?
John Foliot
Gregg Vanderheiden (desired) OUTCOME: Correct Natural Language Pronunciation

or

Correct identification of Natural Language
Laura Carlson

4. Pronunciation of Text Outcome

Please review the Pronunciation of Text Outcome. Do you approve this content to be added to the WCAG 3 draft as exploratory?

Summary

ChoiceAll responders
Results
I approve this content to be added to the WCAG 3 editor's draft as exploratory 10
I approve this content to be added to the WCAG 3 editor's as exploratory with the following editor's notes (list items that need to be addressed before the content moves to Developmental in the comments) 5
I do not approve this content to be added to the WCAG 3 editor's draft as exploratory (list reasons for not approving or items that need to be addresses before moving to exploratory in comments) 2

Details

Responder Pronunciation of Text OutcomeComments
Wilco Fiers I approve this content to be added to the WCAG 3 editor's as exploratory with the following editor's notes (list items that need to be addressed before the content moves to Developmental in the comments) We're missing the definitions for the outcome. I think that was a copy/paste error.

@JF: This is about pronunciation by TTS AT. It's just not about achieving flawless pronunciation.

@Mike, @GMN: This outcome is trying to describe what someone needs. Nobody really needs lang attributes. That's a means to an end. The desired outcome for a person using a TTS assistive tech is that text can be voiced in a way they can understand. It doesn't really matter how that happens, as long as it does. If browsers, or AT, or authoring tools can do it automagically, great. If not, content authors need to.

The WCAG 2 success criteria do not do this. That's why the word "outcome" was introduced I think, to get us thinking more in terms out end results, rather than intermediate things like "thing needs name" or "text needs lang". This creates flexibility.

It's a paradigm shift. I don't know if it'll work out, but I think there's enough merit to the idea that it's worth pursuing, see where it leads us.
Suzanne Taylor I approve this content to be added to the WCAG 3 editor's as exploratory with the following editor's notes (list items that need to be addressed before the content moves to Developmental in the comments) It is possible the Outcome name "Pronunciation of Text" will need to be changed to allow more graceful inclusion of other pronunciation-related guidance. See https://www.w3.org/TR/pronunciation-gap-analysis-and-use-cases/

I think the editor's note should also outline whether or not other outcomes are planned/likely that will address smaller pieces of text.
Isabel Holdsworth I approve this content to be added to the WCAG 3 editor's draft as exploratory
Jonathan Avila I approve this content to be added to the WCAG 3 editor's as exploratory with the following editor's notes (list items that need to be addressed before the content moves to Developmental in the comments) This seems to imply that use of lang is the only thing affecting pronunciation of text - it is not. For example, there are many issues related to pronunciation related to words with multiple ways to pronounce, phonetics, spelling and other items discussed here: https://www.w3.org/WAI/pronunciation/

We also have SC 3.1.6 which is about pronunciation of words in ways that can help users - this doesn't seem to be addressed in the methods.
Shawn Lauriat I approve this content to be added to the WCAG 3 editor's draft as exploratory It needs a lot of work, but the exploratory nature of the addition inherently acknowledges that.
Jennifer Delisi I approve this content to be added to the WCAG 3 editor's as exploratory with the following editor's notes (list items that need to be addressed before the content moves to Developmental in the comments) In the functional categories, I think that "without ability to read" should be reworded, or at least qualified to be more inclusive of the types of reading challenges identified in Making Content Usable for People with Cognitive and Learning Disabilities.

Please consider the following use cases:
1. Able to read but may not be able to determine tense (ironically the word read has multiple meanings depending on its pronunciation and context).
2. A person may be able to read many words, but require the support of speech to text for words that are unfamiliar or more complex.

4.4.7.3 in Content Usable states "Most readers can read the word based on the context, and use their visual memory to guess the correct pronunciation. People with impaired visual memory, slow readers, and text-to-speech may often guess the incorrect term or pronunciation. For example, a user with a language disability is trying to sound out a word. They guess three different pronunciations until they find one that makes sense. Unfortunately, many people with language impairments cannot work out the meaning as words out of context may only provide an idea rather than a specific meaning. Text-to-speech often requires these characters to speak the correct word."


Todd Libby I approve this content to be added to the WCAG 3 editor's draft as exploratory
Sarah Horton I approve this content to be added to the WCAG 3 editor's draft as exploratory
Mary Jo Mueller I approve this content to be added to the WCAG 3 editor's draft as exploratory This reads like it is a requirement or outcome for assistive technology, not for the content itself to provide the information for the AT. Most (all?) other outcomes published in previous WCAG 3.0 drafts indicate the gist of what the content does to meet the guideline. So I'm not sure authors would readily understand that it's in what they do or don't do that affects correct pronunciation.

Unsure if this outcome is intended to support the existing WCAG language of page and/or language of parts (as translated over to WCAG 3), but the method for user agent auto-detection of language in content could only be done reliably for larger blocks of text. It could also potentially be done for common terms or phrases that are in a different language from the rest of the content (e.g. the French term "c'est la vie" used in a U.S. English block of text).
Ian Kersey I approve this content to be added to the WCAG 3 editor's draft as exploratory
Gundula Niemann I approve this content to be added to the WCAG 3 editor's draft as exploratory 1) Merely an understanding question from my side:
I would like to understand whether the direction is to request from screen reader vendors that each character and each string is pronounced correctly if it has a known correct pronunciation.

This would imply to request fixing errors found currently in tests as explored for example in http://accessibleculture.org/articles/2008/03/character-references/ , and it would imply handling String.Latin corrrectly, a data type which contains the Latin-based characters of Unicode. I could find only German sources on String.Latin, which suggests it's a German idea.
Some regulations request to use String.Latin, for example https://www.personenstandsrecht.de/Webs/PERS/DE/informationen/zeichensatz/zeichensatz-node.html (in German). A thorough test recently showed that there are reading issues with this datatype in various screen readers.

If these requests are implied, I see no need for an editor's note in this regard.
If an exception is planned in this direction, I'd like to see an editor's note in this regard.
Personally I prefer to request correctness from screen reader vendors, as the current draft suggests.

2) I would like to see an editor's note, that rules for emphasis still need to be explored.
a)
There might be an exception needed for words with the exact same writing but different meanings.
Example: The German word "umfahren".
There is a version emphasizing the first syllable, and it means to drive around something,
and there is a version emphasizing the second syllable which means to drive something over (so it breaks down, usually a traffic sign).
It can be known/guessed only by context in a written sentence.

b) emphasis might be indicated by text style, in which case also an assistive tool could emphasize.

c) emphasis might also not be part of this requirement.
Oliver Keim
Michael Gower I approve this content to be added to the WCAG 3 editor's as exploratory with the following editor's notes (list items that need to be addressed before the content moves to Developmental in the comments) I think the outcome statement has exceeded current technical ability, and also conflated language identification with pronunciation. This outcome has also blended author responsibilities with those of assistive technologies/user agents. I think for purposes of proper normalization of testing, etc., it is in our interest to compartmentalize the author responsibility. I'm not even sure if it's useful to express it in regards to an assistive technology. Clearly, I need to better understand the philosophy behind this approach.

The current wording is:
> Assistive technologies using text to speech can pronounce blocks of text in their natural language.

IMO, a better outcome would be:
>Assistive technologies can identify blocks of text in their natural language.

The current reality is that screen readers can identify passes in languages they cannot pronounce. That is useful. The biggest problem occurs when the user is fluent in the language unsupported by the screen reader. But this does not seem to be an author problem.

In regard to the AT material, this seems to not align to current material in UAAG, which covers some elements of speech configuration https://www.w3.org/TR/UAAG20-Reference/#gl-speech-config But I'm not even sure where else to look for AT specs...

Finally, I think it is a mistake to focus on pronunciation. That's a different problem, above and beyond all the other things pointed out above. PS There is an entirely separate group working on pronunciation.
Francis Storr I approve this content to be added to the WCAG 3 editor's draft as exploratory
Shawn Thompson
Makoto Ueki
Jeanne F Spellman I approve this content to be added to the WCAG 3 editor's draft as exploratory Note that the purpose of this Outcome is to illustrate the writing process for creating reliable, testable Outcomes. AG approved the writing process for Outcomes last fall, but the group wanted to test the process on real WCAG migration material. Out intent is to turn this over to a group that are expert in Pronunciation who will coordinate with other WAI groups and flesh out the work more completely.
Bruce Bailey I approve this content to be added to the WCAG 3 editor's draft as exploratory My understanding is that Outcomes should include intent or benefit. I suggested an addition sentence in the linked Google Doc.

+1 to WF comments.
John Foliot I do not approve this content to be added to the WCAG 3 editor's draft as exploratory (list reasons for not approving or items that need to be addresses before moving to exploratory in comments) I have also provided feedback via the AG WG Mailing list (please see: https://lists.w3.org/Archives/Public/public-silver/2022May/0025.html)

My concern is rooted in the naming of this activity, as it is not specifically about "Pronunciation" but rather document language accuracy (for assistive technology). With emergent work from a W3C Task force (the Pronunciation Task Force) and their draft specification (https://w3c.github.io/pronunciation/technical-approach/) which looks at pronunciation of individual words, I fear a term collision down the road.

I would like the Working Group to discuss alternative names for this specific activity that more accurately describes the goal BEFORE committing to our Draft.
Gregg Vanderheiden I do not approve this content to be added to the WCAG 3 editor's draft as exploratory (list reasons for not approving or items that need to be addresses before moving to exploratory in comments) Warning - I may be confused as to what an *Outcome* vs a *Method* is. here I am roughly equating an *Outcome* to a *Success Criterion* and a "Method" to a technique.

With that -- this Outcome appears to be a requirement of Assistive Technologies -- not web content.

We already have SC (now outcome?) that require that text be available to assistive technologies (programatically determinable). So getting the text TO the AT is already covered.

and there is an SC that says language other than the page language needs to be marked. (and there are numerous tools for determining the language of the page) So that is covered.

This outcome however goes beyond that and requires that any AT that has text to speech must support all languages.
is that what we are looking for? If so then ---- OK but here are my points to list below then.

Concerns/questions to answer
- is WCAG going to start putting requirements on assistive technologies?
- this says "their natural language". Not all languages are supported by text to speech
- not all text to speech engines support the same breadth of languages - which languages are assistive technologies required to support
Laura Carlson

5. HTML lang attribute method

Please review Method: HTML lang attribute indicates the language of text. Do you approve this content to be added to the WCAG 3 draft as exploratory?

Summary

ChoiceAll responders
Results
I approve this content to be added to the WCAG 3 editor's draft as exploratory 9
I approve this content to be added to the WCAG 3 editor's as exploratory with the following editor's notes (list items that need to be addressed before the content moves to Developmental in the comments) 3
I do not approve this content to be added to the WCAG 3 editor's draft as exploratory (list reasons for not approving or items that need to be addresses before moving to exploratory in comments) 3

Details

Responder HTML lang attribute methodComments
Wilco Fiers I approve this content to be added to the WCAG 3 editor's as exploratory with the following editor's notes (list items that need to be addressed before the content moves to Developmental in the comments) I would like the exampled worked out in code, not just as text. But we can do that in a later iteration too.
Suzanne Taylor I do not approve this content to be added to the WCAG 3 editor's draft as exploratory (list reasons for not approving or items that need to be addresses before moving to exploratory in comments) I think seeking feedback on this amount of detail will result in too much github backlog. It would be better to provide less content here and get overall direction feedback first.

But before publishing even as a exploratory, I would at least remove the language that essentially proposes a new exception to Success Criterion 3.1.2 Language of Parts. "A page written in Haryanvi can not correctly be pronounced by major screen readers. Haryanvi is not considered an accessibility supported language. The page is coded so that the user’s preferred speech synthesizer of the screen reader is used." etc.

The exception suggested here would be based on the temporary state of screen reader support, and assumes that screen reader support and use will stay relatively constant and quite track-able going forward, while I believe that in the future TTS and screen reader use around the globe will become much more varied and more difficult to track. They will be built into other conversational software, small communities will create AT to fit their particular needs, etc

Perhaps I missed the discussion of this new exception?I think that if any work will involve or be based on significant new exceptions, those exceptions should be discussed in AGWG meetings prior to significant work based on those exceptions.

More detail on this concern:
"A page written in Haryanvi can not correctly be pronounced by major screen readers. Haryanvi is not considered an accessibility supported language. The page is coded so that the user’s preferred speech synthesizer of the screen reader is used."

The author should simply code the text correctly. This way the user can be told by the screen reader that the text is in Haryanvi, and can then make decisions themselves what they wish to do about this, and the author can avoid having to continuously monitor the state of Haryanvi in screen readers.
Isabel Holdsworth I approve this content to be added to the WCAG 3 editor's draft as exploratory
Jonathan Avila
Shawn Lauriat I approve this content to be added to the WCAG 3 editor's draft as exploratory
Jennifer Delisi
Todd Libby I approve this content to be added to the WCAG 3 editor's draft as exploratory
Sarah Horton I approve this content to be added to the WCAG 3 editor's draft as exploratory
Mary Jo Mueller I approve this content to be added to the WCAG 3 editor's as exploratory with the following editor's notes (list items that need to be addressed before the content moves to Developmental in the comments) Since this is an HTML method, it should include the code snippets that support/demonstrate each of the examples so a content developer would know exactly what to do.

The description of the method does not indicate not all content in other languages needs to be marked, so this nuance is only discovered if one reads very carefully through the examples (See passed examples 7 & 8 for single words or small phrases that either are marked incorrectly or not marked with a change in language).

This is fine as an exploratory approach, but I would be interested in knowing if someone new to accessibility would understand what needs to be done in their code and when they have done enough in their HTML content to mark changes in language. This may not be information gained when the standard is put out for public review, as it's usually accessibility experts doing this review.
Ian Kersey I approve this content to be added to the WCAG 3 editor's draft as exploratory
Gundula Niemann I approve this content to be added to the WCAG 3 editor's draft as exploratory Still, prior to publishing I suggest to review the examples.

Passed examples 1 and 2: Providing language versions is not in scope if this requirement.
passed examples 7 and 8 in my opinion in fact do fail.
passed example 10 in my opinion in fact does fail.
If it is common to use the English pronunciation of TGV when indicating the French train type, please give the example in an English page context. In German context, the French pronunciation is used for the abbreviation TGV when it means the French train type.

Failed examples 3: As Latin is excempted, I can't follow the fail.
Failed example 4 is a sub-example of failed example 2. I'd rather give it there.
Oliver Keim
Michael Gower I approve this content to be added to the WCAG 3 editor's as exploratory with the following editor's notes (list items that need to be addressed before the content moves to Developmental in the comments) I feel like this approach is going in almost the complete opposite direction to a possible path forward.
If we look at our current 2 language requirements in 2.1, there are already objective and subjective points to them:
> The default human language of each Web page can be programmatically determined.
> The human language of each passage or phrase in the content can be programmatically determined except for proper names, technical terms, words of indeterminate language, and words or phrases that have become part of the vernacular of the immediately surrounding text.

For the former, we can create an objective test that:
1) a page contains a default language attribute
2) the value of the language attribute matches something in a predefined list of allowed values

But the subjective test is whether the language value chosen is correct. This should be a subjective test on which we can place a high level of confidence of similar results from multiple testers, with the exception of pages where the language is unrecognized, indeterminant (say there is almost the same amount of text in two or more languages) or doesn't exist. We can likely provide some guidance (and even values?) to help resolve these.

For the Language of Parts, the task is more problematic.
We can use the same objective tests for proper use of the lang attribute and value, but whether they are placed on a passage that is not in the same language as the main page is more debatable.
Whether a language of parts is missing is obviously a related but different (and probably harder) problem.

The current outcome blends these two different problems, making it arguably more difficult to achieve even a partial success.
I believe a series of more easily evaluated outcomes would lead to a standard that is more predictable and measurable.
Francis Storr I approve this content to be added to the WCAG 3 editor's draft as exploratory
Shawn Thompson
Makoto Ueki
Jeanne F Spellman I approve this content to be added to the WCAG 3 editor's draft as exploratory Note that there are additional methods, including a method for user agents that are not developed or written, but are necessary. I recommend these notes explaining the context be included as editor's notes.
Bruce Bailey I do not approve this content to be added to the WCAG 3 editor's draft as exploratory (list reasons for not approving or items that need to be addresses before moving to exploratory in comments) I agree with the direction this is going, and I am interested in seeing this content added to the WCAG 3 editor's as exploratory, and being added sooner than later -- but I am of the opinion this doc needs more clean up before being exploratory.

For example, top of third page <q> (needs work) </q> [in yellow highlight] -- i am not clear of the intent behind this portion of the document, and it is a little too rough for me to make editorial suggestions.

Also, the exposition on html attributes and glossary terms seem misplaced (i.e., not really specific to this method) but I approve adding those to WCAG 3 editor's draft as exploratory now. (Just not so tightly tied to this particular method.)
John Foliot I do not approve this content to be added to the WCAG 3 editor's draft as exploratory (list reasons for not approving or items that need to be addresses before moving to exploratory in comments) Please see my previous comment. I am not opposed to adding the Method to our collection of methods, but continue to have concerns over the naming of this activity.

Specifically, the use of the @lang attribute does not provide a mechanism for disambiguation of pronunciation beyond "blocks of text". For example, the addition of lang="en" does not tell a TTS engine the appropriate pronunciation of "read" (is it "reed" or "red"?)

As such, the presence of the @lang attribute on the complete HTML document does not fully contribute to "Pronunciation" as commonly defined, but does ensure the correct "language profile" is loaded by the TTS engine, which better ensures overall comprehension. This method and attached Outcome goal should better reflect the nuances of "pronunciation" reflected by the existing and emergent technical mechanisms.
Gregg Vanderheiden I approve this content to be added to the WCAG 3 editor's draft as exploratory
Laura Carlson

More details on responses

  • Wilco Fiers: last responded on 18, May 2022 at 19:20 (UTC)
  • Suzanne Taylor: last responded on 19, May 2022 at 19:08 (UTC)
  • Isabel Holdsworth: last responded on 20, May 2022 at 11:56 (UTC)
  • Jonathan Avila: last responded on 20, May 2022 at 15:24 (UTC)
  • Shawn Lauriat: last responded on 20, May 2022 at 15:26 (UTC)
  • Jennifer Delisi: last responded on 23, May 2022 at 14:35 (UTC)
  • Todd Libby: last responded on 23, May 2022 at 23:21 (UTC)
  • Sarah Horton: last responded on 24, May 2022 at 12:27 (UTC)
  • Mary Jo Mueller: last responded on 24, May 2022 at 13:55 (UTC)
  • Ian Kersey: last responded on 12, June 2022 at 19:21 (UTC)
  • Gundula Niemann: last responded on 13, June 2022 at 12:40 (UTC)
  • Oliver Keim: last responded on 13, June 2022 at 12:45 (UTC)
  • Michael Gower: last responded on 13, June 2022 at 20:15 (UTC)
  • Francis Storr: last responded on 14, June 2022 at 13:21 (UTC)
  • Shawn Thompson: last responded on 14, June 2022 at 13:42 (UTC)
  • Makoto Ueki: last responded on 14, June 2022 at 14:08 (UTC)
  • Jeanne F Spellman: last responded on 14, June 2022 at 14:45 (UTC)
  • Bruce Bailey: last responded on 14, June 2022 at 15:00 (UTC)
  • John Foliot: last responded on 14, June 2022 at 16:04 (UTC)
  • Gregg Vanderheiden: last responded on 14, June 2022 at 16:31 (UTC)
  • Laura Carlson: last responded on 14, June 2022 at 16:43 (UTC)

Non-responders

The following persons have not answered the questionnaire:

  1. Chris Wilson
  2. Lisa Seeman-Horwitz
  3. Janina Sajka
  4. Shawn Lawton Henry
  5. Katie Haritos-Shea
  6. Shadi Abou-Zahra
  7. Chus Garcia
  8. Steve Faulkner
  9. Patrick Lauke
  10. David MacDonald
  11. Gez Lemon
  12. Peter Korn
  13. Preety Kumar
  14. Georgios Grigoriadis
  15. Stefan Schnabel
  16. Romain Deltour
  17. Chris Blouch
  18. Jedi Lin
  19. Kimberly Patch
  20. Glenda Sims
  21. Ian Pouncey
  22. Alastair Campbell
  23. Léonie Watson
  24. David Sloan
  25. John Kirkwood
  26. Detlev Fischer
  27. Reinaldo Ferraz
  28. Matt Garrish
  29. Mike Gifford
  30. Loïc Martínez Normand
  31. Mike Pluke
  32. Justine Pascalides
  33. Chris Loiselle
  34. Tzviya Siegman
  35. Jan McSorley
  36. Sailesh Panchang
  37. Cristina Mussinelli
  38. John Rochford
  39. Sujasree Kurapati
  40. Jatin Vaishnav
  41. Sam Ogami
  42. Kevin White
  43. E.A. Draffan
  44. Paul Bohman
  45. JaEun Jemma Ku
  46. 骅 杨
  47. Victoria Clark
  48. Avneesh Singh
  49. Mitchell Evan
  50. biao liu
  51. Scott McCormack
  52. Denis Boudreau
  53. Rachael Bradley Montgomery
  54. Rick Johnson
  55. David Swallow
  56. Aparna Pasi
  57. Gregorio Pellegrino
  58. Melanie Philipp
  59. Jake Abma
  60. Nicole Windmann
  61. Ruoxi Ran
  62. Wendy Reid
  63. Scott O'Hara
  64. Charles Adams
  65. Muhammad Saleem
  66. Amani Ali
  67. Trevor Bostic
  68. Jamie Herrera
  69. Shinya Takami
  70. Karen Herr
  71. Kathy Eng
  72. Cybele Sack
  73. Audrey Maniez
  74. Arthur Soroken
  75. Daniel Bjorge
  76. Kai Recke
  77. David Fazio
  78. Daniel Montalvo
  79. Mario Chacón-Rivas
  80. Michael Gilbert
  81. Caryn Pagel
  82. Achraf Othman
  83. Fernanda Bonnin
  84. Jared Batterman
  85. Raja Kushalnagar
  86. Jan Williams
  87. Julia Chen
  88. Marcos Franco Murillo
  89. Yutaka Suzuki
  90. Azlan Cuttilan
  91. Jennifer Strickland
  92. Joe Humbert
  93. Ben Tillyer
  94. Charu Pandhi
  95. Poornima Badhan Subramanian
  96. Alain Vagner
  97. Roberto Scano
  98. Rain Breaw Michaels
  99. Kun Zhang
  100. Jaunita George
  101. Regina Sanchez
  102. Thomas Brunet
  103. Kenny Dunsin
  104. Jen Goulden
  105. Mike Beganyi
  106. Ronny Hendriks
  107. Breixo Pastoriza Barcia
  108. Olivia Hogan-Stark
  109. Rashmi Katakwar
  110. Julie Rawe
  111. Duff Johnson
  112. Laura Miller
  113. Will Creedle
  114. Shikha Nikhil Dwivedi
  115. Marie Csanady
  116. Meenakshi Das
  117. Perrin Anto
  118. Stephanie Louraine
  119. Rachele DiTullio
  120. Jan Jaap de Groot
  121. Rebecca Monteleone
  122. Peter Bossley
  123. Anastasia Lanz
  124. Michael Keane
  125. Chiara De Martin
  126. Giacomo Petri
  127. Andrew Barakat
  128. Devanshu Chandra
  129. Helen Zhou
  130. Bryan Trogdon
  131. Mary Ann (MJ) Jawili
  132. 禹佳 陶
  133. 锦澄 王
  134. Stephen James
  135. Jay Mullen
  136. Thorsten Katzmann
  137. Tony Holland
  138. Kent Boucher
  139. Abbey Davis
  140. Phil Day
  141. Julia Kim
  142. Michelle Lana
  143. David Williams
  144. Mikayla Thompson
  145. Catherine Droege
  146. James Edwards
  147. Eric Hind
  148. Quintin Balsdon
  149. Mario Batušić
  150. David Cox
  151. Sazzad Mahamud
  152. Katy Brickley
  153. Kimberly Sarabia
  154. Corey Hinshaw
  155. Ashley Firth
  156. Daniel Harper-Wain
  157. Kiara Stewart
  158. DJ Chase
  159. Suji Sreerama
  160. Lori Oakley
  161. David Middleton
  162. Alyssa Priddy
  163. Young Choi
  164. Nichole Bui
  165. Julie Romanowski
  166. Eloisa Guerrero
  167. Daniel Henderson-Ede
  168. George Kuan
  169. YAPING LIN
  170. Justin Wilson
  171. Tiffany Burtin
  172. Shane Dittmar
  173. Nayan Padrai
  174. Niamh Kelly
  175. Matt Argomaniz Matthew Argomaniz
  176. Frankie Wolf
  177. Kimberly McGee
  178. Ahson Rana
  179. Carolina Crespo
  180. humor927 humor927
  181. Samantha McDaniel
  182. Matthäus Rojek
  183. Phong Tony Le
  184. Bram Janssens
  185. Graham Ritchie
  186. Aleksandar Cindrikj
  187. Jeroen Hulscher
  188. Alina Vayntrub
  189. Marco Sabidussi
  190. John Toles
  191. Jeanne Erickson Cooley
  192. Theo Hale
  193. Gert-Jan Vercauteren
  194. Karla Rubiano
  195. Aashutosh K
  196. Hidde de Vries
  197. Julian Kittelson-Aldred
  198. Roland Buss
  199. Aditya Surendranath
  200. Avon Kuo
  201. Elizabeth Patrick
  202. Nat Tarnoff
  203. Filippo Zorzi
  204. Mike Pedersen
  205. Rachael Yomtoob

Send an email to all the non-responders.


Compact view of the results / list of email addresses of the responders

WBS home / Questionnaires / WG questionnaires / Answer this questionnaire