w3c/wbs-design
or
by mail to sysreq
.
The results of this questionnaire are available to anybody.
This questionnaire was open from 2015-05-10 to 2015-05-19.
9 answers have been received.
Jump to results for question:
Please review the following GitHub issue response: Issue 86.
The link above references the specific comment containing the proposal, but feel free to review the discussion within the issue page.
Responder | |
---|---|
Makoto Ueki | I've been thinking that H69 is a sufficient technique for SC 2.4.1, but it is not required to meet SC 2.4.1. Understanding says "The intent of this Success Criterion is to allow people who navigate sequentially through content more direct access to the primary content of the Web page." So it would be sufficient if a heading (<h1> in many cases) indicates start of main content. "Providing heading elements at the beginning of EACH section of content" is not required for SC 2.4.1. This should be the other issue, but I'd like to point it out. |
Joshue O'Connor | + 1 to keeping h69: Response is generally fine (but IMO, AWKs is better) - we can discuss - some suggested small changes to Davids here: "H69 has been a sufficient technique for 2.4.1 for 6 years and has no tangible negative impact on sighted keyboard users, nor has there been any buzz on the blogs, or complaints from end users that we are aware of. Regarding better user agent support - this could be easily remedied by browser manufacturers in time - for example via a simple revision to the current Landmarks plugin. Therefore, given the long standing precedence, the lack of opposition to the status quo from end users, and the potential impact on existing WCAG conforming sites, we will leave H69 as a sufficient technique for 2.4.1. We will continue to periodically monitor new technologies and comments regarding this issue." |
Michael Cooper | Seems ok. Looking for a radio button to vote so. |
Kathleen Wahlbin | +1 to keeping |
Frederick Boland | +1 to keeping |
Laura Carlson | + 1 to keeping h69. Perhaps in the response mention the concrete positive impact for screen reader users. From the WebAIM survey, "Reliance on headings as the predominant mechanism for finding page information continues to increase." http://webaim.org/projects/screenreadersurvey5/ |
Marc Johlic | Reviewed and commented on in GitHub (+1 for keeping H69) |
Maureen Kraft | Entered comments in GitHub thread. |
Daniel Frank |
Please review the following GitHub issue response: Issue 69.
The link above references the specific comment containing the proposal, but feel free to review the discussion within the issue page.
Responder | |
---|---|
Makoto Ueki | This is a question I asked on behalf of WAIC (Web A11y Committee in Japan). Thanks so much for clarification. I'll share this with the committee. |
Joshue O'Connor | +1 |
Michael Cooper | The original wording is clearly in Gregg-ese. We need to be sure Gregg reviews the proposal, as he often has very specific reasons for his wording choices. To me the proposal seems ok, but not comfortable accepting the change without the GV review. We could put this in the errata for now, if accepted. |
Kathleen Wahlbin | +1 |
Frederick Boland | +1 |
Laura Carlson | +1 |
Marc Johlic | Reviewed and commented on in GitHub (+1 to proposed resolution) |
Maureen Kraft | |
Daniel Frank |
Please review the following GitHub issue (Issue 89) and the Proposed Response.
Responder | |
---|---|
Makoto Ueki | How can we judge if "the page author has done everything possible to conform to WCAG"? Andrew says that the question seems to be "what level of pragmatism is appropriate for allowing authors to claim partial conformance?"[1] And I responded to it with my suggestion [2]. For example, AddThis [3] uses CSS background images for the icons of sharing buttons so that users of Windows high-contrast mode can't see them. However, this is a very popular marketing tool. Actually some of my clients are using this tool. Even if confomance claim can't be made due to it, it would be desirable for them if they could make the partial conformance claim to show how accessible their websites are except for the tool. What do you think??? [1] https://github.com/w3c/wcag/issues/89#issuecomment-97454070 [2] https://github.com/w3c/wcag/issues/89#issuecomment-98319937 [3] https://www.addthis.com/get/sharing |
Joshue O'Connor | Too long. I suggest trimming it; <josh edit> "WCAG defines a statement of partial conformance when the page does not conform to WCAG only for reasons that are legitimately outside the author's control. It is important to recognize that this is a statement of non-conformance and there are users who will not be able to access this page. One reason that content may be outside the author's control is because it is being provided by a third party (blogs, portals, news sites). Web pages may also include content via third party libraries, plugins, or widgets. In practice, it may be possible to claim conformance for web pages that contain third party content. A platform or tool may provide guidance for how to address conformance problems when including it in another web page. Filtering third third party content so that only conforming content is allowed could help raise the bar. If it is not possible to monitor and repair the third party content, it may be possible to identify the non-conforming parts of the page to users. If the rest of the web page conforms to WCAG, such a page qualifies for a statement of partial conformance, third party content. Finally, when an author has made a decision to use that third party implementation, they should choose products that meets accessibility requirements. However, if the content can change without approval from the web page author, then a web page which once conformed may suddenly fail to conform, and the conformance of that web page is outside of the author's control. </josh edit> |
Michael Cooper | s/it is not relieve/it does not relieve/ I also wonder if we should change "will not be able to access this page" to "will not be able to access some content on this page". That leads into a need to discuss the non-interference conformance provision. I would think that a statement of partial conformance cannot be applied if there is a risk that the included content radically breaks accessibility of the entire page, e.g., via flashing content, keyboard trapping, etc. However, I don't see that the wording in WCAG specifically makes that a requirement - it's a *conformance* requirement, not a *partial* conformance requirement. Still, maybe the Understanding should at least point out that you should try extra hard to make sure included content doesn't violate the non-interference provision because it's extra bad. The last paragraph I found hard to parse for some reason. I think one think I'm looking for is for it to say "you still have to have made all the non-third party content conform before a statement of partial conformance statement become legit". The first para essentially says that but the context of the last para makes me think it bears repeating. |
Kathleen Wahlbin | |
Frederick Boland | |
Laura Carlson | Josh's idea of shortening would make it a lot simpler to understand. In addition when authors say, "that's a 3rd party tool or content and we can't control its accessibility" they should in no uncertain terms be made aware that they chose that 3rd party tool or content in the first place. I would suggest rearranging Josh's edit a bit to make that point clear right from the start. (I have witnessed many authors wanting to include uncaptioned 3rd party YouTube videos in web pages and are looking for a WCAG escape clause which condones that practice, instead of contacting the author and trying to get the video captioned.) <laura's edit of josh's edit> When an author makes a decision to use a third party implementation, they should choose products that meet accessibility requirements. However, WCAG defines a statement of partial conformance when the page does not conform to WCAG only for reasons that are legitimately outside the author's control. It is important to recognize that this is a statement of non-conformance and there are users who will not be able to access this page. One reason that content may be outside the author's control is because it is being provided by a third party (blogs, portals, news sites). Web pages may also include content via third party libraries, plugins, or widgets. In practice, it may be possible to claim conformance for web pages that contain third party content. A platform or tool may provide guidance for how to address conformance problems when including it in another web page. Filtering third third party content so that only conforming content is allowed could help raise the bar. Be sure to monitor any content that can change without approval from the web page author, as a page which once conformed may suddenly fail to conform. If it is not possible to monitor and repair the third party content, it may be possible to identify the non-conforming parts of the page to users. If the rest of the web page conforms to WCAG, such a page qualifies for a statement of partial conformance, third party content. </laura's edit of josh's edit> Of note: Sec. 51(a) of Settlement Agreement between the United States of America and Madison County, New York under the Americans with Disabilities Act covers third parties: "Ensure that its websites and all online services, including those websites or online services provided by third parties upon which the County relies to provide services or content, comply with, at minimum, WCAG 2.0 AA" http://www.ada.gov/madison_co_ny_pca/madison_co_ny_sa.html |
Marc Johlic | I like Josh's edit |
Maureen Kraft | |
Daniel Frank |
The WCAG group has discussed and conceptually approved an update to the consensus process for working group decisions. Below is a proposed draft of a Consensus Procedure document for review.
This document explains the decision process of the WCAG Working Group.
The Working Group strives to reach unanimous agreement whenever possible. However, at times this is not possible, and for the sake of continuing to work on important topics the group must arrive at a consensus decision and move forward. In the course of establishing consensus it is critical that all working group members have the opportunity to express their views for consideration so that all relevant information can be used in arriving at the conclusion.
1. Discussion on a topic proceeds until the chairs believe that all points of view have been expressed and the group has considered the variety of information presented. Depending on the topic, this discussion may take a couple of days or a couple of weeks, or more.
a. Discussion can take place in email on the WCAG mailing list, within the comment thread of a GitHub issue or pull request, or on a Working Group call.
2. When the chairs believe that the group is ready to come to a decision they announce a Call for Consensus either email to the Working Group's mailing list. The Call must remain open for a minimum of two working days.
a. The Call will contain pointers to the relevant discussion. This may include links to GitHub issues or pull requests, WCAG surveys, email threads, or meeting minutes topics.
b. Discussion on a WCAG teleconference may precede a Call for Consensus, but it may not replace the official Call for Consensus.
c. Issues that are regarded as editorial by the Chairs do not require a Working Group decision in order for the Chairs to address, and thus do not require a Call for Consensus.
3. Evaluating the Call for Consensus:
a. If no objections are received by the deadline, the draft decision becomes a formal decision of the Working Group.
b. If objections are received but the chairs believe the objections have already been considered and addressed and there is an overall consensus, the draft decision becomes a formal decision of the Working Group with objections. Objections are recorded as an appendix to the formal decision.
c. If objections are received that the chairs believe present substantive new information, or if the chairs believe there is not a clear consensus in the Task Force they will reopen the discussion.
4. The Working Group chairs record the Formal Decisions on the WCAG Decisions page on the wiki.
During discussion on a topic, participants are welcome to raise objections freely to help ensure that all available information can be considered and contribute to the best possible decision. However, when the chairs issue a Call for Consensus, objections should not be raised unless the individual strongly believes the decision is the wrong one in spite of discussion, and the individual cannot "live with" the decision. Compromise on points that the individual considers suboptimal but can "live with" is an essential part of group decisions that must meet various requirements.
If a participant believes the Chairs have not exercised sound judgment in following this policy, they should express their concern first to one of the Working Group Chairs, escalating if needed to the WCAG staff contact, and escalating if needed to the W3C Accessibility Domain Lead.
Choice | All responders |
---|---|
Results | |
I agree with the proposal as written | 5 |
I agree with the proposal with the following changes | 2 |
The Working Group needs to discuss this proposal further | 1 |
(1 response didn't contain an answer to this question)
Responder | WCAG Call for Consensus Proposal | |
---|---|---|
Makoto Ueki | I agree with the proposal as written | |
Joshue O'Connor | I agree with the proposal with the following changes | <grammar> 2. When the chairs believe that the group is ready to come to a decision they announce a Call for Consensus either [via] email to the Working Group's mailing list. The Call must remain open for a minimum of two working days. The Call will contain pointers to the relevant discussion. This may include links to GitHub issues or pull requests, WCAG surveys, email threads, or meeting minutes. <del> topics.</del> Why is TF mentioned here explicitly? Suggest removing: "c. If objections are received that the chairs believe present substantive new information, or if the chairs believe there is not a clear consensus <del> in the Task Force</del> they will reopen the discussion. 4. The Working Group chairs record the Formal Decisions on the WCAG Decisions page. <del> on the wiki.</del> |
Michael Cooper | The Working Group needs to discuss this proposal further | Good overall but think there are some gotchas we need to address: 1.a. Discussion can take place... - I'm reluctant to have the consensus policy say where discussion can take place, and by omission where it cannot. I prefer to say "using any recognized communication channel of the WG". That said, I'm worried about channels where if you miss it you've missed it - in particular IRC or some chat where if you didn't happen to be logged in at that time you didn't even know a discussion took place? Teleconferences have that issue too but at least are minuted so people can catch up. Somehow we need to ensure that everyone has a reasonable chance to participate in the discussion - without requiring we hold up the train just in case someone who was dawdling in the washroom wants to catch the caboose. 2.b. instead of saying "Discussion on a WCAG teleconference" I think it should be "a resolution recorded in a WG teleconference". Discussion can happen anywhere as previously noted. It's the teleconference resolution that we want to clearly state is not an official consensus in this policy. Yet I think we also want to underscore the value of such a resolution as a preliminary step. 2.c. "Issues that are regarded as editorial by the Chairs" there needs to be a way for people to protest the chairs' opinion of what's editorial. ...interrupted, hope to get back to this... |
Kathleen Wahlbin | ||
Frederick Boland | I agree with the proposal as written | |
Laura Carlson | I agree with the proposal as written | |
Marc Johlic | I agree with the proposal as written | |
Maureen Kraft | I agree with the proposal with the following changes | I feel 2 days is a bit short especially with different time zones. One may not see the call for consensus until 1 day has passed. Should we say 3 days to allow for 1 day for folks to receive notice? |
Daniel Frank | I agree with the proposal as written |
The following persons have not answered the questionnaire:
Send an email to all the non-responders.
Compact view of the results / list of email addresses of the responders
WBS home / Questionnaires / WG questionnaires / Answer this questionnaire
w3c/wbs-design
or
by mail to sysreq
.