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

<jemmaKu> rrsagent make log world

<scribe> scribenick: clown

<MichaelC> agenda order 1, 2, 3, 4, 5, 6, 8, 10

take up item 1

MC: It's up to Rich to send the formal decisions
... <looks up what they were>
... I think they all passed.
... Warning for password was amended via MichielBijl.
... Any concerns?

JF: No. to-may-to to-mah-to.
... I think the original felt stronger, but the new text is more of a friendly reminder.

MC: If you want to keep the original text, say so.

<jemmaKu> is this original draft? "Warning: the password role does not convey or apply any of the security or privacy considerations found in native password fields. Authors are responsible for making sure that custom password fields have robust security and privacy protection, as befits their use."

JF: Well, I wrote the originall text. I want authors to understand there are serious limitations in terms of using it.
... I prefer the stronger wording.

MC: I do too.

JK: I can second that.

MC: There is a general preference for the original wording.
... the second CfC was on aria-keyshortcuts.
... Joseph made some non-normative editorial changes.

MK: I'm generally okay.
... I have a few small modifications.

MC: Go ahead an make the mods and then notify Joanie.

MK: Will do, but I will have to look for them.

<Zakim> joanie, you wanted to seek clarification on when to merge

MC: You can ask Joseph or Joanie.

JD: If I know where the changes are, I can make them.

MC: As for doing the merge, it's triggered when Rich makes the formal recommendation.

JD: It's not clear if it's blessed by virtue of this meeting.

MC: It is up to Rich, and I will contact him to make his blessing.
... Last one about the implicit/explicit roles.
... There was no discussion, so I assume everyone is okay with it.
... So, I will notify Rich about that as well.

MC, JD, MK: <discussion on mechanics of github and merging>

ACTION-2039 Update definition of aria-autocomplete

action-2039

<trackbot> action-2039 -- Matthew King to Update definition of aria-autocomplete -- due 2016-03-17 -- PENDINGREVIEW

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

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

MC: Matt, you sent some notes around about it.

MK: I sent to the list a summary of what I've done.

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

MK: I can walk through it.
... This update compared to last week has eight changes.

<mck> http://rawgit.com/w3c/aria/action2039-autocomplete/aria/aria.html#aria-autocomplete

<MichaelC> changes: https://github.com/w3c/aria/compare/action2039-autocomplete

MK: In that branch, the way it was written suggested that regardless of what a user types, automatic predicitions will appear.
... But that only happens only if the app recognizes the input and can make a prediction.
... I modified the definition to indicate that.
... That's in the first paragraph.

<mck> the inline model (aria-autocomplete="inline") that presents a value completion prediction inside the text input

MK: In the second paragraph, I changed it to say "value completion prediciton".
... Focussing on the idea autocomplete is all about predictions.
... In the third paragraph, second sentence used to imply an authoring requirement in a negative manner, and not normative.

<mck> Authors SHOULD either omit specifying a value for aria-autocomplete or set aria-autocomplete to none if an input element provides one or more input proposals where none of the proposals are dependent on the specific input provided by the user.

MK: I changed it to a postive SHOULD statement. (see above).

<MichaelC> last week´s discussion on aria-autocomplete https://www.w3.org/2016/06/02-aria-minutes.html#item02

MC: The main thing we want to do is if people have concerns with your edits.

MK: I will try to summarize quicker.
... I removed the word "state' from "selected state" and went back to something similar to the original language.
... <describes other changes>
... I added the word "MAY" in the value definitions.

MC: Any comments?

JD: Thank you for clarifying the state thing.

MC: The hope is to approve this. Any objections to accepting this branch as proposed?

<JF> +1 to accepting

MC: Let's make a resolution.

RESOLUTION: Accept action-2039 as proposed.

Treeitem, option re children presentational

MC: We talked about this last week, but got stuck

<MichaelC> Last week on children presentational https://www.w3.org/2016/06/02-aria-minutes.html#item03

MK: We had resolution three weeks ago, it went out to CfC and was approved, but there was another thread questioning it.
... The person we thought would not agree was Stefan.

MC: I was supposed to contact him, but I did not.
... He is here today, though.
... Stefan, we wanted to check with you about treeitem and children.

MK: We had an approved CfC, but you and others had some problems.
... We don't have from you if the mailing list discussion is okay.
... This is in regards children-are-presentational for treeitem.

SS: I said there could be more complex treeitems that contain interactive content.
... Also in lists.

