Protocols and Formats Working Group Teleconference -- 23 Jan 2014

<trackbot> Date: 23 January 2014

<richardschwerdtfeger> meeting: W3C WAI-PF ARIA Face to Face

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

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

<richardschwerdtfeger> Current Agenda: http://www.w3.org/WAI/PF/meetings/2014-01-ftf#agenda

<ShaneM> ScribeNick: ShaneM

richardschwerdtfeger: ePub... while it has structural semantics, it is not something that would be used in SVG. If we had modules we would put that stuff in its own module.

ePub readers are based upon browser technology today. But there will be other technologies in the future.

scribe: SVG has other issues. drawing semantics for charts. ARIA things there might fit into HTML5, but it is still independent of core ARIA.

<LisaSeeman_> ping

scribe: We had an OWL-based taxonomy.

cyns: we should not modularize too far.

jamesc: we don't want to get so far we end up with XHTML 2.0 structure.

cyns: when there are separate schedules things can get too disparate. I like how HTML5 does it where most modules are on the same cycle.

<richardschwerdtfeger> ack

LisaSeeman_: Back at the beginning when we were making the OWL taxonomy there was one person doing it (me). It worked because there was one person and it had integrity.
... if there are modules it should still be one person who is responsible for the taxonomy because then it will stay internally consistent.
... We had originally planned to make it extensible and machine interpretable.
... If we did make it extensible now then the core taxonomy could be the building blocks for modules.
... ARIA 1.1 should be very simple and we should do it urgently. Anything we can't do right away or is not *simple* we should do in 2.0

MichaelC: I agree that 1.1 should be simple and urgent.
... as far as I have seen the taxonomy is useful for us in designing ARIA. It is not use by user agents as far as I know.
... We should keep the taxonomy. The spec refers to it often. But it makes it harder for people to consume the ARIA spec.

<Zakim> MichaelC, you wanted to say the taxonomy is very helpful for us to architect, but not meaningful to outsiders

MichaelC: This is opposite of what LisaSeeman_ was suggesting. I think there should be a different mechanism for extensibility.

<cyns> +1 ro MichaelC

richardschwerdtfeger: I would like to continue to use it as a design tool. It helped a lot.
... it helped when we were cleaning up the semantics in ARIA 1.0

<Zakim> jcraig, you wanted to clarify Janina's "ARIA outside web content" item, and to list my additional agenda items for ARIA 1.1 and 2.0

jcraig: When we talk about using ARIA outside, did Janina mean outside of browser?

janina: yes - we might want to consider that.

jcraig: I don't agree. We should call it something else if we are doing that. ARIA is about markup enhancement and it reflects an API for the platform.
... if we try to force people to use ARIA as the base API for the whole system, I think we would fail.

janina: I was really talking about messaging. There might be benefits to ATs if ARIA worked beyond the browser. It is outside of our scope.
... I hear that ARIA is going to go away because it is fixing yesterdays broken stuff. That's a bad message.

jcraig: Yes. ARIA is not going away. HTML doesn't do half of what is needed. ARIA does help retrofit HTML and bad implementations thereof.
... Additional agenda items: more roles and elements that currently cannot have roles. Might be solved with a 'roledescription' attribute.
... keyboard support. not necessarily all of it. and certainly not in 1.1.
... indieUI is trying to solve part of the keyboard problem.
... example: role='button' on a div does not necessarily trigger keyboard access even if an AT might treat it as a button.

cyns: IE does this in some cases

jcraig: And because IE does it some people think that you don't need to handle keypress events on such a div

<davidb> if we are discussing aria prescribing browser driven keyboard ux i'd like to add some caution

jcraig: ARIA 2.0: if we do modules, then a roles module would be nice. it would be nice if liveregions were addressed. the rich text editing API.

<Mark> agrees with davidb on the keyboard issue

jcraig: An API based approach for RTE would be good for custom views. Would be nice if there were ways to specify that there is a JS object that handles A11Y for a region.

<Zakim> MichaelC, you wanted to say we can design the taxonomy with hooks / stubs that support modules being attached and to ask about ARIA as the ¨Web AAPI interface¨ and to say let´s

<LisaSeeman_> I can not hear well

<jcraig> My list so far:

<jcraig> # ARIA F2F

<jcraig> ## ARIA 1.1

<jcraig> - More roles (including generics) for 1:1 mappings to host langs

<jcraig> - SVG: chart, line, relationship

<jcraig> - HTML: para,

<jcraig> - EPUB: section

<jcraig> - Generic Elements: html:div, html:span, svg:g

<jcraig> - @aria-roledescription may solve some of this. E.g. EPUB chapter could be a "region" with a role description of "chapter"

<jcraig> - Keyboard Support

<jcraig> - HTML 5 Commands (Making keypress work automatically on divs)

<jcraig> - rest partially tied IndieUI

<jcraig> ## ARIA 2.0

<jcraig> - Module-based approach (like CSSWG)

<jcraig> - Fixing live regions

<jcraig> - RTE API

<jcraig> - focus proxy

<jcraig> - API-based approach for custom views

<jcraig> - IndieUI Events and Test Creation

MichaelC: The ARIA taxonomy can be designed such that there are stubs that could be the basis for modules.
... before we get into 1.1 and 2.0 we need to address the high level issue of whether we should modularize or not.
... and we need to address the question of whether ARIA is a 'patching technology'. I think 1.1 is supposed to be a patch.
... should ARIA become the accessible layer of web applications? do we need a mapping of every feature of every technology?
... This would be a major design decision for the web in general. We need to make a conscious decision about this.

cyns: Native Platform APIs. There is not a complete overlap between ARIA and platform APIs today.
... jcraig, you mentioned a role description. Microsoft has something like that with localizable control name. jcraig says AX API has "AXRoleDescription".
... this is a good example of where there are platform APIs that could help drive what is in ARIA and help structure the implementation guide.

richardschwerdtfeger: We should do something like roledescription for 1.1. a "sub role".

cyns: We already have something like it in UIA. And it is an example of the class of things that might exist in platforms that we could push back into the ARIA layer.
... I understand that there are people who think ARIA is there to patch HTML. I encourage people to use HTML when they can. The relationship between ARIA and HTML is hard to explain to developers.
... If ARIA *was* a patching technology, it isn't any longer.

jcraig: even the best rendering engine is behind where developers need it to be. They need a way to make custom controls.

cyns: Developers feel like they need complete control. And we can't change that.

<Zakim> jamesn, you wanted to say we need to change this. In TF force work on WCAG aria techniques we keep on hearing - ARIA is a repair technique so we shouldn't have an ARIA technique

jamesn: One of the reasons we have to change this is that our guides say use HTML. We say that ARIA is a patching technology.
... we need a consistent message.

cyns: We should still say that people should use standard controls.

General agreement.

MichaelC: We should make a formal decision about whether ARIA is a bridging technology or not.

cyns: We should still say that basic controls are preferred. When that fails ARIA is a solution.

richardschwerdtfeger: At IBM we see ARIA as the mainstream way of developing controls. No one wants to use the native HTML5 stuff.

