Accessible Rich Internet Applications Working Group Teleconference

18 Feb 2016

See also: IRC log


Joanmarie_Diggs, Tzviya, fesch, Joseph_Scheuhammer, Markus_Gylling, Bryan_Garaventa, jongund, Rich_Schwerdtfeger, MichielBijl


<richardschwerdtfeger> meeting: W3C ARIA Working Group

<richardschwerdtfeger> https://lists.w3.org/Archives/Public/public-aria/2016Feb/0293.html

<scribe> scribenick: clown


RS: the proposed for action 1672 had gone out after resolution.
... it has passed.
... all the deprecated text for aria-grabbed and aria-dropeffect has gone through.

JD: I have put in the new text.

Combobox ACTION-1490

MK: First, let's limit the scope to the structure and relationships within the combobox.
... Nothing about focus nor active descendant.

<mck> <input role=combobox type=text aria-owns=list /> <ul role=listbox id=list> </ul>

MK: The aria 1.0 structure is as above.

RS: There was a second one where the combobox was a container of a textbox and a listbox.

MK: Let's take that up later.
... The first form have a number of issues.
... First, as Bryan has raised regarding value.

<mck> <div role=combobox aria-owns=list contenteditable> </div> <ul role=listbox id=list> </ul>

MK: If you use an input type text, you get the value for free.
... If you use the second form, there is no value.
... From a screen read perspective, both of these end up with one widget, even though on screen there are two things (textbox, listbox)
... The SR can't see it as two items.
... So, two problems; Value and composite nature.

<mck> <div role=combobox> <span role=textbox> </span> <ul role = listbox> </ul> </div>

MK: One more example: screen reader developers like this because it's how native combobox work. (Pastes in example).
... Notice in this pattern, there is no need for aria-owns.

<mck> <div role=combobox aria-owns=list> <span role=textbox> </span> </div> <ul id=list role = listbox> </ul>

MK: And, you could always make it like this with aria-owns (Pastes in another example).
... First, then, focussing on this structure: is there consensus that the spec should reflect the latter two examples?

JS: I believe FF puts in a value for the combobox even in the case not using a text input field.
... But, I'd have to check.

MK: Even with contentediable

JS: Points out that the two composite examples were out there in early versions of the spec.

<Zakim> clown, you wanted to point out the FF still might give a value to the comboxo in the second form.

MK: Well, we still want to allow for the input version, for legacy apps.

CS: We have a native combobox — two kinds.
... Win32 that looks like the container example.
... Then there is XAML
... The XAML combobox are an edit control with a controllerFor relationship to a list.

MK: It sounds like you still have two accessibles.

CS: We do.

MK: That particular structure is in ARIA and the web world.
... But the screen reader developers are rejecting.
... The engjineers are aware of the XAML structure, but do not like it.

CS: Well, narrator supports it.

MK: I don't see a mapping issue if people use the second form.

CS: We might miss the controlling relationship.

MK: But you could do it based on the mark up and infer the controlling relationship.

CS: We might be able to do that, I would hold that in reserve since we might find bugs.

MK: But, we don't want authors to be responsible for crafting the markup exactly, but leave it to the browser to map appropriately.

CS: I think we might be about to do that, but let me check.
... I think I can do it, but I must talk to devs first.

<Zakim> cyns, you wanted to say that I think it's undefined whether the value is still available in the first example, and it is at least not interoperably implemented

MK: The next part is to talk about focus management. But we only have 3 minutes.
... I would like to modify ACTION-1490 branch with the above discussion in mind.

<cyns> I'm going to drop off now

RS: We will continue this next week then.

<mck> scribe: mck

Test harness

RS: I started on this
... we need to tell people where exit criteria are documented

jf needs it among others

mc: i can recreate the url. will take a min

<MichaelC> Draft ARIA 1.1 exit criteria

rs: side note, joanie, i posted comments on link type

jf: new e-mail for test effort. what is that?

<Zakim> JF, you wanted to ask to be reminded of the new mailing list for the test-harness activities

<MichaelC> List of email lists

<richardschwerdtfeger> https://lists.w3.org/Archives/Public/public-aria-test/

mc: on the aria wg home, there is a communications section that includes mailing lists where it is listed.

<clown> https://www.w3.org/WAI/PF/testharness/

