w3c/wbs-design
or
by mail to sysreq
.
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:
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:
Choice | All 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 |
(9 responses didn't contain an answer to this question)
Responder | Add Changes to Natural Language Outcome as Exploratory | Comments |
---|---|---|
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 |
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:
Choice | All 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 |
(10 responses didn't contain an answer to this question)
Responder | Add HTML lang attribute indicates the language of text Method | Comments |
---|---|---|
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 |
Several people raised concern about the guideline name "Pronunciation of text." If you are concerned, please suggest an alternate name in the comments field.
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 |
Please review the Pronunciation of Text Outcome. Do you approve this content to be added to the WCAG 3 draft as exploratory?
Choice | All 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 |
(4 responses didn't contain an answer to this question)
Responder | Pronunciation of Text Outcome | Comments |
---|---|---|
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 |
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?
Choice | All 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 |
(6 responses didn't contain an answer to this question)
Responder | HTML lang attribute method | Comments |
---|---|---|
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 |
The following persons have not answered the questionnaire:
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
w3c/wbs-design
or
by mail to sysreq
.