User Agent Accessibility Guidelines Working Group Teleconference -- 29 May 2014

<trackbot> Date: 29 May 2014

<kford> WebTV use-cases - comment on-line, please

<kford> 981 jim - Create or modify an sc (1.7x) to allow for multiple user stylesheets

<kford> 981 greg - Greg to write conformance/ introduction extension existence discover-ability and life span

<kford> 979 jim - rewrite of 1.4

<kford> 978 jeanne - write proposal for ms05 response

<kford> 977 greg - glossary entry for 'recognize'

<kford> 976 jim - def of rendered content

<kford> 975 jim - use of uaui or rc in document

<kford> 974 jan - work text into introduction

<kford> 972 jeanne - smith cr05 response re: heading nav

<scribe> scribe: allanj

WebTV use cases

have been merged with A11y TF responses and sent to WebTV

action-980

<Greg> ACTION-980 - Write conformance/ introduction extension existence discover-ability and life span [on Greg Lowney - due 2014-05-29]

http://lists.w3.org/Archives/Public/w3c-wai-ua/2014AprJun/0049.html

jr: should put 6.b as the first item in the list
... what does 'maintained' mean

gl: subsidized, published

js: UA can't make an update and break an extension. the extension must be updated also

gl: some ext. might not be available.

jr: concern. next version of software might break anything in UAAG. this is a big change

gl: take responsibility

jr: UA version x works with ext. version y.

kp: this is good, don't have to support or develop further, just ensure it works.

jr: it becomes a claim for business relationship and technical working
... we have conditions for current versions. this puts condition on the future. UA needs to establish relationships with ext. developters

kp: seems to discourage use of extensions.

jr: what if there is 'or', define actively maintained. if no active maintain then don't break ext. used in claim for next release

kp: UA keep a list of things not to break on next releases.
... as a small .com maintaining .ext can break the company

gl: UA changes API to improve functioning...but breaks extensions. when ext. is not supported...no time to update, then ext. is gone. usually 1 maintainer.
... UA doesn't see these

kp: letting developers know about what is changing. UA care about ext. devs
... give heads up or take it over.
... +1 to 'or'

jr: UA actively maintain or support/heads-up to developers
... these are normative
... testable

js: don't have to test, not an SC

jr: maintain for 6 months.

gl: some ext. don't break and haven't been updated. but what happens when they do break

jr: so, ext. works in this version. trying to consider future versions

kp: what happens when it stops working. who knows

kf: what level is this

ja: in conformance claim

jr: essentially level A

kf: no one will do this

jr: unless we have some changes can't support

kf: concerned about b. maintained by UA developer
... maintained implies ownership of the code
... 'UA ensures compatibility with the extension'

jr: so only works for this version.

kf: conformance only works the stated version
... what is purpose of b.

gl: if extension is out there, obscure, or have to pay.

kf: A, C, D cover those
... remove B
... UA would not bet UA conformance on some random extension

as written today, UAx can make a conformance claim because that extension exits. then ext. can ask UAx for money to maintain extension to keep conformance.

kf: to the extent that a UA wants to make a conformance claim, they mostly won't use 3rd party extensions.

objections to removing B.

none heard

Resolution: accept in Conformance Applicability Notes - 6. Extensions: Success criteria can be met by a user agent alone or in

conjunction with extensions and add-ons, as long long as those are:

(a) discoverable by the user

(b) no extra cost to the user

configuration files, databases, or registry entries)

See Components of UAAG 2.0 Conformance Claims

indicator of limited conformance claim

any objections --

none heard

Limited conformance for extensions section

Current: This option may be used for a user agent extension or plug-in

with limited functionality that wishes to claim UAAG 2.0 conformance. An

extension or plugin can claim conformance for a specific success

criterion or a narrow range of success criteria as stated in the claim.

All other success criteria may be denoted as Not Applicable. The add-in

must not cause the combined user agent (hosting user agent plus

installed extension or plug-in) to fail any success criteria that the

