Accessible Rich Internet Applications Working Group Teleconference -- 30 Jun 2016

<joanie> scribe: joanie

Automated Testing

<richardschwerdtfeger> https://www.w3.org/wiki/ARIA_1.1_Automated_Testing

JG: The main thing is scheduling a meeting time.
... I mainly want to coordinate with Cynthia and Joanie.
... And Fred, if he's planning on participating.

FE: I want to be sure SVG can do whatever HTML does.
... If it works, then I don't need to be involved.
... But that's up to you.

JG: Joanie, Cynthia, and what about John (from Microsoft).

CS: I'd prefer to do it as a one-off.
... github might be easier.

JG: But Shane mentions another testing resource.

CS: I think we could share the test cases.

JG: The main thing I want to do is set up a meeting time.

RS: Why not set up a Doodle poll?
... For the week after next, due to vacations.

JG: The people in India are probably not going to be participating in this.
... John F?
... Is it ok to not include them?

JF: They're mainly interested in writing unit tests; not code.

CS: I think we're still talking about frameworks and harnesses.

JG: And also a templating system for writing test cases.

JF: Cool.

RS: Whom do you want on the call?

JG: Anyone who wants to come.
... I'll just send it to the ARIA list.

CS: John Jansen is not on the mailing list.

MC: I think you should continue using the aria-testing list.
... And John (Jansen) can be added to that list.

<richardschwerdtfeger> trackbot, make log public

<trackbot> Sorry, richardschwerdtfeger, I don't understand 'trackbot, make log public'. Please refer to <http://www.w3.org/2005/06/tracker/irc> for help.

MC: You don't have to be a member of that list.

JG: Could you send me the names of the people who are on the list?

<richardschwerdtfeger> trackbot, makelog public

<trackbot> Sorry, richardschwerdtfeger, I don't understand 'trackbot, makelog public'. Please refer to <http://www.w3.org/2005/06/tracker/irc> for help.

MC: Checking....
... I'll have to get that to you later.

JG: I'll just send it to the test list.

MC: Also send the initial mail to the ARIA list as well.
... John Jansen is not on the testing list.

CS: I'll check with him today. Or you can email him.

JG: I'll copy him.

Stefan: Question regarding sample project John sent around.
... I still have some compiling issues with Visual Studio 2015.
... Do I need a more recent version of Windows 10?

CS: Yes.
... You should be able to get the other version of WebDriver to get it to compile.
... But to get the accessibility improvements we've done, you really need to update.

Static/Text Role

<MichaelC> scribe: MichaelC

jd: Have sent proposal for review

https://lists.w3.org/Archives/Public/public-aria/2016Jun/0274.html

have made no changes since that was sent

discussion happening on mailing list

can explain background if needed

cs: not sure if needed, and worried about stripping context

<clown> https://rawgit.com/w3c/aria/action-2086/aria/aria.html#static

rs: my concerns were resolved, about interactive content

I´m less concerned about the name, though know stability of name important

think we should do a consensus call

<joanie> scribe: joanie

MC: I noticed on the thread that Jason White made a proposal.

<Zakim> MichaelC, you wanted to note emerging consensus? around JGW proposal

MC: And we might have some potential consensus.

RS: I'm ok with that as well.

CS: I don't think I saw that one.

<richardschwerdtfeger> https://rawgit.com/w3c/aria/action-2086/aria/aria.html#static

MK: I've missed a lot of stuff.

<MichaelC> https://lists.w3.org/Archives/Public/public-aria/2016Jun/0297.html

MK: But my concerns are very much the same as Cynthia's.
... My biggest concern is why do we need another way to hide stuff?
... That seems to hurt accessibility more than help it.

MC: As I understand Jason's proposal, using an empty roledescription would solve this issue.
... And from the responses on the mailing list, most people seem to think that would address this need for now.

CS: That seems like a reasonable approach for now.
... It may not address SVG.

MK: What we're really saying is that sometimes we want to hide the role.

