See also: IRC log
<trackbot> Date: 02 June 2011
<scribe> scribe: Harper_Simon
<scribe> ScribeNick: sharper
<kford> I like that one.
All: general discussion surrounding Jan's comments
JR: withdraws comments
JA: cannot see the direct benefits apart from the minor clarity in the readability of the proposal
GL: bringing these out would make modularise in the testing slightly easier but this isn't a major thing
JA: what is the consensus of the group?
KP: easier to read if it is together, easier to test if it is a part.
GL moves to look at 5.3.3 If we include this it should include the same two bullet items at 3.5.1 defining what are considered accessibility features. Plus they all need unique titles.
http://www.w3.org/2002/09/wbs/36791/20110601/results#xq3
<jeanne> separate =1
JA: should we split or keep them together?
JR split
KF split
SH Split
GL: neutral
JA: split
KP: neutral
RESOLUTION: split these
<jeanne> ACTION: JS to update document to split 5.3.1 to separate content from user interface. See the survey of 2 June. [recorded in http://www.w3.org/2011/06/02-ua-minutes.html#action01]
<trackbot> Created ACTION-565 - Update document to split 5.3.1 to separate content from user interface. See the survey of 2 June. [on Jeanne F Spellman - due 2011-06-09].
JA: don't see that we need to specifically call out w3 specs that are implemented. this seems like a granular subset of 5.3.2. and should be written in the intent of 5.3.2
JS: I have a concern that we are confusing the issue by "W3C specifications designed to enhance accessibility of the content technology (e.g. WAI-ARIA)". I would rather see "implement and cite in the conformance claim how the user agent implements WAI-ARIA." But this makes WAI-ARIA a requirement of all user agents, and I am not sure if it applies to ALL user agents.
JR: this is where a subset of the other one.
GL: If we include this it should
include the same two bullet items at 3.5.1 defining what are
considered accessibility features. Plus they all need unique
titles.
... we don't require any other specifications to be
implemented, however we do say that if there are accessibility
features in the OS etc then that has to be supported it
therefore should be a separate SC, or a separate category and
3.5.1
JA: like the idea of just adding
GL: parallel language to
3.5.1
... I don't think what we're really trying to say comes out in
the SC.
... for technologies that you implement support their
accessibility features, and implement accessibility
technologies… wordsmithing out loud
... we need to handle the fact that in some cases there is
additional technologies we want user agents to support or
implement
... we could add this to 5.3.1 or if we're splitting up this we
could add it separately
JA: recaps… the third point– would be the platform stuff with an example of the accessibility API…?
GL: stream of consciousness - wordsmithing becomes too complex for the scribe
<Jan> There is a useful list of platform API links here: http://www.w3.org/TR/2011/WD-IMPLEMENTING-ATAG20-20110426/#gl_a12
JA: splitting the platform from the content and then adding the third one that is parallel to the content one that says you also implement and document any complementary specs for accessibility, is that necessary?
JR+1
MH+1
KP+1
KF+1
JS: done we cover this in our
standard section?
... do we not just need to make this clear that ARIA goes is
here?
JR: 4.1.1 seems to be relevant in this case therefore we do not have anything about MSAA
GL: does that mean we can take the platform stuff out of 5.3/JR I think that's right
<Jan> http://www.w3.org/WAI/UA/2011/ED-UAAG20-20110519/#gl-AT-access
JR: if you want to say something about have should talk to the platform should go up in 4.1
<JAllan> +1
s/have/how we should/
RESOLUTION: GL to take this off-line and come up with a structured solution–JR to assist
<Jan> 5.1.1 (former 1.1.1) Non-Web-Based Accessible (Level A) :
<Jan> Non-Web-based user agent user interfaces comply with and cite the requirements of standards or operating environment conventions that benefit accessibility. (Level A)
<Jan> http://www.w3.org/WAI/UA/2011/ED-UAAG20-20110519/#gl-desktop-access
<JAllan> ACTION: Greg to write platform vs a11y spec that help accessibility. as part of discussion of 5.3.3 in survey [recorded in http://www.w3.org/2011/06/02-ua-minutes.html#action02]
<trackbot> Created ACTION-566 - Write platform vs a11y spec that help accessibility. as part of discussion of 5.3.3 in survey [on Greg Lowney - due 2011-06-09].
JS: Agrees with proposal
JR: Perhaps at Level AAA.
JA: This seems to be more of an authoring tool feature. Though UA do have script error consoles and other types of debugging views, so a11y errors could be included in those. on reflection...the various developer and a11y toolbars (Wave and WAT) could meet this. I don't see this rising to the level of a must or should include in a UA to be accessible to users.
GL: If we include it, it'd be easier to read if the inline example were moved to the end of the sentence. Plus they all need unique titles.
JR: related comments - This usage of a user agent is veering into ATAG territory. I wonder if this could be handled by an informative section on how user agents can be part of the authoring process and that browser developers should look at ATAG?
JA: likes this
JS: likes this too
JR: in the informative section we say that user agents are often used by developers flipping between an authoring tool and a user agent and therefore you should also look at the ATAG.
MH: I'm in agreement with JR
RESOLUTION: JR will take an action on this
<Jan> ACTION: JR to create a section in the Intro explaining that user agents can be used in authoring processes and that therefore user agents developers should look at ATAG. [recorded in http://www.w3.org/2011/06/02-ua-minutes.html#action03]
<trackbot> Created ACTION-567 - Create a section in the Intro explaining that user agents can be used in authoring processes and that therefore user agents developers should look at ATAG. [on Jan Richards - due 2011-06-09].
KP+1
KF+1
SH+1
RESOLUTION: remove 5.3.4 in line with the actions above.
JS: accept
JR: Perhaps at AAA? This usage of a user agent is veering into ATAG territory. I wonder if this could be handled by an informative section on how user agents can be part of the authoring process and that browser developers should look at ATAG?
JA: This seems to be more of an authoring tool feature. Though UA do have script error consoles and other types of debugging views, so a11y errors could be included in those. on reflection...the various developer and a11y toolbars (Wave and WAT) could meet this. I don't see this rising to the level of a must or should include in a UA to be accessible to users.
GL: Looks like a duplicate of the proposed 5.3.4?
JA: JR- could you include this in the write-up for 5.3.4
JS: this is to move to a different area where we thought it would be a more appropriate section
RESOLUTION: move to part of the introductory statement that JR will write
JA: this is already covered in the discussions previously
RESOLUTION: no action required
JA: explaining placeholder
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/JL/GL/ Succeeded: s/to/for/ Succeeded: s/Joan A/JA/ Succeeded: s/staff/stuff/ Succeeded: s/GL: // Succeeded: s/to/too/ Succeeded: s/Chile are/JR/ Found Scribe: Harper_Simon Found ScribeNick: sharper Present: jallan kford kpatch mhakkenin glowney jspellman sharper jrichards WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 02 Jun 2011 Guessing minutes URL: http://www.w3.org/2011/06/02-ua-minutes.html People with action items: greg jr js WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]