<MichaelC> ARIA Test Harness

rs: do we want to test properties on every role for the new attribs

mc: no, it is not feasible for every combination
... some props are for only one role
... globals we only test on a sample subset

jf: getting 404 for the list

<clown> https://www.w3.org/WAI/PF/testharness/specs?spec_id=5

<JF> https://www.w3.org/WAI/PF/testharness/specs?spec_id=3

mc: related to test harness not being complete.
... commenting out those links for now

<richardschwerdtfeger> https://rawgit.com/w3c/aria/CR-pub/aria/aria.html#sotd

<clown> Look for "Exit Criteria"

RS: JF look at this link. this is all the stuff needs test cases

question: are the people who work on JF's india team, do they understand ax apis?

jf: they have a working command of that

rs: could they look at the aria spec and write a test ssample and that look at the maaping specs to write a test for each platform.

jf: I think yes
... might be good to get people together on a call and work through an example

rs: there are already examples in there. I'd have they try to write a couple.

<clown> Test cases for ARIA 1.0: https://www.w3.org/WAI/PF/testharness/testcases?testsuite_id=1

<richardschwerdtfeger> https://www.w3.org/WAI/PF/testharness/testcases?testsuite_id=4

<richardschwerdtfeger> https://www.w3.org/WAI/PF/testharness/testcases/edit?testsuite_id=4&testcase_id=75

rs: providing an example
... show expected results for each platform

this needs to be done for each of the exit criteria for each of the new features

jg: we can do some
... is name description and grouping part of it?

<richardschwerdtfeger> https://www.w3.org/WAI/PF/testharness/

rs: there are test cases needed for accname
... this is only what changed, not everything.

probably need another coordination call

would also like Joseph, the King of AccName!

Joseph: there are no substantial changes to accname

we did remove express mapping

rs: need them for UIA

Joseph: we might have them but didn't use them before.

rs: when is a good time for a call?

jf: 2 people in india, early morning is best. before 9:30 austin.

rs: make a doodle pole?

<JF> +1 to a Doodle poll

mc: that's fine

Fred: svg aam is using a wiki page for testable statements and then use a script to load into db

rs: we can look at that.

need names from people on india team.

compiling list of names to pole

jf: My team is going to need some management direction.

<fesch> here are the SVG AAM test assertions https://www.w3.org/wiki/SVG_Accessibility/Testing/Test_Assertions

I can help with that. But, we should have a primary coordinator.

RS: not sure I have the cycles to do it personally.

jf: I can try and help. these are new people. Unrealistic to expect them to be complete self starters.


<clown> action-2018

<trackbot> action-2018 -- Richard Schwerdtfeger to Modify issue1009 text to ensure that aria-details does not aria-details does not participate in accessible name computation -- due 2016-02-18 -- OPEN

<trackbot> http://www.w3.org/WAI/ARIA/track/actions/2018


<trackbot> action-2018 -- Richard Schwerdtfeger to Modify issue1009 text to ensure that aria-details does not aria-details does not participate in accessible name computation -- due 2016-02-18 -- OPEN

<trackbot> http://www.w3.org/WAI/ARIA/track/actions/2018

<richardschwerdtfeger> https://rawgit.com/w3c/aria/issue1009/aria/aria.html#aria-details

This proposal also removes describedat

rs: still have to deal with visibility in dpub

joseph: there is a note about single element referencing. that is not in the text.
... wording in 2nd paragraph.

rs: easy fix
... Is this acceptable proposal for CFC?

<clown> +1

<joanie> +1

<fesch> ack

not raised with dpub yet.

rs: we have a week, if there are only minor comments, we wouldn't need another cfc.

marcus: i'm optomistic

RESOLUTION: Accept aria-details proposal with editorial change to refer to a single element.

Link type proposal

<clown> action-2006

<trackbot> action-2006 -- Joanmarie Diggs to Draft proposal for new aria-linktype attribute for group review -- due 2016-01-27 -- OPEN

<trackbot> http://www.w3.org/WAI/ARIA/track/actions/2006


<trackbot> action-2006 -- Joanmarie Diggs to Draft proposal for new aria-linktype attribute for group review -- due 2016-01-27 -- OPEN

<trackbot> http://www.w3.org/WAI/ARIA/track/actions/2006

