ARIA FtF Day 3 -- 25 Jan 2014

<jamesn> 6:25pm

<janina_> 3:55

<joanie> 3:20

<jongunderson> 4:00

<richardschwerdtfeger> Rich =5:15

<richardschwerdtfeger> https://www.w3.org/WAI/PF/Group/track/products/17

Is ARIA only for AAPIs (and ATs)?

<richardschwerdtfeger> scribe: richardschwerdtfeger

janina: there are people that require assistive support but they don't need ATs
... so we can't get rid of other support features

<David_MacD_Lenovo> aria only for apis

janina: I don't feel this this it is the case that aria is only for apis - as long as it does not break accessibility it is fine
... It is required for all elements
... It may just well be a curb cut elsewhere
... Why not promote its use elsewhere?
... It is a marketing of ARIA approach
... If we stick a fence we will shut others out

davidb: I will be on the page on what the angle is. If you take an aria attribute and user agent feels it is useful and not just for AT

joseph: what if you wanted the feature and SVG and HTML?

davidb: ARIA has informed some html

cynthia: what if we are moving faster than HTML?

davidb: I feel like I don't fully understand Janina yet
... there may be consensus that we want to move at light speed with ARIA and we could run into big arguments with HTML people

cynthia: there was argument as to whether aria-label should be ok for alt as a replacement
... it feels funky in the browser.

Brian: If you have aria-labelledby it would click on the form field
... that would be helpful

davidb: developers do custom work. ARIA was intended to be purely semantic.
... we were just applying the semantics
... it was less painful for the browsers

<clown> scribenick: clown

RS: we had a lot of political things at the beginning of ARIA.
... we had to put it such that it would not break the developers' process, nor break the browser
... But, the host language should be able to decide additional behaviour for ARIA
... it was meant to be a cross-cutting technology.
... to work first in html, then in SVG
... For all RIA web applications
... And it has become that.
... When we go to recommendation that will be even more so.
... we didn't look at HTML 4 holistically.
... We didn't aniticpate ajax.
... Now the developers can leverage ARIA to help with this.
... For example, I advised some developers to use CSS selectors on aria-* attributes
... it will reduce your need for JavaScript
... a problem we had was giving an early draft of ARIA to Ian
... and he put some equivalent things, like autocomplete, into HTML5

<Zakim> davidb, you wanted to ask, is aria the a11y api or the web or is it more than that, i'm concerned about complexity

RS: but, as long as they don't break want we want to do.

CS: They?

RS: The browser vendors.
... It's in their best interest to use ARIA. They can slim down the language and avoid duplication

<scribe> scribe: richardschwerdtfeger

<scribe> scribenick: clown

<richardschwerdtfeger> davidb: Going back to cognitive, the mind of the web developer. Accessibility API - When I think about MSAA, etc. I Like ARIA as the accessibility API of the web.

<scribe> scribe: richardschwerdtfeger

davidb: I like the idea of ARIA being the accessibility API of the web. Do we want it to be an api in the traditional sense or do we wan to see it a unifying way of defining the user interaction of the Web?

jamesn: We would like it for developers to create add-ons for users without having to go through the full AT pattern. ... if you could access the ARIA info from the browser it might make it easier for it to be mainstream

davidb: password fields I have had huge headaches with anti-spyware instantiating our a11y engine. Password field ... do you want lightweight access

jamesn: perhaps if we made it part of javascript it would be easier

cynthia: Touch on windows uses UIA
... given that ARIA has existed for almost a decade now its adoption now is pretty good (better than alt) ...
... the ability to add ARIA state in it just worked
... the ability to store the state of the object on a tag ... we were able to repurpose aria
... The script and the CSS were triggered off of ARIA - it was teany and it worked very well.
... I don't believe the retrofitting scenario will continue to be the norm.

davidb: In the expando case that is still just semantics.

<Zakim> davidb, you wanted to ask, is aria the a11y api of the web or is it more than that, i'm concerned about complexity

david_macdonald: I think it is going the direction where aria attributes will replace the alt. are there feelings against that?
... is it ok that aria semantics replace alt?
... is it related to this?

jcraig: I have an opinion. If people use it as a replacement as some are using aria-label=""

janina: we could talk this for the rest of the day ...
... In my mind we need to understand our audience.

