Indie UI Task Force Face to Face -- 01 Nov 2012

<richardschwerdtfeger> scribe: Rich

<richardschwerdtfeger> janina: I chair PF and the Indie-Ui task force chair

<richardschwerdtfeger> rich: I work for IBM. I am the ARIA chair and have worked on previous standards on Access For All

<richardschwerdtfeger> Katie Harieto Shea - I work on 508 and accessibility

<richardschwerdtfeger> James Craig: I work for Apple and I work on ARIA and I am interested in features needed for ARIA that run outside ARiA 1.0 scope

<richardschwerdtfeger> david Macdonald: I work on HTML 5 and WCAG

<richardschwerdtfeger> Lachlan Hunt: I work for Opera. I work in the web apps working group

<richardschwerdtfeger> andy heath: I am a consultant and work on the access for all piece and related standards around getting personalization going. I work on ISO standard 24751 targeted at accessible e-learning.

<richardschwerdtfeger> Sangwhan Moon: Opera software. I work in the web events and now the new pointer event working group

<richardschwerdtfeger> Hyojin Park: I am a Phd student and I have projects in e-learning and web. I wanted to sit in and am looking to contribute. I am here as a first time observer

<richardschwerdtfeger> Jason Kiss: AC rep for the New Zealand govmnt. I am a member of the HTML working group and I am trying to get a better sense of how things work.

<richardschwerdtfeger> Gottfried Zimmerman: Media University Stutgart and member of GPII

<richardschwerdtfeger> thanks

<richardschwerdtfeger> call in info: 1617 761 6200 passcode 64343

<jcraig> 46343

<jcraig> (indie)

<Gottfried> We are now on the phone

<richardschwerdtfeger> janina: you can join web events or indie ui working group you can join the task force

<richardschwerdtfeger> janina: either one is sufficient

<richardschwerdtfeger> janina: We will discuss the eventing model first and then the use cases later in the day

<richardschwerdtfeger> janina: if we wait for telecom time we will take a very long time on use cases.

<richardschwerdtfeger> janina: Tomorrow we will talk about Cloud4All. The education space has looked at how vocabularies can be created so that user needs can be captured. For example, user's needs for large fonts can be captured by systems.

<richardschwerdtfeger> janina: this is one of our 2 deliverables

<richardschwerdtfeger> janina: This is the most appropriate user experience can be delivered in these situations. Then there is abstract events. This is a major opportunity for authoring.

<richardschwerdtfeger> janina: When we are tired of use cases and want to take a break we will look at Mercurial

Indie UI Overview

<janina> http://www.w3.org/WAI/IndieUI/wiki/Meetings/TPAC2012#Thursday_1_Novemberzakim, call St_Clair_4

<richardschwerdtfeger> jcraig: I work for Apple and I wrote one of the proposals that is used for this work. Some of the group contributions I was getting in from other members of the group did not make sense in the context of how standard event lifecycles work.. Because there people in the group with varying levels of technical experience I wanted to give this presentation. I also want to just have a level set.

<richardschwerdtfeger> jcraig: to get us all on the same page

<lisaseeman> I am hanging up on zakim. Let me know if there is anything else I can try

<richardschwerdtfeger> jcraig: I want to give back ground on aria and how keyboard use only in authoring practices is a stop gap measure due to the scope of ARIA 1.0

<richardschwerdtfeger> channel is not open

<richardschwerdtfeger> need to get it

<richardschwerdtfeger> jcraig: So let's go into background

<richardschwerdtfeger> jcraig: ARIa has declarative markup in the DOM

<richardschwerdtfeger> jcraig: overcome author, browser, and language limitations

<richardschwerdtfeger> jcraig: retrofit markup for accessibility without gutting it - sprinkle some sugar on it and it works

<richardschwerdtfeger> jcraig: very difficult something like a standard radio button is hard as many parts are native

<richardschwerdtfeger> jcraig: Declare semantics where host language cannot

<richardschwerdtfeger> jcraig: Native control output

<richardschwerdtfeger> jcraig: output from web app to assistive technology

<richardschwerdtfeger> jcraig: web app updates a value

<richardschwerdtfeger> jcraig: browser notifies the screen reader

<richardschwerdtfeger> jcraig: native control input

<richardschwerdtfeger> jcraig: user attempts to change slider and the screen reader notifies the user

<richardschwerdtfeger> jcraig: ARIA Control output

<richardschwerdtfeger> jcraig: web app updates a value

<richardschwerdtfeger> jcraig: browser updates the screen reader and the screen reader tells the user

<richardschwerdtfeger> jcraig: browser doesn't know how to change the value of an ARIA slider

<richardschwerdtfeger> jcraig: web application is never notified

<richardschwerdtfeger> jcraig: this was out of scope for ARIA 1.0

<richardschwerdtfeger> jcraig: Standard Event Life Cycle

<richardschwerdtfeger> jcraig: the way voiceover works in MacOSX 10 you could use the standard slider but we also allow screen reader direct manipulation. There is an interact with slider and so on