<richardschwerdtfeger> https://rawgit.com/w3c/aria/action-2006/aria/aria.html#aria-linktype

Joanie: no longer excited about this idea. just kept ruling all the use cases as not necessary.
... not sure that this anything to with aria-details

Joanie reads spec text.

Joanie: I made up some enumerated type values

rs: what broght this up is in dpub

they have new roles that are all forms of links

dpub was adding roles. this is an alternative to more roles. it is like a subrole.

Joanie: I am not sure we need this in core. I am not opposed to it. But do not necessarily see the value outside DPUB

RS: I think there could be cases outside DPUB, like in the case of details.

Marcus: Joanie, why are not not hinking is generally useful?

Joanie: I use the platform API to parse the link and figure out things like samepage and mailto or file of size.
... this new attribute doesn't save any work as a screen reader dev. I can still do these things without it.

Marcus: Is this generally useful to screen reader users?

Joanie: without this feature, I still provide all this information.

rs: how do you do it for details or footnote?

Joanie: I do not handle those cases.

this could be good for that.

rs: I think having it in the main spec is valuable. Links are everywhere.

Tzviya: It is possible this is a way to future proof for annotations.

rs: are people against having a link type?

mb: what is the point of linktype?

rs: In the aria dpub spec, there are lots of roles like links that do thing like point to biblio entry.

we want to avoid proliferation of roles.

if you are AT user you want to know it is a link

It is also useful to know what type it goes to.

mb: VoiceOver already does something like this.
... it says things like "internal link"

<MichielBijl> <div id="foo">

am I muted?

<MichielBijl> <a href="#foo">

how do i unmute

unmute me

rs: Michiel, you understand the concept?

mb: yes, not sure we need it. but I will read more.

Joanie: i included the note about roledescription because there is a distinct difference. roledescription has to be localized by the author. linktype is enumerated.

screen reader can programatically use the value of linktype because it is an enumeration.

but in some way it is similar. We don't want authors to use them interchangeably.

<clown> +1 to joanie's suggestion to fully describe the machine-readable difference between linktype and description.

rs: whatever DPUB has in their spec, please include here.

Joanie: I don't think the core needs all the DPUB values

Modules extend core and not all th dpub values are generally useful.

rs: I would let dpub define the reference values

tzviya: Based on what AT devs are syaing, this isn't generally useful. Is that what we are asking?

rs: No, there is not a way for an AT to know something is a link to a footnote or biblio.

Marcus: perhaps we could subclass it like we do with roles

Joanie: you cant' subclass vluaes
... core would have a short list of values. DPUB would just have more values unique to DPUB.
... knowing that something is a link to a footnote might be useful in html.

Marcus: I don't think keeping reference as a value in core would hurt our table in dpub.

What is the problem with having more of the DPUB values in core?

Rich, please unmute me

I did, but rich seems to have me muted again, I unmuted my mic

MK: I see value in having more of the DPUB value in core.

rs: I am not opposed to that.

Marcus: we do have a worry that collective set of value is spread across documents.
... If we could put all the value in core, than that would be fine too.
... do we use prefixes on the values

joanie: we don't want some that havewhere you need prefixes and others where you don't

tzviya: we have only 4 values now

MK: why do you have to prefix values

rs: agree, we do not need to prefix values

it is not part of our extension module requirements.

rs: add the DPUB values to the core proposal.

<ShaneM> +1 to no prefixes on values

Summary of Action Items

Summary of Resolutions

  1. Accept aria-details proposal with editorial change to refer to a single element.
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.144 (CVS log)
$Date: 2016/02/18 19:03:11 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.144  of Date: 2015/11/17 08:39:34  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Found ScribeNick: clown
Found Scribe: mck
Inferring ScribeNick: mck
ScribeNicks: clown, mck
Default Present: Joanmarie_Diggs, Tzviya, fesch, Joseph_Scheuhammer, Markus_Gylling, Bryan_Garaventa, jongund, Rich_Schwerdtfeger, MichielBijl
Present: Joanmarie_Diggs Tzviya fesch Joseph_Scheuhammer Markus_Gylling Bryan_Garaventa jongund Rich_Schwerdtfeger MichielBijl
Found Date: 18 Feb 2016
Guessing minutes URL: http://www.w3.org/2016/02/18-aria-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.

[End of scribe.perl diagnostic output]