cynthia: I think you are overestimating the understanding of the developer space
... one thing we could do is remove the aria prefix

jamesn: I want to state what we are working on in the task force. you may not meet HTML but you meet wcag 1.1.1
... it is not an accessibility feature ...

<jcraig> MarkS: https://bug-62774-attachments.webkit.org/attachment.cgi?id=215012

<davidb> jcraig, WFM

<clown> http://trends.builtwith.com/docinfo/WAI-ARIA

<Zakim> cyns, you wanted to suggest a wcag failure for aria-label=""

<jcraig> role="none" is ISSUE-348: https://www.w3.org/WAI/PF/Group/track/issues/348

<clown> scribenick: davidb

RS: if you want to do this, we can look at the "none" role, secondly you guys need to figure out how you want to transition from alt and deal with aria-label=""...
... third, html group would need to agree to react to aria-label as alt (e.g. when images are turned off, render the text)

general discussion... don't "replace" alt

<richardschwerdtfeger> scribenick: davidb

JN: can drive in the task force

RS: we'll find a shorter name for "presentation"

JS: sounds like we still have follow up issues about ARIA scope

<jamesn> aria-label="" is easy to check for if you have the get accessible name js check

JS: we can learn as we go

<MarkS> here is a 80+ message thread regarding the alt/aria-label issue that clearly indicates there is no consensus here: http://lists.w3.org/Archives/Public/public-html-a11y/2013Nov/0052.html

*ba-donk!*