RS: Yes.

MK: But role="none"....
... In cases when you want to hide the semantics.

CS: I think they want to keep an object in the accessibility tree, but not its children.

JS: Yes, an object in the accessibility tree with a name.

MK: But if you have a containing object in the accessibility tree....

JS: In that case, the object with role="none" will not be in the tree, but its content will be.

CS: No textual content and an object with a name.

JS: I'm not defending either position; just explaining what they are.

MC: It could be that the APG could explain how to do these.
... My understanding is that existing ARIA can address these needs.

CS: My understanding is they want the functionality of image, without the rolename being presented.

<clown> https://rawgit.com/w3c/aria/action-2086/aria/aria.html#aria-roledescription

MK: If the roledescription is null, and actual role is img, if AT ignores roledescription or there's a way to do so, there's a way to render it as if it hadn't been done.

<clown> https://rawgit.com/w3c/aria/master/core-aam/core-aam.html#ariaRoleDescription

CS: I don't know about the other platforms, but in UIA, roledescription will be exposed as the localized control type.
... I don't know what would happen if the roledescription is an empty string.
... But I'll have to check.

RS: What I would like to do is get some consensus on which approach people want to take.

<clown> https://rawgit.com/w3c/aria/action-2086/aria/aria.html#img

RS: Use img to do this, or create a new role?

CS: Image

MK: Image

JD: Image

<fesch> image +1

MC: James noted on list that image has a different name-from.

<richardschwerdtfeger> RS: Image

<mck> image +1

RS: Others?

MC: I don't have a technical stake in this game.
... I think Jason's suggestion is an elegant solution for now.

RS: I think this is a temporary solution.
... We need to work on a better solution past 1.1.
... But this will get what we need to do for now.

JW: This is not meant to replace the new role.
... It's meant to address some of the use cases for now.

RS: Image or text for 1.1, Jason?

MC: I think on the list, people are happy enough for now, with Jason's suggestion.

JW: Joanie's draft of the role points out that unless you are an accessibility API expert, it's not obvious what the use cases are.
... But this needs to be explained somewhere (non-normative documents or otherwisse).
... I'm fine with the image approach for now.

RS: It sounds like we have a resolution.
... Do we want to have image support name from content?
... That would require some additional authoring work.

<clown> https://rawgit.com/w3c/aria/action-2086/aria/aria.html#img

MC: I think we shouldn't meddle at this point.
... I think we can live with img as it is.

MK: I've still not seen any of the use cases.
... I don't think this improves accessibility.
... It seems people are trying to stylize speech.
... And I think that requires implementation in screen readers.
... It's user preference like punctuation level.
... We may need a property to express this.
... Screen readers could have image announcement levels.
... Anything that hides semantics or flattens stuff in the tree is dangerous.
... And I'm also concerned with null roledescriptions.
... It's going to be hard to write about this in the APG.
... All authors think they know what they're doing.

RS: It's like live regions being misunderstood.
... It looks like the consensus is to move the static/text role to ARIA 2.0.
... But in the meantime, to make the use of Jason's suggestion.

MC: We can resolve to move the text/static role to ARIA 2.0.

MK: Does roledescription allow for empty strings?

<clown> https://rawgit.com/w3c/aria/action-2086/aria/aria.html#aria-roledescription

MC: We should not ask Apple to remove their support.

RS: We already resolved to move this to ARIA 2.0 once.
... So this is not new.
... And that resolution passed CfC.

CS: And we're asking for an authoring topic regarding flattening the tree.

RS: That would be something for the APG to deal with.

MK: You can create an action for that if you want.

MC: Looking at the spec, roledescription just says string.

JS: It also has some SHOULDs

<Zakim> MichaelC, you wanted to say taking this approach means no technical change from the current status quo, but does (we think) remove objections to this status quo, and don´t think

<MichaelC> https://www.w3.org/TR/wai-aria-1.1/#aria-roledescription

JS: (Reads from spec)

