- From: Brad Hill <hillbrad@gmail.com>
- Date: Wed, 17 Dec 2014 21:46:26 +0000
- To: Michael Cooper <cooper@w3.org>, Mike West <mkwst@google.com>, Brad Hill <hillbrad@fb.com>
- Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>, WAI Liaison <wai-liaison@w3.org>
- Message-ID: <CAEeYn8jqWHhTBTSLqRDTb3162T+NzRP9POZ2b7GPAJ+rVCQJHg@mail.gmail.com>
Michael, I made them a "SHOULD" rather than "MUST" because I'm not clear if such APIs always exist and how we can verify conformance to and interoperability for such a requirement as part of our REC-track process. So I thought... "there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course." But this is likely just my ignorance of the landscape. Are there examples of similar requirements in other specifications? If we are going to make this a MUST, are there particular APIs we can normatively reference and test frameworks we can use? thanks, Brad On Wed Dec 17 2014 at 12:38:33 PM Michael Cooper <cooper@w3.org> wrote: > Thank for your prompt response to the comments filed by the PFWG. The > group thinks the edits made largely address the comment. The PFWG has one > request for the changes implemented: the "SHOULD" statement you added > should be a "MUST". So the two instances of "... SHOULD also be made > available through accessibility APIs..." we request be changed to "... MUST > also be made available through accessibility APIs...". > > The rationale is that these requirements are very important for situations > to which they apply. They only apply when the relevant conditions stated in > the rest of the paragraph are active. So they are not across-the-board > requirements - but are critical when applicable. These relate to the > requirements of User Agent Accessibility Guidelines success criteria 4.1.1 > http://www.w3.org/TR/UAAG20/#sc_411 and 4.1.2 > http://www.w3.org/TR/UAAG20/#sc_412. (Those are provided for reference, > not as a request to add those to the specification.) > > > Michael > > > On 11/12/2014 6:53 AM, Mike West wrote: > > Brad's changes look reasonable to me. I've merged his patch, and will be > happy to make further changes if deemed necessary. > > Thanks for reviewing the spec! > > -mike > > -- > Mike West <mkwst@google.com>, @mikewest > > Google Germany GmbH, Dienerstrasse 12, 80331 München, > Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der > Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth > Flores > (Sorry; I'm legally required to add this exciting detail to emails. Bleh.) > > On Wed, Dec 10, 2014 at 3:46 PM, Brad Hill <hillbrad@fb.com> wrote: > >> Thank you, Michael. >> >> Please let me know if you believe the following changes are sufficient: >> >> https://github.com/w3c/webappsec/pull/110 >> >> -Brad Hill >> >> From: Michael Cooper <cooper@w3.org> >> Date: Wednesday, December 10, 2014 at 9:58 AM >> To: "public-webappsec@w3.org" <public-webappsec@w3.org>, WAI Liaison < >> wai-liaison@w3.org> >> Subject: [MIX] PF comments on Mixed Content - accessible indication and >> user controls >> Resent-From: <public-webappsec@w3.org> >> Resent-Date: Wednesday, December 10, 2014 at 9:58 AM >> >> The Protocols and Formats Working Group has reviewed the Mixed Content >> specification and has two comments: >> >> 1) Section 4.3 - UI Requirements http://www.w3.org/TR/2014/WD- >> mixed-content-20140722/#requirements-ux >> <https://urldefense.proofpoint.com/v1/url?u=http://www.w3.org/TR/2014/WD-mixed-content-20140722/%23requirements-ux&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=HU3cThGizwgsko8%2BWBMXZg%3D%3D%0A&m=XPcXAKUl3phy%2FY%2Ft%2BlvgAEh9qYPjZHSeKjorGTIZU5s%3D%0A&s=5c5f053ec7c7d182281966f064f0648c8da272411726617ad0fe54fa6652ffbd> >> >> There is a requirement that the UI have a visual indication as to >> whether the connection is secure or not: >> >> >> If a request for optionally blockable passive resources which are mixed >> content is not treated as active content (per requirement #3 above), then >> the user agent MUST NOT provide the user with a visible indication that the >> top-level browsing context which loaded that resource is secure (for >> instance, via a green lock icon). The user agent SHOULD instead display a >> visible indication that mixed content is present. >> >> >> It is important to have a requirement that the indication is also >> available to assistive technology. Current implementations have an image >> icon that is not made available to accessibility APIs. >> >> 2) Section 4.4 - User Controls http://www.w3.org/TR/2014/WD- >> mixed-content-20140722/#requirements-user-controls >> <https://urldefense.proofpoint.com/v1/url?u=http://www.w3.org/TR/2014/WD-mixed-content-20140722/%23requirements-user-controls&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=HU3cThGizwgsko8%2BWBMXZg%3D%3D%0A&m=XPcXAKUl3phy%2FY%2Ft%2BlvgAEh9qYPjZHSeKjorGTIZU5s%3D%0A&s=71fe814840bf2380b530e9334924d92417469034db7420a7920b26874757fded> >> >> There are some MAY statements about user agents offering controls to >> limit exposure to blockable passive content and active mixed content. Such >> controls need to be available to the assistive technology as well. >> >> For the PFWG, >> Michael Cooper >> >> > >
Received on Wednesday, 17 December 2014 21:46:55 UTC