User Agent Accessibility Guidelines Working Group Teleconference -- 22 May 2014

<trackbot> Date: 22 May 2014

regrets Eric

rrsagent: make minutes

<scribe> scribe: allanj

at the end of last meeting we had a brief discussion about 1.4

and restructuring to make basic customization A with a browser UI and

then AA or AAA stuff be user CSS

gl: when can UA comply with SC with writing user agent CSS
... there has to be a user CSS available to claim compliance if user style sheets are necessary to comply

js: ??? isn't that content

gl: not if provided by the UA.
... or an extension that provide CSS UI

js: Readability - extension to FF to change font info and line spacing

<Greg> I'm thinking that a user agent can never claim compliance based solely on providing the capability of adding an extension or user style sheet; they can claim compliance only if an extension or user style sheet that demonstrates compliance actually exists and is readily available to users.

<jeanne> actually a bookmarklet

<Greg> A user style sheet that provides global changes (e.g. bolding all links in all documents) could be considered an extension, rather than *merely* content.

js: this is really interesting. and would help with lots of websites

<Greg> Of course, this brings up the long-standing question of to what extent an extension must be discoverable, what hoops the user has to go through to obtain it, whether it costs extra money, etc., to still be considered sufficient to make the user agent compliant.

ja: still concerns about extensions to meet SC. UA changes, ext. doesn't work, author does not update...perhaps if UA's maintained extensions

<Greg> I would not like a user agent to claim compliance relying on a third-party extension or style sheet that's only available on some obscure university web site, while the user agent manufacturer makes no effort to raise awareness of it.

js: come up with a proposal to keep extensions up to date and readily discoverable. Could be an SC or in Compliance

gl: appropriate in Compliance, not sure how to put in SC.

js: if in conformance then in Introduction with own heading, so it stands out.

ja: with a note on SC that say Extension

<scribe> ACTION: Greg to write conformance/ introduction extension existence discover-ability and life span [recorded in http://www.w3.org/2014/05/22-ua-minutes.html#action01]

<trackbot> Created ACTION-980 - Write conformance/ introduction extension existence discover-ability and life span [on Greg Lowney - due 2014-05-29].

<jeanne> gl: also include the ease of installation of the extension

<Greg> Similarly, if a user agent only supports one user style sheet at at time, that would not be sufficient for compliance because it would make a style sheet for one SC incompatible with style sheets for other SC, and for other user needs.

<Greg> The same would be true if there was a limitation on how many extensions could be installed, although we have not seen that in practice.

<jeanne> That should go into 1.7

<Greg> Similarly, it would not be sufficient for a user agent to support only a limited set of developer-supplied style sheets.

<scribe> ACTION: Jim to create or modify an SC (1.7x) to allow for multiple user stylesheets. [recorded in http://www.w3.org/2014/05/22-ua-minutes.html#action02]

<trackbot> Created ACTION-981 - Create or modify an sc (1.7x) to allow for multiple user stylesheets. [on Jim Allan - due 2014-05-29].

<Greg> We should probably edit 1.7.4 to clarify that the second sentence is a requirement, rather than merely a comment. ("The user can save copies of the stylesheets referenced by the current page. This allows the user to edit and load the copies as user stylesheets.")

ja: we have no SC pertaining only to extensions. Should we?

open item 5

http://www.w3.org/2011/webtv/wiki/Media_APIs/Use_Cases

from Jan

- everywhere they mention "tablet" it might be better to say "Mobile device" or "Table/Smartphone"

- use case: ability to view captions only on a second device (Table/Smartphone)

- use case: ability to hear secondary audio channel only on second device (Table/Smartphone)

WebTV, on desktop there is an AT layer and the browser. not so on TV

a closed system, no addition of external AT

windows media center. works with nvda, mostly. can read, but not details...spell words

if no 3rd party, how to add scanning keyboard to a closed system if none is built in

looked at timed text, tuner control, font size, captions placement, etc.

Use Case 1 -5

it is assumed that the Tablet has AT installed, that the web interface from the settop box is written to support existing W3C accessibility Standards

<Greg> In Use Case 1, it's assumed that the "service discovery application" is written to conform with accessible design guidelines, and that the tablet on which it's running has assistive technology installed or built-in, and that the combination of the two allows users who have disabilities to use the application to complete the steps in the scenario.

<Greg> If the service discovery application is web-based, then it must comply with WCAG, and the browser must comply with UAAG.

<kford> Reading through all of these much as GL is saying I think the fundamental assumption is that the user gents comply with UAAG and all content with WCAG.

<kford> On my read I don't see places where these use cases or the APIs that would be needed are changing data or adding or removing from it. They seem to be about commmand, control and such of the information.

<kford> But I think the question is for all of this onscreen viewing, where is the accessibility coming from? If not this group who's defining that? Us?

<Greg> If the process of the user "turn(ing) on the Content Service on Tablet" requires user permissions (e.g. entering a password), that process may be implemented by the operating system rather than the browser, in which case it is another component that must been accessible design guidelines. For example, a secure login screen may not be compatible with third-party assistive technology due to...

<Greg> ...security restrictions, and thus must be made self-voicing and have other, similar, accessibility features built-in per requirements for "closed systems".

kf: these are close systems. there must be some accessible interface. built-in or external device to interface with closed-system
... content must comply with WCAG
... any user agent provided must comply with UAAG

gl: if something has Full Screen Mode, then how is interaction supposed to happen with an on-screen keyboard user.

ja: Use Case 2...An overlay is triggered to invite the subscriber to explore the city of San Francisco further on the Tablet...how is information that appears on the TV screen communication in an accessible manner to the user? does this 'overlay' also appear on the tablet?

can you change the fontsize of stuff on the TV? is the information Spoken

<Greg> An example of accessibility issues would be that if an API allowed something to request full-screen mode, it has to accommodate assistive technology that needs to remain visible. For example, a web app requests to go full screen, then queries the size of the viewport it has been given, rather than assuming that it has actually received a viewport the size of the physical display.

@@ is the tablet the Remote control

<Greg> "Channel Bounded Application: It is a web application that provides contents related to the current broadcasting channel. This application is terminated when the user changes to different channel." (from http://www.w3.org/2011/webtv/wiki/Media_APIs/Terminal_Use_Cases)

<Greg> Re use case 7, "channel bounded applications" are started and closed automatically as you change channels. If you had to do something in your assistive technology to either respond to a new application opening, or configure your AT to interact with that application correctly (per your needs), you may have to do repeat that process every time you switch back to a channel. That could be...sub-optima

<Greg> l, compared with having the channel bound application remain running, and merely hide itself when not needed.

<Greg> Other examples would be if the user needed to reposition or zoom the bounded application's window.

<Greg> Note that switching *applications* should not cause channel-bound applications to be hidden or shown, as the user may need to move focus to an assitive technology utility in order to read, view or control the channel-bound application.

meeting ended early

- DRAFT -

User Agent Accessibility Guidelines Working Group Teleconference

22 May 2014

Attendees

Contents

Use Case 1 -5

Summary of Action Items

Scribe.perl diagnostic output