W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > January to March 2013

minutes: UAWG telecon 17 Jan 2013

From: Jim Allan <jimallan@tsbvi.edu>
Date: Thu, 17 Jan 2013 13:41:37 -0600
Message-ID: <CA+=z1Wn=o7QBzBs0s_cnxzn=L96D+gU9ROHmake+vs4gmuzXzg@mail.gmail.com>
To: WAI-ua <w3c-wai-ua@w3.org>
from http://www.w3.org/2013/01/17-ua-minutes.html

User Agent Accessibility Guidelines Working Group Teleconference

17 Jan 2013

See also: IRC log  http://www.w3.org/2013/01/17-ua-irc

Attendees

PresentJim_Allan, Jeanne, Greg_Lowney, sharper, Jan, Kim_Patch,
MarkkuRegretsKim, KellyChairJimAllan, kellyfordScribeJim

Contents

Topics

conformance use cases for conformance scenarios (extensions, mobile apps,
etc)

Summary of Action Items

________________________________

<trackbot> Date: 17 January 2013

conformance use cases for conformance scenarios (extensions, mobile apps,
etc)

http://lists.w3.org/Archives/Public/w3c-wai-ua/2013JanMar/0003.html

<Jan> GL: in 2nd one, UAWG should be UAAG

<scribe> scribe: Jim

gl: in item 2 - confused by 'all functionality'

<Jan> (2) the user agent COMPONENT (plug-in, etc.) must meet any
requirements applying to all functionality (e.g. to be resizable, to
provide documentation, etc.).

jr: right, can't hand off everything. If the guidelines say everything must
be documented, then everything must be documented even for partial
conformance

gl: trying to be inclusive

jr: COMPONENT, need to insert into 2.

This conformance option may be selected when user agent (or plug-in,
extension, etc.)

would be This conformance option may be selected when user agent component
(eg. plug-in, extension, etc.)

gl: this would be one that nearly all browsers would use, because they will
require at least 1 extension to meet all UAAG requirements
... so using term, partial conformance, a browser may not comply except
with an add-on, or partial conformance could only be for an add-on
... take 2 browsers. neith comlies out of the box.
... FF has a plugin that allows it to fully comply. BrowserX doesn't have a
plugin so it does partial.

jr: FF could do partial, but say we have all the archetectural features to
allow for a plugin. if X doesn't have the architecture, then it could not
fully comply

js: add 3rd example - does not meet 2.2.3 and does not have extensible
architecture then they could not claim conformance

jr: had pushback with ATAG. folks would not make a full claim with
extensions, because the extension maker could make case for payment for use
of extension

gl: need some language somewhere to make it clear that person making the
claim, when and how they claim full copliance when using 3rd party add on.
versus partial - where their architecture allows (theoretically) the use of
adons.

<Greg> Want to make sure the document makes it very clear how the person
creating the claim when and how they claim full compliance relying on
third-party, optional components (e.g. the mouseless browsing add-on) vs.
partial compliance in that their architecture in theory allows creation of
such an add-on but either it doesn't exist yet or they don't want to be
reliant upon a specific available add-on.

js: don't like idea of partial conformance of some theoretical existence of
a plugin.

jr: was written specifically that way. theoretical possibility that
something could be written. it shouldn't require you to name names of
plugins (that would be full compliance)

gl: this would allow any open source project to claim full compliance-
because the source code is available and anyone can write an extension

jr: that seems far fetched

gl: what is the reasoning again...

jr: when you make a claim, open source browser, it does not do mouseless
browsing, but it has an open architecture that allows plugins that get
keystrokes, insert content.
... vs other product, that doesn't have an extensible architecture, if you
want mouseless, just rewrite the source.
... could be another type of partial conformance. there should be a way to
make a claim without naming names.

js: I get this.

jr: mouseless browsing, partial conformance. have their relationship with
FF. mouseless should not care that FF can't highlight words. they are only
about mouseless
... what if there is a bunch of mouseless browsing plugins. FF could say
yes there are mouseless plugins but not saying names.

<Jan> http://www.w3.org/TR/WCAG/#conformance-partial

kp: the example should exist, and give examples (x, y, z) or including blah
... 2 different things...I do 1 thing. and I do everything except for x.
there are extensions that meet X examples are foo, foobar, and fubb

gl: but if there is a browser with a closed architecture, with a specific
API, and there is only one extension. no-one is able to write others, etc.

kp: it must be documented.
... difference between open/closed architecture is the documentation

jr: extension exists, do we have to name them.
... host browser, definitional split. mouseless doesn't have to meet
longdesc, and a browser ???
... extension as a browser. PDF is an extension. but is also a browser

<Jan> JR: Its writtenh the way it is because splitting user agent from
plugins is too hairy

<Jan> JR: ie a plugin could be a user agent

<Jan> JR: so instead we just call it partial conformance...

<Jan> JR: and if a full browser wants to claim its a component...fine...its
a lot of work to do...just to then claim you are only a component

js: good here, need some tweekes (editorial?), need a decision tree.
... full compliance must name names of extensions

partial- conformance: theoretical possibility of an extension, or that
architecture allows extension, and there are some in the wild

scribe: there must be documentation as to the extensibility

ja: distinguish between browser missing a few bits, and an extension which
is 1 bit.

gl: plugin as UA - pdf, media player,

jr: PDF is both.
... could imagine a tool that sends everything to a rendering engine
(transcoder) that is outside of itself.
... water is muddy. software that hands things off vs doing something.
mouseless does something, it is the end of the line... the browser hands
things off.
... browser is an onion, it does a lot by itself, but can't do somethings
so it hands it off.
... mouseless takes the handoff, does its thing, and gives it back to the
browser

<Jan> JR: The concept of "hand offs" could be useful

jr: don't want loopholes

mh: partially compliant, with a theoretical extension. does the 3rd party
add on interact with platform API or through a custom API

gl: extension could communicate directly the the a11y API or communicates
through the extension architecture of the browser and the browser chats
with the a11y API
... pdf viewer plugin

<sharper> While I think it is useful to make the best job of this as we
can. It seems to me that we have to be working in good faith. These
companies will have Lawyers, paid millions of [pick your currency] who
would probably be able to run rings around anything we write here if they
want to. I'm sure there will be many loopholes in combination with law, and
companies will be able to get around lots of stuff if they want to.

Feb 8, another meeting to find apps and extensions that meet SC.

Summary of Action Items

[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, 17 January 2013 19:42:08 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:49:43 UTC