MK: So if you put it on role of img, it doesn't say anything about the string.

CS: That makes sense. You can only put it on elements in the tree.

<clown> "Authors SHOULD only use aria-roledescription on elements that equate to a valid WAI-ARIA role (have an implicit WAI-ARIA role semantic) or have a valid WAI-ARIA role applied. If neither condition is met, then user agents MUST NOT expose the aria-roledescription."

JS: It says nothing about empty string.

CS: Which means screen readers probably won't say anything.

MK: In some cases roledescription is a property.
... In some cases we say an empty string is like not providing the property.
... Probably this is a gap in the property.
... You shouldn't leave it up to user agents to ignore a string.

BG: Can we have aria-roledescription="null", rather than "".

MC: It's too tricky to try to create a value of "null".

Stefan: Has Apple already support for aria-roledescription?

RS: Yes.

Stefan: To be used together with role of application?

RS: No, img.

MC: The proposal is for role img, but the roledescription property is not constricted.

<clown> <div role="image" aria-roledescription="" aria-label="might fine label> stuff </div>

Stefan: I thought I read somewhere in the spec....

MC: That is something else.

<MichaelC> jd: ¨¨ may map to null

<MichaelC> if we want explict support for ¨¨ on roledescription, may need to add a line

<scribe> scribe: joanie

MC: I agree. I think one line is needed.

RS: Would that require another CfC?

MC: It would.

JS: And we may want to special-case this in the Core AAM.

RS: We could handle it that way.

MC: The line we need to add to roledescription is non-destructive to the rest of the text in the spec about that property.
... We could do a parallel CfC for pseudo last call.

RS: I really want to get out a last call draft.
... So, Michael, we're not adding anything new.

<jamesn> this seems like a huge hack.... if it allows someone to do the same as role=static I don't know why people see this as preferable

RS: The text/static CfC already passed before.

MC: I think we should log a resolution.
... But that would not need to go out for CfC.

<jamesn> i like role=text/static.... it seems useful

<jamesn> I am speaking at a conference and have no phone access this morning

(Drafting of resolution text)

<richardschwerdtfeger> proposal: The group reinfornces the decision to move the text role to ARIA 2.0, but also to write text for aria-roledescription to state how screen readers should handle “” as a value

<jamesn> why is role="img" aria-label="wibble" aria-roledesciption="" better than role="static" aria-label="wibble"

JS: To point out that JamesN is saying he's in favor of the static/text role, but can't come to the call.

<jamesn> people can still do all the things that people are concerned about breaking

MC: A number of people are in favor of it.
... But they are also ok with putting it off.

MK: JamesN was part of the CfC to push it off in the first place.
... So I think we're fine.

MC: Given that JamesN is participating via IRC, he can object if he wants.
... But I think he is ok with the situation.

<jamesn> I am objecting

MC: Oh, you (JamesN) are objecting.
... This is hard because he's not on the phone.

RS: Cynthia doesn't want to implement the static text role at this time.

<richardschwerdtfeger> Cynthia does not want to implement the text/static role at this time. due to it being another vehicle to hide content

RS: Due to it being .... (typed above)

MK: Was JamesN objecting to using image instead?
... i.e. don't do either for 1.1.?

<jamesn> but role=img aria-roledescription will hide the content in the same way right - but you are ok with that?

MK: Or is he objecting to not reviving the text role?
... It's not clear to me.

<jamesn> i like the text role... i think it is useful

MK: He could be talking about roledescription w.r.t. 1.1.

MC: To attempt to summarize, I think he thinks the roledescription is too hacky.

<richardschwerdtfeger> We agree the aria-roledescription is hacky

<jamesn> i don't like hacking role=img with roledescription to do the same thing

MK: There's a long-term impact to doing the roledescription.
... So we have to determine if it's worth the risk.
... Should ATs read the original role?
... We wouldn't be able to go back on this description.
... Well, I guess we *could*.
... But is it worth the deprecation?
... They'd have to change their code.