<richardschwerdtfeger> jcraig: There is no standard way to do this yet

<richardschwerdtfeger> jcraig: Standard Event lifecycle

<richardschwerdtfeger> jcraig: example: submit button

<richardschwerdtfeger> jcraig: the click event starts at the leaf level node and cam bubble up the tree as long as an author does not choose to intercept and cancel the event. This is called bubbling.

<richardschwerdtfeger> jcraig: in this case the img bubbles up to the submit button

<richardschwerdtfeger> jcraig: example ARIA button

<richardschwerdtfeger> jcraig: same thing happens. I bubbles up the the element with role-"button" and intercepts the event, does something with it and cancels the event. then that life cycle is over

<richardschwerdtfeger> jcraig: in non-interactive elements they keep passing on up the tree to the body and nothing has responded

<richardschwerdtfeger> jcraig: Let's talk about keyboard events

<richardschwerdtfeger> jcraig: it still starts at the leaf node but it works on where things are focused. So, even though there is an image in the div because its parent has focus the div that has keyboard focus does not propagate the event down to the image

<richardschwerdtfeger> jcraig: keyboard event aria button - same deal as long as the aria button has focus

<richardschwerdtfeger> jcraig: with event delegation the aria button has keyboard focus but it does nothing with it and it bubbles up

<richardschwerdtfeger> jcraig: the event target here would be the aria button even though it bubbles up

<richardschwerdtfeger> jcraig: when I talk about canceling I am talking about stopping propagation and preventing the default action.

<richardschwerdtfeger> jcraig: in the case of a link the default action is to move the action to that link

<richardschwerdtfeger> jcraig: if you are on a native button the space bar intercepts that. The space bar can then be propagated up if not stopped by the handler

<richardschwerdtfeger> jcraig: Indie UI event life cycles

<richardschwerdtfeger> jcraig: span inside a span indise a slider inside a body tag

<richardschwerdtfeger> jcraig: the context of this particular node the screen reader knows the user is on a slider.

<richardschwerdtfeger> jcraig: the screen reader can generate a value change request

<richardschwerdtfeger> jcraig: in a web application where nothing is know about this event the author did not opt in to do anything in this event.

<richardschwerdtfeger> jcraig: these are value change vs. value changed events as it is a request to make the change

<richardschwerdtfeger> jcraig: the idea is for backward compatibility we don't break anything that exists as the existing apps no nothing about these events

<richardschwerdtfeger> gottfried: What is the difference here when the AT generates the event?

<richardschwerdtfeger> jcraig: in the case of a native control where <input type="range"> there are cases where the AT can request to adjust the range

<richardschwerdtfeger> jcraig: Today, the app would process arrow keys.

<richardschwerdtfeger> jcraig: the other way to do this would be to have direct manipulation of the value or basically setting the value of the slider

<richardschwerdtfeger> jcraig: you might have a pointer to the slider and you might have a decrement or increment value.

<richardschwerdtfeger> gottfired: why can't they just all the api

<richardschwerdtfeger> jcraig: for native controls yes but not aria controls where aria does not ovveride native functionality of the browser

<richardschwerdtfeger> gottrfried: we could override the value now property. The people in the DOM working group would say that breaks the web

<richardschwerdtfeger> rich: the author is not expecting that to happen

<richardschwerdtfeger> jcraig: it is believed that would break the web

<richardschwerdtfeger> jcraig: mutation events are being deprecated

<richardschwerdtfeger> jcraig: they are deprecated for performance reasons.

<richardschwerdtfeger> lachlan: there are on change events but authors are not expecting them

<richardschwerdtfeger> jcraig: the indie event behavior

<richardschwerdtfeger> jcraig: the point of regard is where we have keyboard focus but the screen reader can also have its own point of regard

<richardschwerdtfeger> lisa: it seems that we need to go up a level to abstraction - elements themselves

<richardschwerdtfeger> lisa: we could descend as well.

<richardschwerdtfeger> lisa: we could say that by inheriting an aria role the component could inherent functionality from the native control

<richardschwerdtfeger> lisa: I am wondering if at that level we could re-engineer it

<richardschwerdtfeger> jcraig: ARiA has never changed the behavior of the user agent

<richardschwerdtfeger> jcraig: in that respect that would be a hugely substantive change to the 1.0 spec. and would create a full recycle. I am not sure that is what we want to do and it would not work in languages other than SVG.

<richardschwerdtfeger> jcraig: escaping from the dialog for example

<richardschwerdtfeger> lisa: for a while we were talking about a back end where all the elements slide together

<richardschwerdtfeger> jcraig: I am not sure what you are talking about

<richardschwerdtfeger> John Li? Lee?: I am from Resarch in Motion

<richardschwerdtfeger> Josh O'Connor: NCBI

<richardschwerdtfeger> jcraig: to recap the last slide, at whatever point the assistive technology or the user agent determines the point of regard, if the user wanted to change the value of the aria slider we would initiate a value change request on this.

