See also: IRC log
<trackbot> Date: 05 June 2014
http://lists.w3.org/Archives/Public/w3c-wai-ua/2014AprJun/0051.html
<scribe> scribe: allanj
scribe-nick: jim
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
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: 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.
<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.
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
... EH13 done
... MS06 done
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/)*/)/ Succeeded: s/MS09/MS08/ Found Scribe: allanj Inferring ScribeNick: allanj WARNING: No "Present: ... " found! Possibly Present: Declarations EH13 Greg Greg_Lowney IPcaller Jan Jeanne Jim_Allan Kelly KimPatch Kim_Patch Microsoft Note Output TAG2 gl ja joined jr js kf kford kford_ kford__ kford___ kford____ kp scribe-nick trackbot ua You can indicate people for the Present list like this: <dbooth> Present: dbooth jonathan mary <dbooth> Present+ amy Regrets: Eric Found Date: 05 Jun 2014 Guessing minutes URL: http://www.w3.org/2014/06/05-ua-minutes.html People with action items: jeanne[End of scribe.perl diagnostic output]