<jamesn> no. my phone crashed last night...

MK: I still go back to the fact that I've seen no compelling case for this.
... I would rather the screen readers just say "image"

<jamesn> what about the one i provided?

MK: Maybe in the future we decide what to do to get screen readers to stylize speech.
... But we want to make ARIA robust.

<jamesn> adobe one

<richardschwerdtfeger> scribenick: Rich

<clown> https://lists.w3.org/Archives/Public/public-aria/2016Jun/0284.html

<clown> jamesn example ^

<clown> Copying the example from the email:

<clown> 19

<clown> vs. <div class="plan_cost" role="static" aria-label="US$19.99/mo"> spans from above </div>

<richardschwerdtfeger> MK: to make the examples speack without saying image in those cases it seems like a very fine level of control over the user experience. It is extremely rare and the benefit is negligable

<jamesn> this is not an image

<richardschwerdtfeger> MK: There were times when you had spacer images and you had to find the content. this is the complete opposite

<joanie> scribe: joanie

<jamesn> (of course Adobe could also fix their code so this included a decimal ;) )

RS: So... We do have an implementation in iOS and OS X.

JD: We have it in Chrome.

RS: Positive?

JD: James Craig said so.

JS: James Craig said so.

MK: JamesN said earlier, it's not an image.
... Do we need a symbol role?
... A role that's designed to hide all of it's children....

<clown> https://lists.w3.org/Archives/Public/public-aria/2016Jun/0132.html

MK: Dealing with how certain characters are spoken is different.

<jaeun> james N said in the email, "I've confirmed that, with an explicit label, this works in WebKit,"

<clown> https://lists.w3.org/Archives/Public/public-aria/2016Jun/0132.html

MK: And things like individual characters are a much, much different use case.

<clown> The text role implementations remain in both WebKit (Safari) and Blink (Google Chrome).

JS: I've but the URL in above.
... And the quote from the message is above.

<MichaelC> scribe: MichaelC

jd: whole point of rewrite was to not change functionality

worked hard with JamesC to be sure of that

text role was meant turn text into not-text

my concern was that people would assume an opposite impact

so my proposal was to put in an accessible name, if there isn´t one, and eliminate the text-ness

in theory, role could be put on a whole paragraph

which messes up its navigation

<jamesn> I am going to have to go as my session is coming up soon.

rs: sounds like still objections to the img / roledescription solution

with the amount of concern, think should move to 2.0

even though JD´s proposal addresses my concerns

<jamesn> I would prefer the roledescrption solution to moving eveeyhting to 2.0 as we need this kind of thing

so I can go either way

<jamesn> if we move it to 2.0 we must support roledescription=""

<jamesn> (but i still think it is super hacky)

jd: JamesC said he was ok postponing at least to 1.2 now we all understand the use case

he was the main proponent

<clown> the email that joanie was referring to: https://lists.w3.org/Archives/Public/public-aria/2016Jun/0291.html

rs: seems like JamesN is (reluctantly) supporting the roledescription solution for now

thanks for meeting us half way

mk: concerned about empty roledescription, what if it wipes out role?

<jamesn> so i am only ok with punting it if we have empty roledescription wiping out the role

<joanie> scribe: joanie

MC: We agreed we need to add something to the spec for empty roledescription.

MK: We need to address it in 1.1.
... But I think we want to say empty means ignore it.

RS: My proposal is above.

JS: I would add to that, possibly changing the mapping of aria-roledescription based on the empty string.

RS: What would you put in there?
... You have to have an object.

JS: Cynthia said, I think, they'd probably stick the role in.
... So you want to explicitly say how to handle an empty string for aria-roledescription.

RS: Well, that's what I have here.

MK: I think we need to entertain different proposals.

RS: That would extend things even longer.

MK: I think we need to address this issue this week.
... We may have competing branches.