<richardschwerdtfeger> jcraig: if the web knew nothing about Indie Ui it would probably just let the event propagate on without being processed: backward compatibility

<richardschwerdtfeger> jcraig: For those that do they can intercept the event and process the value change and updates the aria-valuenow atribute

<richardschwerdtfeger> jcraig: the screen reader would then announce the new value of the slider

<richardschwerdtfeger> ]

<richardschwerdtfeger> jason Kiss: in the previous slide, for older browsers, the event never occured

<richardschwerdtfeger> jcraig: rendering engines try to be extremely efficient

<richardschwerdtfeger> jcraig: where nothing is listening for it the browser does not even allow it to go to the DOM

<richardschwerdtfeger> jcraig: the screen reader would know that the user is focused on this

<richardschwerdtfeger> jcraig: Dismiss dialog example

<richardschwerdtfeger> body which contains an aria dialog, with contains a paragraph which contains an input element

<richardschwerdtfeger> jcraig: the user presses an escape key which sends a dismiss request which bubbles up to the dialog. It intercepts the event at the dialog, cancels the event and executes a response to the dialog dismissal

<richardschwerdtfeger> jcraig: e.preventdefault() lets the UA/AT know the event was intercepted

<richardschwerdtfeger> jcraig: libraries like jquery has special library framework eqivalents

<richardschwerdtfeger> lachlan: is it reasonable that at all times the dismiss request should be sent?

<richardschwerdtfeger> jcraig: yes, I think so. Escape always triggers the browser stop function

<richardschwerdtfeger> jcraig: we don't want these events to be blocking on the application level - we do want on the rendering level

<richardschwerdtfeger> lachlan: how do we do that

<richardschwerdtfeger> jcraig: we would handle this in the bubbling phase. Intercepting the space bar is one. Stopping the page for loading I am not sure about now. That may be handled by the application and not the rendering engine.

<richardschwerdtfeger> jcraig: if this were to fly on a blocking engine … vendors are moving toward separate processed tabs

<richardschwerdtfeger> jason kiss: how does the prevent default notify the AT that the event was completed

<richardschwerdtfeger> jcraig: example: intercept a valueChangeRequest event on a slider

<richardschwerdtfeger> jcraig: here we are talking about a e.requestValue for what is passed.

<richardschwerdtfeger> jcraig: we could have a value step for ARIA. 2.0 or 1.1

<richardschwerdtfeger> rich: we are going to have to create a tracker here for web apps review as the changes will effect the methods provided in events

<richardschwerdtfeger> lisa: my suggestion would be to make this as hugely abstract as possible

<richardschwerdtfeger> lisa: if this is something where ARIA is used with RDF where people create their own widgets we could create new mappings.

<richardschwerdtfeger> lisa: I would try to keep any property names abstract as possible

<richardschwerdtfeger> jcraig: I agree and that is why we have requestValue vs. a slider request value.

<richardschwerdtfeger> jcraig: this is not specific to ARIA

<richardschwerdtfeger> jcraig: accessibility is one of the primary considerations but it is not the only one

<richardschwerdtfeger> jcraig: I am almost done

<richardschwerdtfeger> janina: the bulk of our time will be on use cases

<richardschwerdtfeger> janina: we are walking through to get requirements

<richardschwerdtfeger> janina: this is great. we are talking about a break at 10:45

<richardschwerdtfeger> jcraig: Indie User Context. the reason that this is pushed out longer is that there is a lot more to discuss here and we have a greater grasp of the events model

<richardschwerdtfeger> jcraig: one of the requests that has come in is that we need a way for web apps. to respond to user needs

<richardschwerdtfeger> jcraig: there are other things that are used as preferences. We want to simplify the user and authoring experience

<richardschwerdtfeger> jcraig: we want to make getting at these users needs flexible.

<richardschwerdtfeger> jcraig: we need to be able to get a user preference

<richardschwerdtfeger> jcraig: we need to be notified when a user preference changes

<richardschwerdtfeger> jcraig: we discussed a preference to view captions yesterday

<richardschwerdtfeger> jcraig: The web application will always know that the suer needs captions

<richardschwerdtfeger> jcraig: the user agent could be made aware of increases in the ambient noise and ask that the web app turn on captions

<richardschwerdtfeger> jcraig: register a listener for a preference change event

<richardschwerdtfeger> jcraig: e. preference key for case font size change performa a uI action

<richardschwerdtfeger> jcraig: in certain cases we would want to prevent this but we don;t want to prevent progress

<richardschwerdtfeger> lachlan: in the past we have had to adopt prefixed things from webkit because of its extensive use

<richardschwerdtfeger> Issue: Vendor specific preferences keys

<richardschwerdtfeger> ISSUE: Vendor specific preferences keys

<trackbot> Created ISSUE-4 - Vendor specific preferences keys ; please complete additional details at http://www.w3.org/WAI/IndieUI/track/issues/4/edit .

<richardschwerdtfeger> ISSUE: DOM event method specification will require coordination with web applications

