- From: Jim Allan <jimallan@tsbvi.edu>
- Date: Thu, 29 May 2014 13:48:38 -0500
- To: WAI-ua <w3c-wai-ua@w3.org>
- Message-ID: <CA+=z1Wkq8+gXh6oOjpb8Er_GAbetp0Mqj_zfVukmHOkG-EVNrg@mail.gmail.com>
from: http://www.w3.org/2014/05/29-ua-minutes.html
- DRAFT - User Agent Accessibility Guidelines Working Group Teleconference 29
May 2014
Agenda <http://lists.w3.org/Archives/Public/w3c-wai-ua/2014AprJun/0046.html>
See also: IRC log - http://www.w3.org/2014/05/29-ua-irc
<http://www.w3.org/2014/05/29-ua-irc>
Attendees
Present[Microsoft], Jeanne, Jim_Allan, Kim_Patch, Greg_Lowney, Jan, Kelly
RegretsJanChairSV_MEETING_CHAIRScribeallanj
Contents
- Topics <http://www.w3.org/2014/05/29-ua-minutes.html#agenda>
1. WebTV use cases
<http://www.w3.org/2014/05/29-ua-minutes.html#item01>
2. action-980 <http://www.w3.org/2014/05/29-ua-minutes.html#item02>
3. indicator of limited conformance claim
<http://www.w3.org/2014/05/29-ua-minutes.html#item03>
4. Limited conformance for extensions section
<http://www.w3.org/2014/05/29-ua-minutes.html#item04>
5. comment MS06 <http://www.w3.org/2014/05/29-ua-minutes.html#item05>
6. MS07 <http://www.w3.org/2014/05/29-ua-minutes.html#item06>
- Summary of Action Items
<http://www.w3.org/2014/05/29-ua-minutes.html#ActionSummary>
------------------------------
<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
(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
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
Summary of Action Items *[NEW]* *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]
*[NEW]* *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]
[End of minutes]
--
Jim Allan, Accessibility Coordinator & Webmaster
Texas School for the Blind and Visually Impaired
1100 W. 45th St., Austin, Texas 78756
voice 512.206.9315 fax: 512.206.9264 http://www.tsbvi.edu/
"We shape our tools and thereafter our tools shape us." McLuhan, 1964
Received on Thursday, 29 May 2014 18:49:03 UTC