User Agent Accessibility Guidelines Working Group Teleconference -- 10 Jul 2014

<trackbot> Date: 10 July 2014

code is 82941

rewrite of 1.10.1

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).

SH05 Principle 3

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> 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> 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> 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

- DRAFT -

User Agent Accessibility Guidelines Working Group Teleconference

10 Jul 2014

Attendees

Contents

rewrite of 1.10.1

SH05 Principle 3

Summary of Action Items

Scribe.perl diagnostic output