<trackbot> Created ISSUE-5 - DOM event method specification will require coordination with web applications ; please complete additional details at http://www.w3.org/WAI/IndieUI/track/issues/5/edit .

<richardschwerdtfeger> Rich: Lachlan how would you like to address that

<richardschwerdtfeger> Lachlan: Don't know now. would want to discuss this with other groups

<richardschwerdtfeger> Rich: ok

<richardschwerdtfeger> jcraig: apple has a preference on tab key navigation order

<richardschwerdtfeger> lachlan: have you thought about how this impacts browser finger printing

<richardschwerdtfeger> jcraig: certain elements have relatively how costs or low need for security. We don't want to burden the user all the time.

<richardschwerdtfeger> jcraig: we need to implement some kind of security model

<richardschwerdtfeger> jcraig: no solution yet but has been discussed

<richardschwerdtfeger> jcraig: there are a variety of taxonomies.

<richardschwerdtfeger> jcraig: we would want to allow access to these other taxonomies

<richardschwerdtfeger> lachlan: so is that prefix like a name space?

<richardschwerdtfeger> jcraig: this particular string is influenced by a namespace but we are not imposing XML namepsaces

<richardschwerdtfeger> jcraig: we could have a new top level window object with new methods. This is larger than the scope of accessibility. So, I am not sure this should be part of the navigator object

<richardschwerdtfeger> jcraig: we could have a property that if the user does not care that I worry about a property ...

<richardschwerdtfeger> ISSUE: Potentially could have extensions to window level properties. Potentially need to coordinate with web application working group

<trackbot> Created ISSUE-6 - Potentially could have extensions to window level properties. Potentially need to coordinate with web application working group ; please complete additional details at http://www.w3.org/WAI/IndieUI/track/issues/6/edit .

<richardschwerdtfeger> andy: there is a whole other bag of stuff in preferences as to how one gets them in. They are not only device preferences but there are also media preferences

<richardschwerdtfeger> jcraig: questions: privacy questions. What happens when a web app requires a protected key?

<richardschwerdtfeger> jcraig: should eternal properties bey prefixed, namespaced, etc.?

<richardschwerdtfeger> jcraig: How do we resolve value differences across platforms? e.g. fontSize, returns a different value on different systems. Should we standardize a unit or use a relative size?

<richardschwerdtfeger> http://www.cnn.com/2012/10/31/us/mexico-border-jeep/index.html?hpt=hp_c3

<janina> http://www.w3.org/WAI/IndieUI/wiki/Main_Page

<richardschwerdtfeger> http://www.w3.org/WAI/IndieUI/wiki/Use_Cases_and_Requirements#S6:_Command_move_the_focus_point_within_a_UI_component_down_to_the_next_item_within_a_UI_component

Use cases

<Ryladog> scribe:Ryladog

!.6, 1.7, 1.8, 1.9 up down etc will be our directional uses, then a separate set for logical next and previous

S6 through S9 are for the directional use?

JS: Suggest eight directional uses cases of South, Southwest, North, Northeast etc

<richardschwerdtfeger> nav-up,

<richardschwerdtfeger> nav-up-right,

<richardschwerdtfeger> nav-right,

<richardschwerdtfeger> nav-down-right,

<richardschwerdtfeger> nav-down,

<richardschwerdtfeger> nav-down-left,

<richardschwerdtfeger> nav-left,

GZ: CSS 3 basic UI model elements has a these above
... It may be too much work to cater to so many

<richardschwerdtfeger> nav-up-left

JC: Maybe the CSS styles uses these, but that may be a problem for us
... Tabindex was all + integers, it overroad the default focus order of the DOM on interactive elements, Tabindex took focus out of the normal code order
... This may have a similar problem, using these elements above, as what happened with tabindex

GZ: It may be a problem

<janina> http://www.w3.org/WAI/IndieUI/wiki/Main_Page