cyns: Yes.

(anecdotal evidence that native controls are unused)

<Zakim> jcraig, you wanted to bring us back to agenda planning

bgaraventa1979: It would be way too hard to get people to stop using ARIA as the main way of developing interfaces today.

LisaSeeman_: ARIA 2 should help facilitate extensibility
... where that means ensuring that ARIA like things could be used in extended XML schema and AT would magically just know how to handle those extensions because it is based upon the core taxonomy.
... I would prefer that we look into 2.0 for 1.1 division first because that may drive our discussion.

richardschwerdtfeger: First, lisa, if there are going to be extensions then we need a strategy for it. Otherwise it will become an academic exercise.
... The name "indieUI" is not great. Why are we not just calling it "ARIA Events"?

jcraig: indieUI is not specific to ARIA. This should be a separate agenda item.

<Zakim> MichaelC, you wanted to tie in earlier discussion of ARIA as patch or whole solution http://www.w3.org/2011/01/baking-aria and to say my personal opinion is extensibility in 2.0

mattking: Two topics. Discussion of patching/bridging vs. holistic. And I am curious about how we are going to decide what is in 1.1.
... Issue 633 is about how roles are being misused. We don't have a way to create lists that have their own selection model. This is really common in applications and we don't have a way to specify them.

<jamesn> ISSUE-633?

<trackbot> ISSUE-633 -- listbox and tree may contain only static items; badly need interactive widgets that can contain interactive typed items -- raised

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

jcraig: Why does list not work?

<Zakim> jamesn, you wanted to say that matt's treeview and listview issues also tie into my keyboard issues....

mattking: because lists are static. and listbox can only have static options inside of it. You can't have a list of links, for example.
... for something like simple site navigation there is no way to do it with the current roles.

<jcraig> ISSUE-633?

<trackbot> ISSUE-633 -- listbox and tree may contain only static items; badly need interactive widgets that can contain interactive typed items -- raised

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

mattking: when can we get this on the agenda? Some needs are 2013 needs. Not 2015 needs.
... Is ARIA complete? It seems like ARIA has always had semantics that overlap with core HTML.

<Zakim> davidb, you wanted to talk about web developers

davidb: ARIA is way too complicated. We need to make sure that web developers are thought of first.

<jcraig> +1 +1 +1

<cyns> +1

davidb: we need to optimize for them so that they can succeed, even by accident.
... We have often tried to ensure that A11Y is baked in. In the web space I want it to be HTML. I don't want to have to tell people that they need to do something extra for A11Y for the easy things.
... Remember - KISS. Keep It Simple, Stupid.
... We need to be careful with names. We don't need to cloud the namespace.

cyns: This comes down to the discussion of whether ARIA is bridging technology or not?

<LisaSeeman_> Are we discussing this yet?

<LisaSeeman_> or are we setting the agenda?

davidb: Do we want ARIA to start meddling with the core semantics? A11Y should be accidental for the majority of the cases.

joseph: the reason this worked in dojo is because we made it work.

davidb: If ARIA becomes the driver then it needs a different name.

cyns: MS and IE are way down the path of making ARIA core, but a bridge.

davidb: Then ARIA should not be something where adding an aria attribute breaks the core behavior.

cyns: we need to keep in mind that anything we do in ARIA should not break core functionality.

<davidb> to be clear, I like the idea of there being a mechanism to do the keyboard ui for the developer I just still have concerns if that should be in the mental "aria-" namespace

<jongunderson> ScribeNick: jongunderson

David MacDonald introduces himself

<Zakim> MichaelC, you wanted to tie in earlier discussion of ARIA as patch or whole solution http://www.w3.org/2011/01/baking-aria and to say my personal opinion is extensibility in 2.0

MC: One of the things I wanted to tie in was weather ARIA is a patching technology or a standalone technology
... We need to decide which direction we will go with ARIA at some point
... ARIA 2.0 could be an extensible technology, not sure if the RDF taxonomy will be the technology for extensibility, even though it is useful for the design of ARIA
... Timeline has ARIA 1.1 in about a year
... HTML5 timeline has been extended
... If we want to meet the timeline we need to constrain ourselves to what is achievable
... Extending timelines is a slippery slope and I would discourage extnsions

<Zakim> ShaneM, you wanted to discuss the folly of trying to make markup arbitrarily extensible

Shane: I think it is great to want to support ARIA extensible, the web is not extensible, I am Shane and I am an X xhtml author
... xhtml was a failure for extensions
... If EPub people have extensions that work for them ....
... I would rather us spend our time just making accessibility work

JG: Can we have aria markup to support authors declaring WCAG 2.0 compliance

LS: Link to UI....
... The disadvantage to the UI linking ..., W3C standardize what people are doing, ARIA looks at what new things are doing
... These things come in spurts

<jcraig> drop item 4

LS: As soon as we link it to the UI we loose that
... That measn accessibility will be behind what people are doing

<jcraig> HTML 5 Commands (Making keypress work automatically on focusable elements with click events matching certain roles). jcraig [from jcraig]

LS: People may get a get out jail card
... There a huge cost to moving it, I suggest we do both, there is a type of role like an applied mode, it acts like a predefined widget
... It does mean that is is simpler, but we may lose ....
... Having trouble with computer

<jcraig> q later

CS: I have an opposite view, accessibility is hard, there is also lots of testing on
... I think we should work on platform support, we need to make it easier
... Our key goal is to make it simpler and easier

SJ: Do we see extensibility in the next 3 years?
... If we are going to do extensibility should be on the agenda for the next 3 years

JC: Extensibility means different things to different people

CS: I see role description as a simple extension technique

RS: It is hard to get browsers to get common implementation, but it is getting better

LS: Can respond to CS?
... I agree that it is too hard, I think we can do both, we can have prepackaged roles and extensibility
... If we are doing HTML and you can add it a a tag...

CS: I don't think we loose what we have done so far, we know there are some things missing, we need to tighten it up and make it easier to use

JC: We are still in agenda planning

RS: I would like to get to the chase on this one
... Is ARIA more than a bridging technology?

JC: Lets finish the que

<Zakim> MichaelC, you wanted to say host language bindings can be a different question from featureset - don´t confound them

MC: How does ARIA intersect with the host language
... host language bindings should be a separate question form the ARIA feature set

CS: I think we confounded them with ARAI 1.0

MC: Yes I think we did

MK: I want to respect what JC, I would like to comment on LS
... Keyboard actions to specific roles

JC: It is on the agenda

<Zakim> jcraig, you wanted to order agenda

JC: I am going to read the agenda items

James Craig reads list.....

<MichaelC> agendum 2 = API harmonization? What is the LCD or superset of the platform APIS? At least the necessary parts. [Cyns]

<jcraig> drop item 8

<jcraig> drop item 11

<jcraig> drop item 10

<MichaelC> agendum 5 = ARIA 1.1 additional roles (and possibly something like @aria-roledescription?) e.g., html, svg, epub

LS: I want to add an agenda item
... Discussion of criteria for items in 1.1
... Should ARIA 2.0 should support cognitive
... Do we let the task force make recommendations for 2.0, how do we handle cognitive

