This Wiki page is edited by participants of the WCAG Working Group. It does not necessarily represent consensus and it may have incorrect information or information that is not supported by other Working Group participants, WAI, or W3C. It may also have some very useful information.

SC Managers Phase1

From WCAG WG
Jump to: navigation, search


Contents

WCAG 2.1 SC Review Process/SC Management [DRAFT]

Success Criteria proposals from task forces will be reviewed as described below:

  • SC proposals submitted Dec 1 (completed)

In order to prepare the SC proposal for WG review:

  • Each proposal (represented by a GitHub issue) will have a “manager” who is assigned.
  • No manager will have more than two proposals at any one time.
  • The manager must not have been the primary driver for the proposal on the TF.

SC Manager Role

  • This is a Phase 1/Milestone stage where we are looking for provisional acceptance of SCs - and not final approval.
  • All current issues are set to Phase 1/Milestone.
  • Githhub is the main platform for commenting on any SC.
  • WBS is the main platform for voting on a candidate SC.

The Manager will:

  1. Read and understand the proposal, talking with TF members if needed
  2. Identify overlap/synergies with other SC proposals
  3. Identify major benefits and challenges related to the proposal
  4. Drive discussion on the GitHub issue thread and on WG calls related to the proposal
    1. A manager may raise an underlying issue on the WG list also (e.g. “hey, issue 1 is talking about contrast and we are getting stuck on what the right contrast level is and wanted to talk about this specific item in detail here”)
    2. Discussion may result in closing, deferring, or merging a proposal, which could eliminate the need for further steps for a proposal.
  5. Develop a pull request on GitHub containing the proposal, including any changes for consensus review.
    1. Fork the WCAG21 repository to your own GitHub account
    2. Create a branch off of the Master branch (use a logical name for the branch, e.g. Issue1023 or “highcontrastfocus”)
    3. Make the changes and create the pull request for the Master branch.
  6. When the Pull request is made:
    1. Provide the link to the original issue in the pull request comments.
    2. Provide the link to the pull request in the issue comments.
    3. Close the issue.

The Working Group will discuss the pull request in GitHub, on the list, and on calls where necessary. When a consensus view is reached in the view of the chairs, a Call for Consensus will be raised by the chairs.

SC pull request procedure

See the documentation on making branches, submitting, pull requests and using the SC HTML format for steps to make proposals the editors can incorporate.

GitHub Video help for SC Managers

Forking the WCAG 2.1 source file repository: https://www.youtube.com/watch?v=-J5REgcK1QY

Creating a new branch for SC changes: https://www.youtube.com/watch?v=285s7puQH9s

Current SC Managers

NOTE: Please add yourself to this list (with your Github username in the header also) along with details of any SCs that you are currently working on.

Here is the list of current candidate success criteria on Github.

Alastair Campbell (@alastc)

NOTES/STATUS

Glenda Sims (@Goodwitch)

NOTES/STATUS

Issues/Comments made on Proposed SC for Interactive Element Contrast (Minimum): 49 comments as of Jan 5, 2017. 22 Resolved. 27 Open and being reviewed.

