WCAG2ICT Task Force Teleconference -- 07 Aug 2012

<trackbot> Date: 07 August 2012

Survey for August 7th meeting: https://www.w3.org/2002/09/wbs/55145/AUG072012/results

<scribe> scribe: Andi_Snow-Weaver

discussion about whether we need to use some flavor of "UI Context" in this provision

in some cases, there is no need to use a term like "UI context" - so we are trying to use the simplest language that we can

we're on 3.1.1 Language of Page

<greggvanderheiden> https://sites.google.com/site/wcag2ict/cross-cutting-issues-and-notes/ui-context-in-context

<greggvanderheiden> Not all software technologies support a method to programmatically expose the human language of the software user interface. Applications implemented in technologies where Assistive technologies cannot determine the human language and that do not support the platform "local language setting" may not be able to meet this success criterion.

eventually assistive technologies may be able to determine the human language of the document or software user interface

but AT may not be able to automatically get the human language 100% of the time

our guidance is not the right place for a note about ATs being able to automatically detect human language - since this would also apply to web pages, it's more appropriate in the WCAG 2.0 INTENT

"software user interface" might not be sufficient because people might not think it includes the application content

<greggvanderheiden> This applies directly as written, and as described in INTENT from Understanding WCAG 2.0 (above) replacing "each Web page" with "the document or software user interface".

<greggvanderheiden> Where software platforms provide a "local language" setting, applications that follow that setting would comply with this success criterion. Applications that do not follow the platform "local language setting" but instead use an assistive technology supported method for exposing the human language of the software user interface would also comply with this success criterion. Applications implemented in technologies where Assistive

<greggvanderheiden> technologies cannot determine the human language and that do not support the platform "local language setting" may not be able to meet this success criterion.

<greggvanderheiden> software user interface including any content

M376 team liked "software user interface" because it makes it clear that it doesn't include software that doesn't have a UI

<alex> +1 on Peter

<greggvanderheiden> how about we do [software /user interface] to make this a placeholder

<greggvanderheiden> then lets use software user interface including content

add a note to ourselves that we need to review this later once we settle on the term for "software"

<greggvanderheiden> I see what you mean

<greggvanderheiden> you mean other peoples content

<greggvanderheiden> This applies directly as written, and as described in INTENT from Understanding WCAG 2.0 (above) replacing "each Web page" with "the document or software user interface".

<greggvanderheiden> technologies cannot determine the human language and that do not support the platform "local language setting" may not be able to meet this success criterion.

<greggvanderheiden> This applies directly as written, and as described in INTENT from Understanding WCAG 2.0 (above) replacing "each Web page" with "the document or software".

<greggvanderheiden> technologies cannot determine the human language and that do not support the platform "local language setting" may not be able to meet this success criterion.

<greggvanderheiden> this is Andi's with new last sentence and using software

RESOLUTION: Accept Proposal #8 for 3.1.1

<greggvanderheiden> This applies directly as written, and as described in INTENT from Understanding WCAG 2.0 (above) replacing "each Web page" with "the electronic document or software".

<greggvanderheiden> technologies cannot determine the human language and that do not support the platform "local language setting" may not be able to meet this success criterion.

3.1.2 Language of Parts

change "This applies directly as written, and as described in INTENT from Understanding WCAG 2.0 (above) with “document or software” substituted for "content". " "This applies directly as written, and as described in INTENT from Understanding WCAG 2.0 (above) replacing "content" with "electronic document or software" substituted for "content". "

<greggvanderheiden> doing this we now get

<greggvanderheiden> "This applies directly as written, and as described in INTENT from Understanding WCAG 2.0 (above) replacing "content" with "electronic document or software"

<greggvanderheiden> Note that some document formats can use separate human languages for output and input purposes. In such cases both languages should be programmatically determinable.

<greggvanderheiden> There are some software and document technologies where there is no assistive technology supported method for marking the language for the different passages or phrases in the document or software, and it would not be possible to meet this success criterion with those technologies.

<greggvanderheiden> NOTE: Inheritance is one common method. For example a document or application provides the language that it is using and it can be assumed that all of the text or user interface elements within that document or application will be using the same language unless it is indicated.

<Mike> +q

dicussion about marking the human language of the user's input

<greggvanderheiden> I think it is an edge case and one that raises problems

example is forms (immigration forms) that may be in one language but require the input to be in another language (language of country being entered)

<janina> Wouldn't a software/web version of the U.S. Visa form employ a drop-down with countries spelled the way the U.S. Dept of State wants to see them?

suggestion that extending this to input may go beyond the SC

remove the 2nd paragraph

<greggvanderheiden> Proposal #6 ( FROM meeting -- this is #5 above with first sentence changed and insert/del applied and sentence about input removed since it is beyond SC) ========================

