See also: IRC log
<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
<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
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>.
<Zakim> ShaneM, you wanted to talk about scoped behavior of tabindex
<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
+1
<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
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
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
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
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/jaina/janina/ Succeeded: s/scribe: Rich/scribe: richardschwerdtfeger/ Succeeded: s/agenda?/topic: Is ARIA only for AAPIs (and ATs)?/ Succeeded: s/some are using aria=/some are using aria-label=/ Succeeded: s/In the expando case that is still not semantics/In the expando case that is still just semantics/ Succeeded: s/password fields I have had huge headaches with/password fields I have had huge headaches with anti-spyware instantiating our a11y engine/ Succeeded: s/Going back to the mind of the cognitive side/ Going back to cognitive, the mind of the web developer/ Succeeded: s/managed widget/managed focus widget/ Succeeded: s/my only compliant/my only complaint/ Succeeded: s/late./later/ Succeeded: s/proposla/proposal/ Succeeded: s/JS/JC/ Succeeded: s/I think it is the other half of ARIA/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./ Succeeded: s/We tend to use a 90 minute meeting to get 60 minutes of work done/We tend to use a 90 minute meeting *every week*, to get ~60 minutes of work done *every month*/ Succeeded: s/close issue-603/scribe: jongunderson/ Found Scribe: richardschwerdtfeger Inferring ScribeNick: richardschwerdtfeger Found ScribeNick: clown Found Scribe: richardschwerdtfeger Found ScribeNick: clown Found Scribe: richardschwerdtfeger Inferring ScribeNick: richardschwerdtfeger Found ScribeNick: davidb Found ScribeNick: davidb Found Scribe: rich Found Scribe: richardschwerdtfeger Inferring ScribeNick: richardschwerdtfeger Found Scribe: jamesn Inferring ScribeNick: jamesn Found ScribeNick: clown Found Scribe: jongunderson Inferring ScribeNick: jongunderson Scribes: richardschwerdtfeger, rich, jamesn, jongunderson ScribeNicks: richardschwerdtfeger, clown, davidb, jamesn, jongunderson Default Present: Matt_King, Shane_McCarron, Rich_Schwerdtfeger, David_Bolter, Bryan_Garaventa, Joseph_Scheuhammer, Joanie_Diggs, James_Nurthen, Mark_Sadecki, Michael_Cooper, David_MacDonald, Cynthia_Shelly, Jon_Gunderson, James_Craig Present: Matt_King Shane_McCarron Rich_Schwerdtfeger David_Bolter Bryan_Garaventa Joseph_Scheuhammer Joanie_Diggs James_Nurthen Mark_Sadecki Michael_Cooper David_MacDonald Cynthia_Shelly Jon_Gunderson James_Craig Agenda: http://www.w3.org/WAI/PF/meetings/2014-01-ftf#agenda Got date from IRC log name: 25 Jan 2014 Guessing minutes URL: http://www.w3.org/2014/01/25-aria-minutes.html People with action items: jamesn jcraig king matt WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]