See also: IRC log
<joanie> scribe: joanie
<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.
<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> <div class="plan_cost">
<clown> <span class="superscript">US$</span>
<clown> 19
<clown> <span class="superscript cents">99</span>
<clown> <span class="per_month">/mo</span>
<clown> </div>
<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.
<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
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.
RS: This will pass as a decision.
<richardschwerdtfeger> https://lists.w3.org/Archives/Public/public-aria-admin/2016Jun/0065.html
RS: Link above.
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
<which scribe missed>
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
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
<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
<something about a weird use case I´ve seen>
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
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) Succeeded: s/localized roletype/localized control type/ Succeeded: s/james/ james craig/ Succeeded: s/craig/ N/ Succeeded: s/jaeun: no// Succeeded: s/mvoe/move/ Succeeded: s/ORCA/Orca/ Found Scribe: joanie Inferring ScribeNick: joanie WARNING: No scribe lines found matching previous ScribeNick pattern: <Rich> ... Found Scribe: MichaelC Inferring ScribeNick: MichaelC Found Scribe: joanie Inferring ScribeNick: joanie Found Scribe: joanie Inferring ScribeNick: joanie Found ScribeNick: Rich Found Scribe: joanie Inferring ScribeNick: joanie WARNING: No scribe lines found matching previous ScribeNick pattern: <Rich> ... Found Scribe: MichaelC Inferring ScribeNick: MichaelC Found Scribe: joanie Inferring ScribeNick: joanie Found Scribe: MichaelC Inferring ScribeNick: MichaelC Scribes: joanie, MichaelC ScribeNicks: Rich, joanie, MichaelC Present: Joanmarie_Diggs MichaelC Rich_Schwerdtfeger Stefan Janina Cynthia jongund JF Joseph_Scheuhammer JaeunJemmaKU Tzviya Found Date: 30 Jun 2016 Guessing minutes URL: http://www.w3.org/2016/06/30-aria-minutes.html People with action items: matt mking WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]