w3c/wbs-design
or
by mail to sysreq
.
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:
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.
Choice | All responders |
---|---|
Results | |
Agree | 16 |
Agree with the following changes | 5 |
Disagree |
(1 response didn't contain an answer to this question)
Responder | Design Principle 1 | Comments |
---|---|---|
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 |
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.
Choice | All responders |
---|---|
Results | |
Agree | 9 |
Agree with the following changes | 9 |
Disagree | 3 |
(1 response didn't contain an answer to this question)
Responder | Design Principle 2 | Comments |
---|---|---|
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 |
Accessibility guidelines should: Be flexible enough to support the needs of people with disabilities using emerging technologies.
Choice | All responders |
---|---|
Results | |
Agree | 18 |
Agree with the following changes | 3 |
Disagree |
(1 response didn't contain an answer to this question)
Responder | Design Principle 3 | Comments |
---|---|---|
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 |
Accessibility guidelines should: Follow accessibility guidance.
Choice | All responders |
---|---|
Results | |
Agree | 9 |
Agree with the following changes | 7 |
Disagree | 4 |
(2 responses didn't contain an answer to this question)
Responder | Design Principle 4 | Comments |
---|---|---|
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 |
Accessibility guidelines should: Be written in plain language, as easy as possible to understand.
Choice | All responders |
---|---|
Results | |
Agree | 16 |
Agree with the following changes | 5 |
Disagree |
(1 response didn't contain an answer to this question)
Responder | Design Principle 5 | Comments |
---|---|---|
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 |
The creation process for the guidelines should: Include people with disabilities and recognize that they are important contributors to accessibility standards and solution.
Choice | All responders |
---|---|
Results | |
Agree | 12 |
Agree with the following changes | 9 |
Disagree |
(1 response didn't contain an answer to this question)
Responder | Design Principle 6 | Comments |
---|---|---|
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 |
The creation process for the guidelines should: Have global participation and feedback.
Choice | All responders |
---|---|
Results | |
Agree | 19 |
Agree with the following changes | 2 |
Disagree |
(1 response didn't contain an answer to this question)
Responder | Design Principle 7 | Comments |
---|---|---|
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 |
The creation process for the guidelines should: Strive to be data-informed and evidence-based.
Choice | All responders |
---|---|
Results | |
Agree | 14 |
Agree with the following changes | 7 |
Disagree |
(1 response didn't contain an answer to this question)
Responder | Design Principle 8 | Comments |
---|---|---|
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 |
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.
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 |
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.
Choice | All responders |
---|---|
Results | |
Agree | 5 |
Agree with the following changes | 9 |
Disagree | 4 |
(4 responses didn't contain an answer to this question)
Responder | Requirement 1 | Comments |
---|---|---|
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 |
Flexible structure: Create a structure for guidelines that can better meet the needs of people in unanticipated technologies and interactions.
Choice | All responders |
---|---|
Results | |
Agree | 9 |
Agree with the following changes | 9 |
Disagree |
(4 responses didn't contain an answer to this question)
Responder | Requirement 2 | Comments |
---|---|---|
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 |
Multiple ways to display: Make the guidelines available in different accessible and usable ways so the guidance can be customized by different audiences.
Choice | All responders |
---|---|
Results | |
Agree | 12 |
Agree with the following changes | 6 |
Disagree |
(4 responses didn't contain an answer to this question)
Responder | Requirement 3 | Comments |
---|---|---|
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 |
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.
Choice | All responders |
---|---|
Results | |
Agree | 10 |
Agree with the following changes | 8 |
Disagree |
(4 responses didn't contain an answer to this question)
Responder | Requirement 4 | Comments |
---|---|---|
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 |
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.
Choice | All responders |
---|---|
Results | |
Agree | 7 |
Agree with the following changes | 10 |
Disagree |
(5 responses didn't contain an answer to this question)
Responder | Requirement 5 | Comments |
---|---|---|
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 |
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.
Choice | All responders |
---|---|
Results | |
Agree | 11 |
Agree with the following changes | 5 |
Disagree | 2 |
(4 responses didn't contain an answer to this question)
Responder | Requirement 6 | Comments |
---|---|---|
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. |
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.
Choice | All responders |
---|---|
Results | |
Agree | 11 |
Agree with the following changes | 4 |
Disagree | 1 |
(6 responses didn't contain an answer to this question)
Responder | Requirement 7 | Comments |
---|---|---|
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 |
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.
Choice | All responders |
---|---|
Results | |
Agree | 9 |
Agree with the following changes | 6 |
Disagree | 4 |
(3 responses didn't contain an answer to this question)
Responder | Requirement 8 | Comments |
---|---|---|
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." |
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.
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. |
The following persons have not answered the questionnaire:
Send an email to all the non-responders.
Compact view of the results / list of email addresses of the responders
WBS home / Questionnaires / WG questionnaires / Answer this questionnaire
w3c/wbs-design
or
by mail to sysreq
.