Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Wording updates for requirements #735

Open
wants to merge 8 commits into
base: main
Choose a base branch
from
Open

Wording updates for requirements #735

Changes from 6 commits
Commits
Show all changes
8 commits
Select commit Hold shift + click to select a range
3f44414
Wording updates for requirements
alastc Mar 12, 2024
c561429
Updated from the comments in #44
alastc Mar 21, 2024
12506b9
Aligning with earlier updates.
alastc Mar 21, 2024
66a4d9b
Update from #727
alastc Mar 21, 2024
5ba752c
Merge branch 'main' into Issue44-Testability-rewording
alastc Mar 21, 2024
8e3a3fb
Merge branch 'main' into Issue44-Testability-rewording
alastc Mar 21, 2024
a960692
Update requirements/index.html
alastc Mar 26, 2024
4d46ea9
Merge branch 'main' into Issue44-Testability-rewording
alastc Apr 2, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
77 changes: 40 additions & 37 deletions requirements/index.html
View file
Open in desktop
Expand Up @@ -179,69 +179,72 @@ <h5>Proposed updates</h5>
<h2 id="design_principles">Design Principles</h2>
<p>The WCAG 3.0 Design Principles are based on the requirements of WCAG 2.0 and build on those requirements to meet needs identified in the WCAG 3.0 research. </p>
<p>Accessibility guidelines should:</p>
<ol>
<ol>
<li>Support the needs of a wide range of people with disabilities and recognize that people have individual and multiple needs.</li>
<li>Support a measurement and conformance structure that includes guidance for a broad range of disabilities. This includes particular attention to the needs of low vision and cognitive accessibility, whose needs don't tend to fit the true/false statement success criteria of WCAG 2.x.</li>
<li>Be flexible enough to support the needs of people with disabilities and keep up with emerging technologies. The information structure allows guidance to be added or removed.</li>
<li>Be accessible and conform to the Guidelines. <span class="ednote">Note: This design principle will move to the Requirements section once the Conformance section is completed and we determine a specific measurement of compliance. </span></li>
<li>Be written in plain language, as easy as possible to understand. <span class="ednote"> We need a definition of plain language that includes the ease of translation. Ideally, it will be a broadly accepted definition internationally. </span></li>
<li>Include accompanying documents that are clear and concise. Technical information (such as methods and how-tos) can be located quickly from a central place. </li>
<li>Define normative requirements unambiguously, so that there is only one possible meaning for each requirement. </li>
<li>Improve the ability to support automated testing where appropriate and provide a procedure for repeatable tests when manual testing is appropriate.</li>
<li>Provide requirements to address functional needs, while avoiding or minimizing negative impacts on other functional needs. </li>
<li>Include accompanying documents that provide clear, concise, and findable technical information quickly in one place.</li>
<li>Normative requirements should be unambiguous so there is only one possible meaning for each requirement.</li>

</ol>
<p>The creation process for the guidelines should:</p>
<ol start="7">
<li>Actively recruit a diverse range of people with disabilities in recognition of the importance of their contributions to accessibility standards and solutions. Review and monitor whether people are included. Continually evaluate inclusive features of available tooling and procedures. </li>
<li>Facilitate global participation and feedback.</li>
<li>Be data-informed and evidence-based where possible. We recognize that research and evidence are influenced by the number of people with a particular disability, by the size of the body of research, and by the difficulty in capturing data regarding some disabilities or combination of disabilities. The intent is to make informed decisions wherever possible to ensure that the needs of all people with disabilities are prioritized, including needs that differ from the majority. In situations where there is no evidence or research, valid data-gathering methods should be used to obtain and evaluate information from advocacy groups, people with lived experience and other subject matter experts.</li>
<li>Be written so the Guideline content is usable in adaptable and customizable ways. For example, WCAG 3.0 content is available to be extracted by users to adapt to their needs. </li>

