minutes: UAWG telecon 20 June 2013

from http://www.w3.org/2013/06/20-ua-minutes.html
- DRAFT - User Agent Accessibility Guidelines Working Group Teleconference 20
Jun 2013

See also: IRC log http://www.w3.org/2013/06/20-ua-irc
<http://www.w3.org/2013/06/20-ua-irc>
Attendees
Presentkford, Jeanne, Jim_Allan, Jan, Greg_Lowney, +1.609.734.aaaa, Eric,
Kim_PatchRegretsChairjimAllan, KellyFordScribeGL, jim, Greg
Contents

   - Topics <http://www.w3.org/2013/06/20-ua-minutes.html#agenda>
      1. Revisit Definition of User Agent After CG
Discussion<http://www.w3.org/2013/06/20-ua-minutes.html#item01>
      2. Face to Face
Reminder<http://www.w3.org/2013/06/20-ua-minutes.html#item02>
      3. Action-836 Appendix E of Alternative
Content<http://www.w3.org/2013/06/20-ua-minutes.html#item03>
      4. Testing Details<http://www.w3.org/2013/06/20-ua-minutes.html#item04>
   - Summary of Action
Items<http://www.w3.org/2013/06/20-ua-minutes.html#ActionSummary>

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

<trackbot> Date: 20 June 2013