<richardschwerdtfeger> proposal: The group reinforces the decision to move the text role to ARIA 2.0, but also to write text for aria-roledescription to state how screen readers should handle “” the value

MK: I would like to say that we ignore the role if we have an empty string.

MC: So MK, you're saying that we should make the proposed hack from Jason not work?

MK: Yes.
... I've become very anti-hack when it comes to ARIA.

RESOLUTION: The group reinforces the decision to move the text role to ARIA 2.0, but also to write text for aria-roledescription to state how screen readers should handle the “” value

RS: I'm going to make this the resolution.
... I'll give someone an action.
... Who will take the action to deal with the "" value?

MC: I think Matt may be right regarding competing proposals.
... So I think we give one to Matt.

<jamesn> I only support this resolution of we can make it work using aria-roledescription - if not I do not support this resolution.

<richardschwerdtfeger> ACTION: matt create a proposal for handling the role description value of “” [recorded in http://www.w3.org/2016/06/30-aria-minutes.html#action01]

<trackbot> 'matt' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., mgarrish, mking3).

MC: And give someone on the other side an action.

<richardschwerdtfeger> ACTION: mking create a proposal for handling the role description value of “” [recorded in http://www.w3.org/2016/06/30-aria-minutes.html#action02]

<trackbot> Created ACTION-2092 - Create a proposal for handling the role description value of “” [on Matthew King - due 2016-07-07].

RS: Who will take a competing proposal.

MC: I think Joseph or Joanie.

JD: No.

JS: No.
... I think Jason should.

MK: I can make two branches.

CFC Result: Remove children presentational of true for menu item, tree item, and spinbutton

RS: This will pass as a decision.

<richardschwerdtfeger> https://lists.w3.org/Archives/Public/public-aria-admin/2016Jun/0065.html

RS: Link above.

Joanie Updates to separator role

RS: I didn't have anything at the time. Do you have a link?

https://www.w3.org/WAI/ARIA/track/actions/2091

<MichaelC> scribe: MichaelC

<joanie> https://rawgit.com/w3c/aria/action-2091/aria/aria.html#separator

<joanie> Changes:

<joanie> * Add implicit values: valuemin (0), valuemax (100), and valuenow (50).

<joanie> * Make valuenow required and add an associated "authors MUST".

<joanie> * Add an "authors SHOULD" regarding valuemin and valuemax.

<joanie> * Remove aria-expanded as a supported property. If a platform needs

<joanie> this state, it can be mapped based on the values in the Core AAM.

<joanie> In addition, there was no statement suggesting that authors SHOULD

<joanie> provide an accessible name in environments when there is more than

<joanie> one focusable slider. That statement has been provided as part of

<joanie> these changes.

jd: particularly want input on the removal of aria-expanded

in implementation, if aria-valuenow > aria-valuemin, it´s expanded

so don´t need the property explicitly

<joanie> If the separator is focusable, authors must set the value of aria-valuenow to a number reflecting the current position of the separator and update that value when it changes. Authors should also provide the value of aria-valuemin if it is not 0 and the value of aria-valuemax if it is not 100. If missing or not a number, the implicit values of these attributes are as follows:

<joanie> The implicit value of aria-valuemin is 0.

<joanie> The implicit value of aria-valuemax is 100.

<joanie> The implicit value of aria-valuenow is 50.

<joanie> In applications where there is more than one focusable separator, authors should provide an accessible name for each one.

<jamesn> Can we also recommend aria-controls or is that an APG thing?

jd: To JamesN, dunno

mk: I was trying to minimize changes

but like the more substantial change here

I think we should not put aria-controls

there could be structures on either side

gets to be overkill

could use name to describe what´s going on by using name of region

think we can address in APG

so don´t need something about that in spec

<jamesn> normally seen as controlling one of the regions though.... I.e. what gets minimized when I activate the control

<jamesn> but fine with being in APG

e.g., if between TOC and main content in a book reader, you´d give it a name of ¨TOC separator¨

<joanie> https://rawgit.com/w3c/aria/action-2091/aria/aria.html#separator

<jamesn> that would control the TOC though - as if you minimized it the TOC would go away

fe: would separators always be expressed as percents?

jd: implict values are (implied) percent oriented

but not required if author provides value

there´s guidance to author about using them

so you could have even negative values for valuemin etc.

mk: UA calculates a percent based on the value range

use valuetext if you don´t want a percent expresion

fe: people might want a pixel value

for a window size

jd: that´s available in other APIs

rs: ok with this draft?

<jaeun> it looks good to me

mk: editorial, s/requesting/describing/

jd: that was reflecting

mk: ok

fe: ? valuetext if you don´t want %

mk: e.g., for slider

jd: it´s supported

mk: is it on this role?

jd: don´t remember

fe: yes

<jaeun> +1

rs: ok to accept?

<jaeun> +1

js: add ¨if focusable¨ to default values?

jd: considered but thought not needed

mk: only needed for mapping

RESOLUTION: accept Joanie´s proposal for separator

<fesch> +1

Password role

rs: any use cases for custom passwords come forth?

jd: orca users list, which is usually quite productive, didn´t even find much

rs: objection to moving password to ARIA 2?

jf: NO

<mck> +1 move pw role to 2.0

<joanie> +1 to move it to 2.0

<richardschwerdtfeger> +1 to move to ARIA 2.0

jf: ;) thanks everyone for responding to the concerns