<li>Be written so the Guideline content is usable in adaptable and customizable ways. For example, WCAG 3.0 content is available to be extracted by users to adapt to their needs. </li>
</ol>
</section>
<section>
<h2 id="requirements">Requirements</h2>
<p>Previous W3C Accessibility Guidelines described how to make web pages accessible to people with disabilities. These guidelines provided a flexible framework that has kept the guidelines relevant for 10 years. Changing technology and changing needs of people with disabilities has shown areas where they could be improved. The requirements are drawn from the research performed by WCAG 3.0 to improve the guidelines, and the suggestions from the Silver Design Sprint. </p>
<p>The WCAG 3.0 Requirements are high level and will be expanded and refined as Silver members move through the prototyping process.</p>
<section>
<h3>Broader disability support</h3>
<p>The guidance includes requirements that are not available in WCAG 2.x. Some guidance may use true/false verification but other guidance will use other ways of measuring and/or evaluating where appropriate so that more needs of people with disabilities may be included (for example: rubrics, sliding scale, task-completion, user research with people with disabilities, and more). This approach includes particular attention to people whose needs may better be met with a broad testing strategy, such as people with low vision, limited vision, or cognitive and learning disabilities.</p>
</section>
<section>
<h3>Flexible maintenance and extensibility</h3>
<p>The informative documentation uses a process that is easy to update and maintain.
alastc marked this conversation as resolved.
Show resolved Hide resolved
The process of developing the guidance includes experts who review the guidelines to check they will work for emerging technologies and interactions.</p>
</section>
<section>
<h2 id="requirements">Requirements</h2>
<p>Previous W3C Accessibility Guidelines described how to make web pages accessible to people with disabilities. These guidelines provided a flexible framework that has kept the guidelines relevant for 10 years. Changing technology and changing needs of people with disabilities has shown areas where they could be improved. The requirements are drawn from the research performed by WCAG 3.0 to improve the guidelines, and the suggestions from the Silver Design Sprint. </p>
<p>The WCAG 3.0 Requirements are high level and will be expanded and refined as Silver members move through the prototyping process.</p>
<section>
<h3>Broad disability support</h3>
<p>Silver guidance includes tests and other evaluation methods. Some guidance may use true/false verification but other guidance will use other ways of measuring and/or evaluating where appropriate so that more needs of people with disabilities may be included (for example: rubrics, sliding scale, task-completion, user research with people with disabilities, and more). This approach includes particular attention to people whose needs may better be met with a broad testing strategy, such as people with low vision, limited vision, or cognitive and learning disabilities. </p>
</section>
<section>
<h3>Flexible maintenance and extensibility</h3>
<p>Create a maintenance and extensibility model for guidelines that can better meet the needs of people with disabilities using emerging technologies and interactions. The process of developing the guidance includes experts in the technology.</p>
</section>
<section>
<h3>Multiple ways to display</h3>
<p>Design the guidelines so that they can be presented in different accessible and usable ways or formats, to address the needs of different audiences.</p>
</section>
<section>
<h3>Technology Neutral</h3>
<p>Guidance should be expressed in generic terms so that they may apply to more than one platform or technology. The intent of technology-neutral wording is to provide the opportunity to apply the core guidelines to current and emerging technology, even if specific technical advice doesn't yet exist.</p>
</section>
<section>
<p>Guidance is expressed in technology-neutral terms so that it can be met using different platforms or technologies. The intent of technology-neutral wording is to provide the opportunity to apply the core guidelines to current and emerging technology, even if specific technical advice doesn't yet exist.</p>
</section>
<section>
<h3>Readability</h3>
<p>The core guidelines are understandable by a non-technical audience. Text and presentation are usable and understandable through the use of plain language, structure, and design. They link to instruction videos, illustrations, and how-to where available. Creation of new videos and illustrations are outside the scope of this project at this time.
</p>
</section>
<section>
<p>Requirements in WCAG 3 for plain language shall be applied to WCAG 3. It is desirable for the guidelines to be understandable by the widest possible audience.</p>
</section>
<section>
<h3>Regulatory Environment</h3>
<p>The Guidelines provide broad support, including</p>
<ul>
<li>Structure, methodology, and content that facilitates adoption into law, regulation, or policy, and</li>
<li>clear intent and transparency as to purpose and goals, to assist when there are questions or controversy.</li>
</ul>
</section>
<section>
<h3>Motivation</h3>
<p>The Guidelines motivate organizations to go beyond minimal accessibility requirements by structuring WCAG 3 to provide encouragement to organizations which demonstrate a greater effort to improve accessibility.</p>
</section>
<section>
<h3>Scope</h3>
<p>The guidelines provide guidance and a conformance model for people and organizations that produce digital assets and technology of varying size and complexity. This includes large, dynamic, and complex websites. The associated informative materials will include guidance for a diverse group of stakeholders including content creators, browsers, authoring tools, assistive technologies, and more.</p>

</section>
<p>Requirements are written to facilitate adoption into law, regulation, or policy, since this has been shown to have major impact on practice. This includes:</p>
<ul>
<li>making the need and purpose for the requirement clear</li>
<li>a clear definition of when requirements are met.</li>
</ul>
</section>
<section>
<h3>Motivation</h3>
<p>The guidelines provide guidance and a conformance model for people and organizations that produce digital assets and technology of varying size and complexity. This includes large, dynamic, and complex websites. The associated informative materials will include guidance for a diverse group of stakeholders including content creators, browsers, authoring tools, assistive technologies, and more.</p>
</section>
<section class="appendix" id="changelog">
<section>
<h3>Scope</h3>
<p>WCAG 3 will provide guidance and a conformance model suitable for people and organizations that produce digital assets and technology of varying size and complexity. This includes large, dynamic, and complex websites. The scope of the associated informative materials will include guidance for a diverse group of stakeholders including content creators, browsers, authoring tools, assistive technologies, and more.</p>
</section>
</section>
<section class="appendix" id="changelog">
<h2>Change Log</h2>
<section>
<h3 id="changes-before-the-first-public-working-draft">Changes Prior to First Public Working Draft</h3>
Expand Down