W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > April to June 2014

Minutes: User Agent telecon 5 June 2014

From: Jim Allan <jimallan@tsbvi.edu>
Date: Thu, 5 Jun 2014 13:55:55 -0500
Message-ID: <CA+=z1WkOwZbV-drhxBmHUT436GyfYxdS6zr+58F0NjM7vyqKOg@mail.gmail.com>
To: WAI-ua <w3c-wai-ua@w3.org>
from http://www.w3.org/2014/06/05-ua-minutes.html
User Agent Accessibility Guidelines Working Group Teleconference 05 Jun 2014

See also: IRC log  http://www.w3.org/2014/06/05-ua-irc
<http://www.w3.org/2014/06/05-ua-irc>
Attendees
PresentRegretsEricChairJim Allan and Kelly FordScribeallanj
Contents

   - Topics <http://www.w3.org/2014/06/05-ua-minutes.html#agenda>
      1. TPAC f2f announcement
      <http://www.w3.org/2014/06/05-ua-minutes.html#item01>
      2. Proposed response to MS06
      <http://www.w3.org/2014/06/05-ua-minutes.html#item02>
      3. EH13 <http://www.w3.org/2014/06/05-ua-minutes.html#item03>
      4. Comment MS07 Think beyond desktop computers
      <http://www.w3.org/2014/06/05-ua-minutes.html#item04>
      5. MS08 Realistic expectation of the end users
      <http://www.w3.org/2014/06/05-ua-minutes.html#item05>
   - Summary of Action Items
   <http://www.w3.org/2014/06/05-ua-minutes.html#ActionSummary>

------------------------------

<trackbot> Date: 05 June 2014

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

<scribe> scribe: allanj

scribe-nick: jim
TPAC f2f announcement

UAAG to meet Monday and Tues. in Santa Clara, Oct 27 - 29

could meet a day early and meet with food on your own

<Jan> +1 to 3 days (incl Sunday)

