W3C

Site Navigation

Nearby

Results of Questionnaire Review of Requirements for Silver

The results of this questionnaire are available to anybody.

This questionnaire was open from 2019-03-06 to 2019-04-03.

22 answers have been received.

Jump to results for question:

  1. Design Principle 1
  2. Design Principle 2
  3. Design Principle 3
  4. Design Principle 4
  5. Design Principle 5
  6. Design Principle 6
  7. Design Principle 7
  8. Design Principle 8
  9. Additional Design Principles?
  10. Requirement 1
  11. Requirement 2
  12. Requirement 3
  13. Requirement 4
  14. Requirement 5
  15. Requirement 6
  16. Requirement 7
  17. Requirement 8
  18. Additional Requirements?

1. Design Principle 1

Accessibility guidelines should: Support the needs of the widest range of people with disabilities and recognize that people with disabilities have individual and intersectional needs.

Summary

ChoiceAll responders
Results
Agree 16
Agree with the following changes 5
Disagree

(1 response didn't contain an answer to this question)

Details

Responder Design Principle 1Comments
Justine Pascalides Agree
Abi James Agree
Keyonda Smith Agree
Jonathan Avila Agree
Stefan Schnabel Agree
Garry Grant Agree The Web should be accessible to all
Shawn Lauriat Agree
Brooks Newton Agree
Jake Abma Agree
Andrew Kirkpatrick Agree with the following changes Suggest clarifying intersectional. "people with disabilities have individual needs and needs that are shared with other users with disabilities."
Marc Johlic Agree
Rachael Bradley Montgomery Agree
Laura Carlson Agree
Makoto Ueki Agree
Bruce Bailey Agree
Glenda Sims Agree with the following changes clarify "intersectional"
Michael Gower Agree
Katie Haritos-Shea Agree
Juli-Ann Rowsell Agree with the following changes I think that it's important to understand that when we say the widest range we have to have more robust coverage on testing. I think we need to ensure that is inclusive as possible, but also consider what is pragmatic.
David MacDonald Agree with the following changes I think the "widest range" is too optimistic. I think the word "intersectional" is politicized and may be perceived as partisan. Historically, we've tried to stay away from discussions about class, poverty, privilege, power, and dominance issues in society. How about something like this.

Accessibility guidelines should: Support a wide range of people with disabilities and be created with the consideration of users with individual needs.
Detlev Fischer Agree with the following changes Wouldn't know what 'intersectional' would mean in this context.
Alastair Campbell

2. Design Principle 2

Accessibility guidelines should: Support a measurement and conformance structure that can include guidance for a broad range of disabilities, including low vision and cognitive accessibility needs.

Summary

ChoiceAll responders
Results
Agree 9
Agree with the following changes 9
Disagree 3

(1 response didn't contain an answer to this question)

Details

Responder Design Principle 2Comments
Justine Pascalides Agree
Abi James Agree with the following changes It should be recognised that needs related to disabilities may change over time, particularly as new interfaces and technologies evolve. Many people with cognitive disabilities do not identify as disabled so “broad range of disabilities “ could be too constrained. Perhaps “broad range of access needs” ?
Keyonda Smith Agree with the following changes I suggest removing the word "can"
Jonathan Avila Agree
Stefan Schnabel Agree
Garry Grant Agree
Shawn Lauriat Agree
Brooks Newton Agree
Jake Abma Agree with the following changes Would like to see age / ageing being part of the sentence
Andrew Kirkpatrick Disagree Feels too weak because it uses "should". Perhaps I need to better understand the distinction between design principles and requirements...

Many would argue that WCAG 2.0/2.1 provide guidance for a broad range of PWD. To argue otherwise may require a clearer delineation of what "broad range" means.
Marc Johlic Agree with the following changes Agree with other comments around "can" and "should". I'm also not sure why low vision and cognitive are called out - what about other disabilities? Is there a reason these two were called out?
Rachael Bradley Montgomery Agree
Laura Carlson Agree
Makoto Ueki Agree
Bruce Bailey Agree with the following changes From 3/11 face-to-face conversation, my suggestion is to break this up into two sentences. 1st sentence ends with "...broad range of disabilities". The second clause could mention the particular attention given to low vision and coga.
Glenda Sims Agree with the following changes don't just call out "low vision and cognitive"...list them all, or don't list them specifically.
Michael Gower Agree with the following changes ", including low vision and cognitive accessibility needs" seems odd. I get the historical reason this is here, but I'd like the kitchen sink or nothing. I think the easiest thing to do is just take it out in this principle.
Katie Haritos-Shea Disagree Like Mark, I dont like calling out specific disabilities, and leaving out others - makes me want to also include speech and emotional disabilities, But this sound more like a statement.
Juli-Ann Rowsell Disagree I would prefer to see language that is more inclusive and doesn't limit or highlight only specific disabilities. Include other categories or just state a broad range of disabilities.
David MacDonald Agree with the following changes Accessibility guidelines should: Support a measurement and conformance structure that can include guidance for a broad range of disabilities.
Detlev Fischer Agree with the following changes Agree with some others to take out specific mentions of disabilities.
Alastair Campbell

3. Design Principle 3

Accessibility guidelines should: Be flexible enough to support the needs of people with disabilities using emerging technologies.

Summary

ChoiceAll responders
Results
Agree 18
Agree with the following changes 3
Disagree

(1 response didn't contain an answer to this question)

Details

Responder Design Principle 3Comments
Justine Pascalides Agree
Abi James Agree
Keyonda Smith Agree
Jonathan Avila Agree
Stefan Schnabel Agree
Garry Grant Agree Discussion points:
Legacy or end of life cycle operating systems and end of life cycle for adaptive software. What are the cut off points for accessibility support on the web on both topics?
Shawn Lauriat Agree
Brooks Newton Agree
Jake Abma Agree
Andrew Kirkpatrick Agree with the following changes I agree that it should, which is what this says, but I think that this need speaks more to the need to update the guidance in a more rapid manner.
Marc Johlic Agree
Rachael Bradley Montgomery Agree
Laura Carlson Agree
Makoto Ueki Agree
Bruce Bailey Agree
Glenda Sims Agree
Michael Gower Agree
Katie Haritos-Shea Agree
Juli-Ann Rowsell Agree with the following changes in terms of language I think we "should" be stronger than just should. Need is probably a more direct word without being overly aggressive.
David MacDonald Agree
Detlev Fischer Agree with the following changes Not sure what that flexibility would mean in practice, for the wording of the guidance. We might want to mention modularity / extensibility.
Alastair Campbell

4. Design Principle 4

Accessibility guidelines should: Follow accessibility guidance.

Summary

ChoiceAll responders
Results
Agree 9
Agree with the following changes 7
Disagree 4

(2 responses didn't contain an answer to this question)

Details

Responder Design Principle 4Comments
Justine Pascalides Agree
Abi James Agree
Keyonda Smith Agree
Jonathan Avila Agree
Stefan Schnabel Agree
Garry Grant Agree
Shawn Lauriat Agree with the following changes Could maybe use some clarification that this means that the wording, presentation, etc. of the guidelines should follow the guidelines themselves. In other words: ensure the accessibility of the guidelines.
Brooks Newton Agree with the following changes What does this mean? It seems circular.
Jake Abma Agree with the following changes Seems logical but what exactly was meant here?
Andrew Kirkpatrick Agree with the following changes Meaning that the guidelines are presented in one or more ways that support the described accessibility guidance? I think that this is fine to state, but may be unnecessary. Perhaps this is a implementation report item. If Silver will require 2 implementations at a minimum we could say that it requires 3 implementations, and the specification itself needs to be one of them?
Marc Johlic Disagree I'm not sure what this one is really trying to say. Is it really necessary?
Rachael Bradley Montgomery Agree with the following changes This is so general as to seem redundant. Are we saying that the guidelines themselves should be accessible or that the content should reflect current accessibility research?
Laura Carlson Agree
Makoto Ueki Agree
Bruce Bailey Agree
Glenda Sims Agree with the following changes reword it to make it clearer.
Michael Gower Disagree I didn't get this. Elliptical. I mean, I don't disagree with the statement. It just doesn't seem valuable.
Katie Haritos-Shea Disagree Not clear enough. Provide clarification
Juli-Ann Rowsell Agree with the following changes They need to follow their own guidance in order to be credible. Accessibility related materials that are not accessible immediately erode trust and confidence.
David MacDonald Disagree It seems redundant to include this, and might leave a lot for people scratching their heads. Obviously, the standard needs to be presented in a way that meets its own standard. We've always tried to follow that even though it is not documented.
Detlev Fischer So terse as to be hard to understand, which is ironic.
Alastair Campbell

5. Design Principle 5

Accessibility guidelines should: Be written in plain language, as easy as possible to understand.

Summary

ChoiceAll responders
Results
Agree 16
Agree with the following changes 5
Disagree

(1 response didn't contain an answer to this question)

Details

Responder Design Principle 5Comments
Justine Pascalides Agree
Abi James Agree
Keyonda Smith Agree
Jonathan Avila Agree
Stefan Schnabel Agree
Garry Grant Agree
Shawn Lauriat Agree
Brooks Newton Agree with the following changes I think we should capture the essence of what we want the guidelines to cover, then worry about crafting the language ins such a way that is easiest to understand. We can't try to both innovate standards and at the same time try to wordsmith. Let's get the concepts down and gather consensus around the logic and content, then move to simplify the language through thoughtful re-writes. We should consider multiple versions of guidance, based on the intended audience. Developers need language that's different than what non-technical managers require to get what they need out of the guidelines.
Jake Abma Agree with the following changes The aim is nice but can we add specific levels to achieve? Are there reading standards (we do have those in The Netherlands) to meet?
Andrew Kirkpatrick Agree Noting the subjective/conditional words here "should" and "as easy as possible". I agree that this is needed, but very hard.
Marc Johlic Agree
Rachael Bradley Montgomery Agree with the following changes If we are getting into wording, I think this should state, “Be written in plain language so that they are as easy as possible to understand.”
Laura Carlson Agree
Makoto Ueki Agree
Bruce Bailey Agree
Glenda Sims Agree
Michael Gower Agree It's aspirational. I'm not sure how you measure "plain" and "as easy as possible to understand".
Katie Haritos-Shea Agree Like Rachael's suggested text
Juli-Ann Rowsell Agree with the following changes need to be written in plain language.
David MacDonald Agree with the following changes Einstein said "Make things as simple as possible, but no simpler"
How about something like:

Accessibility guidelines should: Be written in the plainest language possible and as easy to understand as possible without compromising objective conformance measurement.

Detlev Fischer Agree
Alastair Campbell

6. Design Principle 6

The creation process for the guidelines should: Include people with disabilities and recognize that they are important contributors to accessibility standards and solution.

Summary

ChoiceAll responders
Results
Agree 12
Agree with the following changes 9
Disagree

(1 response didn't contain an answer to this question)

Details

Responder Design Principle 6Comments
Justine Pascalides Agree
Abi James Agree
Keyonda Smith Agree with the following changes I would rephrase this. It doesn't sit well with me how it is currently stated. I suggest: "Include people with disabilities TO recognize THE IMPORTANCE OF THEIR CONTRIBUTIONS to accessibility standards and solution."
Jonathan Avila Agree
Stefan Schnabel Agree
Garry Grant Agree There is a lot of online accessibility testing software, and that is an excellent place to start, but there is nothing better than having people with disabilities manually check web sites for compliance or at least best practices. We have two employees that manually check web sites.
Shawn Lauriat Agree
Brooks Newton Agree
Jake Abma Agree with the following changes Agree to include PwD by default in every process where possible. Not sure though what 'include' here means. Is it to get their experiences to base guidelines on? Do some user testing and use the results? Is it to specially include more PwD in the WG (more than we have already) because they have a disability or because they have lots of experience in the accessibility field? Or else...?

Recognising they are important contributors to accessibility standards and solution seems superfluous to mention for accessibility guidelines.
Andrew Kirkpatrick Agree with the following changes Why "should" here? Do we need to specify which types of disabilities?
Marc Johlic Agree
Rachael Bradley Montgomery Agree with the following changes Should we call out a diverse pr representative range of disabilities?
Laura Carlson Agree
Makoto Ueki Agree
Bruce Bailey Agree
Glenda Sims Agree with the following changes I like AWK's suggested wording from the F2F "Include people with disabilities TO recognize THE IMPORTANCE OF THEIR CONTRIBUTIONS to accessibility standards and solution."
Michael Gower Agree with the following changes "creation process" seem a little vague, but this is a good guiding principle.
Katie Haritos-Shea Agree with the following changes For the process and tooling. This is inclusion in the new standard development
Juli-Ann Rowsell Agree with the following changes This is a necessary part of the equation for me. It's critical to ensure that we do this in a robust fashion.
The guidelines will be stronger, more comprehensive and inclusive if this is part of the process.
David MacDonald Agree We want to build on the inclusive approach we had in WCAG 2 where we had a lot of input and representation from the disability community. We don't want to lose that in Silver
Detlev Fischer Agree with the following changes Agree that it might be more specific on the type of involvement but seems OK on this general level.
Alastair Campbell

7. Design Principle 7

The creation process for the guidelines should: Have global participation and feedback.

Summary

ChoiceAll responders
Results
Agree 19
Agree with the following changes 2
Disagree

(1 response didn't contain an answer to this question)

Details

Responder Design Principle 7Comments
Justine Pascalides Agree
Abi James Agree
Keyonda Smith Agree
Jonathan Avila Agree
Stefan Schnabel Agree
Garry Grant Agree
Shawn Lauriat Agree
Brooks Newton Agree
Jake Abma Agree
Andrew Kirkpatrick Agree with the following changes Why "should" here? Are there parameters to this? What if we have US, Canada, UK, Germany, Japan, and Australia - is that enough? What if one or more of those was not involved? This seems like a nice thing to say but unless we identify actual metrics around it it will be mostly aspirational. We could, for example, identify a need for talking/feedback sessions in multiple locations and articulate that as a performance indicator.
Marc Johlic Agree
Rachael Bradley Montgomery Agree
Laura Carlson Agree
Makoto Ueki Agree
Bruce Bailey Agree
Glenda Sims Agree
Michael Gower Agree Same comment at for principle 6
Katie Haritos-Shea Agree
Juli-Ann Rowsell Agree with the following changes language = needs to include or other word that is stronger in saying this is an important part of the process, not a thing that is a nice to have.
David MacDonald Agree We worked hard to get global participation in WCAG 2 and want to build on that in SIlver.
Detlev Fischer Agree
Alastair Campbell

8. Design Principle 8

The creation process for the guidelines should: Strive to be data-informed and evidence-based.

Summary

ChoiceAll responders
Results
Agree 14
Agree with the following changes 7
Disagree

(1 response didn't contain an answer to this question)

Details

Responder Design Principle 8Comments
Justine Pascalides Agree
Abi James Agree with the following changes Absolutely agree, but also the development of Silver wouldn’t be constrained by available data, rather drive the agenda to improve understanding.
Keyonda Smith Agree
Jonathan Avila Agree
Stefan Schnabel Agree with the following changes describe how data is gained and what you mean with clear evidence
Garry Grant Agree
Shawn Lauriat Agree with the following changes "Strive" sounds a little too aspirational, but I don't have a better suggestion at the moment.
Brooks Newton Agree
Jake Abma Agree with the following changes Strive may be deleted, would feel better if the sentence would be something like: Data-informed and evidence-based must also be part of the process
Andrew Kirkpatrick Agree with the following changes Again, subjective. "Should strive to be" vs. "must strive to be" vs "should be" vs. "must be"
Marc Johlic Agree
Rachael Bradley Montgomery Agree
Laura Carlson Agree
Makoto Ueki Agree
Bruce Bailey Agree
Glenda Sims Agree
Michael Gower Agree with the following changes In principle, sounds good. I know we left vestibular disorders at AAA because we _didn't_ have enough data to make a more vigorous SC. Does this principle apply equally to both the requirements and the guidance? For instance, a single user's experience is evidence, but one person's info does not constitute data-informed. So getting back to vestibular disorders, we took anecdotal information and made an SC which didn't include any scope on what amount of animation was okay since we lacked data to support a measurement. (https://www.w3.org/TR/WCAG21/#animation-from-interactions)
Katie Haritos-Shea Agree
Juli-Ann Rowsell Agree with the following changes needs to strive to be
David MacDonald Agree We used as much research and data as was available at the time of WCAG 2.0, and we want to build on that.
Detlev Fischer Agree
Alastair Campbell

9. Additional Design Principles?

If you feel that there are design principles that have not been addressed in the set of eight listed in this survey and would like to add comments to suggest additions, please do so here.

Details

Responder Additional Design Principles?
Justine Pascalides
Abi James
Keyonda Smith
Jonathan Avila
Stefan Schnabel no workarounds for AT flaws schould be reccommended, instead, AT should be explicitely encouraged to improve on its weak spots in a timely fashion. seriously.
Garry Grant
Shawn Lauriat
Brooks Newton
Jake Abma
Andrew Kirkpatrick `I find the design principles confusing and would like to hear more about how they differ from requirements. The confusion may be caused by the Design principles being derived from 2.0 Requirements and there also being Silver requirements. It is also worth noting that the requirements for WCAG 2.0 are not written with "should" language.
Marc Johlic
Rachael Bradley Montgomery Should we include a design principle about the ability to support automated testing when possible and provide a method for repeatable test results when manual testing is required?
Laura Carlson Not an additional principle.

But it may be helpful to define "Design Principles" and "Requirements". And explain how they differ.
Makoto Ueki
Bruce Bailey
Glenda Sims
Michael Gower Realizing these remain _authoring_ guidelines, I'm wondering if there is a way to rethink Silver to get the requriements for user agents and platforms into the fold. Can this somehow incorporate a new version of UAAG?
Katie Haritos-Shea
Juli-Ann Rowsell Are there ways to embed inclusive design principles into accessibility design principles?
David MacDonald
Detlev Fischer
Alastair Campbell

10. Requirement 1

Multiple ways to measure: Different guidance has potential for different measurement beyond a simple true false success criterion so that more needs of people with disabilities can be included.

Summary

ChoiceAll responders
Results
Agree 5
Agree with the following changes 9
Disagree 4

(4 responses didn't contain an answer to this question)

Details

Responder Requirement 1Comments
Justine Pascalides Agree
Abi James Agree
Keyonda Smith Agree with the following changes VARIOUS guidance RESOURCES ALLOWS MULTIPLE WAYS TO MEASURE RESULTS beyond a simple DICHOTOMOUS (TRUE-FALSE) success criterion TO CONSIDER THE needs of people with disabilities.
Jonathan Avila
Stefan Schnabel Agree with the following changes use simple language to explain what you mean with different guidance
Garry Grant Agree
Shawn Lauriat Agree with the following changes Maybe also include how different types of measurement would also allow for more accurate statements of conformance as it relates to the level of accessibility.
Brooks Newton Agree with the following changes I think providing fractional rewards for partial conformance is tricky. Consider that completing a task-based performance requirement means that all of the links in the chain of events from task start to task completion must remain unbroken. If one of the steps in this series of task-related actions has an accessibility block, the task is not completed and the user need is not met. Fractional accessibility often leads to complete failure to support a user need.
Jake Abma Agree with the following changes A possible adjustment:

Besides the current true / false success criterion other ways of usability measurements should be part to determine how accessible products are so that more needs of people with disabilities can be included.
Andrew Kirkpatrick Disagree I feel like this is a critical point that needs discussion and clarification.

It is worth comparing to the WCAG 2.0 requirement for conformance - there is a lot more detail to guide expectations and to guide the work:

2. Ensure that the conformance requirements are clear
WCAG 2.0 must clearly specify the minimal requirements necessary for conformance. Each requirement must be verifiable. The WCAG WG will provide resources to help readers evaluate conformance, such as success criteria, sufficient techniques, and sample content.

The deliverables must
* Specify what is required for conformance.
* Clearly specify how content that is tailored according to client or user capabilities may conform (dynamic content or database driven).
* Resolve the relationship between user agent support and author supplied content (cross-platform and backwards compatibility issues).
* Document the assumptions that underlie the minimum requirements.
Marc Johlic
Rachael Bradley Montgomery Agree with the following changes I agree ideally but would like more discussion around this. This seems too open to be a requirement.
Laura Carlson Disagree Needs clarification. Seems ambiguous for a requirement. How is "potential" measured? How is " more needs" measured? What is meant by "Different guidance"? Requirements that use wishy-washy are not requirements at all. They are judgment calls, subjective to personal opinion.
Makoto Ueki
Bruce Bailey Agree
Glenda Sims Agree
Michael Gower Agree with the following changes I think you can list things that are similar to our Guidelines but slightly more detailed. The challenge of course is that you measure success against the guidelines through their child SCs. So it seems to me that if an author hasn't met ANY of the child requirements, it's pretty tough to say that they've met the guideline. It seems it's possible to say that they've partially met an SC and so have partially met a part of a guideline.

I think this tactic is worth pursuing, but it is TOUGH.
Katie Haritos-Shea Agree with the following changes Must be clarified
Juli-Ann Rowsell Disagree This needs to be carefully considered. How is this measured? How is this determined? I want to be careful about opening doors to two door systems, while realizing that some level of support or alternative way to meet some criteria might be important.
David MacDonald Disagree The huge issue which is outstanding is "conformance". In the 1800's before Canada could build a railroad from sea to sea, it had to do a feasibility study on whether a train could navigate the Rocky Mountains. They didn't have to build the railway through the mountains during this planning but they had to demonstrate it is feasible. Otherwise, they wouldn't have started. The mountain here is conformance. Until a system based on "measurability" has proven to be feasible to work with a point system as proposed, I don't think we can say the conformance model is viable. So far the scoring idea seems a lot more complicated than WCAG 2 conformance. If silver has a requirement to be *easier* to understand than WCAG then I think the point system as its been explained to us is a disconnect with that Silver requirement.
The point system will also need to overcome an approach where there are, say, 3 methods to do the same thing i.e.for link destination (1) aria-label, (2) aria-labelledby, and (3) full text in the link. If they are 3 points each, developers will be temped to do all three methods on the page or site to pick up points.

I wish there was a bullet for abstain or "wait and see".
Detlev Fischer Agree with the following changes Agree with many others that the wording seem swishy-washy.
Alastair Campbell

11. Requirement 2

Flexible structure: Create a structure for guidelines that can better meet the needs of people in unanticipated technologies and interactions.

Summary

ChoiceAll responders
Results
Agree 9
Agree with the following changes 9
Disagree

(4 responses didn't contain an answer to this question)

Details

Responder Requirement 2Comments
Justine Pascalides Agree
Abi James Agree
Keyonda Smith Agree with the following changes Create a structure for guidelines TO BEST meet the needs of people PLACED IN AN UNPLANNED EVENT WHERE A SPECIFIC TECHNOLOGY IS TASKED UNEXPECTEDLY.
Jonathan Avila
Stefan Schnabel Agree with the following changes use simple language to explain what you mean with unanticipated technologies and interactions
Garry Grant Agree
Shawn Lauriat Agree
Brooks Newton Agree with the following changes For those technologies and interactions that are in use today, there needs to be a requirement that standards bodies aggressively create the markup, supported component structures & interaction patterns and other informative guidance required by content authors,wares manufactures and users to do their parts to support an accessible user experience.
Jake Abma Agree with the following changes Create a modular and extensible structure for the guidelines also anticipating for new and upcoming technologies and interactions.
Andrew Kirkpatrick Agree How will we say that we meet this? Do we prove that we meet this requirement by anticipating the next few unanticipated technologies? It is hard to tell what this actually means today.
Marc Johlic
Rachael Bradley Montgomery Agree with the following changes I think this should also include flexibility to expand and adjust the guidelines themselves to meet evolving needs.
Laura Carlson Agree with the following changes How is "unanticipated technologies and interactions" measured? Needs to be more specific.
Makoto Ueki
Bruce Bailey Agree
Glenda Sims Agree
Michael Gower Agree with the following changes Maybe this is too abstract for this requirement, but since it is kinda on topic I'll say it here. I thought we removed "Web" from our WCAG acronym because we wanted it to apply to more than the Web. But now I hear the comment that "this is the W3C, so it's about the web" and so we can't apply the AGWG material beyond the web. So I'd like some clarity of how the TF sees Silver applying. Is it intended to go beyond the web?
Katie Haritos-Shea Agree with the following changes And with emerging technologies
Juli-Ann Rowsell Agree
David MacDonald Agree we want to build on WCAG 2's agnostic approach to cover all techologies
Detlev Fischer Agree with the following changes Again, striving for a modular structure seems clearer.
Alastair Campbell

12. Requirement 3

Multiple ways to display: Make the guidelines available in different accessible and usable ways so the guidance can be customized by different audiences.

Summary

ChoiceAll responders
Results
Agree 12
Agree with the following changes 6
Disagree

(4 responses didn't contain an answer to this question)

Details

Responder Requirement 3Comments
Justine Pascalides Agree
Abi James Agree
Keyonda Smith Agree with the following changes Make the guidelines available in MULTIPLE, accessible, and usable ways TO OFFER CUSTOMIZATION FOR VARIED audiences.
Jonathan Avila
Stefan Schnabel Agree
Garry Grant Agree
Shawn Lauriat Agree with the following changes Nit: not really customizing the guidance itself, but how the audience would read through the guidance to make it more applicable to the audience's context and easier for them to understand it.
Brooks Newton Agree
Jake Abma Agree with the following changes
We already have the guidelines available in different accessible and usable ways
Andrew Kirkpatrick Agree Perhaps this and requirement 5 (readable) should be combined? This raises the question for me "what constitutes 'the guidelines'?" This seems to likely be speaking to the non-normative information as much as the normative. Do we expect that all of the different accessible and usable ways of presenting the guidelines are normative?
Marc Johlic
Rachael Bradley Montgomery Agree
Laura Carlson Agree How is this requirement different from the customizable WCAG quick ref?
Makoto Ueki
Bruce Bailey Agree
Glenda Sims Agree
Michael Gower Agree I would view that as already a requirement of WCAG 2.x Maybe the idea here is that we WILL make multiple formats -- video, audio, malleable text-based, symbol-based, simplified language versions, etc.
Katie Haritos-Shea Agree with the following changes Please make clear that this includes individual users.
Juli-Ann Rowsell Agree with the following changes This needs to be carefully considered. How is this measured? How is this determined? I want to be careful about opening doors to two door systems, while realizing that some level of support or alternative way to meet some criteria might be important.
David MacDonald Agree with the following changes I think that is a "how to meet" issue rather than a Silver issue. I don't disagree, but I think it belongs in the presentation layer in the How to Meet.
Detlev Fischer Agree
Alastair Campbell

13. Requirement 4

Technology Neutral: Guidelines are worded to apply across varied technologies and avoid being technology-specific. The intent of technology-neutral wording is to provide the opportunity to apply guidelines to current and emerging technology, even if the technical advice doesn't yet exist. Technical details are discoverable in the document structure but are not required to understand guidelines.

Summary

ChoiceAll responders
Results
Agree 10
Agree with the following changes 8
Disagree

(4 responses didn't contain an answer to this question)

Details

Responder Requirement 4Comments
Justine Pascalides Agree
Abi James Agree
Keyonda Smith Agree
Jonathan Avila
Stefan Schnabel Agree with the following changes make clear that a translation process must be backed by concrete tech dependant examples with mucho info for the techies
Garry Grant Agree
Shawn Lauriat Agree
Brooks Newton Agree with the following changes I agree, as long as "technology-neutral" doesn't mean ignoring "accessibility support." I think concentrating on the writing language that is water tight over the passage of time without regard to specific technologies sets content authors up to bear the full brunt of conformance. We need to write guidelines that clearly convey the need for the rule, and the benefit achieved when the content author, the user, the wares manufacturers and the standards-makers do their parts. Which means we need to define what each of those parts are as part of the guideline. Otherwise, it all gets lumped onto the lap of the content author.
Jake Abma Agree with the following changes
To a certain degree we should aim for this but not at the cost of reducing clearness. Too much technology agnostic was one of the issues with WCAG till now.
Andrew Kirkpatrick Agree with the following changes This needs to be a "must" - subjective words like "avoid" are problematic. This requirement also seems to presume a specific structure for the guidelines document (unless "Guidelines" doesn't mean a specific level in the structure in prototypes - lower case and upper case "g" is used inconsistently, suggesting that it is significant [or just an error]). This should be up-leveled to speak to conformance by different technologies. For example:

Technology Neutral: The Guidelines are not technology-specific -- conformance with the Guidelines is possible across a wide range of technologies.

I don't understand what "Technical details are discoverable in the document structure but are not required to understand guidelines." means in the requirement.
Marc Johlic
Rachael Bradley Montgomery Agree
Laura Carlson Agree with the following changes Agree, if it was a principle instead of a requirement.

If the group agrees to a technology-neutral requirement, suggest simply using something such as, "Technology Neutral: Guidelines are worded to be "technology-neutral ". Simplify to remove the intent and details sentences.
Makoto Ueki
Bruce Bailey Agree
Glenda Sims Agree
Michael Gower Agree I do find it is tough to provide example without using a technology, but I think overall the Understanding docs and General techniques are achieving that.
Katie Haritos-Shea Agree Agree and support the internationalization comments for translation ease, technology coding built in to support this. Technology agnostic should be a primary goal.
Juli-Ann Rowsell Agree with the following changes must. technology specific is very challenging and difficult. Agonistic approaches are going to lend itself to more inclusion and meeting the other requirements on what guidance should really be reflective of.
David MacDonald Agree with the following changes "The intent of technology-neutral wording is to provide the opportunity to apply guidelines to current and emerging technology, even if the technical advice doesn't yet exist."

How can we apply a guideline if there is no technological solution? Except to say "don't do this yet, there's no way yet to make it accessible." (accessibility supported). Maybe I'm missing something.
Detlev Fischer Agree with the following changes Agree with others that the wording is not so clear - like "Technical details are discoverable in the document structure but are not required to understand guidelines'. The two-level structure of WCAG 2.X (technology neutral at the top layer, tech-specific further down in Techniques) seems generally a good approach, whatever these things end up being called in Silver.
Alastair Campbell

14. Requirement 5

Readability/Usability: The guidelines are understandable by non-technical audience. Text and presentation are usable and understandable through the use of simple language, structure and design.

Summary

ChoiceAll responders
Results
Agree 7
Agree with the following changes 10
Disagree

(5 responses didn't contain an answer to this question)

Details

Responder Requirement 5Comments
Justine Pascalides Agree
Abi James Agree
Keyonda Smith Agree with the following changes Text, NAVIGATION, and presentation are usable and understandable through the use of simple language, structure, and design.
Jonathan Avila
Stefan Schnabel Agree with the following changes see last comment
Garry Grant Agree
Shawn Lauriat Agree
Brooks Newton Agree with the following changes A simplified version of the guidelines should be available to support understanding by non-technical audiences.
Jake Abma Agree with the following changes
Agreed with a "but..."

I don't see how we get this right: "The guidelines are understandable by non-technical audience." as, for example, my mother would never understand lots of guidelines even when written in plain language.

Maybe the sentence could be written as:

Text and presentation are better usable and understandable even by a non-technical audience through the aim of plain language level X, simple structure and design.
Andrew Kirkpatrick Agree with the following changes My problem with this is how it is measured for success. If we can articulate that then this can be a good requirement, but if we can't then we won't have any way to settle a potential debate as to whether we have met this or not.
Marc Johlic
Rachael Bradley Montgomery Agree with the following changes The technical documents support documents will by nature need to be technical.
Laura Carlson Lacks specifics. How would this be measured? Requirements that use wishy-washy are not requirements at all. They are judgment calls, subjective to personal opinion.
Makoto Ueki
Bruce Bailey Agree
Glenda Sims Agree
Michael Gower Agree with the following changes Given requirement 3, this one gave me pause. Don't we potentially want a technical version of this that provides clarity? Can't we have that and still meet this requirement through another version meeting Requirement 3?
Katie Haritos-Shea Agree with the following changes Clarify
Juli-Ann Rowsell Agree Content design and IA are critical to ensuring the usability and accessibility of text, presentation as well as how difficult something might be to navigate.
David MacDonald Agree with the following changes This depends on where conformance hangs off of. If conformance hangs of the Guidelines then it gets iffy. Because sometimes precision requires specific ways of saying something.

If conformance hangs off the methods, then we'll need a catch all method which is precise enough to measure or test (or whatever determines conformance), and we'll might need to make the methods normative.
Detlev Fischer Agree with the following changes I would like a consistent two level approach: an intro which strives to be simple-language, understandable-for-most, and then a level below which works with examples to embed and explain in context the more technical terms.
Alastair Campbell

15. Requirement 6

Regulatory Environment: The Guidelines provide broad support, including:

* structure and content that facilitates adoption into law, regulation, or policy, and
* clear intent and transparency as to purpose and goals, to assist when there are questions or controversy.

Summary

ChoiceAll responders
Results
Agree 11
Agree with the following changes 5
Disagree 2

(4 responses didn't contain an answer to this question)

Details

Responder Requirement 6Comments
Justine Pascalides Agree
Abi James Agree
Keyonda Smith
Jonathan Avila
Stefan Schnabel Agree
Garry Grant Agree with the following changes Because of the exponential growth of lawsuits this over the past few years, their needs to be a curation period adoption into law (Not statewide but nationwide). I would vote for a 90 day to curate or fix the issues preventing people with disabilities from accessing a site or making purchases. Right now there is nothing, especially in California. I have several enterprise companies getting generic our of legal compliance threats. They are nothing more than extortion.
Shawn Lauriat Agree with the following changes "The Guidelines provide broad support for regulatory environments, including…"
Brooks Newton Agree
Jake Abma Agree
Andrew Kirkpatrick Disagree This needs to be clarified. I'm putting "disagree" not because I disagree, but because this is so important and needs to be be measurable as to the WG's success in meeting this requirement.
Marc Johlic
Rachael Bradley Montgomery Agree
Laura Carlson Agree with the following changes Again, lacks specifics. How would this be measured?
Makoto Ueki
Bruce Bailey Agree
Glenda Sims Agree
Michael Gower Disagree This sounds more like a Design principle than a requirement. It seems both too broad and too limited.
Katie Haritos-Shea Agree
Juli-Ann Rowsell Agree
David MacDonald Agree
Detlev Fischer Agree with the following changes That seems to suggest a split into things that are clearly measurable in terms of conformance and another set that is more best-practice-like and would contribute extra points (or whatever beyond the conformance baseline). I commented on Silver Github on the need to keep measurement and points scoring) focused on the object, not on ways to test it - i.e. a site must not get a better rating simply because it has been tested by more users.
Alastair Campbell Agree with the following changes NEW (post CSUN conversation): Something that appears to be missing is that the guidelines need to set a level of responsibility, at least for authors, possibly for UAs/Tools.

It says above "Authors are not responsible for interoperability problems beyond a reasonable effort.", but the guidelines need to either set that level, or provide enough for regulators to set that level.

16. Requirement 7

Motivation: The use of the guidelines supports and motivates organizations to acknowledge gaps and strive to be more inclusive. The intent is to give organizations a path toward greater accessibility.

Summary

ChoiceAll responders
Results
Agree 11
Agree with the following changes 4
Disagree 1

(6 responses didn't contain an answer to this question)

Details

Responder Requirement 7Comments
Justine Pascalides Agree
Abi James Agree
Keyonda Smith Agree with the following changes The use of the guidelines supports and motivates organizations to IDENTIFY ACCESSIBILITY gaps and CONTINUOUSLY AIM FOR IMPROVED INCLUSION.
Jonathan Avila
Stefan Schnabel Agree
Garry Grant Agree
Shawn Lauriat Agree
Brooks Newton Agree with the following changes I agree, as long as those "organizations" include more than just content authors. As I mentioned repeatedly, the list obligated organizations needs to include wares manufacturers and even the W3C.
Jake Abma Agree
Andrew Kirkpatrick Agree with the following changes Needs to be defined in a way that is measurable. What constitutes success in "supporting and motivating organizations"? I think that this could be a good requirement but we need to be able to say what the thing is that we are doing in the design of the guidelines to produce the desired effect. e.g. "The guidelines use gamification and cash rewards to support and motivate organizations..."
Marc Johlic
Rachael Bradley Montgomery I do not fully understand the intent of this.
Laura Carlson Agree with the following changes Lacks specifics. How would this be measured? Requirements that use wishy-washy are not requirements at all. They are judgment calls, subjective to personal opinion.
Makoto Ueki
Bruce Bailey Agree
Glenda Sims Agree
Michael Gower This sounds more like a result than a requirement. How do we measure 'motivating' a group? I obviously don't disagree with the sentiment. Just want this to made more concrete as a requirement.
Katie Haritos-Shea Agree The matrix of users needs in various UIs will help iorg understand where they can fill the gaps.
Juli-Ann Rowsell Agree
David MacDonald Agree Sure, WCAG 2 had this goal and we want to build on that.
Detlev Fischer Disagree Sounds very aspirational, not sure. It seems more the role of supplementary info around the guidelines.
Alastair Campbell

17. Requirement 8

Scope: The guidelines provide guidance for content, authoring tools, user agents and browsers, and assistive technologies.

EDITOR'S NOTE: The group consensus was to avoid over-loaded terms like "content", "authoring tool" and "user agent". Given the understanding that AGWG has of these terms, we also agreed they were clear in a W3C context. We will look for better terms, but we can agree on the concepts.

Summary

ChoiceAll responders
Results
Agree 9
Agree with the following changes 6
Disagree 4

(3 responses didn't contain an answer to this question)

Details

Responder Requirement 8Comments
Justine Pascalides Agree
Abi James Agree
Keyonda Smith Agree
Jonathan Avila
Stefan Schnabel Disagree guidance is not enough. establish a collaboration process with browser vendors and AT that will actively close gaps ans bridges implementation differences. dont left this undone. control and permanently MONITOR this. be more distinkt. demand and certify, do not just „guide“. this is way weak.

develop finally official w3c check tools that are browser and AT validators, not code validators.
Garry Grant Agree
Shawn Lauriat Agree with the following changes Needs to avoid the over-loaded terms to describe the breadth of scope.
Brooks Newton Disagree I'm not sure why these are over-loaded terms. They speak directly to where support for access is needed most. If it is a matter of creating language that is simpler and more universally understood, I am OK with brainstorming alternate labels for the same concepts.
Jake Abma Agree
Andrew Kirkpatrick Disagree This is a huge and important can of worms and we will need to define this in a way that clarifies more about how we will accomplish this. Will we have different user agent requirements for different types of technologies? I'm not clear on how this can work and worry that we are underestimating this. It may merit additional requirements to flesh this out.
Marc Johlic
Rachael Bradley Montgomery Agree
Laura Carlson Agree with the following changes Remove the editor's note. Agree with Brooks in that I am not sure why the terms "content", "authoring tool" and "user agent" are over-loaded.

Again, lacks specifics. The framework should provide structure to incorporate any parts of ATAG and UAAG that the group needs to incorporate.
Makoto Ueki
Bruce Bailey Agree Cautious to agree without plain language phrasing that avoids terms "authoring tools" and "users agents".
Glenda Sims Agree
Michael Gower Agree with the following changes Rather than just say "provide guidance" I'd rather include the provision of specific requirements for user agents and browsers.
Katie Haritos-Shea Agree
Juli-Ann Rowsell Agree with the following changes How will we do that?
The editors note is confusing to me.
David MacDonald Agree with the following changes I'm nervous about browsers. I would like comments from the browser industry....
Detlev Fischer Disagree I think it better to focus on authors OR tool makers OR AT makers that all have a different role to play. WCAG 2.X is already perceived as too big and cumbersome, it should not aim to get even bigger.
Alastair Campbell Agree with the following changes Until this statement the requirments come across as very authoring-focused. I read requirments 3.4, 3.6 & 3.7 as assuming the target audience is an organisation making a website/app/tool.

I'm not clear how it would support the inclusion of user-agent guidelines that are aimed at people making user-agents (or ATAG), it feels like there's a whole bunch of requirements missing if they are target audience(s).

Would it be fair to say that that focus is for oragnisations creating digital stuff, and UA/Tools requirements are there to support that goal, but not to provide a roadmap/standardisation path for UAs / Tools?

Unless there is a plan to migrate methods in from UAAG/ATAG, I would recommend making the scope to include UA methods that help fulfil a user-requirement from an author point of view.

E.g. for a user-requirement of "People can resize content without scrolling in two directions", the UA method could be to support reflow when expanding the content. The other side of the requirement for authors is to use media queries to adjust the layout when zoomed. This could become part of the conformance that replaces 'accessibility supported', where the UA methods are specified by the *author* as their way to meet conformance.

So for the text, how about: "The guidelines provide guidance for people and organisations that produce digital interfaces. As part of that guidance there is some coverage of browsers, authoring tools, and assistive technologies."

18. Additional Requirements?

If you feel that there are requirements that have not been addressed in the set of eight listed in this survey and would like to add comments to suggest additions, please do so here.

Details

Responder Additional Requirements?
Justine Pascalides
Abi James One common scenario that arises with the current guideline are that issues can be found through disabled user testing or audits that do not fit into a success criteria but are clearly an access barrier. Developers will argue that if it’s not under a successcriteria then it is a usability only issue. Is there away to ensure that “multiple ways to measure” includes considering issues that don’t fall within a clear guidelines but at least should be acknowledged/considered?
Keyonda Smith
Jonathan Avila
Stefan Schnabel
Garry Grant
Shawn Lauriat
Brooks Newton These guidelines should recognize the various roles that content authors, wares manufacturers (software and hardware), users and standards-makers play in supporting access to digital content. The guideline creation process should emphasize the strongest accessibility support requirements from those of the four parties who are best positioned to broadly and effectively improve access to digital content for people with disabilities. For each guideline, all parties' roles and responsibilities in supporting accessible user experiences should be defined.
Jake Abma
Andrew Kirkpatrick 1) We need to specify explicitly whether native apps are intended to be covered (this is possibly part of the ATAG/UAAG/WCAG combo bit).
2) I think that we need to consider whether we can establish guidance that results in non-overlap between SC (or whatever we call them).
3) Clarity around partial or substantially effective conformance?
Marc Johlic
Rachael Bradley Montgomery
Laura Carlson
Makoto Ueki
Bruce Bailey
Glenda Sims
Michael Gower
Katie Haritos-Shea
Juli-Ann Rowsell
David MacDonald
Detlev Fischer
Alastair Campbell For people testing, it is worth adding that: Someone testing with the guidelines should not have to test across assistive technologies to establish conformance.

More details on responses

  • Bruce Bailey: last responded on 11, March 2019 at 16:15 (UTC)
  • Glenda Sims: last responded on 11, March 2019 at 17:08 (UTC)
  • Michael Gower: last responded on 11, March 2019 at 18:50 (UTC)
  • Katie Haritos-Shea: last responded on 11, March 2019 at 19:48 (UTC)
  • Juli-Ann Rowsell: last responded on 12, March 2019 at 23:16 (UTC)
  • David MacDonald: last responded on 13, March 2019 at 21:22 (UTC)
  • Detlev Fischer: last responded on 2, April 2019 at 15:24 (UTC)
  • Alastair Campbell: last responded on 2, April 2019 at 15:48 (UTC)

Non-responders

The following persons have not answered the questionnaire:

  1. Gregg Vanderheiden
  2. Chris Wilson
  3. Lisa Seeman-Horwitz
  4. Janina Sajka
  5. Shawn Lawton Henry
  6. Shadi Abou-Zahra
  7. Chus Garcia
  8. Steve Faulkner
  9. Patrick Lauke
  10. Gez Lemon
  11. Peter Korn
  12. Preety Kumar
  13. Georgios Grigoriadis
  14. Romain Deltour
  15. Chris Blouch
  16. Jedi Lin
  17. Jeanne F Spellman
  18. Wilco Fiers
  19. Kimberly Patch
  20. Ian Pouncey
  21. Léonie Watson
  22. David Sloan
  23. Mary Jo Mueller
  24. John Kirkwood
  25. Reinaldo Ferraz
  26. Matt Garrish
  27. Mike Gifford
  28. Loïc Martínez Normand
  29. Mike Pluke
  30. Chris Loiselle
  31. Tzviya Siegman
  32. Jan McSorley
  33. Sailesh Panchang
  34. Cristina Mussinelli
  35. John Rochford
  36. Sarah Horton
  37. Sujasree Kurapati
  38. Jatin Vaishnav
  39. Sam Ogami
  40. Kevin White
  41. E.A. Draffan
  42. Paul Bohman
  43. JaEun Jemma Ku
  44. 骅 杨
  45. Victoria Clark
  46. Avneesh Singh
  47. Mitchell Evan
  48. biao liu
  49. Scott McCormack
  50. Denis Boudreau
  51. Francis Storr
  52. Rick Johnson
  53. David Swallow
  54. Aparna Pasi
  55. Gregorio Pellegrino
  56. Melanie Philipp
  57. Nicole Windmann
  58. Oliver Keim
  59. Gundula Niemann
  60. Ruoxi Ran
  61. Wendy Reid
  62. Scott O'Hara
  63. Charles Adams
  64. Muhammad Saleem
  65. Amani Ali
  66. Trevor Bostic
  67. Jamie Herrera
  68. Shinya Takami
  69. Karen Herr
  70. Kathy Eng
  71. Cybele Sack
  72. Audrey Maniez
  73. Jennifer Delisi
  74. Arthur Soroken
  75. Daniel Bjorge
  76. Kai Recke
  77. David Fazio
  78. Daniel Montalvo
  79. Mario Chacón-Rivas
  80. Michael Gilbert
  81. Caryn Pagel
  82. Achraf Othman
  83. Helen Burge
  84. Fernanda Bonnin
  85. Jared Batterman
  86. Raja Kushalnagar
  87. Jan Williams
  88. Todd Libby
  89. Isabel Holdsworth
  90. Julia Chen
  91. Marcos Franco Murillo
  92. Yutaka Suzuki
  93. Azlan Cuttilan
  94. Jennifer Strickland
  95. Joe Humbert
  96. Ben Tillyer
  97. Charu Pandhi
  98. Poornima Badhan Subramanian
  99. Alain Vagner
  100. Roberto Scano
  101. Rain Breaw Michaels
  102. Kun Zhang
  103. Jaunita George
  104. Regina Sanchez
  105. Shawn Thompson
  106. Thomas Brunet
  107. Kenny Dunsin
  108. Jen Goulden
  109. Mike Beganyi
  110. Ronny Hendriks
  111. Breixo Pastoriza Barcia
  112. Olivia Hogan-Stark
  113. Rashmi Katakwar
  114. Julie Rawe
  115. Duff Johnson
  116. Laura Miller
  117. Will Creedle
  118. Shikha Nikhil Dwivedi
  119. Marie Csanady
  120. Meenakshi Das
  121. Perrin Anto
  122. Stephanie Louraine
  123. Rachele DiTullio
  124. Jan Jaap de Groot
  125. Rebecca Monteleone
  126. Ian Kersey
  127. Peter Bossley
  128. Anastasia Lanz
  129. Michael Keane
  130. Chiara De Martin
  131. Giacomo Petri
  132. Andrew Barakat
  133. Devanshu Chandra
  134. Xiao (Helen) Zhou
  135. Bryan Trogdon
  136. Mary Ann (MJ) Jawili
  137. 禹佳 陶
  138. 锦澄 王
  139. Stephen James
  140. Jay Mullen
  141. Thorsten Katzmann
  142. Tony Holland
  143. Kent Boucher
  144. Abbey Davis
  145. Julia Kim
  146. Michelle Lana
  147. David Williams
  148. Mikayla Thompson
  149. Catherine Droege
  150. James Edwards
  151. Eric Hind
  152. Quintin Balsdon
  153. Mario Batušić
  154. David Cox
  155. Sazzad Mahamud
  156. Katy Brickley
  157. Kimberly Sarabia
  158. Corey Hinshaw
  159. Ashley Firth
  160. Daniel Harper-Wain
  161. Kiara Stewart
  162. DJ Chase
  163. Suji Sreerama
  164. Lori Oakley
  165. David Middleton
  166. Alyssa Priddy
  167. Young Choi
  168. Nichole Bui
  169. Julie Romanowski
  170. Eloisa Guerrero
  171. Daniel Henderson-Ede
  172. George Kuan
  173. YAPING LIN
  174. Justin Wilson
  175. Tiffany Burtin
  176. Shane Dittmar
  177. Nayan Padrai
  178. Niamh Kelly
  179. Matt Argomaniz Matthew Argomaniz
  180. Frankie Wolf
  181. Kimberly McGee
  182. Ahson Rana
  183. Carolina Crespo
  184. humor927 humor927
  185. Samantha McDaniel
  186. Matthäus Rojek
  187. Phong Tony Le
  188. Bram Janssens
  189. Graham Ritchie
  190. Aleksandar Cindrikj
  191. Jeroen Hulscher
  192. Alina Vayntrub
  193. Marco Sabidussi
  194. John Toles
  195. Jeanne Erickson Cooley
  196. Theo Hale
  197. Gert-Jan Vercauteren
  198. Karla Rubiano
  199. Aashutosh K
  200. Hidde de Vries
  201. Julian Kittelson-Aldred
  202. Roland Buss
  203. Aditya Surendranath
  204. Avon Kuo
  205. Elizabeth Patrick
  206. Nat Tarnoff
  207. Filippo Zorzi
  208. Mike Pedersen
  209. Rachael Yomtoob
  210. Oliver Habersetzer

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

Report issues on GitHub project w3c/wbs-design or by mail to sysreq.