MK: The CfC included it on other roles where ATs can't handle internal interactive content.

SS: I can't vote against it, but in reality these things happen.
... It's a bad idea that ARIA 1.1 does not cover it yet.
... Also, we cannot rely cross platform screen reader support.

MK: Whether we change it in the spec or not does not affect AT behaviour now.
... Same with browsers.
... If you put interactive children inside these roles, it won't work, unless you use some tricks.
... But those tricks are not recommended by authoring practices.

FE: Originally Rich, James, and I were against this.
... But, we are willing to put this off to ARIA 2.0

SS: I'm okay with that.
... But, Rich is in the same boat as me?

FE: Yes, as well as James.

<Zakim> joanie, you wanted to question the "nothing will change"

JD: I'm sort of in the same boat.
... With resepect to spinbutton.
... Doesn't that mean the UAs do not expose the children?
... Right now the up/down buttons are actually exposed.
... I think things will change.

SS: I just want to point out that I do not care that much about treeitems with links inside.
... But, we have frequently in our UIs are listitem containers with interactive content inside a listitem.
... And, we need to cover this.

MK: That one, we have a robust solution.
... That's why we added layout grids to ARIA 1.1.

SS: Also, with position information — on item 5 of 8 — we need to see if the layout grid covers this.

MK: It does.

BG: The underlying reason is to shore up the difference between composite and non-composite widgets.
... Tree items have never been composite.
... Composite means that it supports interactive child elements.
... User agents do no expose the child elements in composite widgets.
... To make them composite requires a much larger spec change.

<Zakim> jamesn, you wanted to say it is not a grid visually.....

BG: This can be part of 2.0, but we need to make clear in 1.1 that these are not composite widgets.

JN: I'm always worried when someone says that something that is thought of as a list is actually a grid.
... It concerns me that different users have a different experience.

<JF> +1 to JamesN

JN: It might lead to a wcag error.

MK: I have answer to all your points, but that discussion belongs to authoring practices.

JN: We have those problems in our organization.

BG: A lot of the problem comes down to what it looks like and what it is semantically.
... They don't have to be the same.

<Stefan> +q

BG: As long as they are accessible.
... It's when they look as if they behave a way, but don't, that's a huge problem.

MC: I get the feeling that we do not have consensus.
... It has gone from "I can live with this" to stronger objections.
... Is there something we can agree on that it necessary and sufficient in ARIA 1.1?
... Try to find consensus around that within the next 15 min; otherwise, keep this issue open.

BG: What is a non-composite widget? That is the issue.

MC: A widget is that not composite. A composite is one that consists of other widgets.
... It might also might have structure.

MK: Composite has focusable children.
... The children's semantics are revealed to AT>
... My primary concern is if we do not make the spec consistent with how we have mapped to host languages.
... E.g <option> is not allowed to contain things.
... As soon you break that so that 'option' can have more than one meaning — it create serious problems.
... An advantage of the CfC is that it allows conformance tools to alert authors.

SS: I don't say to hijack options of listitems.
... I just want a new role or mechanism to handle the "complex" listitems.
... Also, I agree with James that using grid for lists is confusing.
... It should not be called a grid by JAWS. We need a new semantic.

MK: JAWS already calls these things grids.

SS: But a grid has editable cells and data bound content.
... But the things I have in mind — text, links, buttons — they don't have that semantic.
... This needs more discussion.

BG: We do need to distinguish between listitem and option. They are different things.
... Listitem does allow children, but option doesn't
... Listime maps to <li> and option to <option>

<joanie> https://trac.webkit.org/browser/trunk/Source/WebCore/accessibility/AccessibilitySpinButton.cpp#L81

JD: Here is a link as what already happens in webkit (see above).

<Stefan> +q

JD: There is code that explicitly exposes the children of a spinbutton.
... If we make this change in the spec, then we are saying webkit is doing the wrong thing.
... Same as on my platform.
... It could be that JAWS doesn't tell you they are there.

BG: I understand that, but the spec says it is not a composite widget.
... How much are we putting on the user agent by such a change?

SS: The children need not be reached because they are not keyboard focusable.
... If there are keystrokes that invokes their function, it doesn't need focus.

<Zakim> MichaelC, you wanted to mention user vs author disconnect? and to ask priority of 1.1 vs 2.0 and to propose ednote

SS: The question is what do screen readers do when they encounter these inner pieces.

MC: I think we do not have consensus.
... There might be different understanding between users and authors.
... We need to do more education.
... I'm still trying to find a way to go ahead with pseudo last call draft with no one uncomfortable with what's in it.