<jeanne> *ACTION:* jeanne to talk to AWK about UAWG meeting at TPAC on
Sunday [recorded in http://www.w3.org/2014/06/05-ua-minutes.html#action01]

<trackbot> Created ACTION-984 - Talk to awk about uawg meeting at tpac on
sunday [on Jeanne F Spellman - due 2014-06-12].

close item 4
Proposed response to MS06

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

http://www.w3.org/WAI/UA/2014/LCcomments.html

js: will remove last sentence.

ja: any comments, objections to MS06 response...

none heard

js: added response to document.
EH13

EH13: What are the allowable reasons that a success criterion (for a
certain conformance level) can be “not applicable.” Is the only allowable
reason that the capability/feature is not supported (#7) or could it also
be that the developer has chosen to exclude a web content technology from
the claim (#8). Not clear.

applies to Components of Conformance Claims #9

http://jspellman.github.io/UAAG/UAAG20/#conformance

js: concerned about complexity of Greg's previous proposal
... history of WCAG and technology supported

<Jan> http://lists.w3.org/Archives/Public/w3c-wai-ua/2013JanMar/0030.html

<Jan> http://lists.w3.org/Archives/Public/w3c-wai-ua/2013JanMar/0026.html

greg's original proposal

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

<Greg> 9. Declarations: For each success criterion, provide a declaration
of either

<Greg> a. whether or not the success criterion has been satisfied; or

<Greg> b. declaration that the success criterion is not applicable and a
rationale for why not, *from the following choices:

<Greg> 1. NA-Platform: not applicable due constraints of the platform, per
Paragraph 7 above (e.g. color handling on a monochrome device, video
handling in a purely audio browser, or interprocess communication on an
operating system that does not support multitasking). Describe the specific
platform limitation.

<Greg> 2. NA-Input: not applicable due to a constrained input set (e.g. a
help system that only displays the HTML files included with the product)

<Greg> 3. NA-Output: not applicable due to intentionally limited output
modalities (e.g. video handling in a browser that only does audio output,
even though the platform may support video)*

jr: conformance claim based on included technologies. e.g. ff claim
conformance with html5 but not svg
... the exclusion of svg happens before conformance

<Jan> http://www.w3.org/TR/UAAG20/#conformance

jr: inclusion is in #8. if something is not on the list then it is not
conformant

js: the first part...the SC is not applicable ... we may still have an
issue. the second half of EH13 comment is ok.

jr: greg has a good list. we don't need to code them.

js: the list could be example rather than the only ones.
... when we think of everything we don't want to allow...creates problems
long term
... the list would be some of the reasons, not the only reasons.

gl: people will create tortured logic to get an NA

jr: the list is very broad, and should be ok.

ja: +1

Declarations: For each success criterion, provide a declaration of either

whether or not the success criterion has been satisfied; or

declaration that the success criterion is not applicable and a rationale
for why not

<Greg> My reason for having specific codes for them to choose from was to
avoid having a claimant fill in the form with a free-form sentence that
doesn't make it clear to the reader what their rationale is, or which
category of NA it fits into.

1. Platform: not applicable due constraints of the platform, per Paragraph
7 above (e.g. color handling on a monochrome device, video handling in a
purely audio browser, or interprocess communication on an operating system
that does not support multitasking). Describe the specific platform
limitation.

<Greg> If we had a conformance claim template or form, it could also have
check boxes for the different categories, in addition to space for
explanatory text.

2. Input: not applicable due to a constrained input set (e.g. a help system
that only displays the HTML files included with the product)

3. Output: not applicable due to intentionally limited output modalities
(e.g. video handling in a browser that only does audio output, even though
the platform may support video)

9. Declarations: For each success criterion, provide a declaration of either

a. whether or not the success criterion has been satisfied; or

b. declaration that the success criterion is not applicable and a rationale
for why not

1. Platform: not applicable due constraints of the platform, per Paragraph
7 above (e.g. color handling on a monochrome device, video handling in a
purely audio browser, or interprocess communication on an operating system
that does not support multitasking). Describe the specific platform
limitation.

2. Input: not applicable due to a constrained input set (e.g. a help system
that only displays the HTML files included with the product)

3. Output: not applicable due to intentionally limited output modalities
(e.g. video handling in a browser that only does audio output, even though
the platform may support video)

kf: what happens if somebody has something not on this list

gl: there could be others, who knows...
... could add 4. Other as a catch all...may be abused

<Greg> If you want to add a (4) Other that's okay, but I anticipate it
would be abused.

<jeanne> Output: not applicable due to intentionally limited output
modalities (e.g. video handling in a browser that only does audio output,
even though the platform may support video)

kf: ok with with list.

<jeanne> b. Output: not applicable due to intentionally limited output
modalities (e.g. video handling in a browser that only does audio output,
even though the platform may support video)

<jeanne> bad

<jeanne> b. declaration that the success criterion is not applicable and a
rationale for why not, from the following choices:

<Greg> Back in 2013 I suggested adding the following to 7:

<Greg> Note: For the purpose of this paragraph, platform includes only the
hardware, operating system, or cross-platform operating environment, as
these generally cannot be replaced without substantially changing the
target market. For example, if the user agent runs on an operating system
that does not provide platform accessibility services, a conformance claim
for this configuration can list the...

<Greg> ...result for that success criterion as “Not applicable due to
platform limitations”, and describe the specific platform limitation.
However, if the user agent was implemented using a widget library that does
not support the platform accessibility services, the user agent could not
claim an exemption based on that design decision.

js: if someone makes a UA on multiple platforms, and it fails UAAG on all
platforms then it is a poor choice of platform

gl: but it can't do something that the platform won't allow

js: but it may be what users need regardless of platform capabilities

jr: ATAG has partial conformance due to platform limitations

<Jan> TAG2: http://www.w3.org/TR/ATAG20/#conf-levels

discussion of platform vs library

gl: kde or gnome, are they platform or libraries.

add Note to 7?

js: -1

jr: they have to list what widget sets they choose, and declare it publicly
that "we chose this knowing it wouldn't work." would be tough to do.

js: we don't want to keep track of all the libraries that comply with UAAG

kp: -1

jr: -1

kf: -1 would like to put it somewhere .... it is good information

jim will put in wiki. will craft a rationale for not accepting the note.
Comment MS07 Think beyond desktop computers

<Greg> My suggested response was merely "Again, 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."

<Greg> I would add something like "Keep in mind that SC related to keyboard
are not just about devices with physical keyboard, but also keyboard
emulators and API that allows discrete input commands."

js: waiting on a response about indieUI.

Core Accessibility API Mappings -
http://rawgit.com/w3c/aria/master/implementation/aria-implementation.html

ja: we have given this a best faith effort. UAWG believes it address mobile
adequately

js: would like to use other language from IndieUI.
... would like to wait. He has a good point. we should review to see if we
can improve.
MS08 Realistic expectation of the end users

related to 1.7 stylesheets

<Greg> I originally commented "I agree with the commenters that relying on
user style sheets is a problematic approach to the problem of inadequately
designed web content. Unfortunately, at this point we are not aware of any
better solutions being proposed. Even if it is not available to most users,
it provides a fall-back solution that would be availble to some, and
potentially to more in the...

<Greg> ...future if efforts are made to share accessible alternative style
sheets (e.g. userstyles.org). If the reviewers have suggestions for
additional features that the user agent can provide, by all means please
make them known."

ja: the other solution would be for UA to provide a robust interface for
the user to make the content match their requirements

kf: "we welcome feedback on realistic alternatives"

jr: functionally, we want the user to be able to make the content meet
their needs.

js: we what the UA to make it easy for the user to modify rendering of
content.

<jeanne> One solution that the group considered was to require the user
agent to provide robust custom styling interface to meet the users
requirements. We want to give users rich customization options to meet
their needs. We thought that improving the usability of user stylesheets
was a better alternative.

<jeanne> UAWG agrees with the commenter that relying on user style sheets
is a problematic approach to the problem of inadequately designed web
content. Unfortunately, at this point we are not aware of any better
solutions being proposed. Even if it is not available to most users, it
provides a fall-back solution that would be availble to some, and
potentially to more in the future if efforts are made to

<jeanne> share accessible alternative style sheets (e.g. userstyles.org).
One solution that the group considered was to require the user agent to
provide robust custom styling interface to meet the users requirements. We
want to give users rich customization options to meet their needs. We
thought that improving the usability of user stylesheets was a more
realistic alternative at this time. We welcome

<jeanne> feedback on realistic alternatives.

<jeanne> UAWG agrees with the commenter that relying on user style sheets
is a problematic approach to the problem of inadequately designed web
content. Unfortunately, at this point we are not aware of any better
solutions being proposed. Even if customized user stylesheets are not
available to most users, they provide a fall-back solution that would be
availble to some users, and potentially to more users

<jeanne> in the future if efforts are made to share accessible alternative
style sheets (e.g. userstyles.org). One solution that the group considered
was to require the user agent to provide robust custom styling interface to
meet the users requirements in order to give users rich customization
options to meet their needs. We thought that improving the usability of
user stylesheets was a more realistic

<jeanne> alternative at this time.

resolution: MS08 done
 Summary of Action Items *[NEW]* *ACTION:* jeanne to talk to AWK about UAWG
meeting at TPAC on Sunday [recorded in
http://www.w3.org/2014/06/05-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, 5 June 2014 18:56:21 UTC

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