W3C

- DRAFT -

WCAG2ICT Task Force Teleconference

10 Jul 2012

See also: IRC log

Attendees

Present
Andi_Snow_Weaver, Gregg_Vanderheiden, Cooper, David_MacDonald, Peter_Korn, Mary_Jo_Mueller, Loïc_Martínez_Normand, Al_Hoffman, Janina_Sajka, Bruce_Bailey, Mike_Pluke
Regrets
Pierce_Crowell
Chair
Andi_Snow-Weaver
Scribe
MaryJo

Contents


<trackbot> Date: 10 July 2012

<Andi> scribe: MaryJo

Re-survey on 2.4.2 Page Titled https://www.w3.org/2002/09/wbs/55145/JUL102012/results

<Andi> For documents this applies directly as written, and as described in INTENT from Understanding WCAG 2.0 (above) with the word “document” substituted for Web Page.

<korn> For software user interfaces, the precise analog to "web page" in the context of this success criterion is difficult to define. However, since there is almost always a single user interface component associated with top-most explicit groupings of user interface components (things like "windows", "dialog boxes", "frames", and "screens"), and since 4.1.2 requires that every user interface component has a programmatically determined name, conforming to

<Andi> Pierce's edit: Note: A document's filename, as well as its title attribute, are both considered types of titles. While the filename is more universally presented by assistive technologies, the title attribute is more formally correct.

PK: Pierce's change to reverse the 2nd sentence looks fine, and Loïc's edits look fine too.

GV: Concerned about ordering of whether to provide title or file name first - one is supported by AT's more and one is more formally correct. Want to make sure we give the right advice.

PK: Can make it clear that doing both increases the chances of this SC being met. Need to come up with right words.

Al: Filenames aren't really equivalent to the proper provision of a title, which is the point Pierce is making.

MP: There are often more limitations on file names, so the title is preferrable.

Loïc: Most people are comfortable with making short file names meaningful.

PK: If there are a large number of documents being named, it is difficult to name the files so they are easy to distinguish from each other in a meaningful way.

<Andi> Note: A document's filename, as well as its title attribute, are both considered types of titles. While the filename is more universally presented by assistive technologies, the title attribute is more formally correct. Using both provides the best accessibility support.

<janina> +1 to gv's proposal

<Andi> Note: A document's filename, as well as its title attribute, are both considered types of titles. While the filename is more universally presented by assistive technologies, the title attribute is more formally correct. Using both provides the best chance of being accessible to the user.

Alex: 'Accessibility support' is a concept we haven't discussed yet in the task force and not a term we have defined.

<Andi> Note: A document's filename, as well as its title attribute, are both considered types of titles. While the filename is more universally presented by assistive technologies, the title attribute is more formally correct. Using both provides the best chance of being accessible to a user.

<Andi> Note: A document's filename, as well as its title attribute, are both considered types of titles. While the filename is more universally presented by assistive technologies, the title attribute is more formally correct. Using both provides the best chance of being accessible to different users.

<janina> Or "greater liklihood" ?

<korn> +1

<Andi> RESOLUTION: accept note for 2.4.2 as amended

AS: Loïc's edit for the software part of 2.4.2.

GV: Fundamental difference in this edit is that it implies we know which part needs naming - the topmost grouping.

Loïc: Would really like to see 'interaction context' in the first sentence. In lieu of using that term, thinks that 'top-most explicit groupings of user interface components' is the closest match to that term in this context.

<Andi> friendly amendment to make it less verbose? "...conforming to 4.1.2 for the top-most explicit groupings of user interface components would thereby mean conformance to this success criterion if the name described its topic or purpose."

MP: We don't want to say this SC is redundant, as 4.1.2 does cover the need for a name, but doesn't cover the aspect of it being a meaningful or descriptive name.

GV: We can make an edit to this to emphasize this aspect. Since you made a name in 4.1.2, if you make the name descriptive then you satisfy this SC.

<Andi> "...conforming to 4.1.2 for the name of the top-most explicit groupings of user interface components would thereby mean conformance to this success criterion if the name described its topic or purpose."

GV: We need to determine which term to use: 'software aspects of prodcts', 'software user interfaces', etc.

PK: A lot of this SC has to do with finding a single web page out of a lot of Web pages. In the software world, there are typically less applications or windows to filter through to find the right one.
... Software use cases are different, so we need to have a good analog that makes sense.

<greggvanderheid-1> For software user interfaces, the precise analog to "web page" in the context of this success criterion is difficult to define. However, since there is almost always a single user interface component associated with top-most explicit groupings of user interface components (things like "windows", "dialog boxes", "frames", and "screens"), and since 4.1.2 requires that every user interface component has a programmatically determined name,

