- From: Richard Schwerdtfeger <richschwer@gmail.com>
- Date: Fri, 10 Jun 2016 06:13:35 -0500
- To: Joseph Scheuhammer <clown@alum.mit.edu>, Matt King <mattking@us.ibm.com>
- Cc: Accessible Rich Internet Applications Working Group <public-aria@w3.org>
Matt, Please send a link to the final aria-keyshortcuts to me and cc the list. I would like to read it before rendering a decision. I assume these are non-normative at this point. I saw there were comments from Joseph as well that I hope you will be taking into account. Best, Rich > On Jun 9, 2016, at 1:10 PM, Joseph Scheuhammer <clown@alum.mit.edu> wrote: > > 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 Friday, 10 June 2016 11:14:08 UTC