Draft Responses to Dec WD Issues
This page contains draft responses to issues logged in GitHub
Open issues: https://github.com/w3c/wcag21/labels/Dec%20WD%20Comment
If your issue is not listed, please add it as a heading 3 and make sure to indicate who drafted the response. See below for examples to follow in terms of organization of the information.
Please write the responses in a way that can be easily copied/pasted into the issue. For each issue the editors will add "Official WG response: Thank you for your comment." to the start, so it isn't necessary to include that in the response.
When an item is approved by the WG it will be indicated in the heading.
331
https://github.com/w3c/wcag21/issues/331
Proposed response:
Thank you for the comment. We will remove this note from the conformance section and address this topic in the Understanding document.
Alternate proposed response 1:
Thank you for the comment. We will replace this note with a note that reads "Authors including multiple views of a page (e.g. using break points to provide different views at different screen sizes) need to consider each view when evaluating conformance. Please see Understanding Conformance Requirement 2 for more information."
Alternate proposed response 2:
Thank you for the comment. This note is non-normative (as are all notes) but does represent the consensus view of the Working Group.
Alternate proposed response 3:
Thank you for your comment. Other methods of detecting the device being used tend to cause content to be served at a different URL, and we cannot ensure that it will not be the same page. We think the current wording strikes the correct balance as a clarification of conformance of a page in a way that is consistent with backward compatibility.
342
https://github.com/w3c/wcag21/issues/342
Thank you for the comment. Your core concern seems to be whether this SC is implementable and helpful. It is being added to the CR draft as an "at risk" item, so we aim to demonstrate this more clearly in the CR period.
366
https://github.com/w3c/wcag21/issues/366
Proposed response:
Thank you for the comment. We will remove this note from the conformance section and address this topic in the Understanding document.
Alternate proposed response 1:
Thank you for the comment. We will replace this note with a note that reads "Authors including multiple views of a page (e.g. using break points to provide different views at different screen sizes) need to consider each view when evaluating conformance. Please see Understanding Conformance Requirement 2 for more information."
Alternate proposed response 2:
Thank you for the comment. This note is non-normative (as are all notes) but does represent the consensus view of the Working Group.
Alternate proposed response 3:
The consensus interpretation of conformance is that a page includes each view of it that targets different screen sizes at that URL. We think this is backwards compatible with WCAG 2.0, and makes it clear. In addition to our consensus, an informal poll of evaluators found that 98% of evaluators already interpret this conformance requirement to include break points as part of the full page. https://twitter.com/davidmacd/status/885863118517264385
631
https://github.com/w3c/wcag21/issues/631 .
Thank you for your question. This Success Criteria was developed in the Mobile Task Force with the primary purpose to ensure that pointer targets are large enough for people with dexterity disabilities to hit the touch target in mobile, with the additional benefit of providing larger click targets for mouse users on desktop who have dexterity disabilities. This was not covered in WCAG 2.0. The task force looked at a number of studies and other standards, such as the BBC Mobile Guidelines. One study demonstrated that some people with dexterity disabilities needed a target size of 100px by 100px. So we knew that we could only provide a minimum value and encourage the author to make targets as large as possible. The idea of the minimum size requirement in the success criteria was to choose a value as large as possible without negatively impacting design. Google mobile developer guidelines recommended 48px by 48px.
We took Apple's recommendation and amended one dimension in response to comments that 44px by 44px was too large for many interfaces, especially vertical lists of text links, and we added a list of exceptions, including specifying a smaller dimension (22px) for some situations. Unfortunately, the SC language was not able to be agreed on within the Working Group, and as a result the AA version of this SC has been removed from the draft.
636
https://github.com/w3c/wcag21/issues/636 (answer by Lisa)
The new wording just requires that the purpose is programmatically determined. We will be adding techniques and have user agent support before we leave CR as per are exit criteria - see https://www.w3.org/WAI/GL/wiki/WCAG_2.1_CR_Exit_Criteria.
It is worth noting that success criteria specify what needs to be done but are never technology specific. How to reach them or what terms to use is always left to techniques. There are often more than one way to achieve success (such as using native html, xforms or ARIA)
651
https://github.com/w3c/wcag21/issues/651
Proposed response:
The SC has been updated to use what browsers currently implement, and there was already a great deal of overlap between what was required for inputs, and the HTML list.
Once implemented, it seems unlikely that the browsers (and therefore the HTML spec) would reduce the list, unless there is a security issue with particular items.
In future iterations that expand this requirement, the working group hopes there will be a stable specification to directly reference for that purpose, but this seems to be a reasonable starting point.
The SC text has been updated to show that it should only be used in technologies that support it, and the understanding and techniques will clarify that.
666
https://github.com/w3c/wcag21/issues/666 (Lisa) Thank you for your feedback. We agree that the wording "a publicly available vocabulary" is problematic. It has been changed in the latest version.
683
https://github.com/w3c/wcag21/issues/683
Thank you for the comment. It is too late to address these changes, and the changing of existing SC was out of scope for WCAG 2.1, but we will mark this issue with the "defer" label to ensure it is considered at an appropriate future time.
684
https://github.com/w3c/wcag21/issues/684
Proposed response: We acknowledge your considered feedback and stance on the SC 1.3.4, however many in the working group feel that this important success criterion is a part of a suite that can create a cohesive personalisation matrix that can be built upon in the future, and with SC 1.3.4 and the now-reduced requirements there are implementations that support this SC. For SC 1.3.5, the SC will be listed as "at risk" in order to establish whether a sufficient level of implementations exist. This work can be continued either within WCAG 2.2 or even in other fora but many in the group support these SC and inclusion within WCAG 2.1.
687
https://github.com/w3c/wcag21/issues/687 Thank you for the comment. The Working Group was not able to reach consensus on Target Size, and as a result the Target Size (SC) is now removed from the Editor's Draft. The Target Size (Enhanced) SC at AAA will be renamed to "Target Size".
691
https://github.com/w3c/wcag21/issues/691
Thank you for your comment. We have introduced and modified the definition in the time since the last Working Draft. Your comment is not on the last Working Draft but on the editor's draft.
693
https://github.com/w3c/wcag21/issues/693
Thank you for your comment. We have removed the definition that included the "publicly available vocabulary" wording.
694
https://github.com/w3c/wcag21/issues/694
Thank you for your comment. We will mark this issue with the "implementation follow up" label for work in the understanding document.
698
https://github.com/w3c/wcag21/issues/698
Thank you for the comment. The language of the SC has changed substantially and we believe that it addresses your concerns.
700
https://github.com/w3c/wcag21/issues/700
Proposed response:
Thank you for the comment. The WG used the discussion in this issue to inform the development of this SC. Please review the current version of the SC in the editor's draft.
701
https://github.com/w3c/wcag21/issues/701
Proposed response:
Thank you for the comment. The Working Group was not able to reach consensus on Target Size, and as a result the Target Size (SC) is now removed from the Editor's Draft. The Target Size (Enhanced) SC at AAA will be renamed to "Target Size".
702
https://github.com/w3c/wcag21/issues/702
Proposed response:
Thank you for the comment. The Working Group has elected to retain the "user agent control" exception, but is offering a AAA version of Target Size.
703
https://github.com/w3c/wcag21/issues/703
Proposed response:
Thank you for the comment. The WG did not decide to add a definition for input modalities as both "input" and "modalities" are used in WCAG 2.0, so it is important to continue to use these terms in the conventional ways rather than potentially redefine the terms.
704
https://github.com/w3c/wcag21/issues/704
Proposed response:
This SC is focused on motion, but we will mark this comment as "defer" to ensure it is review an an appropriate time for future consideration.
705
https://github.com/w3c/wcag21/issues/705
Thank you for the comment. We will clarify this in the understanding documents.
706
https://github.com/w3c/wcag21/issues/706
Proposed response:
Thank you for the comment. The Working Group has not made changes to address your points but these may be possible to address through editorial changes in CR.
707
https://github.com/w3c/wcag21/issues/707
Proposed response:
> This SC seems very complicated. Is it practical for implementation at present? How would it be satisfied?
The SC has changed in ways for which implementations already exist, using the autocomplete/autofill features in browsers.
> Will the purposes in 7.1/7.2 be translated into languages other than EN?
This will depend on translations of the HTML 5.2 specification.
> Will these be implemented in ARIA?
That will depend on the ARIA personalization work, but we expect that they will.
> Which semantic schemas are user agents and assistive tech expected to recognise?
The SC has changed in ways for which implementations already exist, using the autocomplete/autofill features in browsers.
> Some phrases are very similar, particularly sign in/sign up/sign out. Will users appreciate the difference?
This is no longer an issue with the new wording.
> How granular should markup be for multi-field inputs such as address?
Developers will follow the guidance for the autofill meanings in the HTML 5.2 spec.
> "Credit card" appears twice in 7.2.
This is no longer an issue with the new wording.
> "Credit card" maps to an element containing multiple inputs? Or is it applied to every credit-card related input individually?
Developers will follow the guidance for the autofill meanings in the HTML 5.2 spec.
> "URL" (7.2) - will users appreciate that this markup only relates to URLs related to themselves? Would it apply if a user was asked "Enter the URL of your favourite news website"?
We will make sure to cover this in understanding but for the news website example it would not apply.
> "Birthdate" (7.2) - Does it have to correspond to the user or does it apply to any birthdate (e.g. family members in genealogy, insurance, etc.)
Only to the user.
708
https://github.com/w3c/wcag21/issues/708
Proposed response:
Thank you for the comment. The CSS pixel is defined and in the definition there is a reference to the CSS specification for additional information. We will also make sure to clarify this and provide examples in the Understanding document.
709
https://github.com/w3c/wcag21/issues/709
Proposed response:
Thank you for the comment. We are marking this with the "implementation follow up" label for work in the understanding documents.
710
https://github.com/w3c/wcag21/issues/710
Proposed response: (from Laura)
Thank you for the comment. As Alastair stated, a bookmarklet and a stylish plugin exist. Alternatively the user CSS is:
* {
line-height: 1.5 !important;
}
p {
margin-bottom: 2em !important;
}
* {
letter-spacing: 0.12em !important;
}
* {
word-spacing: 0.16em !important;
}
714
https://github.com/w3c/wcag21/issues/714
Thank you for the comment. We have changed the text of the SC significantly, and removed the definition. We believe that these changes address your concerns.
715
https://github.com/w3c/wcag21/issues/715 (Answer by Detlev)
Thank you for your comment. The text of SC 2.5.1 Pointer Gestures focuses on the need for alternatives to path-based or multipoint gestures. The Understanding text makes it clear that this in no way restricts authors from implementing complex gestures. It states explicitly: "When they implement complex multi-point or path-based gestures, they should ensure that the functionality can also be operated via single-point activation." This also applies to pinch-to-zoom gestures. They can and should be supported but another way to zoom content should be available (e.g., appropriately labelled [+] and [-] icons).
As to panning with two fingers, the most frequent implementation of Google maps included on a web page offers an alternative in that a shift of the visible section can also be achieved by zooming out via the [-] button and then zooming in on any particular location via double tapping, a gesture which is included in single pointer. This is certainly more cumbersome and can be tricky if the target is near the edge of the visible map section, but arguably it would qualify as alternative.
716
https://github.com/w3c/wcag21/issues/716
Thank you for your comment.
> 1. Does every form-submission need an ‘un-submit’? (seems impractical)
No, the SC states that only 1 of the 4 conditions must be true (and typically **only** one will be true). By far, the easiest way to pass this for a single click operation, as with most form submissions, is via the first possibility of no down-event. The native user agent behavior of a button is to only fire on the up-event. If, for example, the form could be submitted after a drag and drop, then a mechanism to abort could simply be a dialog asking "Are you sure you want to submit this?". The distinction is that an abort would cancel the function before it executes whereas an undo would reverse it after the fact.
> 2. In Understanding, more guidance is needed about ‘Abort or Undo’
Yes, we agree. The Understanding document reflects a slightly older version of this SC and will be updated in the coming months. In the meantime, a brief explanation for the Abort or Undo possibility is to allow for operations which must use the down-event, such as drag and drop or other gestures, to satisfy the criterion. By simply providing an abort possibility (e.g. via a confirmation dialog) or the ability to undo the action, users are afforded a measure to fix accidents for these types of events. Please see issue #380 for some additional details on this criterion's latest revision.
717
https://github.com/w3c/wcag21/issues/717 (Answer by Detlev)
Thank you for your comment. We address the two issues you are raising in turn.
1. Layman's definition of CSS Pixel:
A definition of 'CSS pixel' exists in the WCAG 2.1 draft: https://www.w3.org/TR/WCAG21/#dfn-css-pixels
The concept of CSS pixel is unfortunately not easily explained in lay terms. We believe that for people implementing or testing the SC, the definition needs to be technically precise.
Due to the wide range of physical screen resolutions and device-reported (virtual) resolutions, measuring target size is only reliably possible by reference to CSS pixel dimensions. There is free software available to measure target sizes on screen, for example, "A ruler for Windows" http://www.arulerforwindows.com/index.html https://www.w3.org/TR/WCAG21/#dfn-css-pixels
To address your concern, we suggest to add the following introductionary sentence:
"CSS pixel is a concept that separates the visible area, or pitch, of a CSS pixel from the actual physical screen pixels used to represent it. This allows for an objective test across devices rather than tests which are completely dependent on the end user device, of which the author has no knowledge or control."
2. Inline target loophole
Several public and member comments to drafts of WCAG 2.1 have indicated that the application of the target size requirement to inline text targets would have a significant impact on screen layout, especially as adjacent lines would need a wide line spacing or a large text size if they are to meet the requirement. This can negatively impact usability as it would reduce the amount of text visible at the same time. The WG therefore decided to exempt targets in inline text .
718
https://github.com/w3c/wcag21/issues/718
Thank you for the feedback. We do not believe that this SC conflicts with other SC, and we will mark this issue with the "implementation follow up" label to address the other parts of your comment in Understanding.
719
https://github.com/w3c/wcag21/issues/719
Thank you for the feedback. 1.3.4 is offered at AA in the latest draft.
720
https://github.com/w3c/wcag21/issues/720
Thank you for the comment. At this point, there is a strong likelihood that 1.3.4 will be in the WCAG 2.1 recommendation, but focused only on purposes for input elements.
721
https://github.com/w3c/wcag21/issues/721
(Detlev) This has RNIB comments to many SCs in one issue.
Proposed responses https://www.w3.org/WAI/GL/wiki/Draft_Response_issue_721
722
https://github.com/w3c/wcag21/issues/722
Thank you for your comment. The Working Group came to a different conclusion, including others from your organization. We hope to gain further data to support this change in the implementation testing during CR.
723
https://github.com/w3c/wcag21/issues/723
Thank you for your comment. The updated SC now addresses both of your concerns as the list of link and button purposes has been removed and the input purposes are based on the HTML 5.2 autofill values.
724
https://github.com/w3c/wcag21/issues/724
Thank you for your comment. The SC was not designed to account for situations where a label is not presented as text. The scenario you describe is worth considering for a future release, so we will mark this issue as "defer" to ensure that it is reviewed at an appropriate time.
736
https://github.com/w3c/wcag21/issues/736
Proposed response: https://www.w3.org/WAI/GL/wiki/Draft_Response_issue_736
Issues that have been addressed
150
https://github.com/w3c/wcag21/issues/150 Assigned to Goodwitch:
Proposed Response (by Goodwitch): Thanks for your comment, Scott. We think we have addressed your concerns in the latest version of this SC and the updated Understanding Document.
SC Changes - In the first draft of WCAG 2.1 (20170228) the proposed SC text for Graphics Contrast had used "essential" in both the positive and in the negative (as part of an exception). Based on your feedback (and feedback from others) we refined this SC text to only use "essential" as part of the exception. This language is parallel to the way "essential" is used in WCAG 2.0 SC 1.4.5 Images of Text.
Understanding Changes - Examples to clarify this SC have been created in the draft understanding document that is published here https://rawgit.com/w3c/wcag21/graphics-contrast/understanding/21/graphics-contrast.html More examples and sufficient techniques will continue to be added to further enhance understandability and consistency in testing.
162
https://github.com/w3c/wcag21/issues/162
Thank you for the comment. The Working Group will add content to the Understanding document as indicated in the issue responses. We will also mark this issue as "defer" to ensure that it is reviewed for more comprehensive changes in the Silver timeframe.
211
https://github.com/w3c/wcag21/issues/211
Proposed response: https://www.w3.org/WAI/GL/wiki/Draft_Responses_to_Dec_WD_Issues_211
260
https://github.com/w3c/wcag21/issues/260
Proposed response (from AWK): Thank you for your comment. Since your comment was logged we have changed the SC and believe that the new SC language (see in editor's draft: http://rawgit.com/w3c/wcag21/master/guidelines/index.html) addresses your concerns.
282
https://github.com/w3c/wcag21/issues/282
Proposed response (from AlastairC): Thank you for your comment. Since your comment was logged the SC has changed significantly. Relevant changes include: The combination of concepts for 'Graphical Objects' and 'Required for understanding' which allow for a more granular testing approach, and they allow for small overlaps. It means there are many more options in terms of colours and design options. Also, the level of contrast has been reduced to 3:1 across situations. There are examples included in the understanding document, and more will be added.
The Low vision task force has consulted with several researchers in the area, and while there is little direct research, their view was that the contrast level should be similar to reading text. However, for simplicity and feasibility the TF accepted the reduction to 3:1.
261
https://github.com/w3c/wcag21/issues/261
Proposed response (from AWK): Thank you for your comment. Since your comment was logged we have changed the SC and definition of target and we believe that your concerns are addressed. First, we are changing the first sentence of the definition to:
Region of the display that will accept a pointer action, such as the interactive area of a user interface component.
Second, regarding the concern about inline content such as footnotes, we now have an exception for links in a sentence or block of text.
We hope that these address your concerns.
408
https://github.com/w3c/wcag21/issues/408
Proposed Response (by AWK): Thank you for the comment. The use of "essential" in WCAG 2.1 is needed in some of the new SC as a way to convey an exception for content that must be presented in a specific manner and it is useful to make consistent use of the defined term for this purpose. In the SC identified the term essential refers to the specific way a graphic is presented, rather than the graphic itself being essential. We will clarify this in the understanding document.
"Essential" is a defined term in WCAG, meaning "if removed, would fundamentally change the information or functionality of the content, and information and functionality cannot be achieved in another way that would conform".
520
https://github.com/w3c/wcag21/issues/520
Proposed Response (by AWK & David MacDonald): Thank you for the comment.
You make four main points:
- The WCAG development process excludes people with intellectual or learning disabilities
- Request for three new Success Criteria and a glossary item
- Navigation to plain language summary
- Plain language summary
- Plain language summary of main pages
- Request for modification of SC 3.1.2
- WCAG 2.1 doesn’t include measures for people with intellectual and learning disabilities
It has been very important to the Working Group that people with various types of cognitive disabilities are included in the work of the group. We formed a task force for cognitive accessibility and welcomed many new members into the working group, many of whom either have some type of cognitive disability or work regularly on the topic. There is no question that the process of developing a specification with a group of almost 100 people providing input can be taxing due to the volume of email, wiki page updates, and spec updates that take place, but the W3C and the Working Group are committed to supporting the needs of any group members to help ensure that it is possible for anyone to participate to the greatest extent possible. Still, we recognize that there is always room for improvement and are open to any suggestions you may have. Although our COGA task force did a significant amount of background research, and an extensive Gap Analysis, it appears that a Success Criteria for a Plain Language Summary as found in your comment was not proposed by any stakeholders in the timeframe for WCAG 2.1. However, there is a proposed Success Criteria called Identify Common Purpose which may allow personalization and simplification of interfaces.
Regarding the inclusion of requirements for people with intellectual and learning disabilities, while we agree that the set of Success Criteria does not address every possible improvement that end users might benefit from, there are substantial challenges to ensure they meet the following acceptance criteria for Success Criteria both in WCAG 2.0 and 2.1:
- Be testable through automated or manual processes.
- Apply to all content (including many human languages - internationalization) unless preconditions for the application of the success criteria are explicitly identified.
- Apply across technologies to the greatest extent possible. (Technology-specific issues should usually be addressed in Techniques.)
- Have Success Techniques which demonstrate that each Success Criterion is implementable, using readily-available formats, user agents, and assistive technologies.
See: https://www.w3.org/WAI/GL/wiki/WCAG_2.1_Success_Criteria.
These are some of the core requirements for Success Criteria that are very important but do set a challenging bar for new criteria to meet. If Success Criteria are included that do not meet these requirements there is a strong risk that WCAG 2.1 might not gain consensus or might not be adopted. Of the currently 18 new Success Criteria, approximately half are viewed as providing some benefit for users with cognitive disabilities.
We should also mention that WCAG 2.0 provides important help for people with cognitive and learning disabilities. We hope that there will be significant advances in Assistive Technology for people with cognitive and learning disabilities in the future, which may facilitate further WCAG requirements upon authors and leverage more of the existing requirements.
The deadline for introducing new Success Criteria closed over the summer as a result of the tight Working Group Charter timeline. However, we will mark this issue with a label (“defer”) to ensure that we can review these at the right time when we are able to review new proposals. This also impacts the suggestion for a definition since that definition is related to the proposed new criteria.
We can provide it to the Cognitive Task Force (COGA) for consideration in a future version. It would impact the most important part of most web template designs and we expect there would be significant response from industry, so any objective research and studies your team can provide may help the COGA team with justifying this UI requirement universally across all web sites may be helpful.
The suggested Amendment Success Criterion 3.1.2 Language of Parts
Amending existing WCAG 2.0 Success Criteria is not permitted for WCAG 2.1 development, so in addition to the timeline consideration above, this suggestion would not be possible during this round of development.
We can provide it to the Cognitive Task Force (COGA) for future consideration. In addition to the concerns about impact on site design, there is currently no assistive technology we know of that could make use of programmatically determined summaries in plain language. We suggest that this be demonstrated to the COGA team.
Insert new Criterion 3.1.7: Plain Language Summary of site
We extensively examined several proposals for plain language requirements in WCAG 2.1. We went through many iterations and we were unable to find a way that they could meet the internationalization requirements for an Success Criteria that could apply to "all content", and also there was some concern about requirements for freedom of expression. Regarding applying a plain language to a summary, these concerns may or may not be able to be overcome.
We can provide it to the Cognitive Task Force (COGA) for future consideration.
Ensure the summary page is clearly identified by a non-verbal icon.
In addition to the timeline considerations above, we have had trouble gaining consensus on specific icons in the past. There are different cultures and different environments which may or may not approve of a particular icon design. We know of no such internationally recognized icon. WCAG strives to apply across the entire web to all countries and all languages, and so we'd like to hear about how we can ensure that a requirement for an icon could meet this need.
Insert new term in Glossary
We extensively examined several proposals for "plain language" requirements in WCAG 2.1. We went through many iterations and we were unable to find a way that they could meet the internationalization requirements for a Success Criteria. Also, there was some concern about requirements for freedom of expression.
There is a strong possibility that there are ideas that the Working Group has simply not considered yet. Fortunately, the Working Group is committed to updating the specification far more rapidly than has been done in the past (targeting every 2 years), so these ideas and others will be able to be considered more fully in the near future.
601
https://github.com/w3c/wcag21/issues/601 Assigned to JOC:
Proposed Response (by JOC): Thank you for your observation. We believe that you refer to section 7.1 Common Control Purposes" https://www.w3.org/TR/WCAG21/#control-purposes. The Working Group will add a item to represent "skip to" links.
602
https://github.com/w3c/wcag21/issues/602
Proposed Response (by AWK): The list of purposes is explicitly not requiring that the author use the specific text to identify a purpose, so adding the requirement to use the listed name is different than what we intended. For example, the "Table of Contents" purpose may be referenced using a different term depending on whether the author is incorporating metadata from one schema or another - one schema might use "toc" and another might use "tableOfContents" but as long as they are aligned with the purpose expressed in the list (and as long as there is accessibility support) either would be sufficient.
605
https://github.com/w3c/wcag21/issues/605 Assigned to JOC:
Proposed response (by Mike Gower):
The initial goal of this SC was broader in scope but various considerations were identified which led the authors to keep the scope contained. Instead the intention is to list Best Practices and Advisory Techniques which could address broader Changes of Content. To that end, the SC language will not be changed.
Here are specific responses to some of the points raised in the issue:
> addresses the implementation of status messages, but doesn't say there needs to be a status message (essentially you can pass by not having a status message)
That is by design. WCAG has a history of defining content requirements when the content is present.
Any attempt to make status messages a requirement will inevitably lead to poor implementations that make applications unusable by screen reader users -- the exact opposite of the goal. It was felt that significant scrutiny is given by designers to information they add to the UI. Restricting the SC to cover such information, where it does not alter a user's context (no change of context), seemed like a way to ensure messages were appropriate and limited.
> indicates that the info be presented by AT without receiving focus
That is not exactly what the SC is saying. It defines status messages as items that do not take focus (change of content without being a change of context), and _then_ makes requirements where such items exist. The SC does not restrict messages from being displayed in a dialog, for example. Such a message is a change of context and so does not meet the definition of a status message, and so is not covered by it (being instead covered by 4.1.2).
> The need (and reasonable implementation) is not limited to markup languages... An interactive book implemented in Swift or Objective-C for iOS can certainly easily provide notification through AT, for example.
The working group spent considerable time debating removing the markup language restriction. In the end, the group felt there is not enough research, evidence or best practices to apply this to other technologies. WCAG 2.0 and 2.1 apply to content at a URL. However, we'd be glad to have you propose a technique for how to apply this to other technologies that we could add as a best practice for those who may be trying to apply WCAG to content not at a URL.
> If a change of content causes new content or functionality to appear on the screen, at least one of the following is true:
We believe this effectively means "For each change of content at least one of the following is true:" We had several iterations with a similar approach to this, covering similar scenarios. All were abandoned due to nuances of implementation or testing. Some of those have been identified below.
> The new content appears directly after the control that triggers it in the reading order.
If the new content is a user interface control, this will likely be detected by screen readers. (Although issues with latency can cause focus issues; for example, where the user's act of leaving a control triggers a change, the user's focus may move to the next existing item before coding updates the DOM, thus the user bypasses the new control.)
But what if the new content is an element that does not take focus? If the screen reader user has previously perused the page and is now navigating by pressing Tab, how is the screen reader user to know the new information exists? Since an author could use this bullet to bypass notifying users (the first bullet), it seems to lose a key accomplishment of the current SC language.
> For content that is updated on a regular basis, or is updated so frequently that status messages may be disruptive, the user is advised of the type and frequency of updates (e.g. through a section heading or label)
These "regular basis" and "disruptive" parameters would have to be defined in a way that was testable. The manner of advising the user would itself be quite difficult to establish in language that ensured it was testable. There is danger that this would be poorly implemented and would degrade the experience for a screen reader user. Perhaps in future iterations of WCAG we can find standardized and testable ways of notifying users of content that updates frequently without this risk of interfering with their experience.
Some examples of interactions which may not be covered/considered by your alternative proposal:
- chat clients and other dynamic interactive content where the content changes are related to the primary page but not ultimately initiated by the user
- twitter feeds and other updating content whose frequency of change and nature of content changes can vary markedly based on parameters beyond the author's control or ability to predict accurately.
- existing content that is altered rather than content that is added (e.g., the items in a select is updated based on a user's chosen value in a control, such as the choice of a country updating the values in the "State/province" select)
608
https://github.com/w3c/wcag21/issues/608
Proposed response (from AWK):
We are closing this issue as it is redundant to issue #609.
609
https://github.com/w3c/wcag21/issues/609
Proposed response (from AWK):
We are happy to make the changes from "which" to "that" for the WCAG 2.1 SC, glossary definitions, and within the "common purposes" section in order to make the guidelines more clear. We cannot change all of the suggested items, including boilerplate text and text within WCAG 2.0 glossary items. The main change needed to make it clear that sentence parts now starting with "which" are restrictive clauses is dropping the comma. The comma will be removed in cases where we need restrictive clauses.
613
https://github.com/w3c/wcag21/issues/613
Editorial. Closed by AWK
614
https://github.com/w3c/wcag21/issues/614
Editorial. Fixed and closed by AWK
615
https://github.com/w3c/wcag21/issues/615
Editorial. Fixed and closed by AWK
616
https://github.com/w3c/wcag21/issues/616
Proposed response (from AWK & AlastairC):
The Working Group made the decision to not modify existing SC from WCAG 2.0, which is why these requirements are in a new SC. If you have any suggestions for an SC title that would address your concerns, please suggest it.
From the suggestions in the thread, "Non-text contrast" got the most support. As a term it is wider in scope than the criteria itself, but it aligns with WCAG 2.0 reasonably well. That change has been made in a new draft.
617
https://github.com/w3c/wcag21/issues/617
Proposed response (from AWK):
We agree that there is a potential for confusion, and have made a change to the SC text to read:
"User Interface Components: Visual information used to indicate states and boundaries of user interface components, except for inactive components or where the appearance of the component is determined by the user agent and not modified by the author;"
618
https://github.com/w3c/wcag21/issues/618
Proposed response (by AWK):
The first two items in your comment are editorial and have been changed as suggested. Regarding the comment about the use of "social Security" we will change the SC text to use your suggestion of "National identification number" as follows:
"Authentication process involves basic personal identification information to which the user has easy access, such as name, address, email address, and National identification number."
619
https://github.com/w3c/wcag21/issues/619 Assigned to JOC and Detlev
Proposed WG response (Detlev)
Thank you for your suggestion. We agree that for interactions that include activation by positioning the device in a particular geographic location (your virtual fountain example), the requirement to provide alternative means of input does not apply. However, pointing a phone in the direction of a virtual location would still be a problem for a user with a motor impairment or a mounted device, so this would not negate the need for keyboard/pointer-accessible alternative modes of input. We believe the provision of alternative accommodations like the one you suggest could be included in a future SC focused on the use scenario of AR / Vr applications, and we are marking this issue as "defer" to ensure that it is reviewed at an appropriate time.
622
https://github.com/w3c/wcag21/issues/622 Assigned to Detlev
Proposed response (Detlev)
Thank you for your comment. You describe usage scenarios where input happens not via a particular user motion, but via the position or orientation of the device. This issue is likely to become more important with the spread or AR / VR use scenarios. However, we believe it can be separated from the use case of motion actuation where motion is relative to the device and the exact position (e.g. on the z-axis, distance to ground) seems less relevant. The case of orientation (no position lock unless by user choice, content adapts to user-chosen orientation) seems already addressed by the SC 2.6.2 Orientation.
You raise an interesting issue when you talk of alternatives other than user interface controls that still use motion but adapt in other ways (e.g., by lowering AR / VR objects for wheelchair users), motivated by the aim to not negate the full experience for wheelchair users (and many others). While different accommodations are certainly useful and should be encouraged, they would not negate the need for a means of input that works with keyboard and pointer interfaces. (An analogy might be sign language: Having a sign language version of a video talk is great, but it does not negate the requirement for captions.) You make the point that in the future, the availability of those other accommodations might be the difference between participation and exclusion (through exceptions) from entire categories of software. Requirements for alternative accommodations would be a good subject for a future SC as these technologies become more mature and widespread. We are open to suggestions to include additional techniques as optional best practices in the understanding document. Can you provide a description and examples that could be used?
630
https://github.com/w3c/wcag21/issues/630 (Answer by Mike Gower)
> I find this really confusing and would like some examples to illustrate these criteria.
The Understanding document is in the process of being updated, and will offer examples and clarity. The current draft provides some explanation and [Examples](https://w3c.github.io/wcag21/understanding/21/content-on-hover-or-focus.html)
> If there must be a mechanism to dismiss content without moving the pointer or keyboard focus, what might that look like?
The normal mechanism for dismissing any kind of overlay is the Escape key; if that is implemented, this first bulleted requirement is met. Note that the wording of the SC does not prevent an author from adding in a mouse-equivalent affordance for this (such as simply moving away from the trigger/new content or hitting a close button displayed as a ‘x’ in the upper right corner of the overlay). The SC simply requires that there be a method that does not involve moving the mouse.
> Most mechanisms to dismiss content ask that the user click on a button, which requires moving the pointer or keyboard focus.
> What is the benefit to being able to hover over additional content that only appears on hover?
The specific reason for a requirement to dismiss the on-hover overlay without moving the mouse, involves low vision users or users with reduced fine motor skills. Low vision users with a substantial level of magnification have a limited viewport. If they accidentally trigger new content with hover, they need to be able to dismiss that new content without losing their current point of regard. Otherwise, they are put in the situation where they must move their entire viewport away from the location they wished to interact with in order to dismiss the new unwanted content. After re-orienting themselves back again after the new content disappears, they then may accidentally trigger the hover again, repeating the same experience. Similarly, a user who cannot easily control the mouse and so is more prone to accidental triggering of on-hover content, needs a method of easily dismissing that is not mouse based.
As will be made clear in the Understanding document, this SC is not recommending or encouraging the use of On Hover or On Focus as the trigger for displaying new content. This is considered a poor interaction by many, since users may easily inadvertently trigger new content. However, where an author elects to employ On Hover as a trigger, this SC places requirements on the implementation which make the resulting experience more accessible.
644
https://github.com/w3c/wcag21/issues/644 (Assigned to Laura):
Proposed response:
Thank you for your comment, we have integrated a change to avoid issues with PDF and application scenarios, so the SC text starts:
"In content implemented using markup languages that support the following text style properties, no loss of content or functionality occurs by setting all of the following and by changing no other style property."
The purpose of the SC is to encourage people to enable over-riding of content via user-agent mechanisms, rather than require on-page widgets. Therefore the working group would like to avoid 'mechanism is available' language for this SC as people tend to read it as meaning adding a widget to a page.
We will also clarify the applicability of this SC in the Understanding document.
656
https://github.com/w3c/wcag21/issues/656
Proposed response (AC): Thank you for your comment, we have integrated a change to avoid issues with PDF and application scenarios, so the SC text starts:
"In content implemented using markup languages that support the following text style properties, no loss of content or functionality occurs by setting all of the following and by changing no other style property."
The purpose of the SC is to encourage people to enable over-riding of content via user-agent mechanisms, rather than require on-page widgets. Therefore the working group would like to avoid 'mechanism is available' language for this SC as people tend to read it as meaning adding a widget to a page.
671
https://github.com/w3c/wcag21/issues/671
Proposed response: (from AWK) Thank you for your suggestion. We agree that the definition of target was hard to parse and needed updating. We have changed "touch action" to "pointer action" to cover all pointer input, not just touch. We have also simplified the text explaining that parts of a target covered by another target must be excluded in target size measurements.
Pull request for revised definition of 'target': https://github.com/w3c/wcag21/pull/673
722
https://github.com/w3c/wcag21/issues/722
Proposed response: Thank you for the comment. We will remove this note from the conformance section and address this topic in the Understanding document.
Alternate proposed response: Thank you for the comment. This note is non-normative (as are all notes) but does represent the consensus view of the Working Group.
386
https://github.com/w3c/wcag21/issues/386
Thank you for the comment. We have re-written the criterion to incorporate your suggestion. The updated SC can be viewed at: [link]
402
https://github.com/w3c/wcag21/issues/402
Proposed response:
Thank you for the comment. The SC has been changed to focus on currently supported attributes, so browsers support this across the board: https://caniuse.com/#feat=input-autocomplete-onoff (There are some issues with browser implementations, but they do not appear to affect the autofill part of autocomplete.)
This aspect alone is very helpful to some people with cognitive issues.
For the aspect of adding icons for users (another goal of the SC) It is also worth noting that there are several implementations already: Chrome extension: http://accessibility.athena-ict.com/personlization.shtml Script: https://github.com/ayelet-seeman/coga.personalisation Website based implementation: https://a11y-resources.com/developer/coga-personalisation
These are at early stages and have been using the COGA semantics spec, but these can be updated to cover the autofill attributes as well, while the other aspects mature.
Overall, there is basic support for the proposal already, and people committed to expanding the functionality during the CR stage.
Given the user-need, and that this new version is far easier to implement, we hope that this addresses your concerns.
407
https://github.com/w3c/wcag21/issues/407
Proposed response:
Thank you for your comment. At times the Working Group uses phrases such as "content implemented using markup languages" as you note, and the reason is that is some cases the Working Group has determined that a certain SC applies to technologies with specific features. This may be because there are specific markup-related that need to be attended to, or it may be used as an exception because the working group is aware of a gap in support for non-markup technologies and in order to arrive at a consensus the language is used to narrow the scope of the criterion.
In the current Editor's draft, "Text Spacing" and "Status Changes" are the only criteria remaining that employ this phrase, and in both the reason is that there is a gap in support for the requirements beyond HTML. We anticipate that this will change, and the Working Group will be able to update the criteria in response.
411
https://github.com/w3c/wcag21/issues/411
Proposed response (from AlastairC):
Thank you for your comment. The term graphical object was selected to be generic as it covers a wide range of parts of graphics. Defining the term object (beyond the current text or the dictionary definition) does not appear to help. However, the Understanding document does include a large section to provide context and examples, and that is being expanded.
541
https://github.com/w3c/wcag21/issues/541
Proposed response:
544
https://github.com/w3c/wcag21/issues/544
Proposed response:
586
https://github.com/w3c/wcag21/issues/586
Proposed response: Unfortunately, due to issues around the implementation and feasibility the purposes related to links and buttons have been removed, but the purposes related to form inputs were retained and expanded. We do intend to expand on this work in future, and would like to defer this comment for future work.
589
https://github.com/w3c/wcag21/issues/589
Proposed response (AWK): Thank you for your comment. We understand your concern about PDF/UA including requirements that are unrelated to reflow in a PDF document. The possible technique has not been drafted or approved, so we appreciate your feedback. It is important to point out that techniques are not required, but they are sufficient, so if a PDF/UA conforming document would always meet the reflow requirements, we could make a technique that clarified this connection, but we would undoubtedly include other techniques as well that would allow a PDF to meet the reflow SC without conforming to PDF/UA.
Of course, as you indicate, to include a PDF/UA-related technique we would need to consider the testing questions you mention and more.
We have work to do to ensure that the understanding and techniques documents are up to date and accurate, but it is worth mentioning that the plan moving forward is that the non-normative techniques and understanding documents will be able to be updated continuously in the event that new information or errors are identified.
590
https://github.com/w3c/wcag21/issues/590
Proposed response: While there are some privacy and security concerns with automatically filling in inputs (without the user wanting to), this is ultimately a user-agent/browser issue. The way to solve the issue is to make sure the user agrees to fields being populated (e.g. clicks a button in the browser interface), and avoid filling in hidden inputs. We can note the concern in the understanding document, but if change is needed it is up to the browsers and Web Platform working group to resolve.
598
https://github.com/w3c/wcag21/issues/598 Thank you for the comment. We intend to include PDF documents in the implementations for review. PDF documents can satisfy the WCAG definition for "web page", which is: "a non-embedded resource obtained from a single URI using HTTP plus any other resources that are used in the rendering or intended to be rendered together with it by a user agent". This is the same reasoning used to include techniques for PDF for WCAG 2.0 in the past, and we will be looking to offer PDF techniques for WCAG 2.1 Success Criteria as well.
620
https://github.com/w3c/wcag21/issues/620 Related question asked by JOC, awaiting response and will then draft response: Assigned to JOC
Proposed WG response (Detlev)
Thank you for your comment. You propose to remove 'user motion' to exclude situations where the user is moving and the device just observing. The aim of the user motion part of the SC was to address motions like hand gestures that are observed by the camera or other sensors that can trigger certain events (such as forwarding a presentation, or panning a view). We have changed the SC text and the understanding text to clarify that 'user motion' means explicit actuation in the context of this SC. We have spelled out that scenarios where the user moves without explixitly actuating content (as in your your Leap Motion example) or where the device just observes without the user intentionally gesturing towards the device, are not in scope of this SC.
We will mark this issue as "defer" to ensure that it is reviewed at an appropriate time in the future.
621
https://github.com/w3c/wcag21/issues/621
Proposed response (Detlev)
Thank you for your comment. You raise two issues - one is splitting device motion and user motion into separate SCs, the second is making us aware of a third type of similar functionality, that of motion / events in the field of view of the device (device is observing). We agree that this is a separate issue and potentially, a separate SC. In this SC, the issue is active, purposeful user input. We believe that the SC Motion Actuation addresses broadly issues common to two scenarios: firstly when the user moves the device itself (shaking, titling, panning) and secondly, when the user motions towards the device, i.e. carries out gestures aimed at actuating functions. We think that both scenarios can therefore be treated in one SC.
We have updated the SC text and the Understanding text to clarify that input caused by the user moving through space, and situations where the device is observing anything other than purposeful user inputs, are not covered by this SC.
As to your suggestion to separate out device and user motion, we will mark this issue as "defer" to ensure that it is reviewed at an appropriate time in the future.
624
https://github.com/w3c/wcag21/issues/624
Proposed response: The wording has been significantly updated, we think this addresses the issue, it no longer includes the buttons aspect.
628
https://github.com/w3c/wcag21/issues/628
629
https://github.com/w3c/wcag21/issues/629
The SC has been changed to focus on currently supported attributes, so browsers support this across the board: https://caniuse.com/#feat=input-autocomplete-onoff (There are some issues with browser implementations, but they do not appear to affect the autofill part of autocomplete.)
This aspect alone is very helpful to some people with cognitive issues.
For the aspect of adding icons for users (another goal of the SC) It is also worth noting that there are several implementations already: Chrome extension: http://accessibility.athena-ict.com/personlization.shtml Script: https://github.com/ayelet-seeman/coga.personalisation Website based implementation: https://a11y-resources.com/developer/coga-personalisation
These are at early stages and have been using the COGA semantics spec, but these can be updated to cover the autofill attributes as well, while the other aspects mature.
Overall, there is basic support for the proposal already, and people committed to expanding the functionality during the CR stage.
Given the user-need, and that this new version is far easier to implement, there does not seem to be an issue with including this SC at level AA.
While there are some privacy and security concerns with automatically filling in inputs (without the user wanting to), this is ultimately a user-agent/browser issue. The way to solve the issue is to make sure the user agrees to fields being populated (e.g. clicks a button in the browser interface), and avoid filling in hidden inputs. We can note the concern in the understanding document, but if change is needed it is up to the browsers and Web Platform working group to resolve.
The SC text and list of purposes has been updated so only the input aspects are used.
634
https://github.com/w3c/wcag21/issues/634
Thanks for the comment. We agree that the definition needs to be clarified. We are changing the definition to:
"Pointer input that operates with one point of contact with the screen, including single taps and clicks, double-taps and clicks, long presses, and path-based gestures"
635
https://github.com/w3c/wcag21/issues/635 (answer from Lisa)
Proposed response:
Thanks for the comment. The new SC text has resolved this issue.
637
https://github.com/w3c/wcag21/issues/637
Thank you for the comment. We will add the notice as done in ARIA. Please note that these are the correct interpretations for these terms even without this sentence since the document indicates that it is governed by the process document and the process document makes this same claim.
649
https://github.com/w3c/wcag21/issues/649
(AlastairC) Thank you for your comment. The working group appreciates that the changes between states should be obvious to people viewing the content. However, it is very difficult to craft a requirement that does not run into the issue of not having enough colours for a particular component. The focus of this success criteria is to cover the non-text parts of (active) UI components, but we will certainly consider expanding to explicitly cover the differentiation of states for UI components in future iterations.
650
https://github.com/w3c/wcag21/issues/650 . (Answer:David MacDonald)
Thank you for your comment. Tabbed interfaces and similar selections, such as a drop-down box, that may cause additional content to become visible on focus/selection were not intended to be covered by this criterion. Rather, the criterion was designed for content that also becomes hidden when focus (or hover) is removed. We agree the criterion text did not reflect this well and made a change so that it now reads:
> Where receiving and removing pointer hover or keyboard focus triggers additional content to become visible and hidden, respectively, the following are true: ...
This scopes out tabbed interfaces because the removal of focus does not then hide the content because it is still selected. In this case, it might seem like the content is removed when the tab loses focus, but the content is actually changed when a different item receives the focus. We hope this addresses your concerns.
Regarding techniques, the working group will be working hard on the supporting understanding and technique materials in the next few months.
653
https://github.com/w3c/wcag21/issues/653
Proposed response: Same response as #672
654
https://github.com/w3c/wcag21/issues/654
Proposed response:
The SC has been changed to focus on currently supported attributes, so browsers support this across the board: https://caniuse.com/#feat=input-autocomplete-onoff (There are some issues with browser implementations, but they do not appear to affect the autofill part of autocomplete.)
This aspect alone is very helpful to some people with cognitive issues.
For the aspect of adding icons for users (another goal of the SC) It is also worth noting that there are several implementations already: Chrome extension: http://accessibility.athena-ict.com/personlization.shtml Script: https://github.com/ayelet-seeman/coga.personalisation Website based implementation: https://a11y-resources.com/developer/coga-personalisation
These are at early stages and have been using the COGA semantics spec, but these can be updated to cover the autofill attributes as well, while the other aspects mature.
Overall, there is basic support for the proposal already, and people committed to expanding the functionality during the CR stage.
Given the user-need, and that this new version is far easier to implement, there does not seem to be an issue with including this SC at level AA.
In the current proposal the list is based on something that browsers have already implemented, in future iterations of WCAG it is possible this will be separated.
655
https://github.com/w3c/wcag21/issues/655
Thank you for your comment. The existing exception language was carefully worded with input from many working group members and is used in other draft criteria (Graphics Contrast and Target Size). The language you proposed does not seem to address the key technology-specific exception of the `title` attribute, because the author has full control of its existence. The distinction about the user agent is needed to identify that the author may not be able to control the visual styling or behavior on hover or focus, but they do control its existence.
It may be possible to apply this to documents and software with the same intentions simply by re-interpreting the "user agent" in those cases. For example:
- **Software:** If the user agent is the OS, then it gives exception to wherever the OS may generate tooltips or similar applicable content and the developer uses the default presentation or has no ability to change it.
- **Documents:** If the authoring software is the user agent, then the exception is again given to hover or focus content that the document author cannot style.
657 and 677 and 685
https://github.com/w3c/wcag21/issues/657
https://github.com/w3c/wcag21/issues/677
https://github.com/w3c/wcag21/issues/685
Proposed response (AWK): Thank you for your comment. These properties are defined in CSS and in typographical principals, and they adhere to the meaning used in CSS. We will modify the description for paragraph spacing to "spacing following paragraphs" instead of "spacing underneath paragraphs" to address the implicit western language bias in this item. We will also add the following exception to address cases such as in Japanese where word-spacing is not typically used.
Exception: Human languages and scripts which do not make use of one or more of these text style properties in written text can conform using only the properties that are used.
https://github.com/w3c/wcag21/pull/729
659
https://github.com/w3c/wcag21/issues/659
Thank you for the comment. We have re-written the criterion to incorporate your suggestion. The updated SC can be viewed at: [link]
660
https://github.com/w3c/wcag21/issues/660
Thank you for the comment. We have clarified the criterion to ensure that Space and Enter are not referred to incorrectly. You can view the updated criterion at: [link]
661
https://github.com/w3c/wcag21/issues/661
Proposed response: Same response as #672
663
https://github.com/w3c/wcag21/issues/663 (Answer by Detlev)
Thank you for your suggestion. We agree that your addition clarifies the text of SC 2.5.1 Pointer gestures. Path-based gestures are often carried out with a single pointer (as in drag-and-drop) so including an explicit reference ("...can be operated with a single pointer without a path-based gesture") leaves less room for misunderstanding.
665
https://github.com/w3c/wcag21/issues/665
Proposed response: The wording has been significantly updated, we think this addresses the issue.
667
https://github.com/w3c/wcag21/issues/667
Thank you for the comment. We will adjust the SC text to make it easier to translate. The new SC text will read:
"Users are warned of the duration of any user inactivity that could cause data loss, unless the data is preserved for more than 20 hours when the user does not take any actions."
https://github.com/w3c/wcag21/pull/730
668
https://github.com/w3c/wcag21/issues/668
Makoto to review latest ed draft.
669
https://github.com/w3c/wcag21/issues/669
Thank you for the comment. In response to other issues (386, 659, 660) we have changed the structure of this SC. We believe that the new structure is clearer and hope it addresses your need for easier translation.
670
https://github.com/w3c/wcag21/issues/670
Thank you for the comment. The specific phrasing of the SC is designed to match phrasing used in other SC. As a result, the WG needs to keep the SC text the same, except for adding "visually" to the end of the SC to provide additional clarity. See https://github.com/w3c/wcag21/pull/728/files for the specific change.
672
https://github.com/w3c/wcag21/issues/672
Proposed response: The SC has been changed to focus on currently supported attributes, so browsers support this across the board: https://caniuse.com/#feat=input-autocomplete-onoff (There are some issues with browser implementations, but they do not appear to affect the autofill part of autocomplete.)
This aspect alone is very helpful to some people with cognitive issues.
For the aspect of adding icons for users (another goal of the SC) It is also worth noting that there are several implementations already: Chrome extension: http://accessibility.athena-ict.com/personlization.shtml Script: https://github.com/ayelet-seeman/coga.personalisation Website based implementation: https://a11y-resources.com/developer/coga-personalisation
These are at early stages and have been using the COGA semantics spec, but these can be updated to cover the autofill attributes as well, while the other aspects mature.
Overall, there is basic support for the proposal already, and people committed to expanding the functionality during the CR stage.
Given the user-need, and that this new version is far easier to implement, there does not seem to be an issue with including this SC at level AA.
674
https://github.com/w3c/wcag21/issues/674
Thank you for the comment. We have made changes to the criterion text to address the issue on vertical text.
676
https://github.com/w3c/wcag21/issues/676
Thank you for the comment. We are updating the SC and modifying the first exception so that it starts with the description "Supported Interfaces", but the phrase "accessibility supported" is still used in the description, as follows:
"The motion is used to operate functionality through an <a>accessibility supported</a> interface;"
The Understanding document will be updated to reflect clearly that the intent is that where motion is used to operate an interface that has accessibility support (meaning that it has user agent and assistive technology support) that motion is exempt. For example, a user might use a head mouse system that operates using the camera in order to interface with the pointer/mouse interface would be exempted. We hope this addresses your concern.
677
https://github.com/w3c/wcag21/issues/677
680
https://github.com/w3c/wcag21/issues/680
(From AlastairC): Thank you for your comment, as a member of the working group we assume there is no need to outline the CR process. Every SC should be tested, thank you for offering that support.
Regarding high contrast mode, from some initial testing neither Windows (10 + Edge) or OSX (+Safari) help with perceiving graphics embedded into web pages, which highlights the importance of that part of this SC even more.
Using a high-contrast mode could assist with the user-interface controls, but would be limited to standard controls, not custom ones created by authors.
If there are user-agent factors that haven't been considered, please do comment on how those might impact the SC. However, it is worth nothing that the requirement from the Low Vision Task Force was that it should be a minimum standard for those without user-agent /OS support for contrast.
686
https://github.com/w3c/wcag21/issues/686
(AlastairC) Thank you for your comment, the group agrees we should test where "graphics are reused in a multiplicity of contexts", do you have any examples you could share?
The group appreciates that context is important for images, and that can change between pages. However, in order to meet the user-need it must focus on what is required for understanding. Utilising that concept also makes it more feasible to implement in general scenarios, as it is a wider exemption that pure-decoration.
688
https://github.com/w3c/wcag21/issues/688
Thank you for your comment. We understand your desire to avoid imposing requirements on authors that might best be addressed by UA or AT, and believe that the current language's use of "a mechanism is available" helps ensure that solutions exist for end users in the near term but also provides a way for improvements in UA and AT support to remove this responsibility from authors. Today, with no AT or UA support, web applications like gmail can readily implement support (and have) for this SC. Since this SC is focused on developers who are implementing custom keyboard shortcuts, it is not expected that this SC will pose a challenge for most sites. We will clarify this in the understanding document to ensure that authors know how to evaluate whether UA and AT support exist and what techniques are available to meet this SC.
689
https://github.com/w3c/wcag21/issues/689
Proposed response: Thank you for your comment. Unfortunately, due to issues around the implementation and feasibility the purposes related to links and buttons have been removed. We do intend to expand on this work in future, and would like to defer this comment for future work.
695
https://github.com/w3c/wcag21/issues/695
Thank you for your comment. While the intent and requirement for the Hoverable condition has always been the same, we've struggled to state it as simply as possible in the SC. We have taken your suggestion to state it more plainly and edited it to read:
> **Hoverable:** If pointer hover can trigger the additional content, then the pointer can be moved over the additional content without the additional content disappearing;
697
https://github.com/w3c/wcag21/issues/697
(From AlastairC): Thank you for the comment. The working group agrees that the widening of scope to include all animation is not warranted at this time, and has scoped the SC text to motion animation, with an updated definition of animation, available at the pull request: https://github.com/w3c/wcag21/pull/738
711
https://github.com/w3c/wcag21/issues/711
Thank you for your comment. While the intent and requirement for the Hoverable condition has always been the same, we've struggled to state it as simply as possible in the SC. We have taken your suggestion to state it more plainly and edited it to read:
> **Hoverable:** If pointer hover can trigger the additional content, then the pointer can be moved over the additional content without the additional content disappearing;