MK: There were eight roles in the CfC.
... You can go forward with five of them.

MC: How about an editorial note on the remaining three?
... This is meant to be a "last all working draft", and that can be changed.
... Especially with an editorial note that flags that things may change.
... Is that acceptable?
... And maybe a wiki page?

BG: If we make role option composite, it is going to break listboxes.

MK: I'm comfortable with an editorial note.

<jemmaKu> I agree with Michale's suggestion - recording all the different opinioins and keep track of those discussion

MC: I'm not proposing making option composite. That's too big a change.

<Zakim> joanie, you wanted to say that I'm ok with it if MichaelC puts an explicit statement in the "We especially want feedback on" section

JD: Basically what I typed above is it.
... Add that we want feedback on these editorial notes.

MC: Yes, I would do that.
... Is that acceptable — the editorial notes?

<jemmaKu> I can live with "editorial notes"

<mck> +1

<joanie> +1

<fesch> +1

<jemmaKu> +1

<jamesn> option, treeitem, spinbutton

MC: what are the three rols?

BG, MK: option, treeitem ,and spinbutton

SS: I'm not against this definition for ARIA 1.1. That's okay.
... We need to address this in 2.0

MC: I think there is a 2.0 issue in tracker.

proposed: Add edtiorial note to option, treeitem, and spinbutton roles that their children are presentational is provisional

RESOLUTION Add edtiorial note to option, treeitem, and spinbutton roles that their "children are presentational" status is provisional

RESOLUTION: Add editorial note to option, treeitem, and spinbutton roles that their "children are presentational" status is provisional

MC: I can't find a 2.0 issue. Can Matt or Stefan file one?

MK: I can...

MC: Do roles like spinbutton be composite?

MK: That's one issue…
... Another is whether certain roles support interactive children.

ACTION-2079 and ACTION-2080 Draft ¨host language should¨ language for password

MC: Somehow both Joanie and I got similar actions.
... I will rescind mine in favour of Joanie's

JD: My understanding of how we got duplicate actions.
... We need to make to make sure to not have authors to put the role where is does not belong.
... And we need to make the statement that it is strong, so you can't override it.

MC: Do we need both actions?

JD: Maybe.

MC: There was feed back on my action that it needs larger scope.
... Joanie has a proposal.

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

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

action-2080

<trackbot> action-2080 -- Joanmarie Diggs to Draft aria spec text limiting the use of role password on editable objects -- due 2016-06-09 -- OPEN

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

JD: Here is my proposal:

<joanie> Authors SHOULD limit the use of the password role to single-line

<joanie> elements which are editable. Authors MAY use the password role on

<joanie> elements which are not currently editable due to application-specific

<joanie> conditions. However, in that instance, authors MUST indicate that the

<joanie> element is read only by setting aria-readonly to true or using the

<joanie> appropriate native host language attribute. User agents MUST ignore the

<joanie> password role when it is applied to elements which are neither editable

<joanie> nor explicitly marked as read only.

<jemmaKu> +1

JD: Rich asked what the use case for a read-only password.
... An admin dialog to reset the password, when the user is not an admin.

<JF> if the private +1 came from me, it was intended to be public

JD: James suggested a mutli-line password (?)
... I don't think that's a real password but in any case, it is a SHOULD, not a MUST.

MC: I support Joanies text.

<fesch> +1

<JF> +1

JF: I sent a private +1 to Joanie. Now it is public

<jamesn> +1

RESOLUTION: Accept Joanie's proposal on action2080

MC: Now let's address my action

action-2079

<trackbot> action-2079 -- Michael Cooper to Draft ¨host language should¨ language for password that they should restrict elements it can apply to, with input from minutes of 2 june 2016 meeting -- due 2016-06-09 -- OPEN

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

<MichaelC> Proposal: https://github.com/w3c/aria/compare/master...ACTION-2079

MC: <Reads his changes>

<MichaelC> Using the <code>password</code> role on elements that would not accept passwords could create a security risk in conforming user agents, prompting users to enter a password in an inappropriate place where it could be accidentally exposed. Therefore, host languages SHOULD restrict use of the <code>password</code> role to elements that accept text input from users, and only when within a form submission context.

MC: There were some comments
... John suggested some edits.
... James did not support the form submission context.
... Joanie agreed with James, as did Rich (?)
... James pointed out there is no such restriction on input type="password"
... John, you don't agree?