<jcraig> drop item 15

RS: HTML5 semantics have a video tag so we want

JS: You can make assertions about accessibility

<jcraig> Red Leader: stay on target

RS: There is a media controller in there...

JS: We should think about JG topic, but not today

JC: Putting click events on button widgets

JS: Is that on our scrub list
... If it is on our scrub list we are on the way

JC: I am not sure it is there

RS: This is the API document mapping stuff

JC: HTML5 ...

MC: the bindings are rules on how ARIA can be used in native languages, strong and weak mappings
... It is a separate from an ARIA feature

J: Host language is good for me

JC: The next item goes with Indie UI discussion

RS: I do want to make sure we cover the implementation guides
... We don't have an implementation guide to HTML 5, I used the current guide to make HTML 5 and SVG semantics

JC: Clarification is part of MC host language and authoring

RS: This is implementation guide
... For example in SVG spec, when do you map something to the accessibility API, a drawing object with no ALT should not be mapped
... Named computation is different in SVG than HTML

JS: It is the organization of the document moving forward

RS: I have a draft of this I would like to discuss

JC: This is different than the modularization discussion?

RS: It would be affected by modularization, it will be how we create sub groups

MK: Is the question is documentation centered on modularization?

RS: Yes

<jcraig> ??P2 is LisaSeeman

JC: Let's discuss with modularization

RS: Can we get going

CS: Is there one we can finish before lunch?

JC: Timelines (14 on agenda)
... ARIA next more than emerging technologies

reordering the agenda items......

<MichaelC> agenda order 14, 1, 17, 5, 16

JS: I am concerned with time for these items

RS: We can combine some items

MK: That was closely related to extensibility

JC: Drop item #12

<MichaelC> drop item 12

JC: There are 50 issues for scrubbing ARIA 1.1 issues

RS: Would like to get the bridging item out of the way

<MichaelC> agenda order 14, 1, 17, 19, 5, 16, 18, 3

JC: Is this a decent order?

RS: We also want to build test suites, we don't want to wait until the end

JC: Should we limit discussion on items

<richardschwerdtfeger> zakum, next item

Timelines for ARIA 1.1 and ARIA 2.0

<MichaelC> Current draft timeline

RS: HTML 5.1 last call is the end of 2016?

JS: No

RS: When is HTML 5.1 suppose to go to last call?
... If they are like everybody else there will be a second last call

JS: I don't think 5.1 will be like 5.0

Mark: 2014 Q3

RS: We are not going to make that date

<ShaneM> http://dev.w3.org/html5/decision-policy/html5-2014-plan.html

<Mark> HTML5.1 Timeline

RS: We have to have our last call at the end of the year
... What was our original plan?

MC: Q1 2015

RS: We don't know what is in HTML 5.1 that will affect us?
... What is there CR date?

JS: Q1 2015

JC: Assuming they go to last call about that date

MC: There maybe being doing changes in last call

JS: 2 year CR

RS: If we build our test cases in parallel we can do a shorter CR

MC: If our test cases are done and tested when we wrap up we can skip CR

RS: We need to have things that they can link to that replicate their host native semantics

MC: That would probably be good

RS: They pointed to the ARIA spec, the only thing left is states, as long as they don't limit our states

JC: What additional states are we thinking about

RS: I am not sure

MK: aria-active or aria-current

RS: We need something for tables, like aria-colspan and aria-rowspan

JC: That would put last call in Q2 2015

RS: That would be OK

JS: With a short or zero CR

JC: I don't think it will be zero

JS: We have the test hareness now

MC: If we want a zero last call when we have all of our implementations
... If we go to last call and do not have all our implementations it will harder

JC: It means we have all our implementations at last call?

MC: We can go to a last call with all our implementations, or we can issue a last call but not done, and kind of plan second last call

RS: I have not seen a group not have a second last call

MC: If we have all our implementations..

CS: If people don't hink the spec is ready

JC: The CSS and Web Apps group both reviewed...

CS: I am thinking more about browser developer and web developers groups
... I think test cases are good

RS: We can probably get the browser manufactures going, but authors are a different story

CS: In reality last call is we think we are done

JS: There is time for a second last calll

MC: DO we want to be in sync with HTML 5.1, do we wait for them to go to rec

RS: I don't think we decide that now

CS: The HTML 5.1 has got there act together, they are cutting features

MC: There is a lot of pressure to have accurate timelines
... Defensible to wait until HTML 5.1 is wait

RS: Q3 is reasonable

MC: I am comfortable with that

Decide whether ARIA.Next is more than a bridging technology MichaelC

RS: Does anyone disagree it is not a bridging technology?

DB: Can you not use the work bridging

RS: It is not waiting for host language semantics

JC: AUthors want to create custom controls

CS: Its purpose has evolved
... When you say it is a bridging technology it is waiting for something else, I don't believe that now

RS: ARIA now makes it possible to communicate accessibility information
... The reality is that many authors will alsway make custom controls

<jcraig> ?

CS: We still want accessibility in native host languages, but developers will still go around the host lanagueg

<Zakim> jcraig, you wanted to mention svg2 and to mention missing HTML controls that are still missing, like data grids

DB: I stumbled on bridge, there will always be a gap

JC: It is not just HTML centric, it is used in SVG, SVG decided to use aria as their accessibility

DB: There are some semantics in SVG

JC: They are very incomplete semantics

DB: It is too simple to say in SVG that there is no mappings without ARIA

RS: There are performance issues
... In webkit they said if you do this you get this

JC: In HTML there are missing data grids
... There will always be something else
... There maybe a grid in HTML, but never in SVG

David: I was working with a company who wanted to have a different look and feel

JC: AT least with buttons you can do that

David: They really wanted to do something different and it looked great

CS: I think we wand CSS based controls that look different with graphical designers

JC: Maybe WAI needs to educate developers, what are the elements that can't be customized with CSS

CS: PF needs to work on some of these issues with CSS

<Zakim> Joseph_Scheuhammer, you wanted to point out cross-platform nature of aria.

Joseph: A lot of accessibility APIs, there is one DOM spec, for accessibility there are many APIs
... ARIA covers all these APIS, it is the accessibility API for the web

CS: We are using them to build quasi desktop apps run through the browser

Shane: ChromeOS is an example of web apps

JS: Anyone speak against?

DB: Back to ARIA being the accessibility API for the web, I agree with that, we still have the desktop
... I can expose an HTML button to an accessibility API, but ARIA button is not there...

<davidb> I meant ARIA is not there

CS: If you are in the DOM the button element is different from the div with role=button

DB: DO we want the DOM to make them look the same?
... If there is an API standard, what is the role of this thing

JS: We seem to be going that direction

JC: This is why we need to have a 1:1 mapping for every host language semantic

<davidb> exactly james just said "getComputedRole" which captures the nuance here

JC: For any element get its computed role, so we need that for every element, including elements like script elements
... I would like to have a read only label attribute for a form control

MK: If we are talking about making the ROLE mapping ....

JC: There is a concept of reflective roles....., a little off topic
... States can be returned from the DOM