<greggvanderheiden> Additional guidance when applying to Electronic Documents and Software Aspects of Products

<greggvanderheiden> "This applies directly as written, and as described in INTENT from Understanding WCAG 2.0 (above) replacing "content" with "electronic document or software"

<scribe> ACTION: Mike to discuss issue of identifying the language of the input with M376 team and come back with a proposal if necessary [recorded in http://www.w3.org/2012/08/07-wcag2ict-minutes.html#action01]

<trackbot> Created ACTION-46 - Discuss issue of identifying the language of the input with M376 team and come back with a proposal if necessary [on Mike Pluke - due 2012-08-14].

RESOLUTION: Accept Proposal #6 for 3.1.2
... Accept that no further guidance is needed on 2.2.1 and 3.3.4

<Judy> https://www.w3.org/2002/09/wbs/55145/AUG072012/results#xq4

3.2.1 On Focus

discussion about Pierce's comment

<Judy> Judy suggesting that if we are holding this to check on that we do so for specific issues or questions, and for specific periods of time, rather than leaving things open

keep 3.2.1 open - follow up with Pierce to try to close by Friday

3.2.2 On Input

keep 3.2.2 open - follow up with Pierce to try to close by Friday

<korn> How about "Form controls provided by many document formats..."?

4.1.2 Name, Role, Value

in many technologies standard controls that are used according to specification are not accessible

<korn> We already say "For conforming to this success criterion, it is usually best practice for software user interfaces to use the accessibility services provided by platform software." Why not continue in that direction? "For conforming to this success criterion, it is usually best practice for document authors to use the controls provided by the document format."

discussion about Mike's proposed note: Note: For many document formats, standard user interface components already meet this success criterion when used according to the general design and accessibility guidance for the document format.

Note: For many document formats, standard user interface components would commonly meet this success criterion when used according to the general design and accessibility guidance for the document format.
... For many document formats, standard user interface components commonly meet this success criterion when used according to the general design and accessibility guidance for the document format.

For many document formats, standard user interface components may meet this success criterion when used according to the general design and accessibility guidance for the document format.

For document formats that support interoperability with AT, standard user interface components often meet this success criterion when used according to the general design and accessibility guidance for the document format.

<korn> +1

<greggvanderheiden> +1

RESOLUTION: Accept additional note for 4.1.2: Note: For document formats that support interoperability with AT, standard user interface components often meet this success criterion when used according to the general design and accessibility guidance for the document format.

<korn> https://sites.google.com/site/wcag2ict/cross-cutting-issues-and-notes/user-interface-context/ui-context-examples

User Interface Context discussion

<korn> https://sites.google.com/site/wcag2ict/cross-cutting-issues-and-notes/user-interface-context/ui-context-examples

proposal that in a UI where content changes over time constitutes a change of UI context and therefore invokes 2.4.1 and 3.2.2

<korn> https://sites.google.com/site/wcag2ict/cross-cutting-issues-and-notes/user-interface-context/ui-context-examples

<BBailey> https://sites.google.com/site/wcag2ict/cross-cutting-issues-and-notes/user-interface-context/ui-context-examples/how-many-two-document-windows

<korn> https://sites.google.com/site/wcag2ict/cross-cutting-issues-and-notes/user-interface-context/ui-context-examples

<BBailey> https://sites.google.com/site/wcag2ict/cross-cutting-issues-and-notes/user-interface-context/ui-context-examples/change-exampe-1-simple-tree-expansion-only-text-in-tree-nodes

<BBailey> https://sites.google.com/site/wcag2ict/cross-cutting-issues-and-notes/user-interface-context/ui-context-examples/changed-example-2-complex-tree-expansion

would we all agree on the number of UI contexts in the examples and whether or not there was a change in UI context in the examples?

ask industry developers and Access Board to look at these examples also - if we get consistent answers, validates the concept of UI Context

suggestion that developers only need to understand UI Context when trying to interpret a particular success criterion

<Mike> +1

<greggvanderheiden> https://sites.google.com/site/wcag2ict/cross-cutting-issues-and-notes/ui-context-in-context

<David> (2.4.1, 2.4.2, 2.4.5) are the ones that need any distinction of context...

<David> 2.4.1 bypass blocks, 2.4.2 Page titled,, 2.4.5 multiple ways are the ones that need context al else is context

- DRAFT -

WCAG2ICT Task Force Teleconference

07 Aug 2012

Attendees

Contents

Survey for August 7th meeting: https://www.w3.org/2002/09/wbs/55145/AUG072012/results

User Interface Context discussion

Summary of Action Items

Scribe.perl diagnostic output