JF: I'm not overly concerned with that.
... I think if it outside of a form is a strange thing.
... It kind of feels like a phishing attack.

CS: A lot of developers don't use forms anymore. They use scripts for submission.

JF: I'm just trying to keep this in check, but if everyone feels this way, I won't fight for it.

FE: Stuff in things like Angular.js, don't re quire a form submission.

JN: Exactly.

JF: I'm not going to die on this hill. I don't care.

MC: I think there is consensus here then, so remove the form clause.

JD: I don't have big problems with your statement, but yours is not quite in sync with mine.
... I'm suggesting host language restrictions, but yours are stronger.

MC: Likely mine needs changes.

JD: Your's is "host languages need to declare ?"

MC: So, something like "should restrict password role to…"

JF: There is only so much we can impose on a host language.
... There are instance where authors are creating a form-type element, where the role tells AT to echo back the rendered text.
... By definition, it works for something that accepts text input.
... Which isn't a radio button, for example.

MC: I think the two texts are actually complementary.

JD: Maybe Michael's action needs another week.

JF: We need a composite submission.

JD: Michael's action is that html-aam makes a specific statement about input type password.

MC: My action is providing a hook for that.
... It's weird to have a host language restriction in aria

JF: The host language we are talking about is HTML
... What other language?

MC, JD: SVG

JF: But, SVG doesn't really have a form input type thingy.

MC: That was projected to change, but I may be wrong about that.

FE: I don't know of any content editable elements in SVG.

MC: Even if html is the only host language that matters, I want my text to be more general.
... I'm not sure if you action item covers it Joanie
... Could we just add a sentence to what you just read Joanie?

JD: Sure.
... Feel free to add it to my branch.

MC: Let me write the sentence here.

<MichaelC> proposed for end of ACTION-2080 proposal: Host languages SHOULD document that the password role can only be used on elements that have these characteristics.

<MichaelC> proposed for end of ACTION-2080 proposal: Host languages SHOULD document that the password role can only be used on elements that are editable and not read only..

<joanie> +1

<JF> +1

FE: we might want to say "not permantly read only"
... Joanie pointed out that it might be toggled.

<MichaelC> proposed for end of ACTION-2080 proposal: Host languages SHOULD document that the password role can only be used on elements that are editable and not permanently read only.

JN: I hate to bring this up, but...
... Isn't that the obscuring the password text is toggled, but it doesn't change the role.

CS: There used to be CSS rules for Webkit that could do such toggling.
... Windows show the plain text for a brief period, but then obsures it.

JN: The way it is written is the screen reader will read what is on screen.

JD: That is what is in the spec.

JN: How does that work in Cynthia's case?

CS: I think the screen reader does something different than the visual experience.

<MichaelC> close action-2079

<trackbot> Closed action-2079.

MC: We have a friendly amendment. Any objections?

<fesch> q_

ACTION-2081 Draft wording for editorial note on password

JN: I have not done this. I have to re-read the comments I got.

testing

CS: Where does testing get discussed, Michael?

MC: Jon has sent up a sub group, but he hasn't got back to me.
... There is a mailing list as well.

CS: My guess is we will be working on github, but I'm not sure.

MC: We may want to split the tests out of the aria repo and into a test repo.
... We need to discuss this.

<MichaelC> public-aria-test@w3.org

MC: People need to contact me if they want to subscribe to the public-aria-test list.

MK: Should I paste in the new Issues into the minutes.

<mck> ISSUE-1034: Should spinbutton be a composite role? - Accessible Rich Internet Applications Working Group Tracker

<trackbot> Notes added to ISSUE-1034 Should spinbutton be a composite role?.

<mck> https://www.w3.org/WAI/ARIA/track/issues/1034

<mck> ISSUE-1035: Are additional roles or properties needed to help authors build interactive list and tree structures with complex items? - Accessible Rich

<trackbot> Notes added to ISSUE-1035 Are additional roles or properties needed to help authors build interactive list and tree structures with complex items?.

<mck> https://www.w3.org/WAI/ARIA/track/issues/1035

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

MC: Meeting is done. We will pick up next week where we left off.

- DRAFT -

Accessible Rich Internet Applications Working Group Teleconference

09 Jun 2016

Attendees

Contents

ACTION-2039 Update definition of aria-autocomplete

Treeitem, option re children presentational

ACTION-2079 and ACTION-2080 Draft ¨host language should¨ language for password

ACTION-2081 Draft wording for editorial note on password

testing

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output