RESOLUTION: move password to ARIA 2

Spinbutton

<joanie> https://www.w3.org/WAI/ARIA/track/actions/2088

<joanie> https://rawgit.com/w3c/aria/action-2088/aria/aria.html#spinbutton

<joanie> Authors may create a spinbutton with children or owned elements, but must limit those elements to a textbox and/or two buttons.

<joanie> To be keyboard accessible, authors should manage focus of descendants for all instances of this role, as described in Managing Focus. When a spinbutton receives focus, authors should ensure focus is placed on the textbox element if one is present, and on the spinbutton itself otherwise. As a general rule, authors should not make the button elements keyboard focusable because users of devices with keyboards

<joanie> will likely prefer the use of the arrow keys to change the value of the spinbutton.

rs: works except on IOS

jd: doesn´t have keyboard anyways

rs: yet Android does support keyboard

jf: many devices support bluetooth etc. keyboards

20% of users use that

jd: this text is aimed at users who are using keyboards

on non-keyboard devices, other input methods used

rs: IOS doesn´t send keyboard input to divs and spans

so forces use of the buttons for a spinbutton

whereas on Android you could use the keyboard arrow keys

mk: s/likely prefer/<something better than that>/

<clown> "…users of devices with keyboards will likely prefer the use of the arrow keys to change the value of the spinbutton."

don´t think likely preferences of users is a justification we should use

<clown> "…users of devices with keyboards will use of the arrow keys to change the value of the spinbutton."

jd: is that editorial? could we sort after meeting

<clown> "…users of devices with keyboards will use the arrow keys to change the value of the spinbutton."

mk: yes, yes

jd: hope we can accept modulo minor editorial changes

bg: sounds clear to me

still wonder how attributes like valuetext conveyed if focus not on the thing

jd: it´s only supported on the spinbutton itself

would be author error to put in other parts of the widget

bg: have seen cases where valuetext not reflected in what´s displayed

jd: so maybe clarification needed

mk: is AT responsibility to report what´s up

jd: Orca does

we could ignore the fringe case, or we could hold up to refine

bg: like what´s there

just want an addition about AT

mk: not normative in a note, but could elsewhere

RESOLUTION: accept Joanie´s proposal on spinbutton

- DRAFT -

Accessible Rich Internet Applications Working Group Teleconference

30 Jun 2016

Attendees

Contents

Automated Testing

Static/Text Role

CFC Result: Remove children presentational of true for menu item, tree item, and spinbutton

Joanie Updates to separator role

Password role

Spinbutton

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output