See also: IRC log
<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
<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
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
RS: I want the "bridging" text out of ARIA 1.0
MC: need to do that for Monday
JC: I can do that
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
<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
+1
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
<general agreement>
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
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
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/jamesn/jamesc/ Succeeded: s/Apple does something similar/AX API has "AXRoleDescription"/ Succeeded: s/jongunderson: the reason/joseph: the reason/ Succeeded: s/where an aria attribute/where adding an aria attribute/ Succeeded: s/ARAI/ARIA/g Succeeded: s/HRML/HTML/ FAILED: s/multiple platforms// Succeeded: s/multipl plateforms/multiple platforms/ Succeeded: s/JS/JC/ Succeeded: s/secton/section/ Succeeded: s/arias/aria/ Succeeded: s/developers/implementers/ Succeeded: s/aria 1.0 is only for markup of the web./aria 1.0 is not really the "Accessibility API for the Web", because the current iteration is only for the "markup of the Web."/ Succeeded: s/needs to have a scriptable interface/Among other things, we need to have a scriptable interface for things like WebGL that have no markup base./ Succeeded: s/roels/roles/ Succeeded: s/JS/JC/ Succeeded: s/tags/takes/ Succeeded: s/2.09/2.0/ Succeeded: s/checkbox/radio button/ Found embedded ScribeOptions: final -final *** RESTARTING DUE TO EMBEDDED OPTIONS *** Succeeded: s/multiple platforms// Found ScribeNick: ShaneM Found ScribeNick: jongunderson Found Scribe: Mark Inferring ScribeNick: Mark Found Scribe: jnurthen Inferring ScribeNick: jnurthen Found Scribe: cyns Inferring ScribeNick: cyns Found Scribe: Michael WARNING: "Scribe: Michael" command found, but no lines found matching "<Michael> . . . " Continuing with ScribeNick: <cyns> Use "ScribeNick: dbooth" (for example) to specify the scribe's IRC nickname. Found Scribe: MichaelC Inferring ScribeNick: MichaelC Found Scribe: cyns Inferring ScribeNick: cyns Found Scribe: MichaelC Inferring ScribeNick: MichaelC Scribes: Mark, jnurthen, cyns, Michael, MichaelC ScribeNicks: ShaneM, jongunderson, Mark, jnurthen, cyns, MichaelC Default Present: +1.541.678.aaaa, Matt_King, Lisa_Seeman, Shane_McCarron, Bryan_Garaventa, Joseph_Scheuhammer, Rich_Schwerdtfeger, Jon_Gunderson, Janina_Sajka, Joanmarie_Diggs, Alexander_Surkov, David_Bolter, James_Craig, James_Nurthen, Mark_Sadecki, Cynthia_Shelly, Michael_Cooper, David_MacDonald, Jason_White Present: +1.541.678.aaaa Matt_King Lisa_Seeman Shane_McCarron Bryan_Garaventa Joseph_Scheuhammer Rich_Schwerdtfeger Jon_Gunderson Janina_Sajka Joanmarie_Diggs Alexander_Surkov David_Bolter James_Craig James_Nurthen Mark_Sadecki Cynthia_Shelly Michael_Cooper David_MacDonald Jason_White Agenda: http://www.w3.org/WAI/PF/meetings/2014-01-ftf#agenda Found Date: 23 Jan 2014 Guessing minutes URL: http://www.w3.org/2014/01/23-aria-minutes.html People with action items: cynthia david_macdonald dmd eo jamesn jcraig meet rich[End of scribe.perl diagnostic output]