<jcraig> ACTION: jcraig to add directional navigations event with 8-way directional order property (e.g. n, ne, e, se, …) [recorded in http://www.w3.org/2012/11/01-indie-ui-minutes.html#action01]

<trackbot> Created ACTION-14 - Add directional navigations event with 8-way directional order property (e.g. n, ne, e, se, …) [on James Craig - due 2012-11-08].

<jcraig> http://www.w3.org/WAI/IndieUI/wiki/Use_Cases_and_Requirements

RS: We are going to create events that are similar to SVG Tiny 1.2 for the names of the directional events for S6 through S9. And then two additonal,, next and previous

<jcraig> ACTION: jcraig to add logical previous/next event (not tied to directional focus event) (maybe focusNextRequest and focusPreviousRequest?) [recorded in http://www.w3.org/2012/11/01-indie-ui-minutes.html#action02]

<trackbot> Created ACTION-15 - Add logical previous/next event (not tied to directional focus event) (maybe focusNextRequest and focusPreviousRequest?) [on James Craig - due 2012-11-08].

<richardschwerdtfeger> SWAO

<richardschwerdtfeger> SWAP

LS: Suggest SWAP we thought was useful. The main use cases were for learning disabilities

Semantic Web Accessibility Platform

<Joshue108> http://www.w3.org/2000/10/swap/

LS: Easily navigable semantic information

<Joshue108> http://www.w3.org/2004/06/DI-MCA-WS/submissions/position-uba.html

LS: Someone could build and RDF by a proxy server if not on top of the app

JC and AH: This may be most useful in the User Needs/Preferences module

RS: Could you look at the Use cases we have and see if that would work with the use cases we have

JS: Richs request is a good one, if you can look over the use cases

<Zakim> jcraig, you wanted to mention this could be covered by taxonomy-prefixed preference keys

RS: For example, a user case to simplify the content - that would help us because we do not have any like that

JC: Part of the User Context module might have a way to inject (maybe via proxy) what an application request value, font size, captions, color, etc. Taxonomy defines this preference for short term memory

KHS: Could we include Simpler Language as a User Need?

JC: It may not fit, may be best addressed through a Taxonomy

LS: Short term memory loss is a very large challenge
... TV channel change, I put a sticker next to the on/off, simpler method, less choices

JS: Yes, this is a big issue,

RS: I think we need an event to this. We are seeing this in the education space

LS: You can map it to a use case
... Like your online mail

Lachlan: From a developers perspective, there does seem to be a problem with having to code for each disability

AH: I would be happy to speak with you off-line later

<sangwhan> +1

<Lachy> to clarify my point, solutions to the problems and use cases need to really look at the issue from web developer perspectives and making things easier and with more incentive to use

<Zakim> jcraig, you wanted to say a "simplify" event is still too general; simplify interface? simplify language? this may be valid, but IMO as a preference, not as an event.

RS: For the general web - maybe not too much, but in the education space developers do want this. I would like you to put together a user case for this

<Joshue108> +q

<lisaseeman> +q

JC: My thoughts on having a 'simplify' event. If you feel this is a valid need to have an event. You should provide the properties for this simply event, to help define and clarify. This is an action for you to provide a concrete proposal.

RS: I really want Lisa to give us some use cases. There is a project at the Department of Education right now, that is working on this.

LH: Without specific guidance it is hard for web developers to do

This is not going to sell to developers if this is mostly an Accessibility Spec

<richardschwerdtfeger> +1

Joshue: I would like to see this spec be more general, which would be better adopted

<sangwhan> /me would appreciate it if accessibility related acronyms are spelled out at least once for the noobs (like me)

<sangwhan> s/ \/me would appreciate it if accessibility related acronyms are spelled out at least once for the noobs (like me)//

AH: I wish we had put it in AFA, and would like it to be in AFA 3. GPII want it. If it a preference, I do not think it is an event........

<jcraig> AFA = access for all

<jcraig> PNP = personal needs and prefs?

<jcraig> GPII? dunno.

<Zakim> jcraig, you wanted to respond to sangwhan's comment that spec is currently accessibility-focused

<janina> rm li

<janina> q li

Global Public Inclusive Infrastructure (GPII)

JC: I am guilty that this is Accessibility focused. This spec grew from trying to fill the wholes that prevent access
... There are types of things that can not be done today, but we do want to make it more main stream

<Joshue108> +1 to James

<Zakim> Gottfried, you wanted to say that we need to address preference properties in a registry-based approach

JC: I do not want to address ALL of the needs in a 1.0 version that covers much Access issues

GZ: I see there is alot more in terms of content negotiation, but this cannot be addressed by IndieUI. This will be better covered in GPII, some thongs that I will talk about tomorrow - mconcerning a global repoistory

<Lachy> This is what I was in the queue earlier to say: Device independence is an incentive for developers. They want to target touch keyboards, computers with international keyboards, different pointers, etc. So providing events that let them provide the same functionlity regardless of their specific device is good. This kind of stuff can provide transparent accessibility benefits. But I don't think exposing accessibility-specific user preferences has the same incen[CUT]

<Lachy> use.

AH: I am not suggesting we move away from Accessibility

<Joshue108> +1 to Lachy on 'can provide transparent accessibility benefits.'

<Zakim> jcraig, you wanted to briefly mention avoiding deep dives in either direction for 1.0: either accessibility or mainstream prefs

RS: AT IBM if you can tie accessibility to a main stream use, there will be greater uptake

<Joshue108> I think that the more the work that can be done to support a11y via the backdoor the better.

JC: For 1.0 I do not think we can cover all accessibility needs, but we want to focus on the most critical access needs that will be best adpted

LS: I would like to see a task force in the W3C concerning cognitive issues related to diability

MC: I would like to suggest a new Community Group

KHS: I agree, great idea

<sangwhan> To clarify: my point is not that the spec should drop accessibility, I would like the spec to *not look like one* and more like a general spec that can cover the most generic use cases to be approachable - just to clarify that I am completely up for making a accessible specification. If it's transparently accessible as a generic event spec that's a free win for both the content developers and WAI.

JS: eBook has a good solution for simplification

<janina> About to resume ...

<Lachy> ScribeNick: Lachy

<richardschwerdtfeger> test

RS: The next one, assuming we've moved all the directional stuff into the spec, is S10. A command to direct media players to pause and play.

<Ryladog> LH: In HTML5 has custom controls you would want to provide this a higher level command that says pause

S10: Command to direct a media player to pause playing

LH: The interpretation of event is application-specific.

<Ryladog> GZ: Follow the event

<Ryladog> JS: Are you saying that HTML5 a;ready supports this?

<Ryladog> LH: It depends on the app - you can do it from a context menu

<scribe> ScribeNick: Ryladog

<richardschwerdtfeger> Proposed resolution: Define a requestPause that asks a web application to pause any or all any media (audio, video, streaming) on the page

<Lachy> --> PauseRequest

<Lachy> ScribeNick: Lachy

Lachy: Another use case for pausing is an application downloading data for its own use. e.g. to populate a database (IndexedDB), download a lot of application data in the background. The user might want to pause that download.

<richardschwerdtfeger> Proposed resolution: Define a PauseRequest event that asks a web application to pause any or all any media (audio, video, streaming) on the page

Ryladog: I think it's something you could use in many contexts.

RS: We could say to pause any live, ongoing action

james: One example: we have this idea of a primary action.

… VoiceOver iOS has a gesture with a default action for the application. It's contextual depending on what you're doing. Media playing, on a phone call, etc.

<jcraig> take photo in a photo application

<jcraig> specific gesture is unimportant

Gottfried: I think we should have both.

<jcraig> does play/pause or pause/resume need specific event, or is this a more general need that isn't specific for playing/pausing

james: We should have toggle events. The same action could trigger toggleable action. Pause/resume, etc.

<jcraig> such toggle events may be initiated at a specific DOM node, or at the body element if no point of regard can be determined.

<jcraig> From the current draft "Event fires on document.activeElement (or AT equivalent) if applicable, or otherwise document.body."

<jcraig> https://dvcs.w3.org/hg/IndieUI/raw-file/tip/src/events.html#RequestEvents

<jcraig> so event delegation is recommended

<jcraig> lh: many apps do not have stop, just play/pause, is there a need for stop? does the user care?

<jcraig> gz: stop is a macro for pause, then move playback slider to beginning

<jcraig> lh: difference between pause/stop may be a legacy use for paused cassette or video tape , keep on screen versus stop entirely

<jcraig> gz: pause means halt/resume, but windows media player is a macro for pause and exit, because it exits, but remembers previous location when starting again.

<jcraig> lh: example of potential use. netflix playback asks if you want to resume or start at beginning.

<jcraig> gz: since "stop" means different things on different platforms, we would not want to spec that as and intentional event, because the user's "intent" is ambiguous depending on platform.

gz: Would that stop or pause event apply to animated gifs?

Ryladog: you could apply it to all kinds of elements.

james: That might be something that is a separate event.

… Esc key pauses gifs in Firefox

… In the context of VoiceOver iOS, we have a dismiss action, which sometimes means activate the back button, sometimes means close the current modal view, etc.

Ryladog: An escape action could be one of those intents.

gz: Escape is a means to an intent, dismiss is an intent.

james: The original proposal was calling it EscapeRequest. Dismiss seemed more general.

… I have some other functional keys on my keyboard that will trigger specific intentions.

… Play/pause, seek, volume up/down, etc.

… Stop is a macro for different functionality in different contexts

LH: HTMLMediaElement has pause() and play(). No toggle().
... We might want to have a toggle intent though, which the app can interpret according to its internal state

james: The indication that these are media related keys on the keyboard indicates that these are separate from the general purpose pause and resume.

… Is suspend and resume worthy of being separate from pause/play?

… suspend/resume might make sense for a download or upload, which are separate from media playback. I wouldn't want them to hit a play/pause button on their screen and have it stop a download.

RS: So you want to have two separate events?

James: I don't think the media related events should be used for other purposes.

RS: Suspend/Resume could also apply to live regions. e.g. a twitter stream.

LH: e.g. live blogging examples, which are constantly updating with new posts. e.g. live blogging for an Apple event.

james: Mozilla OS has some APIs that interactive with native device controls. e.g. receiving a phone call.

gz: My point is we should avoid letting the web developer make all the choices because that will lead to inconsistent applications.

james: What do you mean by choices?

gz: The choice of how to respond to events.

james: We might have a UA that chooses not to convey some events to the web app, but I think we would want to leave it up to the web app.

… There may be some way that a user can define what kinds of actions they want to convey to web apps.

LH: Is there a way for the web app to declare what kind of events their interested in?

james: I would expect that the web apps would declare that by registerring for those events.

LH: We need some way for the web app to declare which kind of intents it's really interested, so that a device that make a better guess at what the user's intent is, and to send the appropriate event.

… e.g. a swipe up could mean scroll or pan; or in the case of an iOS date picker or list box, it could mean change the value. I think there needs to be more context given by the web app beyond the simple case of registerring for events.

<jcraig> We could defined expected events for certain types of controls, but Lachlan is saying this may need to be declared for each page or control types that the UA or AT does not know about. e.g. ARIA does not define a "map" view element, so it should register for the directional and zoom events, otherwise UAs would need to send events not knowing if anything is "listening"

<jcraig> s/defined/define/

james: We should also allow a web app to declare what kind of preferences they're interested in.

gz: Android applications, when installed, declare up front what access they're interested in. The user can grant or deny permission.

andy: Does it make any difference which group drives this work, re which preferences a web app is interested in?

james: The UA should only volunteer the information if it's been specifically requested by the web application, and the UA should request permission.

LH: Let's get back on topic.

Ryladog: We just covered use case S11. Stop playing.

<jcraig> ACTION: jcraig to add spec event for play/pause toggle event (and maybe media next/prev) [recorded in http://www.w3.org/2012/11/01-indie-ui-minutes.html#action03]

<trackbot> Created ACTION-16 - Add spec event for play/pause toggle event (and maybe media next/prev) [on James Craig - due 2012-11-08].

<jcraig> ACTION: jcraig to add spec event for suspend/resume (non-media playback) for example, suspend upload or suspend live region chat log updates [recorded in http://www.w3.org/2012/11/01-indie-ui-minutes.html#action04]

<trackbot> Created ACTION-17 - Add spec event for suspend/resume (non-media playback) for example, suspend upload or suspend live region chat log updates [on James Craig - due 2012-11-08].

RS: I'm adding a suspend/resume use case.

james: S13: Media caption toggle.

… I think we need two different events. I think we want to display or not display captions.

… The user preference change should fire an event.

… Some people are always going to turn on captions.

… We're going to want to explicitly turn them on or off.

gz: I think we should have both. You may have an AT that interprets gestures. It may be the same gesture for toggleable event.

… Gesture control is a main stream use case for our spec.

… Maybe it's not 3 different events. Maybe it's 1 event with a variable.

Andy: There are also audio descriptions and other media alternatives that the user may want to turn on or off

gz: there are cases where the device might want to automatically enable captions for the user, based on the user's environment.

james: Do we want to split User wants captions explicitly, or user probably needs captions due to environment?

janina: Break.

RRSAgent: make minutes

<Ryladog> test

<jcraig> LH: if we specify caption languages as a preference (e.g. "English, Spanish" etc) make sure the default value is undefined, so that any defined preference can be interpreted as an explicit user preference rather than the undefined default.

Debbie: In Multimodal Interaction, speech, e.g. there's a lot of user intent conveyed by speech rather than clicking or typing.

… It always seemed to me that speech was just another way to type.

… when someone says something like "I want the blue shirt", to translate that into a radio button that says blue next to it is stupid

… As I understand this WG, the way what the user wants to do from how they express it.

… I'd like to see if there's some benefit we can get from this abstraction.

james: It may be beneficial to do a short version of the intro from this morning.

… There are people within teh group with various levels of technical backgrounds, and varying levels of understanding of ARIA.

… This is a short into to ARIA and Indie UI

… Some of the background is about event models

… and how these new events would be slightly different from the current system.

… ARIA is declarative. So you can do things that overcome problems with authoring mistakes, browser implementations, etc.

… ARIA allows you to sprinkle on some sugar and you don't have to completely rewrite the app to be accessible.

… There are browser limitations with form control styling.

… ARIA lets to style other elements and specify a role to give it the right semantics.

… You can also declare semantics that are missing from the host language.

… The way that you do a native control such as a slider, a web app might update a value by updating an attribute. The browser will notify the screen reader.

… native control input works such that if a user wants to change the value of a slider, the AT can ask the browser to do that.

… The web app is notified via the change event.

… The same example with a custom aria slider, output works conceptually the same.

… For input, though, the user can try to change the value, but the browser doesn't know what to do.

… Click event behaviour. User clicks an image in a button, the event bubbles up to the button element, which performs the default action.

… registerred event handlers can also capture the event and perform a custom action.

s/registerred/registered/

… Keyboard events get sent to the element with focus.

… Indie UI events are similar to keyboard events in this regard

… IndieUI events are all FooRequest events. e.g. ValueChangeRequest. These are only requests, and do not perform any default action.

[that's not quite right]

… If the web app calls event.preventDefault(), then the UA and AT know that the web app handled the event.

… e.g. dismissing a dialog. Pressing the Esc key on a keyboard should generally dismiss the dialog.

… If an input control within the dialog (repesented by HTML <div role="dialog">), then the event will bubble up to the div, which can then handle it.

… DismissRequest

… preference change events.

… There's an API to query user preferences, and the event notifies when the user has changed the value.

… The keys may be defined in the spec, vendor specific or belong in an external taxonomy.

<jcraig> http://www.w3.org/WAI/IndieUI/wiki/Use_Cases_and_Requirements

<jcraig> https://dvcs.w3.org/hg/IndieUI/raw-file/tip/src/events.html

<jcraig> https://dvcs.w3.org/hg/IndieUI/raw-file/tip/src/user_context.html

Dan: What would be inappropriate use of these events?

… Once you make events available to programmers, they will find creative ways to use them.

… As a group concerned about multimodal interaction, you might have different input. You use events to pass information.

… These are now a new set of events that are there to fill gaps in the existing set of events, but do you forsee any problems in how they might be used.

james: I see potential for abuse in the user prefs section. Being able to inspect prefences that reveal disabilities, is ripe for abuse.

… As far as the events being abused, I don't know.

… In the example of the dismiss request, there is a point of regard. It may or may not have keyboard focus. In the case of a web app with multiple dialogs, many of which may be dismissed.

… In the case of a dismiss requested fired at a high level like the body, rather than a particular dialog, then we would expect the web app would ignore what it doesn't understand.

… Maybe there are two dialogs, and there is a point of regard in a form control within one dialog, then that dialog will receive the event.

… The types of events currently in the spec are: Undo, Redo, Delete, Dismiss, Expand, Collapse, Scroll

… DOMAttrChangeRequest may be dropped.

… ATFocusIn and ATFocusOut. These are not specific to keyboard focus.

… Screen readers have a point of regard independent of keyboard focus.

Debbie: Can we talk through an example of something, such as DismissRequest. Say there's a dialog on the screen, one way to dismiss it is by clicking a provided button, or by listening for an Esc key press.

james: The browser doesn't know how to dismiss a web app custom dialog, the web app does.

… Because there is no dialog element in HTML, everything we see as one is basically styled HTML.

Debbit: If you had speech enable, you could say "Dismiss that", then the dismiss request event could be dispatched based on that command.

james: yes

Debbie: That would be nice from a multimodal perspective.

james: Part of the event bubbling is such that you can differentiate different types of undo.

… Depending on what has focus or point of regard, the event could be interpreted differently by the web app.

Debbie: What if you wanted to select a radio button?

james: I think that is pretty well covered by the default action.

… It's equivalent to click or DOMActivate.

… Those work well across custom applications.

… The ones that don't work well are ones that have some kind of secondary action.

Debbie: For the example of the radio button, we use a Pizza ordering use case. There is a small, medium and large buttons, and by speech, you select the "Large" radio button.

james: I think we could consider doing a value change request and select the ones with the right value.
... Click is commonly used as a more general purpose event. It's fired by AT, by mouse, etc.

Helena: There's a pointing action without activation, like focussing.

james: That's changing the point of regard

Debbie: e.g. On a mouse over, you might, e.g., change the font size.

james: We have ATFocusIn/Out to show where the point of regard is.

LH: What is the use case for ATFocusIn/Out

james: There are cases where you may want receive a focus event on something that is out of view.

… and the only way that custom views can respond to that is with custom views, and that's problematic.

… A common accessibility error is that you move your mose over something and something happens. The ATFocusIn/Out handles this if they listen for it.

<janina> ,,,,,,,,,,,,,,,,/me Lisa? Is it you?

Debbie: I think we should consolodate what our next steps might be.

… If we see any gaps with respect to multimodal interaction, that we should fill in.

james: There are a bunch of things we want to put in now after these disucssions

Debbie: Making the case for speech interaction in general, you can do things that aren't on the screen.

… The user might say they want to go to the home page of the site. But this seems out of scope.

james: When you said what apects do you think might be abused, if you have any aspects of this that might inform out decisions over privacy issues, etc.

… let us know

<lisaseeman> ping me when the brake is over

[discussion about Access for All, APIP, etc.]

james: With each of these different taxonomies, have any of them addressed the privacy concerns?

RS: The way they have been named is to not show the person's medical disability. They just express user needs, rather than disabilities. I need captions. Not I'm deaf.

Zakim: IPCaller is lisaseeman

<jcraig> ACTION: Andy to summarize important or common preferences/keys list from AfA/APIP/GPII, etc. and send to the IndieUI group for discussion and potential inclusion in the User Context deliverable. [recorded in http://www.w3.org/2012/11/01-indie-ui-minutes.html#action05]

<trackbot> Created ACTION-18 - Summarize important or common preferences/keys list from AfA/APIP/GPII, etc. and send to the IndieUI group for discussion and potential inclusion in the User Context deliverable. [on Andy Heath - due 2012-11-08].

gz: The user must have control over what preferences are conveyed to the web app

andy: We must be careful about users exposing preferences that could let strangers determine personal details, such as their disability.

<jcraig> Actually use these: https://dvcs.w3.org/hg/IndieUI/raw-file/tip/src/user_context.html

<jcraig> https://dvcs.w3.org/hg/IndieUI/raw-file/tip/src/events.html

<jcraig> Judy, the URLs with hash values are specific commits that will never change. Refer to 'tip' for the latest.

RRSAgent: make minutes

- DRAFT -

Indie UI Task Force Face to Face

01 Nov 2012

Attendees

Contents

Indie UI Overview

Use cases

S10: Command to direct a media player to pause playing

Summary of Action Items

Scribe.perl diagnostic output