<greggvanderheid-1> conforming to 4.1.2 would thereby mean that is success criterion was met if the name for the user interface component associated with top-most explicit groupings of user interface components described its topic or purpose.

<greggvanderheid-1> For software user interfaces, the precise analog to "web page" in the context of this success criterion is difficult to define. However, since there is almost always a single user interface component associated with top-most explicit groupings of user interface components (things like "windows", "dialog boxes", "frames", and "screens"), and since 4.1.2 requires that every user interface component has a programmatically determined name,

<greggvanderheid-1> conforming to 4.1.2 would thereby mean that this success criterion was met if the name for the user interface component associated with top-most explicit groupings of user interface components described its topic or purpose.

PK: We shouldn't be too precise in this, to make sure that future technologies can be covered without having to readdress this SC.

Loïc: Agrees with the above proposed text from Gregg.
... This is only applicable to software that has a user interface, not DLL's, etc.

<korn> "If the names of all explicit groupings of user interface components are descriptive of the title or purpose, it will certainly be the case that all of the top-most ones are"

AS: We have a work item to go back and look at the terms used for software to make them consistent throughout the document.
... 'Product' term is a problem, because this SC should also apply to software developed in-house for internal use that is not productized.

GV: Agree that we do need to go back and revisit terms we came up with for the SCs to make them consistent.

<Andi> since 4.1.2 requires that every user interface component has a programmatically determined name, conforming to 4.1.2 would thereby mean that this success criterion was met if the name for the user interface component associated with top-most explicit groupings of user interface components described its topic or purpose. If the names of all explicit groupings of user interface components are

<Andi> descriptive of the title or purpose, it will certainly be the case that all of the top-most ones are.

<greggvanderheid-1> +1

<Loïc> +1

<Andi> Amended in the meeting: For documents this applies directly as written, and as described in INTENT from Understanding WCAG 2.0 (above) with the word “document” substituted for Web Page.

<Andi> Note: A document's filename, as well as its title attribute, are both considered types of titles. While the filename is more universally presented by assistive technologies, the title attribute is more formally correct. Using both provides the best chance of being accessible to different users.

<Andi> For software user interfaces, the precise analog to "web page" in the context of this success criterion is difficult to define. However, since there is almost always a single user interface component associated with top-most explicit groupings of user interface components (things like "windows", "dialog boxes", "frames", and "screens"), and since 4.1.2 requires that every user interface

<Andi> component has a programmatically determined name,

<Andi> conforming to 4.1.2 would thereby mean that this success criterion was met if the name for the user interface component associated with top-most explicit groupings of user interface components described its topic or purpose. If the names of all explicit groupings of user interface components are

<Andi> descriptive of the title or purpose, it will certainly be the case that all of the top-most ones are.

<Andi> Note: Where the accessibility services of the platform include a description attribute in addition to a name attribute, the description attribute and the name attribute are often used together to provide both a short cue and longer description of the topic or purpose.

RESOLUTION: Accept 2.4.2 as amended in version #5.

Alex: Concerned that 2.4.2 text doesn't explicitly exclude command line interfaces where the concept of a 'page title' doesn't exist.

<Loïc> +1 to Peter. Only one screen there is nothing to look for.

PK: If multiple CLI windows are being used, the operating system is handling them.

AS: If this is important to use the SC and asses for CLI interfaces, we need to circle back at a later time with this in mind.

Draft proposed edits to WCAG 2.0 resolution on 1.3.1 Info and Relationships http://lists.w3.org/Archives/Public/public-wcag2ict-tf/2012Jul/0029.html

AS: WCAG didn't accept the text exactly as we proposed, but did agree to put part of our proposal in. Pierce and Al had concerns and the link points to 2 possible edits to what WCAG agreed to add.

GV: Likes Andi's wording. Even though it is more verbose, it is clearer in meaning.

<Andi> Sighted users perceive structure AND RELATIONSHIPS through various visual cues — headings are often in a larger, bold font separated from paragraphs by blank lines; list items are preceded by a bullet and perhaps indented; paragraphs are separated by a blank line; form fields may be positioned as groups that share text labels; a different background color may be used to indicate that several items are related to each other; words that have special status are indicated by changing the font family and /or bolding, italicizing, or underlining them; ITEMS THAT SHARE A COMMON CHARACTERISTIC ARE ORGANIZED INTO A TABLE WHERE THE RELATIONSHIP OF CELLS SHARING THE SAME ROW OR COLUMN AND THE RELATIONSHIP OF EACH CELL TO ITS ROW AND/OR COLUMN HEADER ARE NECESSARY FOR UNDERSTANDING; and so on. Having THESE structures and relationships programmatically determined or available in text ensures that information important for comprehension will be perceivable by all.