JS: I think we are at lunch

<Zakim> jcraig, you wanted to action someone to remove the "bridging tech" language

JC: We need an action

MC: I do want to speak pros and cons

RS: I think we can remove the "bridging"....

JS: I think we are also in consensus

RS: Did you remove?

MC: Maybe the action got moved to 1.1

<jcraig> no action in 1.1 either

<LisaSeeman> P2 is Lisa

<jcraig> ACTION: jamesn to track down references to ~"bridging technology" or other less-desirable language; action each editor to remove/rephrase. [recorded in http://www.w3.org/2014/01/23-aria-minutes.html#action01]

<trackbot> Created ACTION-1328 - Track down references to ~"bridging technology" or other less-desirable language; action each editor to remove/rephrase. [on James Nurthen - due 2014-01-30].

<LisaSeeman> r u back?

<mattking> YES

<mattking> sounds like conf room still muted

<mattking> Michael, do not forget the telephone is muted

<LisaSeeman> can u unumte

<clown> http://www.w3.org/WAI/PF/aria/introduction#co-evolution

<clown> ^ where the "bridging" wording is (the above url).

<richardschwerdtfeger> Current bridging statement in ARIA spec: http://www.w3.org/WAI/PF/aria/introduction#co-evolution

<richardschwerdtfeger> public statement on bridging: http://www.w3.org/TR/wai-aria/introduction#co-evolution

<mattking> +1 on 1.1

<clown> first sentence, section clause of the above url.

<jnurthen> +1

<jcraig> ACTION: jcraig to clarify the "bridging" language in #co-evolution to make it clear that ARIA is not a stop-gap technology. It will always be relevant SVG, and it will remain relevant for HTML as long as web developers have *any* reason to not use the native control, including the use to retrofit existing sites or frameworks without completely gutting the implementation. [recorded in http://www.w3.org/2014/01/23-aria-minutes.html#action02]

<trackbot> Created ACTION-1329 - Clarify the "bridging" language in #co-evolution to make it clear that aria is not a stop-gap technology. it will always be relevant svg, and it will remain relevant for html as long as web developers have *any* reason to not use the native control, including the use to retrofit existing sites or frameworks without completely gutting the implementation. [on James Craig - due 2014-01-30].

<LisaSeeman> lisa: a retrofited site can use aria even if you could do it in native syntax

<jcraig> action-1329?

<trackbot> action-1329 -- James Craig to Clarify the "bridging" language in #co-evolution to make it clear that aria is not a stop-gap technology. it will always be relevant svg, and it will remain relevant for html as long as web developers have *any* reason to not use the native control, including the use to retrofit existing sites or frameworks without completely gutting the implementation. -- due 2014-01-30 -- OPEN

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

<LisaSeeman> lisa: also bad news when people do HTML hacks (like ofscreen text\0 instied of html

<LisaSeeman> Lisa: much better to do it in aria

<richardschwerdtfeger> ACTION: Cynthia meet EO to provide guidance on when and when not to use WAI-ARIA [recorded in http://www.w3.org/2014/01/23-aria-minutes.html#action03]

<trackbot> Created ACTION-1330 - Meet eo to provide guidance on when and when not to use wai-aria [on Cynthia Shelly - due 2014-01-30].

<Mark> scribe: Mark

MC: Just to put this into pros and cons
...pro: create a giant mapping between aapi's and aria. identify gaps
...con: if we say its the a11y solution of the future, other groups will ignore a11y, including those that ARIA doesn't touch
... the aria- prefix "ghettoizes" accessibility
... imposing on ourselves to keep aria up to date as new technologies emerge

<jcraig> jcraig to respond to Michael's points
...con: are there implementation costs to having ARIA supported everywhere
... we need to be comfortable with these risks if we take this approach

<davidb> what a terrible time for me to have to step away

<Zakim> cyns, you wanted to say that being the accessibility api layer of the web doesn't mean that other technologies don't need to do anything, just that they need to implement that API

CS: agree that some of these things are risks. having an universal AAPI doesn't mean others are off the hook.

MC: that is a messaging challenge, ok

CS: as far as implementation costs, it shouldn't be an extra cost.

ach richardschwerdtfeger

RS: implementers want to have one point of reference.
... value of ARIA is that it can create a single vocabulary
... had convo with AWK who asked me if we can ditch ALT
... its not like flipping a switch

<mattking> Do we need a resolution proposal like the following?

<mattking> Starting with with ARIA 1.1, shape specification contents and language to position ARIA is a comprehensive and uniform approach to specifying accessibility semantics in native host language elements, customized elements of host language elements, and ......

<mattking> Note: this does not take host languages off the hook.

<Zakim> jcraig, you wanted to respond to Michael's points

JC: setting up an API that works for every aspect of the web, doesn't mean that everyone else is off the hook for a11y.
... in the case of HTML, there is base functionality that, because the provide functionality, have to provide a11y
... aria 1.0 is not really the "Accessibility API for the Web", because the current iteration is only for the "markup of the Web." Among other things, we need to have a scriptable interface for things like WebGL that have no markup base.

CS: not convinced scriptable interface is the way to go, but willing to have that convo

MC: I just wanted to be sure we thought it through
... simply resolution is that ARIA should be a complete technology

CS: wanted to point out that ARIA is not really an API

MC: important to know what we're all talking about. can come back and wordsmith later

<richardschwerdtfeger> *richardschwerdtfeger Goal is to have ARIA be the base, cross markup, accessibility layer for the web

<richardschwerdtfeger> *richardschwerdtfeger Goal is to have ARIA be the base accessibility layer for the web

<clown> replace "cross markup" with "cross platform"?

<jcraig> no need, because the web is already cross-platform

<richardschwerdtfeger> RESOLUTION: The intention of the group is for WAI-ARIA to become the base accessibility layer for the Web

host language binding

RS: I want the "bridging" text out of ARIA 1.0

MC: need to do that for Monday

JC: I can do that

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

host language binding

MC: We have a section in ARIA a section on how ARIA interacts with host language semantics. We say that host languages can say where ARIA is allowed to override their native semantics or not.
... I feel like we got into the weeds when doing this for HTML
... Need to be clear that the ARIA features are the ARIA features.
... in ARIA we will need a feature for emphasis. What the feature looks like shouldn't be caught up in what HTML supports
... i.e. the strong tag should not be reclassified based on a limitation imposed by HTML's definition
... jsut want to say that host language bindings for ARIA should be separate from host language features.
... could be done with separate specs or separate sections of the spec.

JC: 1:1 mapping with HTML would effectively double our roles. would be easier to test, but there is an aspect that means that it would be too big of a challenge for 1.1
... so there would be some unknown or unmapped roles

RS: would this be done in web apps, in some scripting part of ARIA

CS: implementation guide maybe?

MC: one of the ways we want to slice ARIA is to have roles in one place and anything else in some other place; mappings to host languages, AAPI's, etc
... won't have the list of roles in 1.1.

CS: the issue of text runs is a separate issue

MC: for 1.1 we would say, "no ARIA mapping" in that case
... in 2.0 we come in and fill in the blanks
... don't object to considering the issue, just not committing to getting it done in 1.1

<Zakim> jcraig, you wanted to mention WebIDL: partial interface Element { readonly attribute role; attribute OrderedDOMTokenList roleList; }

JC: could use this to create extensions to the DOM

RS: SVG WG is aligning itself with the HTML DOM which has been moved to HTML WG. We can get these features implemented there

-> http://www.w3.org/TR/dom/ DOM4

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

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

<jcraig> issue-398?

<trackbot> issue-398 -- Errata: aria-setsize and aria-posinset should apply to more than just listitem and option -- open

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

<jcraig> issue-411

<trackbot> issue-411 -- Consider aria-description which would take a string like aria-label -- open

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

<LisaSeeman> If there is anything that uyou need me for we should do it today (I can not be there tomorow)

JC: this is what aria-label is to aria-labelled by for aria-describedby

<bgaraventa1979> aria-describedby associates header cells on ARIA grids as well

JC: if we add 4 ways to add descriptions, it gets complicated for developers to know which to use and when

DM: the biggest error with longdesc is when people but a long description directly in the attribute value

JN: i find it strange that we don't have the equivalent to aria-label

CS: we had a scenario where this came up. The button said "allow" and text that informed what they were "allowing". Didn't work in any browser

MK: think describedby is the better solution for that

LS: anything that gets rid of people positioning text off the screen is good with me

MK: this process is to decide what is in the 1.1 queue or not
... ISSUE-411 is frequently brought up, but there is no simple solution. should be pushed out.

JN: it would be easy to implement

<Zakim> jcraig, you wanted to consider with ISSUE-406 and to ask Cyns if there is a Windows platform API equivalent of something like aria-help (ISSUE-406) or aria-description (ISSUE-411)

JC: this is not as easy as people think.

RS: agreed

JS: this is 2.0

MK: agreed

JC: this should be coupled with aria-help. on mac, it acts as a fallback, like title

<ShaneM> issue-406?

<trackbot> issue-406 -- Proposal for new aria-help property. -- raised

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

JD: I have a lot of different problems with the hacks that are currently being used to solve this problem.

RS: if you hide content, you don't have access to the semantics

JD: not all Screen readers have an off screen model
... we don't want to encourage content creators to put stuff off screen or to hide content.
... these issues are connected, because there are no other solution combinations for this problem

JC: aria-hidden= false is a way to hide content visually, but not from screen readers

RS: and this is in the DOM

<jcraig> but neither is important enough for ARIA 1.1

JC: aria-help would solve these issues. Maybe we should aim for that instead (this is all in ISSUE-406)

-> https://www.w3.org/WAI/PF/Group/track/issues/406 ISSUE-406

scribe: this should be the same mechanism as tooltip

CS: wouldn't this impact description calculation

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

MK: is there a possibility that we could give one precedence and worry about the calculation in 2.0

<Zakim> Joseph_Scheuhammer, you wanted to ask how does this fit with the tootip role?

<clown> issue-398?

<trackbot> issue-398 -- Errata: aria-setsize and aria-posinset should apply to more than just listitem and option -- open

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

JC: cyns to determine the best place to map these in MSAA UIA

CS: not sure how it would work
... if we do this, we need test files early. best bet at getting implementations

RS: we need to consider a column role

CS: there is a lot of work for tables.

JC: grids don't work well because the data is not programatically accessible. We don't have that because ARIA is declarative.

CS: I submit that ARIA table should be in 2.0 but that we start working on it now

JN: i don't want to punt this, but if it has to go to 2.0, it has to go

<jcraig> Punt ISSUE-398 to ARIA 2.0

ISSUE-435

<trackbot> ISSUE-435 -- Consider role="text" to expose elements (and contents) as static text node -- open

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

JC: this one is easy

RS: agreed, lets keep it

<clown> Example: My <img src="heart.png" alt="heart" role="text"> breaks

ISSUE-436

<trackbot> ISSUE-436 -- Consider role="disclosure" to match semantics of desktop API disclosure triangles, or other show/hide widgets -- open

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

RS: we cannot ignore this. we have it in HTML5

ISSUE-446

<trackbot> ISSUE-446 -- proposing new switch role (subclass of checkbox) that represents an on/off state -- open

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

JC: this is a switch that maps to an on or off state, checkbox
... visual design distinction not defined in ARIA
... there is a semantic difference here. its not checked or unchecked, its more like on or off

JG: what is its state?

keeping 446 in 1.1

ISSUE-468

<trackbot> ISSUE-468 -- Create ARIA role for figure or other image groups (including SVG) -- open

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

RS: we have role=image. why do we need this for figure

JC: figure can contain a chart and a caption.

JN: its a group

MK: you can label groups.

JC: figure is already mapped to group. all of the pieces of that figure are mapped to image, text, etc.

agree to push ISSUE-468 to 2.0

ISSUE-472

<trackbot> ISSUE-472 -- Provide an attribute for a poster description -- open

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

JS: we need this in 1.1

RS: if we had a video role, we could do this.

JC: not important enough to address outside of the video role

CS: i think html should deal with this, its their bug

RS: they said its not their issue

DM: what if WCAG takes an action to address this with a technique

<scribe> ACTION: dmd to write a WCAG technique that address the description for the poster of an HTML5 video [recorded in http://www.w3.org/2014/01/23-aria-minutes.html#action04]

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

<jcraig> ACTION: David_MacDonald to create a WCAG technique for poster description [recorded in http://www.w3.org/2014/01/23-aria-minutes.html#action05]

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

RS: HTML5 wants us to have host language semantics and we don't have that for the video element

JC: the only way to implement this now is as a subrole of group
... most of these controls are handled in the shadow dom on most platforms. has to be a group
... lets create a new issue for considering role of video in ARIA 1.1
... we should consider an audio role as well

<jcraig> ISSUE: video and audio roles (simple groups, not full functionality APIs)

<trackbot> Created ISSUE-634 - Video and audio roles (simple groups, not full functionality apis). Please complete additional details at <https://www.w3.org/WAI/PF/Group/track/issues/634/edit>.

<jcraig> ACTION: JamesN to create a WCAG technique for poster description [recorded in http://www.w3.org/2014/01/23-aria-minutes.html#action06]

<trackbot> Created ACTION-1331 - Create a wcag technique for poster description [on James Nurthen - due 2014-01-30].

<clown> -13 C here;

<clown> windchill −20 C

<clown> 23 C in the room...

<MichaelC> trackbot, associate action-1331 with issue-472

<trackbot> action-1331 (Create a wcag technique for poster description) associated with issue-472.

<jcraig> Issue-482?

<trackbot> Issue-482 -- Normative reference to status role in status definition must be removed due to redundancy -- open

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

<jnurthen> scribe: jnurthen

matt: seems editorial in that it doesn't change the meaning

jc: taking a look at it

<jcraig> http://www.w3.org/WAI/PF/aria/complete#status

jc: it is redundant to say that authors must include status in status

<jcraig> ACTION: jcraig to <change> [recorded in http://www.w3.org/2014/01/23-aria-minutes.html#action07]

<trackbot> Created ACTION-1332 - <change> [on James Craig - due 2014-01-30].

<jcraig> Authors MUST provide status information content within an an element with role="status". Authors SHOULD ensure this object does not receive focus.

<jcraig> </change><to>Authors SHOULD ensure this object with role="status" does not receive focus.</to>

<jcraig> action-1332

<trackbot> action-1332 -- James Craig to <change> -- due 2014-01-30 -- OPEN

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

shane: the link you just gave is to an editors draft. The CR draft doesn't say any of this

<ShaneM> http://www.w3.org/TR/wai-aria/complete#status

JC: changed status object to element with role status but didnt remove the redundant requirement

ISSUE-483?

<trackbot> ISSUE-483 -- Modify toolbar role to include aria-labelledby as an acceptable authoring mechanism for labeling when more than one toolbar is provided. -- open

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

jc: seems editorial

js: this is from the errata list

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

<jcraig> ACTION: jcraig to "aria-label" to "label" in #toolbar "Authors MUST supply an aria-label property on each toolbar when the application contains more than one toolbar." [recorded in http://www.w3.org/2014/01/23-aria-minutes.html#action08]

<trackbot> Created ACTION-1333 - "aria-label" to "label" in #toolbar "authors must supply an aria-label property on each toolbar when the application contains more than one toolbar." [on James Craig - due 2014-01-30].

MC: had to work around author musts in the implementation report

rs: should review the author musts

<jcraig> ACTION: jcraig to complete edit from ISSUE-485 [recorded in http://www.w3.org/2014/01/23-aria-minutes.html#action09]

<trackbot> Created ACTION-1334 - Complete edit from issue-485 [on James Craig - due 2014-01-30].

ISSUE-493?

<trackbot> ISSUE-493 -- When states and properties are required, authors must provide a value; but the explicit value of "undefined" is not prohibited and should be -- open

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

jc: can take an action to add to a section

<jcraig> http://www.w3.org/WAI/PF/aria/complete#requiredState

jc: change to explicitly disallow empty or undefined

<jcraig> Content authors MUST provide values for required states and properties.

jc: shouldn't close the issue

rs: aria-checked="undefined" on a radio button was an issue

jc: we have explicitly allowed the string value of undefined to mean nothing
... I think that is ok as we have the case where role="checkbox" where undefined equates to false
... leave the issue open for now

ISSUE-494?

<trackbot> ISSUE-494 -- Is menu really a form control (since it inherits from select) or should it be treated as something different? -- open

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

<jcraig> ACTION: jcraig to propose edit for ISSUE-493 to explicitly disallow strings matching "" or "undefined" in this sentence: Content authors MUST provide values for required states and properties. [recorded in http://www.w3.org/2014/01/23-aria-minutes.html#action10]

<trackbot> Created ACTION-1335 - Propose edit for issue-493 to explicitly disallow strings matching "" or "undefined" in this sentence: content authors must provide values for required states and properties. [on James Craig - due 2014-01-30].

mc: why is menu a form control?

rs: it is interactive

jc: do we need to resolve in 1.1?

mc: not causing harm so puts in 2.0 timeframe

jc: what does it mean to have a required menu. makes no sense....

mk: punt to 2.0

js: punt

<jcraig> issue-497?

<trackbot> issue-497 -- When features require an element with a particular role be present (e.g., grid requires that gridcell be owned by row), implicit native semantics, if defined, count (e.g., tr without a role attribute counts as an element with role row) -- open

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

dmd: is it a navigatoion menu or a functional menu?

jc: both potentially

rs: we need this

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

<trackbot> Created ACTION-1336 - Patch issue-497 [on James Craig - due 2014-01-30].

<jcraig> ACTION-1336

<trackbot> ACTION-1336 -- James Craig to Patch issue-497 -- due 2014-01-30 -- OPEN

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

ACTION-502?

<trackbot> ACTION-502 -- Michael Cooper to Ask Doug Schepers whether SVG follows XML schema rules validation -- due 2009-07-31 -- CLOSED

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

ISSUE-502?

<trackbot> ISSUE-502 -- Decide whether accessible name is required for menus -- open

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

rs: no they are not required. Needs cleaning up

ISSUE-503?

<trackbot> ISSUE-503 -- Does everything inhert to owned roles, or just the states and properties? spec doesn't clarify, we should be explicit about what inherits and what doesn't unless it's everything -- open

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

jc: move to 2.0

<clown> http://www.w3.org/WAI/PF/aria/roles#menu (characteristics table).

ISSUE-504?

<trackbot> ISSUE-504 -- radio shouldn't have aria-selected -- open

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

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

<trackbot> Created ACTION-1337 - Patch issue-502 [on James Craig - due 2014-01-30].

<jcraig> action-1337

<trackbot> action-1337 -- James Craig to Patch issue-502 -- due 2014-01-30 -- OPEN

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

rs: need an action to fix taxonomy so aria-selected is not required on radio

mk: sounds pretty well thought out in the text

<jcraig> Radio shouldn't inherit from option, just from checkbox; copy aria-posinset and aria-setsize to radio; move aria-checked to checkbox, leave aria-selected on option with radio not inheriting that; affects nearby items in the taxonomy which need a close look. Probably also need to remove aria-checked from the option role.

rs: david bolter came up with a mixed use case for radio button
... did we say domething like mixed doesn't apply

<clown> http://www.w3.org/WAI/PF/aria/states_and_properties#aria-checked

<jcraig> ACTION: jcraig to patch issue-504, then assign to cooper for the taxonomy doc [recorded in http://www.w3.org/2014/01/23-aria-minutes.html#action13]

<trackbot> Created ACTION-1338 - Patch issue-504, then assign to cooper for the taxonomy doc [on James Craig - due 2014-01-30].

clown: we have stuff in the checked state to disallow this

<clown> "The mixed value is not supported on radio or menuitemradio or any element that inherits from these in the taxonomy, and user agents MUST treat a mixed value as equivalent to false for those roles."

rs: if we make this change do we have to fix the taxonomy?

<jcraig> ACTION-1338

<trackbot> ACTION-1338 -- James Craig to Patch issue-504, then assign to cooper for the taxonomy doc -- due 2014-01-30 -- OPEN

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

ACTION-508?

<trackbot> ACTION-508 -- James Craig to Create a new proposal based on the comments from this week for comment 115 -- due 2009-08-10 -- CLOSED

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

ISSUE-508?

<trackbot> ISSUE-508 -- Add treegrid as allowed role in required context role for rowgroup -- open

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

jc: shouldn't we do this?
... I think this is a simple edit

mc: this is a simple edit to the spec. Don't know if it is a simple implmentation or not

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

<trackbot> Created ACTION-1339 - Patch issue-508 [on James Craig - due 2014-01-30].

<jcraig> ACTION-1339

<trackbot> ACTION-1339 -- James Craig to Patch issue-508 -- due 2014-01-30 -- OPEN

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

rs: need to look to see if there is an impact on test tools of a taxonomy

<scribe> ACTION: rich to Look to see if taxonomy changes will impact test tools [recorded in http://www.w3.org/2014/01/23-aria-minutes.html#action15]

<trackbot> Created ACTION-1340 - Look to see if taxonomy changes will impact test tools [on Richard Schwerdtfeger - due 2014-01-30].

<clown> https://www.w3.org/WAI/PF/testharness/testresults?testsuite_id=1&testcase_id=56

joanie: random panels doesn't seem right. Perhaps better with no role

rs: is there a reason you created a panel for this?

jc: needs something for 1:1 mapping with tbody etc.

Issue: determine if UAIG mappings for rowgroup are correct

<trackbot> Created ISSUE-635 - Determine if uaig mappings for rowgroup are correct. Please complete additional details at <https://www.w3.org/WAI/PF/Group/track/issues/635/edit>.

ISSUE-510?

<trackbot> ISSUE-510 -- Investigate issues around the authors must statement in the select role -- open

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

<clown> www.w3.org/WAI/PF/aria/roles#select

<jcraig> Authors MUST ensure elements with role option are contained in an element using one of the non-abstract child roles of select, such as combobox, listbox, menu, radiogroup, or tree.

mk: author musts - add to the action to review author musts

ISSUE-513?

<trackbot> ISSUE-513 -- #toolbar normative statement should not require @aria-label, any label will do -- open

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

close 513

ISSUE-514?

<trackbot> ISSUE-514 -- #treegrid has normative-like statement with no normative requirements: "The value of the treegrid element's aria-readonly attribute is implicitly propagated to all of its owned gridcell elements, and will be exposed through the accessibility API." -- open

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

jn: do we do the same on grid?

<jcraig> ACTION: jcraig to patch ISSUE-514 (include grid) [recorded in http://www.w3.org/2014/01/23-aria-minutes.html#action16]

<trackbot> Created ACTION-1341 - Patch issue-514 (include grid) [on James Craig - due 2014-01-30].

<jcraig> ACTION-1341

<trackbot> ACTION-1341 -- James Craig to Patch issue-514 (include grid) -- due 2014-01-30 -- OPEN

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

ISSUE-516?

<trackbot> ISSUE-516 -- Reconsider RFC requirements for UA/AT in #aria-flowto -- open

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

jc: maybe outside the scope of aria

mk: didn't want any normative language around AT

jc: we are declaring User Interface here....

mk: not worth a fight

cs: I don't want to make it a may
... need more must statements against AT

mk: AT vendors would need to do implementations

jc: these are competing software products and some of these things are differentiating features
... when we start decreeing user interface on things then it is the UI's choice how to expose it

mk: if we are going to resolve this it would need to be in an implementation guide not a spec

cs: one of the problems is that it is assumed that we all work around AT requirements

jc: change 516 to be a general AT issue against 2.0

<clown> http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/tests/form/test_Spinner.html

<clown> https://www.w3.org/WAI/PF/testharness/testresults?testsuite_id=3&testcase_id=17

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

<cyns> https://www.w3.org/WAI/PF/Group/track/issues/519

<cyns> scribe: cyns

cs: is this related to the earlier issue around row and column posinset

mc: ok for 1.1

mk: level shouldn't be on item tag, should it?

mc: yes it is, because you use aria-level because the ua can't compute depth. that means you have to set on all children

jc: is there ever a case where we need aria-level on a grid?

js: sounds like part of 2.0 grid discussion?

<jcraig> issue-520

<trackbot> issue-520 -- Expand list of roles on which aria-readonly can be used, most likely changing textbox to input - ARIA 1.1 -- open

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

mk: i raised it, it's ok to push to 2.0

https://www.w3.org/WAI/PF/Group/track/issues/522

Bullet point 3 in 2A is causing confusion to the public

"If aria-labelledby and aria-label are both empty or undefined, and if the element is not marked as presentational (role="presentation"), check for the presence of an equivalent host language attribute or element for associating a label, and use those mechanisms to determine a text alternative. For example, in HTML, the img element's alt attribute defines a label string and the label element references the form element it labels. See How to Specify Alternate Text ([

People are reading this to mean that anything with role="presentation" does not get included in the accessible name calculation (including any child content of that element). This needs clarifying

js: this sounds like we should clean it up

<jcraig> issue-523

<trackbot> issue-523 -- searchbox/searchfield role which is a subrole of textbox/textfield -- open

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

jc: apple has a slightly different search semantic

js: also covered in html5, we should sync to them

<scribe> ACTION: jcraig to patch issue-523 [recorded in http://www.w3.org/2014/01/23-aria-minutes.html#action17]

<trackbot> Created ACTION-1342 - Patch issue-523 [on James Craig - due 2014-01-30].

<jcraig> ACTION-1342

<trackbot> ACTION-1342 -- James Craig to Patch issue-523 -- due 2014-01-30 -- OPEN

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

https://www.w3.org/WAI/PF/Group/track/issues/525

mk: dup of 516

525 has more detail and broader scope, so resolve 516 as dup

is a 2.0 issue

https://www.w3.org/WAI/PF/Group/track/issues/526

js: keep for 1.1

https://www.w3.org/WAI/PF/Group/track/issues/530

jc: useful for validation tools, but not urgent

all: move to 2.0

https://www.w3.org/WAI/PF/Group/track/issues/532

mc: is this an issue of inconsistency?
... this is a UAIG issue. changing product

https://www.w3.org/WAI/PF/Group/track/issues/537

rs: if joanie is ok with this, let's leave it to 2.0

mk: does this cover the issue we were discussing 2 weeks ago? If hidden=false and it's an unrendered element, should we put element into a11y tree.

jc: that's currently how it's worded. there's contention, and support varies, but there are 2 impl so it's in.

joanie: I want to put it off to 2.0, because we don't know what the use case are, and get expereince from that before changing.

mk: consensus?

js: welll.....

rs: we could say that we don't have to map the tree if there is an aria hidden

jc: related to html5?

rs: hidden doesn't have strong host langauge semantices in html5. someone can apply aria-hidden=false and apply to an element with @hidden. maybe use a may?

<jcraig> http://www.w3.org/WAI/PF/aria/complete#aria-hidden

<jcraig> Note: Authors are advised to avoid using aria-hidden="false" with styles or attributes that have historically prevented rendering in all modalities, such as display:none or visibility:hidden in CSS, or the hidden attribute in HTML 5. At the time of this writing, aria-hidden="false" is known to work inconsistently when used in conjunction with such features. As future implementations improve, use caution and test thoroughly before relying on this approach.

rs: is there anything in uaig?

cs: adding something to uaig 1.1 is a good idea.

<richardschwerdtfeger> ACTION: Cynthia define a mapping in the UAIG that covered aria-hidden="false" in all situations - including when a hidden attribute is applied. [recorded in http://www.w3.org/2014/01/23-aria-minutes.html#action18]

<trackbot> Created ACTION-1343 - Define a mapping in the uaig that covered aria-hidden="false" in all situations - including when a hidden attribute is applied. [on Cynthia Shelly - due 2014-01-30].

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

<trackbot> Created ACTION-1344 - Patch issue-544 [on James Craig - due 2014-01-30].

<jcraig> ACTION-1344

<trackbot> ACTION-1344 -- James Craig to Patch issue-544 -- due 2014-01-30 -- OPEN

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

jw: is this to expose content to AT and hide it from visual rendering?

js: yes

<clown> action-1343?

<trackbot> action-1343 -- Cynthia Shelly to Define a mapping in the uaig that covered aria-hidden="false" in all situations - including when a hidden attribute is applied. -- due 2014-01-30 -- OPEN

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

rs: moving 537 to ARIA 2.0

https://www.w3.org/WAI/PF/Group/track/issues/544

jc: editorial

mk: this says AT "will" which is interesting language

cs: is that 'will' prescriptive or descriptive?

<jcraig> http://www.w3.org/WAI/PF/aria/complete#aria-atomic

jc: descriptive

cs: consider re-wording so that it's clear that it's descriptive

jc: still1.1. closed issue but open action

https://www.w3.org/WAI/PF/Group/track/issues/545

jc: spec refers to DOM tree changes and UAIG refers to aapi tree changes

rs: on windows tree refelcts dom

cs: that's the goal, but impl is not perfect

jc: we need a live-region algo that is at least as complex as the name algo. or, we need an API to do announcements.
... the way we force authors and rendering engines to calculate chagnes is broken
... if you have a live region, and inside you have an element that is display:none. you set it to display:block. there is no DOM change, but there is an aapi tree change.
... there is al ot of ambiguity. one way to fix (probably 2.0) is describe all the differen scenarios (node chagne, text insertion, etc) and what happens.

rs: we ignore DOM changes

jc: yes we do

rs: uaig doesn't have api mapping for general dom in html. we don't say when the dom chagnes, you should expect these things to happne

cs: that would be a feature for HTML UAIG

jc: these are platform specific changes

cs: i disagree

rs: i disagree
... what happens when display:none is set

jc: removed from tree.

rs; where spec'd?

<MichaelC> scribe: Michael

<MichaelC> scribe: MichaelC

rs: we need a singular spec that says if something is removed from DOM, what happens

or if you hide from AT

mk: 1.1/

cs: not ARIA issue

rs: yes but we need a generic spec for these basic DOM things

cs: how different from HTML API map

rs: also need for SVG

jc: yes, need something for a UAIG, but not ARIA core and not 1.1

rs: true

but need to sync implementation guide for HTML and ARIA

cs: no resources

rs: gotta do

HTML wants this to be normative

cs: me too, but don´t hear the support for that

rs: the HTML A11Y TF

jc: <sorts out what spec say what>

so think UAIG needs to spec something

would like to do in 1.1 as prose

for DOM-based AT, the ARIA layer is the AAPI layer

another AT could choose which layer to use

jc: will propose an edit

and see how it lands

jgw: separate issue for 2.0?

jc: something to talk about at this meeting

anything we don´t get to, raise issues

<jcraig> ACTION: jcraig to propose an edit ISSUE-545 resolving live region changes to dom vs a11y tree [recorded in http://www.w3.org/2014/01/23-aria-minutes.html#action20]

<trackbot> Created ACTION-1345 - Propose an edit issue-545 resolving live region changes to dom vs a11y tree [on James Craig - due 2014-01-30].

<jcraig> ACTION-1345

<trackbot> ACTION-1345 -- James Craig to Propose an edit issue-545 resolving live region changes to dom vs a11y tree -- due 2014-01-30 -- OPEN

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

<cyns> scribe: cyns

jc: aria-roledescription. allows authors to change what is spoken

<MichaelC> scribe: MichaelC

cs: ARIA role might be item or listitem

@aria-roledescription (custom role descriptions on known role types)

but for a special kind, local type could be e.g., ¨foobarlistitem¨

that´s a localizable string

jc: either browser or AT can localize that

cs: in the AAPI not localizable, but as voiced to user, can be

not under author control, it´s an IE feature

<jcraig> example: <video> element in html would default to something like <video role="group" aria-roledescription="video">

jc: @@

cs: it´s an artefact that it´s localizable

jc: video element defaults to role=group and roledescription=video

in a slideset, each slide is role=region and roledescription=slide

rs: do we require roledescription?

mk: sounds like a way to do mapping in HTML 5

but do the AAPIs all support this?

jc: platform role doesn´t change, has to be a known token

cs: which creates behaviour

mk: and in AT

<jcraig> example: slides in presentation software would could be something like <div role="region" aria-roledescription="slide">

cs: Windows applications can change the string

HTML authors can´t

rs: this is another thing to localize

cs: only if they want to

mk: so different behaviour for different role tokens?

jc, cs: no, just spoken role is different, not underlying behaviour

jmd: in Hungarian, @@

the localization doesn´t work the same way

jc: browser should piece together string

jmd: have to pay attention to declension etc.

cs: only one thing changes

jc: label is usually most important because unique

role description second

we had a mailboxgroup

to AT as group

we treated these as token values

so got mailbox groupo in es

so less nonsensical to have the things put together

better than a longer technically perfect localization

rs: what incentive for average author to put in role description?

cs: average author need do nothing

rs: they´ll just use group

cs: fine

rs: but video...

cs: that´s automatic anyways

rs: what about flash video labeled group?

jc: author mistake

cs: Adobe will provide an appropriate embed code sample

mk: do you expect AT to say ¨video group¨?

cs: now we´re talking about an object that is a flash player....

mk: do you want role description so you can map video to group and have localizable additional info?

cs: IE does that already

there´s the automatic behaviour of browser

plus opportunity for author to tweak output

jc: maybe we should spec an expected mapping, plus a non-normative roledescription suggestion

mk: why not use aria-label?

jc: so platform API can take best advantage

don´t want to add junk roles to map 1:1 ARIA

cs: IE gives video role=group and name=video

but if you use label, that takes over

js: we need to pick this up

<jcraig> ISSUE: Continue discussion of @aria-roledescription (custom role descriptions on known role types)

<trackbot> Created ISSUE-636 - Continue discussion of @aria-roledescription (custom role descriptions on known role types). Please complete additional details at <https://www.w3.org/WAI/PF/Group/track/issues/636/edit>.

cs: author configurability of role description may be too much for 1.1

Protocols and Formats Working Group Teleconference
23 Jan 2014

Attendees

Contents

Timelines for ARIA 1.1 and ARIA 2.0

Decide whether ARIA.Next is more than a bridging technology MichaelC

host language binding

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

host language binding

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

@aria-roledescription (custom role descriptions on known role types)

Summary of Action Items

Scribe.perl diagnostic output

Protocols and Formats Working Group Teleconference 23 Jan 2014

Attendees

Contents

Timelines for ARIA 1.1 and ARIA 2.0

Decide whether ARIA.Next is more than a bridging technology MichaelC

host language binding

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

host language binding

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

@aria-roledescription (custom role descriptions on known role types)

Summary of Action Items

Scribe.perl diagnostic output

Protocols and Formats Working Group Teleconference
23 Jan 2014