<kford> What do we want to do with it? (
http://www.w3.org/TR/IMPLEMENTING-UAAG20/#alternative-content-list) in
Implementing?
Revisit Definition of User Agent After CG Discussion

<kford> Scribe: GL

<Greg> KF: Discussion yesterday with several WG members. Some people felt
AA example should be considered a UA, but Kelly does not.

<Greg> JR: Agrees with Kelly that AA app should not be a UA.

<Greg> KF: Feels you know a UA when you experience one. He feels AA app
should not be considered UA because (a) very task specific, and while may
render HTML it is doing that for a single purpose, thus not a *general*
user agent, and (b) burden of asking for the myriad of things required for
UAAG conformance is something we should not ask of every developer.

<Greg> KF: Maybe we need more to let developers pick and choose which
portions of UAAG are applicable to them.

<Greg> KF: If you're rendering HTML content that should be developed to
WCAG conformance. A real world example: the Kim has talked about Show
Numbers feature in Lynx as an implementation method for direct navigation.
However, if the platform doesn't support it, can we expect every developer
to build it for their apps? No.

<Greg> JR: We require direct navigation because there are web pages out
there with thousands of links, but if you only display your own pages that
don't need that feature--optimized for just two buttons--you should not
have to provide it.

<Greg> JR: Way to move forward is for people who think UAAG should apply to
American Airlines app, go through UAAG and pick out things that should be
applied to UA and are not already covered by WCAG.

<Greg> JS: That would put her on task force to look at those, because does
want to provide guidance for mobile apps.

<Greg> JA: Seems that we're trying to provide functionality for navigation
by headings and the like, because WCAG and UAAG are different sides of the
same coin: WCAG requires headings, but do no good if the UA doesn't use
them.

<Greg> JR: Disagree, in a mobile app you might have only two headings on a
page, nice to know that it's a heading even if you don't have a headings
navigation mechanism.

<Greg> JA: Difference between app and full-blown browser it that Firefox
lets you hide its UI, leaving only content that the author has provided on
the web site, does it suddenly turn from a full-featured browser into an
app?

<Greg> JA: Every web site could essentially create its own app, say it
doesn't need general purpose browsers anymore.

<Greg> JA: Functionality like headings navigation needs to come from
somewhere other than every web site creating it themselves.

<Greg> GL: But those cases we don't see the web site going away,
site-specific apps just being an available alternative.

<Greg> JR: Why do people choose apps over using the web sites directly?
Possibly because browser experience does not come across as nice as when
you have a tuned app.

<Greg> JR: Full UAAG is overkill for many apps, so recommends having a
subset of UAAG for mobile apps.

<Greg> JA: Make all Level A apply to everything including apps, while
full-blown UAs have to address AA as well?

<Greg> GL: The way we define levels doesn't always correspond with what's
applicable to apps vs. full UA.

<Greg> JR: If only 20 out of 120 SCs apply to apps, then we should provide
a simpler view for app developers.

<allanj> scribe: jim

<allanj> gl: with the AA app if the only part is web functionality, is just
getting some xml data. they don't seem to overlap.

<allanj> jr: there are button, and text fields....html

<allanj> gl: but it might not be, then does WCAG not apply.

<allanj> jr: only in the narrow view, wcag functionality also applies to
applications

<allanj> erh: relationship between wcag and uaag. does wcag need to be
considered in our conformance.

<allanj> jr: yes in the case of web-based user agents.

<allanj> gl: agree with Jan, moving on to other items.

<allanj> *ACTION:* jim to work with Jeanne to create a list of SC that
likely apply mobile apps (what is the difference between mobile web app,
and any other app?) [recorded in
http://www.w3.org/2013/06/20-ua-minutes.html#action01]

<trackbot> Created ACTION-839 - Work with Jeanne to create a list of SC
that likely apply mobile apps (what is the difference between mobile web
app, and any other app?) [on Jim Allan - due 2013-06-27].
Face to Face Reminder

<Greg> scribe: Greg

Kelly: mail coming out soon with details about the face to face in Redmond.

KF: Dial in will be available for those who can't attend in person.
Action-836 Appendix E of Alternative Content

JA: He cleaned it up into a table, and sent to the list. Columns for
different W3C formats.
... Working on filling out columns for those technologies. Some things
deprecated or pending in different technologies.
... Should he include links to places in the specs where the information
came from? Probably yes.

JS: Yes, but should be to a version of the spec that won't disappear.
... Need to figure out how to do that for ATAG anyway, so will look into it
soon and let Jim know.

JA: E.g. alt for EMBED element is supported by all browsers, but isn't in
HTML 4 or XHTML. EMBED is mentioned in HTML 5 but Alt is not a valid
attribute for it. Yet it works. Do we count it as a valid form of
alternative content that browsers should support?

JS: Should include it but note that it's commonly supported even though not
in specifications.

JA: Another is Q element for quotes has cite attribute that links to source
of the quote, its value is a URL. No browser reveals it. Is it alternative
content?

JR: No, it's something else.

JA: Agreed.
... Everyone review the list and let him know of any alternative content
forms he missed.
... Also wrestled with title, because specs says it's advisory, but it is
necessary for some things. It functions as the label for check boxes and
radio buttons, so is it alternative content or not?

JS: Feels it belongs on the list, at least for those cases. Required for
accessibility for forms. Also required for drop-down lists.

JA: But screen readers might not pick those up.

KF: Screen readers will read title on select.

GL: Even if no browser exposes an attribute, an extension can be written to
do so, so they can still be useful alternative content.
Testing Details

KF: We've had people send sample tests to the list.

KP: Likes what Greg said about what things can be tested at once.

JR: Also Greg's concern about testability in his email are good.
... "boulderish" grains of salt
... Ran into some of the same issues working on ATAG but didn't write them
down as well.
... If we want to go down to every detail, we lost the generality. ATAG
wrote them very generally for a reason. Didn't have resources to write more
specific tests for different types of pages, etc.

<allanj> gregs message ..
http://lists.w3.org/Archives/Public/w3c-wai-ua/2013AprJun/0103.html

GL: Raised three major issues: (1) can we lump several tests together into
a single test pass over the application, (2) to what extent should we
require testing edge cases, (3) do we want the test results to list all the
failing cases for an SC, or just the first encountered?

<allanj> ja: do lump test with atomized results

<allanj> gl: combined test, then results on different rows of the table.

JS: Need atomized results, as you have to prove that every every SC passes.

GL: In a test procedure, in addition to saying "record FAIL", instructions
could say "record FAIL for test 015", etc.
... That would allow a single test instruction to record separate results
for multiple SC tests.

JS: Suggest until we learn more about what what the testing framework will
support, write them separately for now but note those that could be
combined.

KP: To avoid editorial nightmare of having lots of copies and having to do
corrections/changes in all of them, could reference sections for inclusion.

EH: Agree with this approach. A key part is that you define the scope in
which they're looking, identify a set of elements they'll look at, then
repeat some procedure for each element in the list. It may check an element
for compliance with several SC.
... A test procedure could be couched in non-normative suggestion of how
the tests could be combined into a single pass.

JS: Likes Kim's idea if we can note common steps.

KP: like a cookbook having an entry for a basic sauce, which is then
referenced in other recipes.

JS: Put into a wiki so everyone can modify it?

<allanj> +1

KP: Could name the common test elements for reference in various tests.

JS: Put common elements into separate page.

JA: Greg raised questions about text search.
... Require searching into iFrame etc.?

GL: My preference would be yes because the user isn't necessarily cognizant
of the implementation, to them it seems just a normal page, so would be
quite dysfunctional if search skipped portions of it seemingly randomly.

<Jan> +1

<allanj> =!

<allanj> +1

GL: However, noting that there may be embedded objects/embedded UA that,
the same way, seem to be part of the normal page, but can't be searched by
the hosting user agent.
... e.g. a plug-in for Firefox (a nested user agent) that allows PDF files
to be shown on a page, will Firefox's text search search the contents of
the PDF?
... I don't think we can require searching into nested user agents.
... Do plug-in architectures for any browsers support searching into nested
user agents?
... If it was supported on some architectures, then I'd be more likely to
require it, but would not if it's not supported anywhere.
... These types of questions really should be addressed somewhere, perhaps
as a note in Implementing or in the test cases.

<allanj> the pdf plug-in requires the use of the pdf-ui to search the pdf
content. the user agent inpage search does not search pdf

GL: Or even a note in the main document.

JR: Probably the Implementing guide is a good place for it.
... If actually doing QA testing at a company, they'd enumerate all these
test cases.

GL: However, if there are cases we feel strongly about, where there's
behavior that if the user agent didn't handle those cases we wouldn't want
them to pass, then we really have to make sure those are enumerated, or
else we can run into products passing even though they don't meet the
spirit/intent of the SC.
... it's difficult to draw the line sometimes between bugs of limits in
functionality that are relatively harmless, minor bugs, and those that can
really negatively impact some users.

<allanj> kp: how do we know when a barrier is presented or not?

KP: sometimes the only way to get speech to work is to search for really
strange things, so then you can navigate or search from that point. You
need to focus on things that you'd never think a person would need to put
focus on.
... The number of edge cases is very large as a result.
... Hard to judge that something is not important.
... If the rule is that you can search for anything, that's good; any
limitation on what you can search for is potentially a problem.
... We can't predict what people will want to do.

GL: We can note edge cases we expect the product to support in a Note in
Implementing, with or without actually including them in the test scripts.

JS: May need to avoid getting too bogged down in edge cases.

<allanj> gl: It's possible to imagine implementations that would meet the
letter of the SC without meeting its spirit. For example, a command that
merely displayed a list box with page/line references for all occurrences
of a string would comply, but it wouldn't be very useful for an
screen-based browser.

<allanj> ... then what do we do.

<allanj> jr: that could happen, we can't guard against poor usability. if
it meets the letter, but not the spirit, that's OK

JR: That could happen, but it would be poor usability. It would suffer in
other ways.

<allanj> gl: change example...if you cant get @alt inline, but get the @alt
in a separate document. does that pass

<allanj> jr: we can't block people trying to cheat the system.

GL: I'm more worried about a user agent creating a quick-and-dirty
extension that complies minimally without actually making it useful for
people with disabilities.

<allanj> js: leave those alone, and assume developers want to do the right
thing.

<allanj> gl: in experience, developers will do the minimum to meet the
requirements, even if it is totally unusable.

<allanj> ... you will never be able to rid the creation of bad design.

<allanj> gl: we have written SC that are written in legealeze, to prevent
the edge cases.

<allanj> js: if we do that, and make it harder on all of the other folks
requiring more testing, etc.

<allanj> kp: agree with js, work on wording, but assume the best.

<allanj> gl: html5, test for 12 different strings, we need to provide the
test.
 Summary of Action Items *[NEW]* *ACTION:* jim to work with Jeanne to
create a list of SC that likely apply mobile apps (what is the difference
between mobile web app, and any other app?) [recorded in
http://www.w3.org/2013/06/20-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