AS: Al or Pierce should try to attend the WCAG meeting to be there when the text is agreed upon or edited.

<Andi> http://lists.w3.org/Archives/Public/public-wcag2ict-tf/2012Jul/0029.html

RESOLUTION: Accept proposal #1 modification to the Intent for 1.3.1 from email http://lists.w3.org/Archives/Public/public-wcag2ict-tf/2012Jul/0029.html.

Summary of WCAG 2.0 decision on SC we sent for their review http://lists.w3.org/Archives/Public/public-wcag2ict-tf/2012Jul/0031.html

AS: 2.1.1 Keyboard

<Andi> https://sites.google.com/site/wcag2ict/home/2-operable/21-make-all-functionality-available-from-a-keyboard/211-keyboard

<Andi> Note: This does not imply that software must directly support OR PROVIDE a keyboard or "keyboard interface". UNDERLYING Platform software may provide device independent input services to applications that enable operation via a keyboard. Software that supports operation via such platform device independent services would be operable by a keyboard and would comply.

<Andi> Note: This does not imply that software must directly support a keyboard or "keyboard interface" OR PROVIDE A SOFT KEYBOARD. UNDERLYING Platform software may provide device independent input services to applications that enable operation via a keyboard. Software that supports operation via such platform device independent services would be operable by a keyboard and would comply.

<Loïc> +1 To Andi's edit

Loïc: Concerned that 'provide a keyboard' would be misinterpreted as 'provide a hardware keyboard'.

PK: Propose we add this edit to our document and after public comment we can send this and any other further WCAG updates then.

Loïc: Would prefer to send this to WCAG now.

<korn> +1

<Mike> +1

<Andi> This does not imply that software must directly support a keyboard or "keyboard interface". NOR DOES IT REQUIRE THAT SOFTWARE PROVIDE A SOFT KEYBOARD. UNDERLYING Platform software may provide device independent input services to applications that enable operation via a keyboard. Software that supports operation via such platform device independent services would be operable by a keyboard

<Andi> and would comply.

<Loïc> +1

<Andi> This does not imply that software must directly support a keyboard or "keyboard interface". NOR DOES IT IMPLY THAT SOFTWARE PROVIDE A SOFT KEYBOARD. UNDERLYING Platform software may provide device independent input services to applications that enable operation via a keyboard. Software that supports operation via such platform device independent services would be operable by a keyboard

<Andi> and would comply.

<korn> Again to be parallel, "... nor does it imply that software MUST PROVIDE a soft keyboard"

<Andi> This does not imply that software must directly support a keyboard or "keyboard interface". NOR DOES IT IMPLY THAT SOFTWARE MUST PROVIDE A SOFT KEYBOARD. UNDERLYING Platform software may provide device independent input services to applications that enable operation via a keyboard. Software that supports operation via such platform device independent services would be operable by a keyboard

<Andi> and would comply.

RESOLUTION: Send edit proposed in meeting for 2.1.1 to WCAG.

AS:2.2.2 Pause, Stop, Hide

<Andi> https://sites.google.com/site/wcag2ict/home/2-operable/22-provide-users-enough-time-to-read-and-use-content/222-pause-stop-hide

<Andi> Proposed: Note: While the success criteria uses the term "information", the WCAG 2.0 INTENT section makes it clear that this is to be applied to all content. Any content, whether informative or decorative, that blinks or moves creates a significant accessibility barrier for some users with cognitive, learning, and other disabilities."

<greggvanderheid-1> Any content, whether informative or decorative, that IS UPDATED AUTOMATICALLY MAY CREATE AN ACCESSIBILITY BARRIER IF USERS DO NOT KNOW IT HAS UPDATED. FURTHER, ANY CONTENT, WHETHER INFORMATIVE OR DECORATIVE THAT blinks or moves creates a significant accessibility barrier for some users with cognitive, learning, and other disabilities."

<Andi> WCAG approved: Note: While the success criteria uses the term "information", the WCAG 2.0 INTENT section makes it clear that this is to be applied to all content. Any content, whether informative or decorative, that IS UPDATED AUTOMATICALLY MAY CREATE AN ACCESSIBILITY BARRIER IF USERS DO NOT KNOW IT HAS UPDATED. FURTHER, ANY CONTENT, WHETHER INFORMATIVE OR DECORATIVE THAT blinks or moves