Version 2 Changes (Jan 4, 2017) Incorporating Comments Round 1
  1. Changed from proposed Level A to proposed Level AA. (Why: To stay in sync with Issue 9. Suggested by Makoto, Bruce Bailey & AWK. Approved by LVTF.) When: Change made in wiki on 19:51, 7 December 2016‎
  2. Changed "selected indicator" to "selection indicator". (Why: To keep vocabulary consistent with WCAG 2.0. Wording change proposed by AWK and Maureen Kraft.) When: Change made in wiki on 20:56, 28 December 2016
  3. Move disabled element contrast to Silver because it needs preference control. (Why: Approved by LVTF. Action-93. Suggested by Michael Gower, Wilco, jnurthen, Joshue O'Connor and more). The color contrast needs for disabled form controls has conflicting solutions for some low vision users and some users with cognitive issues. Therefore, the color contrast needs for disabled elements needs a preference control and it will be well suited for Silver). When: Change made in wiki on 23:24, 28 December 2016‎ and 23:29, 28 December 2016‎
  4. Removed ( ) from non-text. (Why: For clarity. Suggested by Wilco.) When: Change made in wiki on 23:39, 28 December 2016‎
  5. Changed "input elements" to "user interface components". (Why: For consistency with WCAG 2.0 vocabulary. Suggested by Wilco.) When: Change made in wiki on 23:54, 28 December 2016‎
  6. Changed the term "graphical element" to "interactive image" for consistency with proposed glossary term. (Why: For internal consistency. Suggested by Wilco.) When: Change made in wiki on 00:09, 29 December 2016
  7. Changed "important" to "essential". (Why: To stay in sync with proposed SC Informational Graphic Contrast) Inspired by Alastair Campbell and comments made by Wilco and AWK. When: Change made in wiki on 00:23, 29 December 2016‎
  8. Added "outer" to immediate surrounding background. (Why: For clarity. Per Michael Gower's suggestion. To stay in sync with proposed SC Informational Graphic Contrast) When: 00:47, 29 December 2016‎
Version 3 Changes (Jan 29, 2017 - Feb 8, 2017) Incorporating Comments Round 2

50 comments as of Jan 29, 2017. 46 Resolved. 4 Open and being reviewed. See that latest version of this proposed SC at LVTF wiki - Interactive Control Contrast (Minimum) where Glenda makes changes first (when appropriate, Glenda asks Jim Allan to migrate approved changes to github).

  1. Changed px to CSS px (Why: For testability and consistency with Issue 9 ) Inspired by Wilco's comment in github. When: Change made on wiki 27-29 January 2017
  2. Added CSS px definition (Why: For clarity, testability and to parallel issue 9) Inspired by Wilco's comment in github. When: Change made on wiki 29 January 2017
  3. Removed references to interactive image(s) (Why: anything related to contrast within a graphic is moving to Issue 9 ) Inspired by Bruce Bailey's comment on WCAG survey 2016/11/20 and jnurthen on github. When: Change made on wiki 29 January 2017
  4. Renamed proposed SC from "Interactive Element Contrast (Minimum)" to "Interactive Control Contrast (Minimum)". And issue 9 is changing from "informational Graphic Contrast (Minimum)" to "Graphic Contrast (Minimum)". (Why: For simplicity and clarity, Issue 9 will cover contrast related to graphics. Issue 10 will cover contrast related to user interface components (like text inputs and radio buttons) and focus indicators, selection indicators. ) Inspired by Bruce Bailey's comment on WCAG survey 2016/11/20. When: Change made on wiki 29 January 2017
  5. Refined "immediate surrounding background" to "immediate surrounding color(s)" and adjusted definition of "immediate surrounding color(s)". (Why: For clarity and consistency with Issue 9 ) Inspired by jnurthen comment in github. When: Change made on wiki 27-29 January 2017
  6. Removed confusing / unnecessary glossary terms (Why: the proposed glossary terms of border line, medium width border and medium indicator caused confusion. Proposed SC has been simplified so these terms are no longer necessary) Inspired by Maureen Kraft, Bruce Bailey, Andrew Kirkpatrick When: Change made on wiki 27-29 January 2017
  7. Added examples ( (Why: For clarity) Inspired by Josh O'Connor and jnurthen's comments on WCAG survey 2016/11/20. When: Change made on wiki 29 January 2017
  8. Clarified that color contrast only applies to essential graphical objects (Why: The previously proposed SC text might have been misunderstood to mean that any and all graphical objects would need to meet color contrast requirements) Inspired by Maureen Kraft. When: Change made on wiki 3, February 2017
  9. Added test for selection vs non-selection (Why: Realized that I had not included a color contrast requirement for selected vs non-selected) Inspired by me working on sufficient contrast examples. When: Change made on wiki 3 Feb 2017
  10. Simplified SC Text (Why: SC Text was hard to understand) Inspired by Wilco. When: Change made on wiki 8 Feb 2017

Jake Abma (@jake-abma)

NOTES/STATUS

Wayne Dick (@WayneEDick)

NOTES/STATUS

Pull request due - Feb 4th [Josh]

David MacDonald (@DavidMacDonald)

NOTES/STATUS

Laura Carlson (@lauracarlson)

Issue 78 Adapting Text
Email
Minutes
Public and Member Comments
Related Issues
Research
Resolutions
Surveys
Techniques
Understanding Document
Wiki Pages

Katie Haritos-Shea (@Ryladog)

NOTES/STATUS

Marc Johlic (@marcjohlic)

NOTES/STATUS

  1. 62 Keyboard with AT - This may indicate a need for a change to the core SC 2.1.1.

Jon Avila (@mraccess77)

NOTES/STATUS

NOTE: This may indicate a needed change in core SC 2.1.1

Bradley Montgomery, Rachael (@rachaelbradley)

NOTES/STATUS

  1. 33 - Error prevention - PR imminent.

Andrew Kirkpatrick (@awkawk)

NOTES/STATUS

Josh O Connor (@joshueoconnor)

NOTES/STATUS

Erich Manser (@emanser)

NOTES/STATUS

Issue 79 Font Family is closed. It has merged with #78, and #74 into Ability to Override

Neil Milliken (@)

NOTES/STATUS

Status update requested - Feb 4th 2017

Thaddeus Cambron (@inclusiveThinking)

NOTES/STATUS

Familiar Design (Minimum) Based on questions from @awkawk. @lseeman suggested adding "help" and "navigation to help" to Glossary. I suggested the following definition based on a SC specific to help where help is defined as: Help - A mechanism provided to give a user access to help content, a support page or a support function that is reachable with one user action. @patrickhlauke asked for clarification as to what constitutes "one" in the definition above. As this definition comes from a different SC which is also under review I would like to take this to the larger group or to the Manager of that SC as any changes would need to be reflected in the original SC as well. Note: Need reference to original SC help definition for review.

Both @detlevhfischer and @patrickhlauke have concerns around the lack of current customization/personalization options available to the users. In addition both members stated concerns around the complexity of the rollback option. @inclusiveThinking would like the larger group to consider if there are any additional ways to support this SC. @detlevhfischer mentioned the possibility of a test of standard controls but indicated that this as a test may not lead to 100% conformance.

Familiar Design (Enhanced)

@detlevhfischer had similar concerns for this SC as were stated in Familiar Design (Minimum), specifically lack of current customization/personalization options available to the users. Use of standard controls were suggested but limitations were noted as per the comments above in Familiar Design (Minimum)

Consistent Navigation

@patrickhlauke suggested the following change to reflect the SC stance of the position of an element

"3.2.3 Consistent Navigation: Navigational mechanisms that are repeated on multiple Web pages within a set of Web pages occur in the same relative order @@ and position in the overall page layout @@ each time they are repeated, unless a change is initiated by the user. "

Thereby eliminating the phrase "in the primary modality of the content"

Status update requested - Feb 4th 2017

EA Draffan (@ eadraffan)

NOTES/STATUS

Status update requested - Feb 4th 2017

John Rochford (@JohnRochfordUMMS)

NOTES/STATUS

Pull request for Accessible Authentication SC

  1. 24 Manageable Blocks / #23 Accessible Authentication reviewed and discussed not currently accepted by WG.

https://www.w3.org/2002/09/wbs/35422/SC_review_Jan2017/results

Jim Smith (@jim-work)

NOTES/STATUS

Status update requested - Feb 4th 2017

PR work done by Thaddeus @inclusivethinking.

Mike Pluke (@mapluke)

NOTES/STATUS

Status update requested 4th Feb 2017

Jan McSorley (@jmcsorle)

NOTES/STATUS

Status update requested 4th Feb 2017

Chaohai Ding (@chaohaiding )

NOTES/STATUS

Re-assigned to Lisa 6th Feb. Status update requested 4th Feb 2017

Lisa Seeman(@lseeman)

NOTES/STATUS

Status update requested 4th Feb 2017

Steve Lee(@SteveALee)

NOTES/STATUS

Pull request for #39 Critical features

John Kirkwood(@citymouse)

Jeanne Spellman (@jspellman)

NOTES/STATUS

Status update requested 4th Feb 2017

Detlev Fischer (@detlevhfischer)

NOTES/STATUS

#61 Pointer gestures

Picked up SC 61. has been reworked to allow editing/viewing.

There is a comment by Microsoft #196 stating that complex vs. simple pointer gestures are not defined, that an exception is needed for situations where the use of multiple fingers and complexity gestures are essential, and that the SC should be scoped to exclude multi-user scenarios / be bound to single-user scenarios.

A comment by Webaim #264 wonders whether this SC is moot as it may already be covered by the proposed SC 2.5.3 Touch with Assistive Technology. The comment is gnerally supportive but would prefer to move the Pointer Gestures SC to level AA. I have responded

#66 Pointer inputs with additional sensors

SC 66 has been reworked to allow editing/viewing.

Comments have called the SC "a criteria awaiting a problem" and what it addresses an "outlier situation", seeing proximity / potential overlap with #61 Pointer gestures and #67 Device Sensor.

There is now also a Microsoft comment on Pointer inputs with additional sensors #194 finding the SC "a little too sweeping". calling for an exception for underlying function that requires input beyond x y coordinates, e.g. for scenarios such as painting and calligraphy.

Denis Boudreau (@dboudreau)

NOTES/STATUS

Issue 18
Public and Member Comments for Issue 18
Retrieved from "https://www.w3.org/WAI/GL/wiki/index.php?title=SC_Managers_Phase1&oldid=8079"