- From: Joseph Scheuhammer <clown@alum.mit.edu>
- Date: Thu, 9 Jun 2016 14:10:00 -0400
- To: Accessible Rich Internet Applications Working Group <public-aria@w3.org>
Link: https://www.w3.org/2016/06/09-aria-minutes.html
Plain text version follows below:
[1]W3C
[1] http://www.w3.org/
- DRAFT -
Accessible Rich Internet Applications Working Group Teleconference
09 Jun 2016
[2]Agenda
[2] https://lists.w3.org/Archives/Public/public-aria/2016Jun/0047.html
See also: [3]IRC log
[3] http://www.w3.org/2016/06/09-aria-irc
Attendees
Present
Joanmarie_Diggs, fesch, MichaelC, Jemma, Cynthia, JF,
JaEunJemmaKu, Matt, Joseph, JamesN, Bryan,
Bryan_Garaventa, Stefan
Regrets
Rich, Léonie, Michiel
Chair
MichaelC
Scribe
clown
Contents
* [4]Topics
1. [5]ACTION-2039 Update definition of aria-autocomplete
2. [6]Treeitem, option re children presentational
3. [7]ACTION-2079 and ACTION-2080 Draft ¨host language
should¨ language for password
4. [8]ACTION-2081 Draft wording for editorial note on
password
5. [9]testing
* [10]Summary of Action Items
* [11]Summary of Resolutions
__________________________________________________________
<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> [12]http://www.w3.org/WAI/ARIA/track/actions/2039
[12] http://www.w3.org/WAI/ARIA/track/actions/2039
<MichaelC>
[13]https://lists.w3.org/Archives/Public/public-aria/2016Jun/00
58.html
[13] 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>
[14]https://lists.w3.org/Archives/Public/public-aria/2016Jun/00
58.html
[14] 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>
[15]http://rawgit.com/w3c/aria/action2039-autocomplete/aria/ari
a.html#aria-autocomplete
[15] http://rawgit.com/w3c/aria/action2039-autocomplete/aria/aria.html#aria-autocomplete
<MichaelC> changes:
[16]https://github.com/w3c/aria/compare/action2039-autocomplete
[16] 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
[17]https://www.w3.org/2016/06/02-aria-minutes.html#item02
[17] 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
[18]https://www.w3.org/2016/06/02-aria-minutes.html#item03
[18] 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>
[19]https://trac.webkit.org/browser/trunk/Source/WebCore/access
ibility/AccessibilitySpinButton.cpp#L81
[19] 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.
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> [20]https://www.w3.org/WAI/ARIA/track/actions/2080
[20] https://www.w3.org/WAI/ARIA/track/actions/2080
<MichaelC> Proposal:
[21]https://lists.w3.org/Archives/Public/public-aria/2016Jun/00
50.html
[21] 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> [22]http://www.w3.org/WAI/ARIA/track/actions/2080
[22] 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> [23]http://www.w3.org/WAI/ARIA/track/actions/2079
[23] http://www.w3.org/WAI/ARIA/track/actions/2079
<MichaelC> Proposal:
[24]https://github.com/w3c/aria/compare/master...ACTION-2079
[24] 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_
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> [25]https://www.w3.org/WAI/ARIA/track/issues/1034
[25] 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> [26]https://www.w3.org/WAI/ARIA/track/issues/1035
[26] https://www.w3.org/WAI/ARIA/track/issues/1035
<jemmaKu>
[27]https://lists.w3.org/Archives/Public/public-aria-test/
[27] https://lists.w3.org/Archives/Public/public-aria-test/
MC: Meeting is done. We will pick up next week where we left
off.
Summary of Action Items
Summary of Resolutions
1. [28]Accept action-2039 as proposed.
2. [29]Add editorial note to option, treeitem, and spinbutton
roles that their "children are presentational" status is
provisional
3. [30]Accept Joanie's proposal on action2080
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [31]scribe.perl version
1.144 ([32]CVS log)
$Date: 2016/06/09 18:05:13 $
__________________________________________________________
[31] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[32] http://dev.w3.org/cvsweb/2002/scribe/
[36] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
--
;;;;joseph.
'Die Wahrheit ist Irgendwo da Draußen. Wieder.'
- C. Carter -
Received on Thursday, 9 June 2016 18:10:16 UTC