See also: IRC log
<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
<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.
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"
+1
<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.
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.
+1
<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
+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_
JN: I have not done this. I have to re-read the comments I got.
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.
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/felt strongly/felt stronger/ Succeeded: s/serious restrictions in terms/serious limitations in terms/ Succeeded: s/There was not discussion/There was no discussion/ Succeeded: s/edtiorial/editorial/ Succeeded: s/submission form context/form submission context/ Succeeded: s/fishing/phishing/ Found ScribeNick: clown Inferring Scribes: clown Present: Joanmarie_Diggs fesch MichaelC Jemma Cynthia JF JaEunJemmaKu Matt Joseph JamesN Bryan Bryan_Garaventa Stefan Regrets: Rich Léonie Michiel Agenda: https://lists.w3.org/Archives/Public/public-aria/2016Jun/0047.html Found Date: 09 Jun 2016 Guessing minutes URL: http://www.w3.org/2016/06/09-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]