(that's the sound of 80+ messages)

JS: we'll find a middle ground

Joseph: ARIA 1.0 is one way, from browser into a11y API, but on desktop it actually goes the other way, you can actually drive

<MichaelC> drop item 2

<MichaelC> close item 3

<richardschwerdtfeger> scribe: rich

<MichaelC> scribe: richardschwerdtfeger

Keyboard handling within complex widgets with child components

jamesn: the current authoring practices that fall apart when you get to very complex widgets
... as soon as you put a text input widget int the toolbar you have a problem
... trees with child components are a problem
... we need a consistent keyboard model in ARIA that allows you to drill in and out of a component
... we need something more generic
... this would also apply to toolbars
... to support this we need to define this interaction behavior

<jcraig> ISSUE-547 (Matt King): Toolbars need to be treated as composite widgets by assistive technologies but are currently only subclass of structure

<jcraig> https://www.w3.org/WAI/PF/Group/track/issues/547

jamesn: Otherwise we have jacky solutions around each

jcraig: I like the idea that we have a property to indicate if something is a managed focus widget. I think this is a good idea.

<clown> For reference, the keyboard model for grid navigation vs activation is here: http://www.w3.org/WAI/PF/aria-practices/Overview.html#grid

rich: we need someone to take up the authoring techniques

cynthia: I might be able to take this up but I am concerned about time
... I am willing to write some scripts

clown: It needs some edits

mattking: I think this is the group we need to take this on
... being on the front line of implementors I think the authoring guidance document is extremely important
... MattKing, JamesN, Cynthia, Jongunderson, david Macdonald will work on the authoring guidelines
... i think we should coordinate with HTML5

<Zakim> jcraig, you wanted to discuss toolbar issue by MattKing as part of this.

rich: what do we think about what to do with indie ui and SVG wrt. authoring practices
... keyboard is the biggest overhead for accessibility

jcraig: we agree we need a managed focus
... I agree keyboard support is off the charts

jamesn: I would propose that once we have a managed focus we wold need ability to drill into a component.

mattking: I am not sure about that but we should not have that discussion today

jcraig: the normal process for toolbars, ribbons, etc. etc. Tabbing is not useful. We do jut tab through most buttons. I fought to keep toolbar optionally manage focused as there is not necessarily a one to one mapping.
... we have more uses than that

<jcraig> issue-547

<trackbot> issue-547 -- Toolbars need to be treated as composite widgets by assistive technologies but are currently only subclass of structure -- raised

<trackbot> https://www.w3.org/WAI/PF/Group/track/issues/547

jamesn: toolbars needed to be treated as composite widgets. Do you want all toolbars to be managed focus?

sorry that was jcraig

mattking: We wanted toolbar to be a group. It is not treated as one at the AT level
... when a widget has focus and keyboard is passed it is not passed to the screen reader. They automatically go into their forms mode. JAWS treats toolbars like this now.

jcraig: we should take this up with the later issues

<clown> http://www.w3.org/WAI/PF/aria/roles#toolbar

<clown> http://www.w3.org/WAI/PF/aria/roles#application

mattking: I would suggest that the wording change. It is leading to uses that are awful.

<scribe> ACTION: jamesn suggest new text for the application role [recorded in http://www.w3.org/2014/01/25-aria-minutes.html#action01]

<trackbot> Created ACTION-1361 - Suggest new text for the application role [on James Nurthen - due 2014-02-01].

<clown> http://www.w3.org/WAI/PF/aria/roles#treeitem

Brian: isn't role="document" in a tree item for for maintaining active elements within a document.

mattking: you can put a tree inside a document that can be used inside a widget

jamesn: there are a whole bunch of complex widgets. I need to the ability to drill into this.

mattking: this is not something we can just handle in the authoring practices
... we can come back to PF from the authoring practices group to the main aria group

<jcraig> https://www.w3.org/Bugs/Public/show_bug.cgi?id=23871

<Zakim> jcraig, you wanted to mention tabindex scoping

jcraig: We need an improvement for tab index - tab index scoping
... get the normal full access feature
... the object orient way to do tab index.

jamesn: you can solve this with scripting I would like to see us have this

mattking: I am so excited to be able to simplify the world here
... when we say keep it simple stupid. it would be great to do this.

janina: tab index is too linear

davidb: do we want infinite nesting?

mattking: we can do this dynamically.

jcraig: I was thinking of positioning context in CSS to address David Bolter's question about nesting depth

dbolter: we have an F6 ring now

Shane: we had talked briefly 2 days ago about our languishing access extension. That seems like a place we could just do this

<bgaraventa1979> found the reference I was refering to, though it is not specific to trees, the text implies that it can be applicable to any of the interactive widgets, dialogs, applications, trees, etc. http://www.w3.org/TR/wai-aria/roles#document

<davidb> (I like what jcraig said)

<jcraig> Tabindex scoping could behave more like positioning contexts in CSS.

<ShaneM> http://www.w3.org/TR/xhtml-access/

<davidb> agree with jcraig

<jamesn> issue: investigate aria-hasmanagedfocus to indicate whether a region manages focus to enable complex widgets

<trackbot> Created ISSUE-640 - Investigate aria-hasmanagedfocus to indicate whether a region manages focus to enable complex widgets. Please complete additional details at <https://www.w3.org/WAI/PF/Group/track/issues/640/edit>.

Break

<Zakim> ShaneM, you wanted to talk about scoped behavior of tabindex

Bugzilla vs Tracker

<jamesn> scribe: jamesn

mc: at the moment we are set up with space in bugzilla but the only component is the UAIG

<jcraig> https://www.w3.org/Bugs/Public/show_bug.cgi?id=23803

mc: have not been using bugzilla as a central part of our issue management at the moment
... if we do it we need to work out how it fits into our issue management approach
... if an issue is raised through bugzilla is it a formal public comment or not
... we have other channels for that
... with bugzilla one option is that these are also formal public comments. that is more effort for me
... could also state that these are not formal comment requirements and there are no guarantees that will be processed

cs: why is the existing process better?

mc: easier for me in our current process as there are a clear set of steps - we decide on a resolution and send to the commenter. In bugzilla people splatter into the entry what they thinkn
... it is harder to differentiante the group input from randoms from the filer
... hard to assertain when we have reached consensus and when can close the comment
... tidiness vs increased openness
... options
... not use at all
... use both bugzilla and current
... or lets move to bugzilla for everything
... i think anyone can change the state

jc: think that isn't true. can comment but not change state

mc: wanted to get the groups input
... caveat if more work then want help

<jcraig> https://www.w3.org/Bugs/Public/show_bug.cgi?id=23803

jc: SF emailed to ask this to happen as there is a strange process

cs: agree that the tracker is hard to use

jc: editorial issues and some big issues come in. Think that perhaps sometimes we create an issue in trackbot for things which are larger but it would be nice to be in one place and in public.
... I am all for adding bugzilla

mc: a bugzilla bug can be a feature request or a bug or something else

rs: I want some sort of command-line utility
... from IRC

jc: propose to stop using tracker except for issues.

cs: biggest issue of tracker is that you can't assign it to someone

mc: bugzilla, tracker and the comment tracker. 3 different tools
... would we want to move both into bugzilla?
... others have used the comment tracker in the past
... by design much is only visible to WG members

db: mc should have a voice in this as has big stake in this

mc: hard requirment is that LC draft need to receive public comments and need to respond, be archived on mailing list, and be a group consensus
... then commenter can agree or not
... have always needed to be very clear on what is a comment because of this rule
... we might deal with other stuff but won't track it

mk: in bugzilla when choose what filing against could you have a coponent for ARIA 1.1 comment

cs: 2 things. My requirement is to have all the stuff in 1 place. I would prefer that that is a bug tracking system.
... want everything to be assignable

<joanie> +1000 to cyns's comments

cs: I have a product that does a lot of this. Similar to bugzilla in a lot of ways but can do cool process tracking etc.

<jcraig> +1 to making Bugzilla the primary tracker

mc: assuming we could make bugzilla meet these requirements does the group want to adopt bugzilla and supplant the commetn tracking tool

<davidb> +1

<clown> +1

<richardschwerdtfeger> +1

js: my only complaint is that buzilla tends to replace email for debate

cs: don't like mail things get lost

jc: son't have to search mailbozes etc.

cs: you get it when you are ready

db: have heard complaints about bugilla accessibility
... comments become dicusssion

RESOLUTION: PF adopts bugzilla for formal comment tracking

cs: want everything in the same place

mc: how we process any email comments
... at the moment i put things in the PF comment tracker manually. There is no option currently to file automatically into the comment tracker

<davidb> http://www.bugzilla.org/features/

<Zakim> Joseph_Scheuhammer, you wanted to say the comment tracker is for "last call".

<davidb> http://www.bugzilla.org/features/#email-in

mc: the question is - do we want a central db. do we abandon the other tool?

RESOLUTION: Stop using the old PF comment tracker

mc: do we want to stop using the trackbot tracker?

jc: if we keep it it should be just for the IRC integration. We could add it and immediately close the issues

clown: what would it take to add trackbot to bugzilla

mc: think we would know if there was

<joanie> supybot has bugzilla plugins

db: is there an irc bot for writing email
... can email bugs to bugzilla

mc: we would like to migrate for trackbot to bugzilla but need to sort out some irc to bugzilla integration steps
... will let steve know this will happen but not in the next 2 weeks

<jcraig> ISSUE-547 (Matt King): Toolbars need to be treated as composite widgets by assistive technologies but are currently only subclass of structure

<jcraig> https://www.w3.org/WAI/PF/Group/track/issues/547

Scrubbing ARIA 1.1 Issues and Actions https://www.w3.org/WAI/PF/Group/track/products/17

mk: toolbar is a structure not a widget. when at gets focus inside a toolbar you can't support the keyboard model unless the AT treats it as a widget. Right now ATs are doing that. not becuase the spec suggests this but instead because we asked them to do so.
... what is happening in the wild is what we want to happen.
... authoring practices are out of step with the spec and suggests should support arrow keys but can't unless it is a widget

<clown> http://www.w3.org/WAI/PF/aria/roles#toolbar

<jcraig> I disagree with this proposed change. This would require toolbars to be managed-focus widgets and would therefore not allow other managed-focus widget children such as a radiogroup. Radio groups are common in toolbars (example: document editor controls for alignment left, right, or justified)…

<jcraig> https://lists.w3.org/Archives/Member/w3c-wai-pf/2012OctDec/0246.html

<davidb> http://access.aol.com/dhtml-style-guide-working-group/#toolbar

jc: your assumption that we want to do this is based on a behaviour which is unique to certain toolbars and platforms.

mk: you can't do this unless you allow this.

jc: can either use full keyboard access - so depends on how it is set up

mk: not consistent - it is the user's preference
... how can the author manage focus if the at doesn't show the toolbar as a widget

jc: because VO doesn't intercept key presses then this is no issue

<bgaraventa1979> I'm confused, according to http://www.w3.org/TR/wai-aria/roles#toolbar managing focus is mentioned as part of the widget, so it supports either method of navigation, single tab stop and arrow keys with aria-activedescendant?

jn: hasmanagedfocus would solve. kind of like role=application but much more contrained and likely for people to get it right

rs: think this would help

mk: why would you want a toolbar without managed focus?
... you mean managed focus with arrow keys rather than tab

jc: this is why i want to keep ui designation behaviour out of the spec
... we should not spec this kind of behaviour in the technical specifciations
... we shouldn't assume that all toolbars behave the same

<bgaraventa1979> what happens if a toolbar has an edit field? single tab stop and arrowing shouldn't apply, so functionality should be determined based on the implementation

cs: a less sophisticated dev who is trying to use aria is going to assume that the blue thing a the top is the toolbar. While there are some things that should create berowser behaviour this isn't one

<jcraig> I second closing the issue

mk: perhaps the ADG is too prespriptive. what we are doing a lot is hacking things like toolbar and use them in ways where we are being too prescrpitve for the authors. What is being highlighted is the lack of widget roles and not toolbar. Perhaps we should just close this and look at more widget roles

<jcraig> We have other issues tracking "managedfocus" and other roles, so this can/should be closed.

mk: if we did it with a property and applied it to a region would this be like an applicaton region.

need to look what the allowed roles would be for that property

rs: any objections to adding a managed focus property in 1.1

cs: just because some screen readers do something poorly we shouldn't throw out a role

<Zakim> cyns, you wanted to say that just becuase some screen readers doing something with poor usability based on a role, doesn't mean that the role should go away

<jcraig> issue-640

<trackbot> issue-640 -- Investigate aria-hasmanagedfocus to indicate whether a region manages focus to enable complex widgets -- raised

<trackbot> https://www.w3.org/WAI/PF/Group/track/issues/640

<Zakim> Joseph_Scheuhammer, you wanted to note that application role is a landmark.

clown: want to note that applicatoion is a landmark so is useful for navigation

<jcraig> ACTION: jcraig to patch issue-640 [recorded in http://www.w3.org/2014/01/25-aria-minutes.html#action02]

<trackbot> Created ACTION-1362 - Patch issue-640 [on James Craig - due 2014-02-01].

<clown> scribenick: clown

<Zakim> jcraig, you wanted to close issue-547

<jcraig> action-1362

<trackbot> action-1362 -- James Craig to Patch issue-640 -- due 2014-02-01 -- OPEN

<trackbot> https://www.w3.org/WAI/PF/Group/track/actions/1362

<jcraig> close issue-547

<trackbot> Closed issue-547.

<jcraig> close issue-640

<trackbot> Closed issue-640.

<richardschwerdtfeger> RESOLUTION: create a new ARIA attribute to let ATs know that the element manages focus to address issue 1362

<jcraig> ISSUE-554 (Alex Surkov): Should elements inherit certain attr values from ancestor elements? aria-relevant does. What about aria-required and aria-invalid?

<jcraig> https://www.w3.org/WAI/PF/Group/track/issues/554

<jcraig> ISSUE-602 (James Craig): Need a role or property to indicate a text field is intended for audio or visual CAPTCHA input.

<jcraig> https://www.w3.org/WAI/PF/Group/track/issues/602

<jcraig> ISSUE-603 (James Craig): Need an attr to indicate element activation triggers audio, video, etc.

<jcraig> https://www.w3.org/WAI/PF/Group/track/issues/603

<jcraig> ISSUE-627 (Joseph Scheuhammer): Conflict between aria-autocomplete and HTML5 autocomplete.

<jcraig> https://www.w3.org/WAI/PF/Group/track/issues/627

<jcraig> ISSUE-633 (Matt King): listbox and tree may contain only static items; badly need interactive widgets that can contain interactive typed items

<jcraig> https://www.w3.org/WAI/PF/Group/track/issues/633

break for five minutes.

kaboooom!

<jcraig> ISSUE-554 (Alex Surkov): Should elements inherit certain attr values from ancestor elements? aria-relevant does. What about aria-required and aria-invalid?

<jcraig> https://www.w3.org/WAI/PF/Group/track/issues/554

JC: alex is not here, maybe we should discuss later
... if you have an aria-required on a group, do all the items in the group get it?

<jcraig> ISSUE-602 (James Craig): Need a role or property to indicate a text field is intended for audio or visual CAPTCHA input.

<jcraig> https://www.w3.org/WAI/PF/Group/track/issues/602

DB: let's wait until alex is around.

JC: By default most screen readers have an echo while you type.
... and you hear not only the CAPTCHA, but also the type echo.

RS: why not? Easy to add?

JN: I don't want the captcha role.

<joanie> role=thisisevil

<davidb> :)

MK: this shoulld be an informative property, if we do this?

JC: what to call it?

MK: Indicate that this this problematic for the SR user.

JS: Is this 1.1 or 2.0?

RS: It's not that bad.

CS: I think it's 2.0.

MK: Is it a pressing problem?

<jamesn> +1 for 2.0

JS: James says it is.

JC: It would give us a way to say if users are typing, not to echo.

MK: That's something that sr users do is turn off echo.

<ShaneM> CAPTCHA is uniquitous and MUST be a challenge for some classes of users. like old folks like me.

JC: Those are power users.

MK: It is so hard to predict that the user wants this behaviour.
... to put this responsibility on the author...

JC: I"m not saying that. Onlly to inidcate that the text field is a captcha.

JN: We have a policy to not use captchas since it gives false sense of security.
... They don't really work.

MK: Yes, I can use plugins to get past the captcha.

CS: Let's move this ot 2.0

JS: The room is saying "punt".

<David_MacD_Lenovo> @matt what is that FF plugin to defeat Captcha

JC: Let me come back with a better proposal (use case?)

<ShaneM> I can live with punt

JS: We have agreed to punt. Let's proceed.

MK: I thought this was 554.

JC: David said let's talk about 554 when alex is here; so we moved on.

JN: we should find a way for people to turn off echo.

<jcraig> ISSUE-603 (James Craig): Need an attr to indicate element activation triggers audio, video, etc.

<jcraig> https://www.w3.org/WAI/PF/Group/track/issues/603

<davidb> hasmedia?

<jcraig> UIAccessibilityTraitStartsMediaSession

JC: If you play an audio track or a video track, you press the play button.
... But will suppress some of the output.

RS: what output do you want to supress?

JC: That depends on the AT.
... all this does is indicate that when you press the control, then some media will play.

JS: Talkback on android says the tilte of the movie that will play.

JC: I"m about to play a song. Press the button and it plays.

RS: It's okay with me. Might be difficult to get authors to do it.

MK: It's informative to screen readers again.

JS: Is there a general way to figure out what kind of file?

JC: That's something else. This just indicates that something is about to happen if pressed.
... It may be a sound effect.

<jcraig> jcraig to patch issue-603

JC: I will give myself an action for this issue, hearing not objections.

DB: : You want it modality speicifc, right.

JC: Audio vs. video?

DB: Yes, or both.

<jcraig> ACTION: jcraig to patch issue-603 [recorded in http://www.w3.org/2014/01/25-aria-minutes.html#action03]

JC: we can do that.

<trackbot> Created ACTION-1363 - Patch issue-603 [on James Craig - due 2014-02-01].

<jcraig> action-1363: davidb make it modality specific (audio vs video)

<trackbot> Notes added to action-1363 Patch issue-603.

<jcraig> scribe: jongunderson

<trackbot> Closed issue-603.

<jcraig> ISSUE-627 (Joseph Scheuhammer): Conflict between aria-autocomplete and HTML5 autocomplete.

<jcraig> https://www.w3.org/WAI/PF/Group/track/issues/627

JC: Next one is JospephS issue

JosephS: Found in testing auto complete with input element, it says that it is auto complete is always on

JN: Can't you turn it off

<jcraig> http://www.w3.org/TR/2011/WD-html5-20110525/common-input-element-attributes.html#the-autocomplete-attribute

JosephS: It is a problem with lecacy apps that don't set auto complete, autocomplete by default is on in HTML 5 implementations

JC: It is an enumerated attribute
... This is OK

<jcraig> html5:*@autocomplete is enum not boolean

CS: The expected behavior, if you have an auto-complete....

JosephS: Alex says HTML5 wins

JC: Clearly need this in 1.1

<jcraig> ISSUE-633 (Matt King): listbox and tree may contain only static items; badly need interactive widgets that can contain interactive typed items

<jcraig> https://www.w3.org/WAI/PF/Group/track/issues/633

JC: Last one is one of MK issues
... ISSUE-633: listbox and tree may contain only static items; badly need interactive widgets that can contain interactive typed items
... has managed focus is part of this
... MK is this actionable as a standalone issue

MK: I am willing to take an action

JC: Text for implementation guide?

MK: If we are creating a role, we will need text for the mapping table
... I will take that action

<jcraig> ACTION: matt to propose text for issue-633 in spec and uaig [recorded in http://www.w3.org/2014/01/25-aria-minutes.html#action04]

<trackbot> Error finding 'matt'. You can review and register nicknames at <https://www.w3.org/WAI/PF/Group/track/users>.

<jcraig> ACTION: king to propose text for issue-633 in spec and uaig [recorded in http://www.w3.org/2014/01/25-aria-minutes.html#action05]

<trackbot> Created ACTION-1364 - Propose text for issue-633 in spec and uaig [on Matthew King - due 2014-02-01].

JC: That was all of the 6 that I wanted to go through

JS: We have 43 minutes

JC: Let's look at the other agenda items

<jcraig> drop item 1

JC: We have more issues these, these were just the important ones

<jcraig> drop item 4

JS: We need to talk about time lines
... Make 2.0 about extensibility

<jcraig> drop item 7

<jcraig> drop item 8

JC: Going through remaining issues...

RS: I would like to talk about IndieUI
... The pervasiveness of mobile devices
... One of the things not in 1.0 was the whole keyboard and other devices, but we are at the point where keyboard is so important
... If we are redoing the authoring practices we should look at this at the same time
... The interaction pieces needs to be a part of the spec
... I get this all the time, is the authoring guide a standard
... Thrid party just wants to put tab index on everything
... Good time to talk about this

JC: I am on the cue
... We can do a couple of things
... We are talking about IndieUI events, most people have some idea, but I will summarize
... I would like to keep is separate from accessibility, because it is not about just accessibility
... The spec is about make it easier to manage device specific events
... Voice and other AT cannnot control these interfaces
... We can make it easier to control delta events, by making it much easier
... We want developers because it is easier for them
... If we make it simple they will use it
... This is NOT an accessibility thing
... It is much easier than managing 10 events
... If it about accessibility it will not get as much attention

CS: ARIA has had very good uptake

JC: 99% of pages have no aria

RS: We need to figure out how to get developers to pick this up
... in a big way

<clown> http://trends.builtwith.com/docinfo/WAI-ARIA

RS: We have to do this

<clown> some stats on aria uptake: http://trends.builtwith.com/docinfo/WAI-ARIA

RS: We can always in our authoring practices ....
... It is a lot easier than what we have now
... I know this is not ARIA, but how do we get ...

MK: What are the timeline?

JC: A heart beat draft in a month

JS: And a last call this spring

JC: People won't read it until last call
... Evangelism has to happen organically
... We have to separate this from accessibility or we will loose it
... Probably WebApps

RS: Is Microsoft part of WebApps
... I have a meeting with Microsoft to discuss this

JC: Last call in spring may be premeture
... My personal experience is that people think this is interesting

<Zakim> MichaelC, you wanted to ask about taking over the world

MC: We want ARIA to be more than just a patch, rather a more complete solution
... Do we want to try to take over the world approach
... I think if we decide that we want to be the accessibility solution, then we want to have a unified brand, including IndieUI
... Attempts to take over the world are more aspirational, it often does always turn out that way, so JC approach then makes more sense
... This is an orientation question, and will make a difference on how we market it

RS: What is going to insure that we have uptake
... At IBM it took a lot to educate people at IBM, but now it is not a second class citizen
... If it is more strategic ..., our mobile people..., the whole lines blur, a noisy room I need captions
... It is part of an education issue, if it goes into I don't care, I would like to see that it is not limited to just HTML
... We need it for SVG interaction

JC: It should work fine with SVG

<Zakim> jamesn, you wanted to say that some polyfills for this would really help convince people of its utility

JN: If we can get developer using it

RS: IBM would use it
... But we got to get people moving on this
... We can very easily use it in authoring practices
... At least you are describing what it does

JS: I tried to talk to CMN about it

JC: We might need to move it out of WAI

<davidb> i want IndieUI

CS: So I have some concerns about IndieUI, how does it interact with ARIA
... People ask why is ARIA one way

JC: All of the plateforms work in their own way
... We have actions and AXIncrement .....

CS: One of the concerns with IndieUI, we have aria is one way and then we add this other thing that is not ARIA, I would like to complete aria 2.0 first
... I am not sure how IndiUI gives us the other half ARIA

JC: I think it is the other half of ARIA, but it's more than that; it's making interaction patterns easier to implement for everyone.

<joanie> cyns: ^^

JC: People are excited about the new HTML 5 controls like date picker

JS: it we are a joint group with with WebApps

<Zakim> ShaneM, you wanted to say that, while I don't think I can actually speak from here, I want to say that if we just imagine that "accessible" means "making the web semantically

<cyns> http://msdn.microsoft.com/en-us/library/windows/desktop/ee671594(v=vs.85).aspx

CS: We have to make our apps accessible for the government, and we need the other half of ARIA

JC: reading Shane's comment

DM: I was on the WCAG group and now I am really busy since it is part of the law
... I can't keep up with demand

RS: we can address this with WCAG techniques

JC: Can be in authoring practices

RS: Your platform will need a keyboard way to make it accessible

<Zakim> MichaelC, you wanted to say the WAI strategy in the past was spec review - are we revisiting that?

MC: I have a meta question
... In the past we have used spec review to coordinate accessibility, now we are talking about making new technologies, is this direction we want to go

RS: I am not following

MC: Do we want work with other groups on integrating accessibility into other specs, or create new technologies

RS: What we are talking to taking events to a higher level
... discuss of a previous spec ....
... You can have people part of other working groups, to make sure accessibility is addressed
... we are hitting on something very sensitive, but if we can make them think it is their idea
... We are not throwing it over the wall....

JS: We are out of time

CS: I don't think we need to make a choice about working with other groups or making new specs

<janina_> 1~ack c

MC: I just want us to be aware

JC: I ARIA will be two way, this a proposal, if you have something else lets see something in proposal form

CS: Thats reasonable

JS: TOPIC: Timeline

Timelines

MC: Primarily the 1.1 timeline
... we have decided to take ARIA 1.1 the middle of next year for last call, and then track HTML 5.1 for recommendation

JC: It will take me a couple of months to get all of these actions processed
... There maybe a couple of things that would push them out

MC: Will there be issues what will take extended discussion?

DB: Unkown

MK: The sooner we get some thing in draft form will help understand how much time for consensus

MC: That could fill up a year of meetings

JC: We should probably try to get the meetings more efficient
... We tend to use a 90 minute meeting *every week*, to get ~60 minutes of work done *every month*

MK: It would be important to identify the most difficult issues and set deadlines on resolving them

MC: We can adopt meeting strategies, we need to get people to get their actions done

CS: Can we move the meeting time?

JC: It he doesn't need to be there, I would like to move the meeting times
... Can we ping Stephan to see if he cares if we move the meeting

CS: 8:00 does not for me

MC: Lets do a conference call time
... I feel a couple strong desires to move the call

RS: I have a lot of international calls, I would like to do it ion the afternoons

<Zakim> cyns, you wanted to say that our mission is to create the accessibility layer, ARIA is incomplete and we need to finish it and to say "both/and"

MC: ARIA 2.0 timeline, CS is ahead of me

CS: Thats old

<Zakim> MichaelC, you wanted to talk ARIA 2 timeline also

MC: Suunds like 1.1 is achievable
... We have been talking about ARIA 2.0 in parallel, and it is the same people

CS: Modularization helps, since they can be sub groups
... I might be able to work on other things
... Modular calls can be a different times

MC: When do we want to start real work?

JS: ePub is starting monday

RS: We need test cases and testing

CS: Graphics modules would have different peopele

<Zakim> jcraig, you wanted to talk about ARIA 2.0 doc format

MC: Start on the modules be defer on how they will be integrated later

JC: the document format requirements, it is in paragraphs and prose, if we changes the document format, we can make it easier for developers
... Javscript interface with examples
... 4 pages of paragraphs, we need to turn it into algorithms and ....

MC: I think we need some editorial proposals

RS: I don't want it to be like HTML 5

MC: We need to be strict on timelines

- DRAFT -

ARIA FtF Day 3

25 Jan 2014

Attendees

Contents