See also: IRC log
<trackbot> Date: 10 July 2014
code is 82941
proposed:
1.10.1 Access Related Information: The user can access information from explicitly-defined relationships in the content, including at least the following (Level AA):
* label for a control or image (e.g. HTML label element, figcaption and aria-labelledby attributes)
* caption for a table
* row and column labels for a table cell
<scribe> scribe: allanj
<Jan> http://lists.w3.org/Archives/Public/w3c-wai-ua/2014JulSep/0014.html
jr: concerned about HTML mentioned in sc
ja: fine with leaving HTML out, just use label element
gl: in 2.3.3 we say landmark - this is a generic term, unless we qualify by saying aria-landmark. we should be clear
jr: we should do it same way through out document
<Greg> Similarly, Summary of 2.6 uses "onmouseover" without explaining it's an HTML etc. attribute.
gl: fine with leaving out the example, assume it will be explained in implementing document
<Greg> I'm okay omitting the entire parenthetical e.g. and explaining it in the Implementing document. I just tend to include parenthetical examples, perhaps too often.
proposed:
1.10.1 Access Related Information: The user can access information from explicitly-defined relationships in the content, including at least the following (Level AA):
* label for a control or image
* caption for a table
* row and column labels for a table cell
ja: any objections?
none heard
gl: examples need to go in the implementing doc
<scribe> ACTION: jeanne add 1.10.1 1.10.1 Access Related Information: The user can access information from explicitly-defined relationships in the content, including at least the following (Level AA): * label for a control or image * caption for a table * row and column labels for a table cell with these examples " (e.g. HTML label element, figcaption and aria-labelledby attributes)" in implementing doc [recorded in http://www.w3.org/2014/07/10-ua-minutes.html#action01]
<trackbot> Created ACTION-996 - Add 1.10.1 1.10.1 access related information: the user can access information from explicitly-defined relationships in the content, including at least the following (level aa): * label for a control or image * caption for a table * row and column labels for a table cell with these examples " (e.g. html label element, figcaption and aria-labelledby attributes)" in implementing doc [on Jeanne F
<trackbot> ... Spellman - due 2014-07-17].
close action-995
<trackbot> Closed action-995.
<Greg> Chatzilla really should not bold text after an asterisk if it's followed by a space.
<scribe> ACTION: jeanne to revise IER for 1.10.1 to match the new wording of the SC [recorded in http://www.w3.org/2014/07/10-ua-minutes.html#action02]
<trackbot> Created ACTION-997 - Revise ier for 1.10.1 to match the new wording of the sc [on Jeanne F Spellman - due 2014-07-17].
<Greg> I note that the Intent for 1.10.1 explicitly mentioned use of id and child elements, neither of which apply any more except in very limited cases (e.g. aria-labelledby).
For the understandability principle, then isn't this a little all encompassing. There is nothing about simple language usage or graphic usage for people with a learning disability. So my question is understandable to whom?
<Jan> http://jspellman.github.io/UAAG-LC-Comment/
jr: we have requirement that
web-base user agents follow WCAG (simple language) AAA
... had the same issue of ATAG, a11y of the platform based
tool. is there a higher bar for web-based that
platform-based.
... we used the 'key' parts of WCAG for the platform-based
tools. Perhaps UAAG should do the same.
gl: do we need to add new SCs to cover understandable.
ja: perhaps the issue is with the term "understandable"
<Greg> I doubt it's feasible for us to add a bunch of new SCs for understandability at this point.
jr: wcag could/should apply to software
<Jan> FYI http://www.w3.org/TR/WCAG20/#understandable
kp: is the issue that Principle 3
is too broad
... P3 is an organizing principle, though it is not all
encompassing
gl: simple language for interface
kp: is it more or less important
in WCAG or UAAG. seems more in WCAG.
... putting all of WCAG in UAAG would clutter the document.
UAAG has chosen the bits we felt important
jr: what if in 5.1 we put a note that non-web UAs look at WCAG for interface design.
<Jan> oops call dropped
<Jan> http://www.w3.org/TR/wcag2ict/
kp: if remove the part in 5.1.1 about web-based UA and just make it UAs, and point to wcagict
<Jan> 5.1.1 Comply with WCAG: User agent user interfaces meet the WCAG 2.0 success criteria. (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; and Level AAA to meet WCAG 2.0 Level A, AA, and AAA success criteria)
<Jan> Note: To understand how this success criterion applies to non-web-based user agent user interfaces, refer to Guidance on Applying WCAG 2.0 to Non-Web Information and Communications Technologies (WCAG2ICT).
gl: if you want to test FF for new 5.1.1... are we going to create use cases for every wcag SC to apply to UAs
jr: ATAG relies on wcag tests
gl: this scares me
jr: did you have a concern about old 5.1.1 for web-based UAs
gl: not sure there are any tests for WCAG2ICT
jr: re: evaluation methodology is out.
<Greg> I assumed that the old 5.1.1 was testable because W3C had approved test cases for WCAG on web content, but probably not for WCAG2ICT.
jr: no tests for WCAG2ICT compliance.
gl: what tests will UAWG have to create to allow developers to meet 5.1.1 (proposed)
ja: sounds like there are no tests.
jr: excellent point
... in the end, UAWG was trying to make some guidelines that go
beyond basic software accessibility.
... ok with leaving 5.1.1 as it was and not accepting SH05
ja: +1, we covered what we thought was important in Principle 3
gl: leaving 5.1.1. as is easiest course of action. otherwise a big can of worms. are there other reasons than covering Understandability
jr: will we create unintended new requirements base on the convergences of UAAG and WCAG
ja: add a note to principle 3 that UAWG chose the following to cover Understandability of the UA. If the developer wants to go further review WCAG2ICT for guidance.
gl: what about adding a note to 5.1.1 also. seems more appropriate.
jr: note only on 5.1.1 not principle 3
<Jan> 5.1.1 Comply with WCAG: Web-based user agent user interfaces meet the WCAG 2.0 success criteria. (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; and Level AAA to meet WCAG 2.0 Level A, AA, and AAA success criteria)
<Jan> Note: This success criterion does not apply to non-web-based user agent user interfaces, but does include any parts of non-web-based user agents that are web-based (e.g. help systems). However, it is receommended that developers of non-web-based user agent user interfaces refer to Guidance on Applying WCAG 2.0 to Non-Web Information and Communications Technologies (WCAG2ICT).
ja: +1
kp: +1
ja: any objections?
<Jan> 5.1.1 Comply with WCAG: Web-based user agent user interfaces meet the WCAG 2.0 success criteria. (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; and Level AAA to meet WCAG 2.0 Level A, AA, and AAA success criteria)
<Jan> Note: This success criterion does not apply to non-web-based user agent user interfaces, but does include any parts of non-web-based user agents that are web-based (e.g. help systems). However, it is recommended that developers of non-web-based user agent user interfaces follow the Guidance on Applying WCAG 2.0 to Non-Web Information and Communications Technologies (WCAG2ICT).
<Greg> Take out "developers of"?
<Jan> 5.1.1 Comply with WCAG: Web-based user agent user interfaces meet the WCAG 2.0 success criteria. (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; and Level AAA to meet WCAG 2.0 Level A, AA, and AAA success criteria)
<Jan> Note: This success criterion does not apply to non-web-based user agent user interfaces, but does include any parts of non-web-based user agents that are web-based (e.g. help systems). However, it is recommended that non-web-based user agent user interfaces follow the Guidance on Applying WCAG 2.0 to Non-Web Information and Communications Technologies (WCAG2ICT).
<Greg> ("Non-web-based user agent user interfaces" is such a horrible noun-stack.)
<Jan> Back to...
<Jan> 5.1.1 Comply with WCAG: Web-based user agent user interfaces meet the WCAG 2.0 success criteria. (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; and Level AAA to meet WCAG 2.0 Level A, AA, and AAA success criteria)
<Jan> Note: This success criterion does not apply to non-web-based user agent user interfaces, but does include any parts of non-web-based user agents that are web-based (e.g. help systems). However, it is recommended that developers of non-web-based user agent user interfaces follow the Guidance on Applying WCAG 2.0 to Non-Web Information and Communications Technologies (WCAG2ICT).
<Jan> JR: +1
<Greg> GL: +1
<scribe> ACTION: jeanne to add to 5.1.1 Note: This success criterion does not apply to non-web-based user agent user interfaces, but does include any parts of non-web-based user agents that are web-based (e.g. help systems). However, it is recommended that developers of non-web-based user agent user interfaces follow the Guidance on Applying WCAG 2.0 to Non-Web Information and Communications... [recorded in http://www.w3.org/2014/07/10-ua-minutes.html#action03]
<trackbot> Created ACTION-998 - Add to 5.1.1 note: this success criterion does not apply to non-web-based user agent user interfaces, but does include any parts of non-web-based user agents that are web-based (e.g. help systems). however, it is recommended that developers of non-web-based user agent user interfaces follow the guidance on applying wcag 2.0 to non-web information and communications... [on Jeanne F Spellman - due
<trackbot> ... 2014-07-17].
UNKNOWN_SPEAKER: Technologies (WCAG2ICT). replacing old note.
jr: calling out UAUI in this doc may diminish the impact of 5.1.1 note, seems contradictory
gl: example?
jr: 2.1.5 & 2.1.6,
... 215 says UI, 216 say UAUI but say the same thing other
wise
gl: note in 511 doesn't address comment about understandability
http://jspellman.github.io/UAAG-LC-Comment/
gl: graphic usage or simple wording.
<Greg> Simon gave two examples of where Principle 3 failed to address aspects of understandability: simple language, and graphics as alternative to text. The note on 5.1.1 might address the first (in a roundabout way), but what about the second?
jr: it does. WCAG lots on
wording, pronunciation, etc. nothing about graphics
... media alternative for text
... but, no requirement for media as an alternative for
text.
<Greg> If WCAG uses the term Understandability without addressing people who cannot read, then I guess we can, too. (Although of course it would be nice not to ignore those issues.)
jr: UAAG cannot go further than WCAG on media replacement for text. see cognitive task force
response - UAAG accepts, added note to 5.1.1, to encourage developers to incorporate WCAG into the process. UAWG chose items in Principle 3 that were feasible and important
scribe: include text of the note.
<Jan> Response: UAWG partially accepts. We note that SC5.1.1 already requires web-based user agents to meet parts of WCAG 2.0. We also added a note to 5.1.1, to encourage non-web-based user agent developers to follow WCAG 2.0. UAWG chose items in Principle 3 that were feasible and important.
<Greg> "While there are aspects of understandability which are not addressed in UAAG20, UAWG chose to include items in Principle 3 that were both important and feasible."?
Response: UAWG partially accepts. We note that SC5.1.1 already requires web-based user agents to meet parts of WCAG 2.0. We also added a note to 5.1.1, to encourage non-web-based user agent developers to follow WCAG 2.0. While there are aspects of understandability which are not addressed in UAAG20, UAWG chose to include items in Principle 3 that were both important and feasible.
<Greg> Just softening it a bit, acknowledging that he's in fact correct about his original observation.
RESOLUTION:
Response to SH05: UAWG partially accepts. We note that SC5.1.1
already requires web-based user agents to meet parts of WCAG
2.0. We also added a note to 5.1.1, to encourage non-web-based
user agent developers to follow WCAG 2.0. While there are
aspects of understandability which are not addressed in UAAG20,
UAWG chose to include items in Principle 3 that were both
important and...
... feasible.
Topic SH06 4.1.7
is about making API Calls be timely such that delays aren't perceived by users, but this is difficult if the software interfaced to us not timely, people may the perceive a delay. I think this needs to be a little more explicit.
4.1.7 Make Programmatic Exchanges Timely: For APIs implemented to satisfy the requirements of UAAG 2.0, ensure that programmatic exchanges proceed at a rate such that users do not perceive a delay. (Level A)
ja: does this need specific timings... .5 seconds
jr: depends on computing environment
gl: not more explicit about time, but about APIs that are causing problems that are beyond the control of the UA
<Greg> I think Simon's saying, not that we need to be explicit about a minimum time delay, but that the UA is not held responsible for delays outside of its control. For example, if the UA API function call the OS which takes a half second to return, that is not violating 4.1.7 because the UA did not itself introduce the delay.
<Greg> How about "4.1.7 Make Programmatic Exchange Timely: For APIs implemented to satisfy the requirements of UAAG 2.0, ensure that (the user agent does not introduce delays into* programmatic exchanges such that users would perceive the delay. (Level A)"
<Greg> That is, "4.1.7 Make Programmatic Exchange Timely: For APIs implemented to satisfy the requirements of UAAG 2.0, ensure that *the user agent does not introduce delays into* programmatic exchanges such that users would perceive the delay. (Level A)"
kf: this is useless without metrics.
kp: timing issues are huge with speech
kf: this is about how quickly an AT can build a list of UI elements
gl: well, AT queries UA, and the call returns (that is the cycle time)
ja: how do we test this. how do we know whose fault it is.
kf: we should remove this.
... after further reflection this is not a testable criteria.
General software performance suggests developers should be
doing this anyway
kp: timing kills speech. timing cascades build and cause problems
kf: those delays are not caused
by inter API communication
... IE with narrator - ask for list of UI elements, can take
SECONDS. but the problem is not IEs fault.
kp: are you sure the UA never has anything to do with timing
<Greg> I am a little concerned that some UA may implement accessibility API in an inefficient (slow) way because it's implemented solely to comply with a requirement, rather than actually to address the needs of users who rely on assistive technology.
kf: this is not testable. what is
the appropriate number.
... 300 milliseconds
jr: need to test api call and screen reader processing.
kf: the causes of this are not
the UA, they cannot fix it.
... fine if we leave it in.
rssagent, make minutes
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) Succeeded: s/add a new SCs/add a bunch of new SCs/ Found Scribe: allanj Inferring ScribeNick: allanj Present: jim kelly jan greg kim Regrets: eric jeanne Found Date: 10 Jul 2014 Guessing minutes URL: http://www.w3.org/2014/07/10-ua-minutes.html People with action items: jeanne[End of scribe.perl diagnostic output]