See also: IRC log
<trackbot> Date: 09 May 2013
<kford> survey: https://www.w3.org/2002/09/wbs/36791/20130430/
<jeanne> http://lists.w3.org/Archives/Public/w3c-wai-ua/2013AprJun/0042.html
<scribe> scribe: Greg
JS: Tried to summarize conversation of last week and convert to math.
http://lists.w3.org/Archives/Public/w3c-wai-ua/2013AprJun/0042.html
JS: Each 3 day F2F is estimated to reduce the timeline to CR by about 3 months.
<jeanne> http://www.w3.org/WAI/UA/2013/draft_uawg_charter.html
JS: (The milestones haven't yet
been updated in that document.)
... This gives us a year to push and get ready to start
testing.
... Needs people to review this proposed timeline: FPWD
2008-03, LC 2013-07, CR 2015-05, PR 2016-04, Rec 2016-06.
SH: Surprised, thought we were closer to the end. How does this compare with other projects like ATAG?
JS: Comparable to other WAI standards, but slower than many non-WAI standards.
JR: Agreed, but WAI work has a different dynamic than other standards, because companies trying to promote something to standard can throw larger amounts of resources at it.
JS: Also, often technical standards have less non-technical factors to consider.
SH: How much are we expected to change things after last call? Worried that people comment and then we seem to redesign the guidelines from scratch.
JS: Complicated issue, but once
we got to last call we're staying we think we're done. We
should have been getting feedback from companies etc. all
along, but in reality we haven't. Will they continue to ignore
it, or will they seriously look at it only at that point and
overwhelm us with new (later) feedback?
... We hope to make as few changes as possible after last call.
Jan has done fantastic job of expediting ATAG comments, but
they do take time.
KF: Big concern is depending on both F2Fs happening to make the progress we're committed to. Any other way to shorten the conversations we have?
JS: Perhaps, but we need buy-in
from everyone.
... If we don't get a lot of comments, we could be done much
faster than this timeline.
JR: Thinks this timeline is
ambitious, definitely not slow.
... CR is pretty far along. The point of this is to align
thinking of browsers on what should be done in browsers, so
schedule of getting to Rec is less important.
JS: Would like to send UAAG SC to groups discussing specific browser behaviors, like maintaining point of regard, but has more weight if it's CR.
SH: If everything goes more smoothly, can we proceed faster than this?
JS: Certainly.
GL: Do we have to give warning before moving up the deadlines?
JS: No requirements around that.
KF: Hope that we can get done a lot sooner.
General agreement that we can live with this, and hope to get done sooner.
<kford> Resolved: Group agrees to Jeanne's proposal
<jeanne> Resolution: Groups agrees to the proposed timelines for the charter.
KF: Hearing concern about number of Level A SC.
JS: Looking for help filling out
priority sheet, with just the column of how many
implementations exist. This is Judy's suggestion for dealing
with the number of Level A's we have, being able to point out
that some high percentage are already implemented in the
marketplace. However, our column is only about half filled out
at this point.
... Would people be available before next call, say 10 AM EST
or Monday or Friday afternoons?
<jeanne> Friday (tomorrow 10th at 1:00 EDT)
Jan, Kelly, and Greg can join Jeanne at 1 PM EST tomorrow.
GL: Logistics for bridge, IRC?
<jeanne> Code tomorrow will be 82942
<jeanne> http://lists.w3.org/Archives/Public/w3c-wai-ua/2013AprJun/0043.html
JS: Emailed proposal for action
827 about proposal for definitions of levels. Greg sent email
with good comments.
... Didn't have much time to work on this but discussed briefly
with Greg this morning.
... Greg pointed out that the language used in defining the
levels would leave out some SC.
... Added the sentence "To avoid over-complication, the various
combinations of factors were separated into 3 levels:"
... For Level A, changed "and" to "and/or" to make it more
inclusive.
... Forwarding to the list the document that Greg emailed
her.
<jeanne> http://lists.w3.org/Archives/Public/w3c-wai-ua/2013AprJun/0044.html
The six factors, summarized:
1. How important is it for accessibility?
2. Will compliance hurt or inconvenience any population? (If the feature is significantly detrimental to some users, ensure it is worded so they can avoid it, or make it a recommendation rather than a requirement.)
3. Is it always possible? (If it is not always possible, be sure to include appropriate exceptions in the wording, or else make it a recommendation rather than a requirement.)
4. Can it be objectively measurable? (If it cannot be objectively measured at reasonable expense, it should be a recommendation rather than a requirement.)
5. How difficult is it to implement? (If it is so difficult or costly that it would have a severe detrimental effect on the company or other users, consider making it a recommendation rather than a requirement.)
6. When is compliance likely? (If we cannot expect at least two products to comply in a reasonable time frame, make it a recommendation or future requirement. If it is already widespread enough to be expected, and the other criteria are met, consider making it a requirement even if is not of high importance.)
EH: Responded in last week's survey and proposed rewording, which should be taken into account.
<jeanne> https://www.w3.org/2002/09/wbs/36791/20130430/results
GL: The document has good wording on factors taken into account, but would need significant editing to create summary paragraphs for each level.
<jeanne> Eric's proposal:
<jeanne> The three levels of UAAG2 conformance (described above) are based on based on the level (A, AA, or AAA) designations of the more than 100 success criteria (i.e., specific requirements). The description of each success criterion in this document shows that designation. In making these designations, the UAWG considered both the impact of the success criterion of individuals with disabilities as well
<jeanne> as the likely degree of technical challenge in satisfying the success criteria.
<jeanne> ... The level A designation was given to success criteria for which failure to satisfy would block access for one or more groups of individuals with disabilities. [Eric comment: Isn't the blocking of access for level A SCs much more essential aspect than technical challenge? If seems to me that while some of the level A SCs "are relatively minor for developers to solve", others are not. In a sense,
<jeanne> if it would block access we do we really care if it is hard or easy to solve?]
<jeanne> ... The level AA designation was given to success criteria where failure to satisfy would make access difficult for one or more disability groups and where the technical challenge in satisfying would be moderate or easier.
<jeanne> ... The level AA designation was given to success criteria where failure to satisfy would make access difficult for one or more disability groups and where the technical challenge in satisfying would likely be large.
EH: Thought Level A could focus entirely on impact, ignoring difficulty of implementation. Level AA would present difficulties for some users but would require moderate or less level of effort, while AAA would present difficulties but would be a major effort to address. Trying to simplify it a bit.
GL: I don't think we can make things Level A if they're impossible for most user agents to implement, as it would probably end up causing the standard to be ignored.
EH: Aren't all SC supposed to be
objectively measurable, regardless of level?
... If an SC isn't testable, should perhaps be removed from the
document.
... Impact plus difficulty of implementation could be the two
key factors used in determining levels.
JS: Proposed postponing this until next week, work on it using Greg's and Eric's input.
KF: How do we get to closing this next week?
JR: Chair's job to speak up when they feel things are getting out of hand.
KF: Would really like to finish this next week. Make motivated effort to bring to the list of Jeanne soon if you have input.
JR: Keep in mind it's informative only.
GL: But last week it was pointed out if we're too specific it would allow level assignments to be challenged.
JR: True. We should not bee to specific or imply the factors and assignment practices are objective.
<jeanne> There are many different types of disabilities and different types of user agents, so the UAAG level assigned to a success criterion may not precisely match the definition of the level in all circumstances.
EH: Jan's simpler approach might be better.
JS: Need to define levels; Judy is always asked by governments how these are defined.
JR: Very hard, which is why ATAG didn't try to do so. If you have strong criteria and didn't live up to them entirely, will get challenged.
KF: No matter how good we are, we'll find places where we didn't exactly conform to our criteria, and also open up to people disagreeing with the criteria.
JS: Being able to promote UAAG in the long run outweighs criticism in the short run.
KF: Talked about it a few times, several people expressed interest, anyone feeling like leading this?
JR: Can look like pseudo-code.
JR is using as an example the SC on background image toggle (2.11.1).
<jeanne> Test 0001 Assertion: If the authoring tool contains editing-views that render visual time-based content, then those editing-views can be paused and can be set to not play automatically
<jeanne> If the authoring tool cannot be used to edit time-based content such as video, animation, animated gifs etc., then select SKIP
<jeanne> If the authoring tool does not include editing views that render visual time-based content such as video, animation, animated gifs etc., then select SKIP
<jeanne> If the renderings are non-editable, such as previews, then select SKIP.
<jeanne> For each editing view that renders and plays visual time-based content:
<jeanne> Load sample video (audio, animation, animated gifs etc.)
<jeanne> If the editing view does not automatically play time-based content automatically, then go the next editing view that renders and plays visual time-based content (if any).
<jeanne> If the authoring tool can be set to never play time-based content automatically AND once playing the content can be paused, then go the next editing view that renders and plays visual time-based content (if any).
<jeanne> If the editing view is web-based and the browser can be used to prevent auto-play and to pause the playing content then go the next editing view that renders and plays visual time-based content (if any).
<jeanne> Go the next editing view that renders and plays visual time-based content (if any).
<jeanne> SelectPASS (all editing views must have passed)
(The above example would be more easily understood if the paragraph numbers had copied and pasted.)
<jeanne> http://www.w3.org/WAI/AU/2013/ATAG2-10April2012PublicWD-Tests
<Jan> Test 0001 Assertion: Authors can choose from a set of in-market user agents for previews.
<Jan> Determine from the user interface, online help, or documentation that the application provides a preview function. If no preview mode exists, then select SKIP.
<Jan> Note: A preview is non-editable view of how the content would appear to end users of user agents.
<Jan> If authors can specify which user agent (of those installed on their system that can render the content technology in question) is to be used to perform the preview, then select PASS.
<Jan> Otherwise, select FAIL.
JR: Did most of ATAG. Had a few
tweaks but few long arguments about the tests themselves.
... Just getting people to come to meetings and attest to the
fact they'd read the proposed tests was difficult.
SH: Concerned that if we write
the tests, then end up changing SC, we have to rewrite
completed tests.
... Seems doing tests like this for our SC would be reasonable,
it they don't have to be redone repeatedly.
JS: Considering integrating tests into the main document so if we tweak an SC we can tweak the test at the same time.
SH: Will do some tests for 1.1 in the next few weeks, to see how difficult it is.
JR: Can try to find some time to identify where we can reuse tests already written for ATAG.
JS: Note that all occurrences of "SKIP" will be changed to "NOT APPLICABLE"; it was originally written for a different tool.
JS: Everyone was going to check their schedules regarding second week of July.
<jeanne> July 23-25 (Tues-Thurs)
The group had a possible conflicts on 2nd and 3rd weeks of July, but considering 4th week of July.
<sharper> http://www.sigaccess.org/assets13/
SH: What about doing something around the ACM Assets conference in Seattle October 21-23?
JS: Unfortunately that's close to the TPAC in China, where we hope to have a F2F.
<jeanne> TPAC in CHina is November 10-15
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Found Scribe: Greg Inferring ScribeNick: Greg Default Present: +1.425.883.aaaa, Jeanne, Greg_Lowney, kford, sharper, Jan, +1.609.734.aabb, Kim_Patch Present: Eric Greg_Lowney Jan Jeanne Kim_Patch kford sharper Regrets: Jim Found Date: 09 May 2013 Guessing minutes URL: http://www.w3.org/2013/05/09-ua-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]