hosting user agent would otherwise pass.

Proposed:

This option may be used for a user agent extension or plug-in with limited functionality that wishes to claim UAAG 2.0 conformance. An extension or plugin can claim conformance for a specific success criterion or a narrow range of success criteria as stated in the claim. All other success criteria may be denoted as Not Applicable. UAAG recognizes that some extensions may be so specialized to...

scribe: the needs of a particular disability that the extension is be mutually exclusive with other success criteria of UAAG, but the goal would be for extensions to work with the user agent so that any features of the user agent needed for UAAG conformance are not broken by one extension. If the extension limits other accessibility features of the user agent, then include a statement to that...
...effect: "This extension breaks success criterion (SC) x.x.x for this class of users because it is intended to meet 'foo' need of this other class of user."

any objections?

none heard

<scribe> ACTION: jeanne to update the document with the approved wording for 6. (all but b), adding 4. check box, and new Limited Conformance for extensions wording [recorded in http://www.w3.org/2014/05/29-ua-minutes.html#action01]

<trackbot> Created ACTION-982 - Update the document with the approved wording for 6. (all but b), adding 4. check box, and new limited conformance for extensions wording [on Jeanne F Spellman - due 2014-06-05].

close action-980

<trackbot> Closed action-980.

comment MS06

http://jspellman.github.io/UAAG-LC-Comment/

js: change paradigm for levels of SC
... not about PWD only about A. UA and environment, AA aid overcoming content failures, AAA find solution

initial response: If a large portion of the content on the web does not entirely comply with WCAG 2.0, I do not feel that user agents should be absolved from responsibility for compensating for those deficiencies where the techniques for doing so are well understood and reasonable. Of course, that is not to say user agents can decide not to take those steps, but doing so should have the...

scribe: consequence of not being able to claim to be as fully accessible as users would expect. Just as most users expect browsers to make best efforts to render content that has errors in its HTML, users will expect browsers to make reasonable effort to render content that does not fully and accurately comply with WCAG, and we would be doing an injustice to say a browser is doing its part if it...
... fails to make those efforts. Of course, the user agent will not be faulted for failing to remedy inadequate documents if it simply refuses to render them at all. That being said, please point out any specific success criteria that you feel are “unclear, untested, or unrealistic”, or that should be reprioritized from A to AA or AAA; such specific input would be more useful than broad...
... generalizations.

gl: which SC are miss-categorized.

current levels

Level A success criteria address needs where (a) groups of people with disabilities are blocked from information or accomplishing a task, and/or (b) provide solutions that are relatively minor for developers to implement or are common in the marketplace.

Level AA success criteria address needs where (a) groups of people with disabilities have difficulty accessing information or accomplishing a task (including tasks causing excessive fatigue) and/or (b) the solutions may be more difficult to implement.

Level AAA success criteria address needs where (a) the solution improves accessibility or reduces fatigue for specific groups of people with disabilities and/or (b) the solution is very difficult to implement.

js: UAAG def is user oriented
... proposal is UA utility oriented.
... don't know how we would map our SC to the proposed model.

kp: almost all of our SCs map to level A
... comment also seems to want to narrow the scope. but no specifics.

gl: want to include futuristic stuff is to push the UA to do more
... at the AAA level

kp: we balance the user and developer, because we are concerned about the difficulty of implementing
... but commenter does not consider difficulty
... we have different opinions about generally accessible UI and provides programmatic access. comments seem a misconception of what we wrote.
... perhaps also an education problem.

use "Just as most users expect browsers to make best efforts to render content that has errors in its HTML, users will expect browsers to make reasonable effort to render content that does not fully and accurately comply with WCAG, and we would be doing an injustice to say a browser is doing its part if it fails to make those efforts."

point to http://jspellman.github.io/UAAG/UAAG20/#intro-conf-levels for explaination of levels

reviewed proposed levels and feel the entire document meets the commenter's proposed Level A

comment did not take into account difficulty of implementation. we did

kp: we are in agreement with ABCD of comment, but we balance the benefit to the user vs the difficulty of implementation

we spread SCs across 3 levels because of the balance

commenter suggests that Level A only concern is about content that meets WCAG20...

<Greg> "The commenter suggests that any SC relating to the rendering of content that fails to completely meet WCAG 2.0 should be relegated to lower priority levels."

response to Level A: "Just as most users expect browsers to make best efforts to render content that has errors in its HTML, users will expect browsers to make reasonable effort to render content that does not fully and accurately comply with WCAG, and we would be doing an injustice to say a browser is doing its part if it fails to make those efforts."

Kim will smith a response based on the above.

MS07

"Think beyond the desktop"

initial response: if there are specific success criteria that you feel can better address devices with small screens and which perhaps lack keyboard input, please point them out.

js: mobile keyboards are not used for navigation. UAAG says they must

gl: no, we say keyboard or keyboard emulator
... can you connect a bluetooth keyboard

js: but tab does not work, arrow keys have limitations.
... we need to look at this.

ja: What about device independence note.

js: not testable, and overridden by 2.1.1 - full keyboard functionality

kp: there are apps that have keyboard shortcuts.

js: we have a problem
... add a phrase "keyboard features supported by the platform can be operated via the keyboard"

current: 2.1.1 Provide Full Keyboard Functionality: All functionality can be operated via the keyboard using sequential or direct keyboard commands that do not require specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints (e.g. free hand drawing). This does not forbid and...
... should not discourage providing other input methods in addition to keyboard operation including mouse, touch, gesture and speech. (Level A)

<jeanne2> All functionality supported by the keyboard interface of the platform can be operated...

proposed: 2.1.1 Provide Full Keyboard Functionality: All functionality provided by the keyboard interface of the platform can be operated via the keyboard using sequential or direct keyboard commands that do not require specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints...
... (e.g. free hand drawing). This does not forbid and should not discourage providing other input methods in addition to keyboard operation including mouse, touch, gesture and speech. (Level A)

js: then need to add explanation to intent and examples

comments on the proposal?

gl: don't agree. working on response

kp: we say Keyboard, but mean IndieUI.

js: Navigation is the sticking point. breaks for devices with out keyboard
... if it is not supported on platform that has something better, do we want to make them go back to keyboard.

kp: better for whom. keyboard works for those who can't "pinch to zoom".
... we should be talking about both.
... touch is better for many. speech is incomplete.
... touch on desktop. many solutions are incomplete, shouldn't have to choose among them.
... if there were full keyboard access to smart devices, you would see more keyboard access
... we are prescribing how users need to use a device. we shouldn't

gl: talked about replacing "keyboard" with some other term. 'discrete input'

js: 2.1.1 is the most prescriptive. keyboard or kb interface

kp: we mean indieUI

gl: or API,

<jeanne2> how about keyboard, keyboard interface, or indie ui event

gl: if just for text input, not good enough. need navigation and interaction control

ja: platform interaction API

<scribe> ACTION: jeanne to check with MC about language for alternative for keyboard interface, indieUI [recorded in http://www.w3.org/2014/05/29-ua-minutes.html#action02]

<trackbot> Created ACTION-983 - Check with mc about language for alternative for keyboard interface, indieui [on Jeanne F Spellman - due 2014-06-05].

kp: we use 'equivalencies' swipe, touch, tap, etc. speech user says "launch foo". not equivalent at all!
... I want both
... when I am supporting someone, or testing

platform interaction API(s) - touch, keyboard, voice, shake, rattle, roll

- DRAFT -

User Agent Accessibility Guidelines Working Group Teleconference

29 May 2014

Attendees

Contents

WebTV use cases

action-980

indicator of limited conformance claim

Limited conformance for extensions section

comment MS06

MS07

Summary of Action Items

Scribe.perl diagnostic output