User Agent Accessibility Guidelines Working Group Teleconference -- 20 Jun 2013

<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.

- DRAFT -

User Agent Accessibility Guidelines Working Group Teleconference

20 Jun 2013

Attendees

Contents

Revisit Definition of User Agent After CG Discussion

Face to Face Reminder

Action-836 Appendix E of Alternative Content

Testing Details

Summary of Action Items

Scribe.perl diagnostic output