- From: Jeanne Spellman <jeanne@w3.org>
- Date: Thu, 09 May 2013 14:42:52 -0400
- To: UAWG <w3c-wai-ua@w3.org>
Minutes:
http://www.w3.org/2013/05/09-ua-minutes.html
Text of Minutes
[1]W3C
[1] http://www.w3.org/
- DRAFT -
User Agent Accessibility Guidelines Working Group Teleconference
09 May 2013
See also: [2]IRC log
[2] http://www.w3.org/2013/05/09-ua-irc
Attendees
Present
Eric, Greg_Lowney, Jan, Jeanne, Kim_Patch, kford,
sharper
Regrets
Jim
Chair
Kford
Scribe
Greg
Contents
* [3]Topics
1. [4]Timelines for the charter
2. [5]Scheduling a subgroup to work on implementations
for level A
3. [6]Definition for levels
4. [7]Testing sub-group
5. [8]scheduling a Face to Face
* [9]Summary of Action Items
__________________________________________________________
<trackbot> Date: 09 May 2013
<kford> survey:
[10]https://www.w3.org/2002/09/wbs/36791/20130430/
[10] https://www.w3.org/2002/09/wbs/36791/20130430/
Timelines for the charter
<jeanne>
[11]http://lists.w3.org/Archives/Public/w3c-wai-ua/2013AprJun/0
042.html
[11]
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.
[12]http://lists.w3.org/Archives/Public/w3c-wai-ua/2013AprJun/0
042.html
[12]
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>
[13]http://www.w3.org/WAI/UA/2013/draft_uawg_charter.html
[13] 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.
Scheduling a subgroup to work on implementations for level A
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
Definition for levels
<jeanne>
[14]http://lists.w3.org/Archives/Public/w3c-wai-ua/2013AprJun/0
043.html
[14]
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>
[15]http://lists.w3.org/Archives/Public/w3c-wai-ua/2013AprJun/0
044.html
[15]
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>
[16]https://www.w3.org/2002/09/wbs/36791/20130430/results
[16] 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.
Testing sub-group
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>
[17]http://www.w3.org/WAI/AU/2013/ATAG2-10April2012PublicWD-Tes
ts
[17] 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.
scheduling a Face to Face
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> [18]http://www.sigaccess.org/assets13/
[18] 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
Summary of Action Items
[End of minutes]
Received on Thursday, 9 May 2013 18:43:30 UTC