See also: IRC log
<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
have been merged with A11y TF responses and sent to WebTV
<Greg> ACTION-980 - Write conformance/ introduction extension existence discover-ability and life span [on Greg Lowney - due 2014-05-29]
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
... 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
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
... 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.
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
(c) easily installed (i.e. not requiring expert knowledge or editing of
configuration files, databases, or registry entries)
See Components of UAAG 2.0 Conformance Claims
any objections --
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.
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
...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."
<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].
<trackbot> Closed action-980.
js: change paradigm for levels of
... 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
... 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...
gl: which SC are miss-categorized.
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
... 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
... 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
... 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.
"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
... 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
... 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
... (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
... I want both
... when I am supporting someone, or testing
platform interaction API(s) - touch, keyboard, voice, shake, rattle, roll
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/kp;/kp:/ Succeeded: s/equivelencies/equivalencies/ Found Scribe: allanj Inferring ScribeNick: allanj Default Present: [Microsoft], Jeanne, Jim_Allan, Kim_Patch, Greg_Lowney, Jan Present: [Microsoft] Jeanne Jim_Allan Kim_Patch Greg_Lowney Jan Kelly Regrets: Jan Agenda: http://lists.w3.org/Archives/Public/w3c-wai-ua/2014AprJun/0046.html WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 29 May 2014 Guessing minutes URL: http://www.w3.org/2014/05/29-ua-minutes.html People with action items: jeanne[End of scribe.perl diagnostic output]