<Andi> creates a significant accessibility barrier for some users with cognitive, learning, and other disabilities."

AS: The WCAG changes to our proposed text seems editorial. Only the second sentence was changed.

GV: It added back the aspect about 'automatically updating'.

Loïc: The explanation for the user to know about updating information is not covered by this SC. This SC is about user control over the updating content.

<Loïc> Any content, wether informative or decorative, that is updated automatically, blinks or moves creates a significant accessibility barrier...

<Andi> Note: While the success criteria uses the term "information", the WCAG 2.0 INTENT section makes it clear that this is to be applied to all content. Any content, whether informative or decorative, that IS UPDATED AUTOMATICALLY, BLINKS OR MOVES MAY CREATE AN ACCESSIBILITY BARRIER.

GV: Agrees with Loïc's suggestion.

RESOLUTION: Send edits proposed in meeting for 2.2.2 to WCAG.

<Andi> Conditionally accepted by WCAG: 2.2.1, 3.2.1, 3.2.2, 3.3.4, 4.1.2

GV: WCAG group found some situations where our criteria could be met, but content would still fail the SC.

AS: WCAG wants us to remove the exception we had for documents that can automatically comply.

Loïc: We may need to look at all of these SC to make sure it makes sense with the sentence removed.

<Andi> ACTION: Andi to check these five success criteria (2.2.1, 3.2.1, 3.2.2, 3.3.4, 4.1.2) to make sure documents are still covered if we drop the sentence. [recorded in http://www.w3.org/2012/07/10-wcag2ict-minutes.html#action01]

<trackbot> Created ACTION-29 - Check these five success criteria (2.2.1, 3.2.1, 3.2.2, 3.3.4, 4.1.2) to make sure documents are still covered if we drop the sentence. [on Andi Snow-Weaver - due 2012-07-17].

<korn> +1

PK: Did go through the SC and it did make sense, but agrees that Andi should take a 2nd look.

Al: Proposes that an example is added to each one of these.
... These examples can be added after our first draft is complete.

<Andi> ACTION: Andi to work with Gregg and Peter to gather examples provided by WCAG for 2.2.1, 3.2.1, 3.2.2, 3.3.4, 4.1.2 and draft examples to add after first public working draft [recorded in http://www.w3.org/2012/07/10-wcag2ict-minutes.html#action02]

<trackbot> Created ACTION-30 - Work with Gregg and Peter to gather examples provided by WCAG for 2.2.1, 3.2.1, 3.2.2, 3.3.4, 4.1.2 and draft examples to add after first public working draft [on Andi Snow-Weaver - due 2012-07-17].

Al: Doesn't want to remove useful guidance if the examples are obscure.

GV: Could add 'Except for unusual cases such as...' and then give the guidance we have.

<korn> I'm sorry, but I have to leave now - we are over the meeting time and I have another thing I need to go to.

GV: Or edit our text with something like: "For pages that are nothing but text and simple hypertext links..."

RESOLUTION: Accept WCAG proposed edits for 2.2.1, 3.2.1, 3.2.2, 3.3.4, 4.1.2 and work on examples later.

Summary of Action Items

[NEW] ACTION: Andi to check these five success criteria (2.2.1, 3.2.1, 3.2.2, 3.3.4, 4.1.2) to make sure documents are still covered if we drop the sentence. [recorded in http://www.w3.org/2012/07/10-wcag2ict-minutes.html#action01]
[NEW] ACTION: Andi to work with Gregg and Peter to gather examples provided by WCAG for 2.2.1, 3.2.1, 3.2.2, 3.3.4, 4.1.2 and draft examples to add after first public working draft [recorded in http://www.w3.org/2012/07/10-wcag2ict-minutes.html#action02]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.136 (CVS log)
$Date: 2012/07/10 19:40:15 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.136  of Date: 2011/05/12 12:01:43  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Found Scribe: MaryJo
Inferring ScribeNick: MaryJo
Default Present: Andi_Snow_Weaver, Gregg_Vanderheiden, Cooper, Peter, David_MacDonald, Peter_Korn, Mary_Jo_Mueller, Loïc_Martínez_Normand
Present: Andi_Snow_Weaver Gregg_Vanderheiden Cooper Peter David_MacDonald Peter_Korn Mary_Jo_Mueller Loïc_Martínez_Normand
Found Date: 10 Jul 2012
Guessing minutes URL: http://www.w3.org/2012/07/10-wcag2ict-minutes.html
People with action items: andi

[End of scribe.perl diagnostic output]