See also: IRC log
<scribe> scribe: MaryJo
<greggvanderheiden> agree with judy
AS: Will attend WCAG working group twice monthly to give an update to the group on the task force progress.
<Andi> close action-6
<trackbot> ACTION-6 Set up regular reporting to WCAG working group closed
AS: Actions 10 and 12 will go out on the survey later this week.
<greggvanderheiden> I am but we can take this back up in a bit
PK: Action on 2.4.1, Gregg proposed edits to improve the language. Wants to hear from Gregg before this goes out for survey again.
AS: Need to resurvey 2.4.1
<Andi> https://www.w3.org/2002/09/wbs/55145/JUN152012/results#xq5
<pierce> +q
<Andi> https://www.w3.org/2002/09/wbs/55145/JUN152012/results
<janina> +1 to a programmatic association
<korn> Pierce: look at http://www.w3.org/TR/UNDERSTANDING-WCAG20/minimize-error-cues.html#labeldef
AS: Propose that we ask WCAG to
add to the intent that a note that if labels are provided that
they be programatically determinable per 1.3.1.
... For the linked definitions, we need to revisit this when we
work on resolving the term 'content'.
<scribe> ACTION: Gregg to ask WCAG to modify the INTENT of 3.3.2 to add a note: If labels are provided they must be programmatically determinable per 1.3.1. [recorded in http://www.w3.org/2012/06/19-wcag2ict-minutes.html#action01]
<trackbot> Created ACTION-13 - Ask WCAG to modify the INTENT of 3.3.2 to add a note: If labels are provided they must be programmatically determinable per 1.3.1. [on Gregg Vanderheiden - due 2012-06-26].
RESOLUTION: Accept 3.3.2 as proposed with a note to ourselves to revisit with discussion of term "content" ("label" definition referenced in the SC uses the term "content")
<pierce> -q
<Andi> https://www.w3.org/2002/09/wbs/55145/JUN192012/results
AS: 2.1.1 Keyboard
https://www.w3.org/2002/09/wbs/55145/JUN192012/results#xq4
RESOLUTION: Accept 2.1.1 proposal #3
<pierce> +q
AS: 1.1.1 Non-text content
https://www.w3.org/2002/09/wbs/55145/JUN192012/results#xq1
<pierce> -q
<Andi> This SC applies directly as written, and as described above in WCAG intent.
<Andi> CAPTCHAs do not currently appear outside of the Web. However, if they do appear, this guidance is accurate. If they do not appear then, (as with any situation where an SC talks about something that is not present) the SC would be met automatically.
<Andi> (see introduction for the way to interpret the terms "Content")
RESOLUTION: Accept 1.1.1 as amended in the meeting notes.
<pierce> +q
1.3.3 Sensory Characteristics
https://www.w3.org/2002/09/wbs/55145/JUN192012/results#xq2
Pierce: Concerned about bringing in the topic of tactile hardware into this.
GV: We are trying to remove a restriction where documentation needs to describe the tactile aspects of hardware.
<Andi> WCAG was designed to apply only to controls that were displayed on screen. The intent was to prevent references to visual or auditory cues. When applying this to instructions for operating physical hardware controls (e.g. a web kiosk with dedicated content), tactile cues on the hardware might be described (e.g. the arrow shaped key, the round key on the right side).
<Andi> This success criterion was not intended to prevent the use of tactile cues in instructions.
<Andi> This success criterion is not intended to prevent the use of tactile cues in instructions.
RESOLUTION: Accept 1.3.3 as amended in the meeting.
4.1.1 Parsing
https://www.w3.org/2002/09/wbs/55145/JUN192012/results#xq3
AS: There's a lot of comments that this doesn't apply to software.
<pierce> +q
GV: We no longer differentiate
between hardware and software because the lines are blurring.
Could apply to books, documents, documents with embedded
javascript, etc. which could be handled or parsed in the same
fashion.
... Most software isn't in a markup language and it would
automatically comply.
<greggvanderheiden> I q+
<greggvanderheiden> +
PK: The issue is whether this makes sense and meets a disability need. Real-world AT's don't parse XML. Only daisy or braille converters parse, but don't see how this applies to documents and software outside of the Web.
Pierce: Well-formedness in documents are generally run by software rules. This applies to both worlds when the user could introduce errors in tags, etc.
GV: We had an earlier discussion
that it is hard to draw a line between documents and software,
so we moved away from that.
... People do create documents that are in a markup language
that aren't delivered on the Web, so this applies. In cases
where it the SC doesn't apply, they automatically comply.
PK: Provisions that have to do
with authoring are covered by ATAG.
... There is HTML markup documents deliverd outside of the Web,
but these won't be parsed by AT. Maybe we should scope this to
non-web HTML documents but beyond that, we don't have the
authority to address them.
AH: There is a lot of markup language out there, but most wouldn't be valid for parsing. Should say it applies to HTML as written.
<greggvanderheiden> ask WCAG to add to intent. This is meant to apply to Web Markup languages and not to other markup languages that are not parsed by regular web browsers and Assistive technologies.
<pierce> -q
<pierce> +q
<greggvanderheiden> ask WCAG to add to intent. This is meant to apply to Web Markup languages and not to other markup languages that are not parsed by regular web browsers
<greggvanderheiden> This is meant to apply to Web Markup languages and not to other markup languages that are not parsed by regular web browsers and Assistive technologies.
PK: We need to include assistive technologies in gregg's proposed WCAG intent update.
<Zakim> janina, you wanted to ask what about HTML5 canvas?
JS: HTML5 has new markup constraints, so saying HTML alone may not be sufficient.
PK: Any viewer that converts HTML to show content outside of the Web. Internal non-web formats such as XML are not parsed by AT.
AH: Some readers that are considered ATs do parse the XML.
<pierce> +q
<greggvanderheiden> ask WCAG to add to intent. This is meant to apply to Web Markup languages and not to other markup languages that are not parsed by regular web browsers and assistive technologies.
GV: If we get WCAG to add in the intent as described above, they can set the constraints. We can't say that this doesn't apply, but say how it is handled when applied to non-web situations.
PK: Would like clarification on what Web markup languages are covered. Is PDF, SVG, etc. covered? Are they parsed by AT?
<Andi> This is meant to apply to markup languages that are parsed by regular web browsers and assistive technologies. It is not meant to apply to markup languages that are not parsed by regular web browsers and assistive technologies.
<pierce> +q
<pierce> -q
<pierce> +q
JB: Need to be cautious about what we ask WCAG to add to the intent as there are many tools available to automatically fix/generate the markup.
<Zakim> Judy, you wanted to emphasize that there are cases where manually-generated "vs" automatically-generated is not a binary question.
JB: There is a class of documents that are only automatically generated. The more traditional Web documents manually-generated vs. automatically-generated is not a binary thing.
<pierce> -q
<Andi> This is meant to apply to markup languages that are parsed by regular web browsers and assistive technologies. It is not meant to apply to markup languages that are not parsed by regular web browsers and assistive technologies.
AS: Propose instead of focusing on how it's generated, but how it's parsed.
<korn> Works for me.
<pierce> +q
<greggvanderheiden> This is not meant to apply to markup languages that are not parsed by regular web browsers and assistive technologies.
<Andi> This is not meant to apply to markup languages that are not parsed directly by regular web browsers and assistive technologies.
<Andi> This is not meant to apply to markup languages that are not parsed directly by general purpose web browsers and assistive technologies.
<greggvanderheiden> This is meant to apply to markup languages that are parsed by general purpose web browsers and assistive technologies. It is not meant to apply to markup languages that are not parsed by regular web browsers and assistive technologies. If authors do not write or edit markup languages directly the can assume this provision is met.
<greggvanderheiden> This is not meant to apply to markup languages that are not parsed by regular web browsers and assistive technologies. If authors do not write or edit markup languages directly they can assume this provision is met.
PK: Recommend we have 2 requests 1) intent for what markup languages are applicable. 2) Applied to markup not directly edited by an author.
<greggvanderheiden> ask WCAG to add to intent. This is not meant to apply to markup languages that are not parsed by general purpose web browsers and assistive technologies. If authors do not write or edit markup languages directly they can assume this provision is met.
<Andi> ACTION: Gregg to ask WCAG working group to add to 4.1.1 INTENT: This is not meant to apply to markup languages that are not parsed by general purpose web browsers and assistive technologies. If authors do not write or edit markup languages directly they can assume this provision is met. [recorded in http://www.w3.org/2012/06/19-wcag2ict-minutes.html#action02]
<trackbot> Created ACTION-14 - Ask WCAG working group to add to 4.1.1 INTENT: This is not meant to apply to markup languages that are not parsed by general purpose web browsers and assistive technologies. If authors do not write or edit markup languages directly they can assume this provision is met. [on Gregg Vanderheiden - due 2012-06-26].
AS: There is a new survey with 7 items in it for next meeting.
<Andi> ACTION: Gregg to ask WCAG to add to 1.3.3 INTENT: WCAG was designed to apply only to controls that were displayed on screen. The intent was to prevent references to visual or auditory cues. When applying this to instructions for operating physical hardware controls (e.g. a web kiosk with dedicated content), tactile cues on the hardware might be described (e.g. the arrow shaped key, the round [recorded in http://www.w3.org/2012/06/19-wcag2ict-minutes.html#action03]
<Andi> key on the right side). This success criterion is not intended to prevent the use of tactile cues in instructions.
<trackbot> Created ACTION-15 - Ask WCAG to add to 1.3.3 INTENT: WCAG was designed to apply only to controls that were displayed on screen. The intent was to prevent references to visual or auditory cues. When applying this to instructions for operating physical hardware controls (e.g. a web kiosk with dedicated content), tactile cues on the hardware might be described (e.g. the arrow shaped key, the round [on Gregg Vanderheiden - due 2012-06-26].
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) Succeeded: s/PC: Action on 2.4.1/PK: Action on 2.4.1/ Succeeded: s/Regret I need to leave to prepare for the Open A11y telecon// Succeeded: s/BB/AH/ Succeeded: s/revisit with definition of the term "label" which uses term "content"/revisit with discussion of term "content" ("label" definition referenced in the SC uses the term "content"/ Succeeded: s/uses the term "content"/uses the term "content")/ Found Scribe: MaryJo Inferring ScribeNick: MaryJo Default Present: +0162859aaaa, Cooper, Kiran_Keja, Andi_Snow_Weaver, +1.202.447.aabb, Al_Hoffman, +1.512.255.aacc, +1.410.965.aadd, Mary_Jo_Mueller Present: +0162859aaaa Cooper Kiran_Keja Andi_Snow_Weaver +1.202.447.aabb Al_Hoffman +1.512.255.aacc +1.410.965.aadd Mary_Jo_Mueller Peter_Korn Pierce_Crowell Alex_Li Gregg_Vanderheiden Judy_Brewer Bruce_Bailey Janina_Sajka Regrets: David_MacDonald Mike_Pluke Loïc_Martínez_Normand Got date from IRC log name: 19 Jun 2012 Guessing minutes URL: http://www.w3.org/2012/06/19-wcag2ict-minutes.html People with action items: gregg WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]