https://www.w3.org/WAI/EO/wiki/api.php?action=feedcontributions&feedformat=atom&user=WdickEducation & Outreach - User contributions [en]2024-03-28T22:56:13ZUser contributionsMediaWiki 1.41.0https://www.w3.org/WAI/EO/wiki/index.php?title=Quick_Start_Guides/Structure_and_Content&diff=12729Quick Start Guides/Structure and Content2015-05-06T22:48:33Z<p>Wdick: /* Tips */</p>
<hr />
<div>{{TOClimit|2}}<br />
<br />
This page captures the proposed content for the Quick Start guides. Each task area has a set of topics that should be succinct and actionable.<br />
<br />
See [[Quick Start Guides/Requirements Analysis#Approach]] and [[Quick Start Guides/Design]] for more information on how this will be structured.<br />
<br />
== EOWG editing notes ==<br />
<br />
Below are suggestions for formatting your ideas for rewording, [your comments that aren't a direct rewording], and your ideas for a new tip:<br />
<br />
* Tip from original draft<br />
** {{Comment|Reword: Suggestion for rewording the tip above|your name|dd MMM YYYY}}<br />
* Tip from original draft<br />
** {{Comment|Comment on this tip that's not rewording|your name|dd MMM YYYY}}<br />
* {{Comment|New:New tip suggestion|your name|dd MMM YYYY}}<br />
<br />
== Designing ==<br />
<br />
Visual or interface designers<br />
<br />
=== Tips ===<br />
<br />
* Ensure color palette is high contrast<br />
** {{Comment|Reword: Provide sufficient contrast between text and background colors|Shawn|1 May 2015}}<br />
** For each text foreground/background color combination, including on buttons, check that the contrast between the two colors has sufficient contrast. For text presented over a background image take a sample of dominant colors or provide some way to make the text stand out.<br />
*** Learn more:<br>[http://w3c.github.io/wai-eval-tools/#accessibility-color-wheel Accessibility Color Wheel], [http://w3c.github.io/wai-eval-tools/#color-oracle Color Oracle], [http://w3c.github.io/wai-eval-tools/#contrast-checker Contrast Checker], [http://w3c.github.io/wai-eval-tools/#contrast-finder Contrast Finder]: Various tools that help in exploring color contrast<br>[http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-contrast.html Success Criteria 1.4.3 Contrast (Minimum)]: WCAG Success Criteria for color contrast<br>[http://www.w3.org/WAI/intro/people-use-web/stories#shopper Mr. Lee, Online shopper with color blindness]: Describes how a user with color discrimination experiences the Web<br />
* Don't use color alone to signify meaning<br />
* Ensure links and interactive elements have a hover and focus styling<br />
* Provide navigation that allows easy access to other website pages and clear indication of location in website<br />
* Provide visible controls for audio and video players<br />
* Ensure form elements include clearly associated labels, with space for important instructions<br />
* Present form errors in a block above the form and make the fields in error extremely obvious<br />
** ✓ {{Comment|I needed to Google “salient” – probably a less known word by non-native speakers?|Eric|1 May 2015}}<br />
* Structure text to include headers, not be too wide, and in a good font size<br />
** {{Comment|This is 3 tips in one and I think should be separated|Shawn|1 May 2015}}</span><br />
* Learn more about accessibility<br />
** {{Comment|This seems gratuitous. Without function related activity it will annoy readers. |Wayne May 2015}}<br />
* {{Comment|New: Ensure that it is easy to distinguish between page sections|Eric|1 May 2015}}<br />
* {{Comment|New: Provide text alternatives or visible labels for icons|Eric|1 May 2015}}<br />
* {{Comment|New: something on images|Melody, Sharron, Vicki|1 May 2015}}<br />
<br />
== Developing ==<br />
<br />
Front-end developer, or programmer.<br />
<br />
=== Tips ===<br />
<br />
* Ensure good semantic mark-up; e.g. if it looks like a header, mark it up with a header element<br />
**{{comment|...if it looks or acts like a header...!Wayne May 2015}}<br />
* Ensure all form elements have an associated label<br />
** The &lt;label&gt; element is associated with form elements using the ''for'' and ''id'' attributes. Where a design does not include a visible label, provide one but position it offscreen using CSS.<br />
*** Example:<br><code>&lt;label for="username"&gt;<br>&lt;input id="username" type="text"&gt;</code><br />
*** Learn more:<br>[http://www.w3.org/WAI/tutorials/forms/labels/ Labelling controls]: Provides more involved help on how to label form controls and elements<br>[http://www.w3.org/TR/UNDERSTANDING-WCAG20/minimize-error-cues.html Success Criteria 3.3.2 Labels or Instructions]: WCAG Success Criteria for labels<br>[http://www.w3.org/WAI/intro/people-use-web/browsing#navigation Design solutions - navigating and finding content]: Explores how providing labels benefits people with disabilities<br />
* Use HTML5 structural elements<br />
* Match the reading order and the code order<br />
* Use ARIA to provide meaning to non-standard interactive elements<br />
* Ensure that all interactive elements are keyboard accessible<br />
* Check your code validates<br />
* Learn more about accessibility<br />
**{Actually I do think this is important. It just needs specifics |Wayne 2015}<br />
<br />
== Authoring ==<br />
<br />
Content author, or content manager.<br />
<br />
=== Tips ===<br />
<br />
* Content authors with help from content managers should have primary responsibility for text alternatives, especially long descriptions. Presumably the author knows why an image is used and whether it is content or decoration |Wayne<br />
* Keep it short and simple<br />
* Avoid using 'click here'<br />
* Provide short, meaningful headings to break-up long text blocks<br />
* Ensure that captions are provided for audio/visual content<br />
* Avoid using complex words and sentence structures<br />
* Ensure all pages are provided with a meaningful title<br />
* File download link text should include file type and size<br />
* Learn more about accessibility<br />
<br />
== Evaluating ==<br />
<br />
QA, tester, or evaluator.<br />
<br />
=== Tips ===<br />
<br />
* Use Easy Checks for early quick reviews<br />
* Run evaluation sessions with real people<br />
* Review QA process to incorporate early evaluations<br />
* Review evaluation methodology in line with WCAG-EM<br />
* Incorporate WCAG-EM Reporting Tool into QA process<br />
* Develop and maintain database of commonly identified issues<br />
* Learn more about accessibility<br />
<br />
== Advocating ==<br />
<br />
Champion, or spokesperson.<br />
<br />
=== Tips ===<br />
<br />
* Learn more about accessibility<br />
* Create awareness for accessibility through presentation and outreach<br />
* Develop accessibility business case<br />
* Secure management support for accessibility activities<br />
* Communicate accessibility wins<br />
* Create an internal and external feedback mechanism<br />
* Use Easy Checks to develop a general appreciation for key website accessibility<br />
* Actively seek input from people with disabilities<br />
<br />
== Project managing ==<br />
<br />
Project managers or website owners<br />
<br />
=== Tips ===<br />
<br />
* Secure buy-in from senior management<br />
** Support from management helps ensure budget and resources are available for accessibility activities. A strong business case, tailored to organizational goals, will help.<br />
*** Learn more:<br>[http://www.w3.org/WAI/bcase/Overview.html Developing a Web Accessibility Business Case for Your Organization]: Provides information on how to create a business case<br>[http://www.w3.org/WAI/impl/#goal Determine Your Goal and Gather Support]: Section of Strategic Planning document that discusses broad area of securing management support.<br />
* Provide accessibility awareness training<br />
* Appoint at least one accessibility specialist<br />
* Plan for regular accessibility checks<br />
* Create an accessibility policy<br />
* Provide a publicly available website accessibility statement<br />
* Involve users with disability in any usability testing<br />
* Learn more about accessibility<br />
<br />
== Feedback ==<br />
<br />
This document was raised for general feedback in the [https://www.w3.org/2002/09/wbs/35532/eowg27042015/results#xq12 27 April Survey] and discussed on [http://www.w3.org/2015/05/01-eo-minutes.html 1 May meeting].<br />
<br />
=== General points for discussion ===<br />
<br />
* {{Comment|Maybe change from role-based (eg. "tips for designers") to task-based (eg. "tips for designing")?|Shadi|30 Apr 2015}}<br>{{Comment|User Experience Designer is also missing as an audience.|Melody|27 Apr 2015}}<br />
** {{Comment|Need to seek a balance between classifying every role and ensuring a clear distinction between relevant tips. How should we create this balance?|Kevin|1 May 2015}}<br />
* {{Comment|Is this going to be in depth enough for evaluators? There is a wide spread of skill between advocate and developer/evaluator. How do we bridge that?|Wayne|30 Apr 2015}}<br />
** {{Comment|There is certainly a difference in level of detail required depending on level of activity. Should the aim be to try to balance the tips across all activity areas, or within an area, or not at all?|Kevin|1 May 2015}}<br />
* {{Comment|Keep this resource a simple sign-post to existing resources, rather than try to re-develop existing content.|Shadi|30 Apr 2015}}<br>{{Comment|I recall that the joys that everyone took in the biz card was it clarity and brevity.|Sharron|30 Apr 2015}}<br />
** {{Comment|This discussion point aims to explore what content should be included; the requirements have suggested a top, a short expansion paragraph, and optional example, benefits, and/or relevant resources|Kevin|1 May 2015}}<br />
<br />
=== Focused points for discussion ===<br />
<br />
* {{Comment|Designer: Hover styling doesn't apply to touch devices. Was "active" styling meant?|Melody|27 Apr 2015}}<br />
** {{Comment|I deliberately used 'hover' and 'focus' as 'active' is sometimes taken to apply to mouse interactions only. I agree that 'active' would be more accurate, but the terminology may be lost on some.|Kevin|28 Apr 2015}}<br />
* {{Comment|Designer and Developer: Missing guidance for images|Melody|27 Apr 2015}}<br>{{Comment|I believe authors should be responsible for non-text elements that require text (images, charts, etc).|Jon|30 Apr 2015}}<br />
** {{Comment|Someone needs to take responsibility for ensuring all imagery has appropriate alternative text. The difficulty is that the responsibility for this is likely to vary quite a bit. Perhaps a note of this is required in multiple places, possibly including Author?|Kevin|28 Apr 2015}}<br />
* {{Comment|Isn't it a bit redundant to recommend that people "Learn more about accessibility?" I mean, isn't that why they're here?|Jon|30 Apr 2015}}<br />
** {{Comment|The aim of this tip was to highlight that this was not the end of the journey but just the beginning, and to signpost to other more detailed resources. It might benefit with more clarification.|Kevin|1 May 2015}}<br />
<br />
=== Previous feedback ===<br />
<br />
* {{LongComment|summary=Also helps with...|comment=Might be worth also including a short snippet that highlights the value this activity brings to a broader audience|by=Andrew/Kevin|date=10 Apr 2015}}</div>Wdickhttps://www.w3.org/WAI/EO/wiki/index.php?title=Quick_Start_Guides/Structure_and_Content&diff=12728Quick Start Guides/Structure and Content2015-05-06T22:35:05Z<p>Wdick: /* Tips */</p>
<hr />
<div>{{TOClimit|2}}<br />
<br />
This page captures the proposed content for the Quick Start guides. Each task area has a set of topics that should be succinct and actionable.<br />
<br />
See [[Quick Start Guides/Requirements Analysis#Approach]] and [[Quick Start Guides/Design]] for more information on how this will be structured.<br />
<br />
== EOWG editing notes ==<br />
<br />
Below are suggestions for formatting your ideas for rewording, [your comments that aren't a direct rewording], and your ideas for a new tip:<br />
<br />
* Tip from original draft<br />
** {{Comment|Reword: Suggestion for rewording the tip above|your name|dd MMM YYYY}}<br />
* Tip from original draft<br />
** {{Comment|Comment on this tip that's not rewording|your name|dd MMM YYYY}}<br />
* {{Comment|New:New tip suggestion|your name|dd MMM YYYY}}<br />
<br />
== Designing ==<br />
<br />
Visual or interface designers<br />
<br />
=== Tips ===<br />
<br />
* Ensure color palette is high contrast<br />
** {{Comment|Reword: Provide sufficient contrast between text and background colors|Shawn|1 May 2015}}<br />
** For each text foreground/background color combination, including on buttons, check that the contrast between the two colors has sufficient contrast. For text presented over a background image take a sample of dominant colors or provide some way to make the text stand out.<br />
*** Learn more:<br>[http://w3c.github.io/wai-eval-tools/#accessibility-color-wheel Accessibility Color Wheel], [http://w3c.github.io/wai-eval-tools/#color-oracle Color Oracle], [http://w3c.github.io/wai-eval-tools/#contrast-checker Contrast Checker], [http://w3c.github.io/wai-eval-tools/#contrast-finder Contrast Finder]: Various tools that help in exploring color contrast<br>[http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-contrast.html Success Criteria 1.4.3 Contrast (Minimum)]: WCAG Success Criteria for color contrast<br>[http://www.w3.org/WAI/intro/people-use-web/stories#shopper Mr. Lee, Online shopper with color blindness]: Describes how a user with color discrimination experiences the Web<br />
* Don't use color alone to signify meaning<br />
* Ensure links and interactive elements have a hover and focus styling<br />
* Provide navigation that allows easy access to other website pages and clear indication of location in website<br />
* Provide visible controls for audio and video players<br />
* Ensure form elements include clearly associated labels, with space for important instructions<br />
* Present form errors in a block above the form and make the fields in error extremely obvious<br />
** ✓ {{Comment|I needed to Google “salient” – probably a less known word by non-native speakers?|Eric|1 May 2015}}<br />
* Structure text to include headers, not be too wide, and in a good font size<br />
** {{Comment|This is 3 tips in one and I think should be separated|Shawn|1 May 2015}}</span><br />
* Learn more about accessibility<br />
** {{Comment|This seems gratuitous. Without function related activity it will annoy readers. |Wayne May 2015}}<br />
* {{Comment|New: Ensure that it is easy to distinguish between page sections|Eric|1 May 2015}}<br />
* {{Comment|New: Provide text alternatives or visible labels for icons|Eric|1 May 2015}}<br />
* {{Comment|New: something on images|Melody, Sharron, Vicki|1 May 2015}}<br />
<br />
== Developing ==<br />
<br />
Front-end developer, or programmer.<br />
<br />
=== Tips ===<br />
<br />
* Ensure good semantic mark-up; e.g. if it looks like a header, mark it up with a header element<br />
**{{comment|...if it looks or acts like a header...!Wayne May 2015}}<br />
* Ensure all form elements have an associated label<br />
** The &lt;label&gt; element is associated with form elements using the ''for'' and ''id'' attributes. Where a design does not include a visible label, provide one but position it offscreen using CSS.<br />
*** Example:<br><code>&lt;label for="username"&gt;<br>&lt;input id="username" type="text"&gt;</code><br />
*** Learn more:<br>[http://www.w3.org/WAI/tutorials/forms/labels/ Labelling controls]: Provides more involved help on how to label form controls and elements<br>[http://www.w3.org/TR/UNDERSTANDING-WCAG20/minimize-error-cues.html Success Criteria 3.3.2 Labels or Instructions]: WCAG Success Criteria for labels<br>[http://www.w3.org/WAI/intro/people-use-web/browsing#navigation Design solutions - navigating and finding content]: Explores how providing labels benefits people with disabilities<br />
* Use HTML5 structural elements<br />
* Match the reading order and the code order<br />
* Use ARIA to provide meaning to non-standard interactive elements<br />
* Ensure that all interactive elements are keyboard accessible<br />
* Check your code validates<br />
* Learn more about accessibility<br />
**{Actually I do think this is important. It just needs specifics |Wayne 2015}<br />
<br />
== Authoring ==<br />
<br />
Content author, or content manager.<br />
<br />
=== Tips ===<br />
<br />
* Keep it short and simple<br />
* Avoid using 'click here'<br />
* Provide short, meaningful headings to break-up long text blocks<br />
* Ensure that captions are provided for audio/visual content<br />
* Avoid using complex words and sentence structures<br />
* Ensure all pages are provided with a meaningful title<br />
* File download link text should include file type and size<br />
* Learn more about accessibility<br />
<br />
== Evaluating ==<br />
<br />
QA, tester, or evaluator.<br />
<br />
=== Tips ===<br />
<br />
* Use Easy Checks for early quick reviews<br />
* Run evaluation sessions with real people<br />
* Review QA process to incorporate early evaluations<br />
* Review evaluation methodology in line with WCAG-EM<br />
* Incorporate WCAG-EM Reporting Tool into QA process<br />
* Develop and maintain database of commonly identified issues<br />
* Learn more about accessibility<br />
<br />
== Advocating ==<br />
<br />
Champion, or spokesperson.<br />
<br />
=== Tips ===<br />
<br />
* Learn more about accessibility<br />
* Create awareness for accessibility through presentation and outreach<br />
* Develop accessibility business case<br />
* Secure management support for accessibility activities<br />
* Communicate accessibility wins<br />
* Create an internal and external feedback mechanism<br />
* Use Easy Checks to develop a general appreciation for key website accessibility<br />
* Actively seek input from people with disabilities<br />
<br />
== Project managing ==<br />
<br />
Project managers or website owners<br />
<br />
=== Tips ===<br />
<br />
* Secure buy-in from senior management<br />
** Support from management helps ensure budget and resources are available for accessibility activities. A strong business case, tailored to organizational goals, will help.<br />
*** Learn more:<br>[http://www.w3.org/WAI/bcase/Overview.html Developing a Web Accessibility Business Case for Your Organization]: Provides information on how to create a business case<br>[http://www.w3.org/WAI/impl/#goal Determine Your Goal and Gather Support]: Section of Strategic Planning document that discusses broad area of securing management support.<br />
* Provide accessibility awareness training<br />
* Appoint at least one accessibility specialist<br />
* Plan for regular accessibility checks<br />
* Create an accessibility policy<br />
* Provide a publicly available website accessibility statement<br />
* Involve users with disability in any usability testing<br />
* Learn more about accessibility<br />
<br />
== Feedback ==<br />
<br />
This document was raised for general feedback in the [https://www.w3.org/2002/09/wbs/35532/eowg27042015/results#xq12 27 April Survey] and discussed on [http://www.w3.org/2015/05/01-eo-minutes.html 1 May meeting].<br />
<br />
=== General points for discussion ===<br />
<br />
* {{Comment|Maybe change from role-based (eg. "tips for designers") to task-based (eg. "tips for designing")?|Shadi|30 Apr 2015}}<br>{{Comment|User Experience Designer is also missing as an audience.|Melody|27 Apr 2015}}<br />
** {{Comment|Need to seek a balance between classifying every role and ensuring a clear distinction between relevant tips. How should we create this balance?|Kevin|1 May 2015}}<br />
* {{Comment|Is this going to be in depth enough for evaluators? There is a wide spread of skill between advocate and developer/evaluator. How do we bridge that?|Wayne|30 Apr 2015}}<br />
** {{Comment|There is certainly a difference in level of detail required depending on level of activity. Should the aim be to try to balance the tips across all activity areas, or within an area, or not at all?|Kevin|1 May 2015}}<br />
* {{Comment|Keep this resource a simple sign-post to existing resources, rather than try to re-develop existing content.|Shadi|30 Apr 2015}}<br>{{Comment|I recall that the joys that everyone took in the biz card was it clarity and brevity.|Sharron|30 Apr 2015}}<br />
** {{Comment|This discussion point aims to explore what content should be included; the requirements have suggested a top, a short expansion paragraph, and optional example, benefits, and/or relevant resources|Kevin|1 May 2015}}<br />
<br />
=== Focused points for discussion ===<br />
<br />
* {{Comment|Designer: Hover styling doesn't apply to touch devices. Was "active" styling meant?|Melody|27 Apr 2015}}<br />
** {{Comment|I deliberately used 'hover' and 'focus' as 'active' is sometimes taken to apply to mouse interactions only. I agree that 'active' would be more accurate, but the terminology may be lost on some.|Kevin|28 Apr 2015}}<br />
* {{Comment|Designer and Developer: Missing guidance for images|Melody|27 Apr 2015}}<br>{{Comment|I believe authors should be responsible for non-text elements that require text (images, charts, etc).|Jon|30 Apr 2015}}<br />
** {{Comment|Someone needs to take responsibility for ensuring all imagery has appropriate alternative text. The difficulty is that the responsibility for this is likely to vary quite a bit. Perhaps a note of this is required in multiple places, possibly including Author?|Kevin|28 Apr 2015}}<br />
* {{Comment|Isn't it a bit redundant to recommend that people "Learn more about accessibility?" I mean, isn't that why they're here?|Jon|30 Apr 2015}}<br />
** {{Comment|The aim of this tip was to highlight that this was not the end of the journey but just the beginning, and to signpost to other more detailed resources. It might benefit with more clarification.|Kevin|1 May 2015}}<br />
<br />
=== Previous feedback ===<br />
<br />
* {{LongComment|summary=Also helps with...|comment=Might be worth also including a short snippet that highlights the value this activity brings to a broader audience|by=Andrew/Kevin|date=10 Apr 2015}}</div>Wdickhttps://www.w3.org/WAI/EO/wiki/index.php?title=Quick_Start_Guides/Structure_and_Content&diff=12727Quick Start Guides/Structure and Content2015-05-06T22:32:15Z<p>Wdick: /* Tips */</p>
<hr />
<div>{{TOClimit|2}}<br />
<br />
This page captures the proposed content for the Quick Start guides. Each task area has a set of topics that should be succinct and actionable.<br />
<br />
See [[Quick Start Guides/Requirements Analysis#Approach]] and [[Quick Start Guides/Design]] for more information on how this will be structured.<br />
<br />
== EOWG editing notes ==<br />
<br />
Below are suggestions for formatting your ideas for rewording, [your comments that aren't a direct rewording], and your ideas for a new tip:<br />
<br />
* Tip from original draft<br />
** {{Comment|Reword: Suggestion for rewording the tip above|your name|dd MMM YYYY}}<br />
* Tip from original draft<br />
** {{Comment|Comment on this tip that's not rewording|your name|dd MMM YYYY}}<br />
* {{Comment|New:New tip suggestion|your name|dd MMM YYYY}}<br />
<br />
== Designing ==<br />
<br />
Visual or interface designers<br />
<br />
=== Tips ===<br />
<br />
* Ensure color palette is high contrast<br />
** {{Comment|Reword: Provide sufficient contrast between text and background colors|Shawn|1 May 2015}}<br />
** For each text foreground/background color combination, including on buttons, check that the contrast between the two colors has sufficient contrast. For text presented over a background image take a sample of dominant colors or provide some way to make the text stand out.<br />
*** Learn more:<br>[http://w3c.github.io/wai-eval-tools/#accessibility-color-wheel Accessibility Color Wheel], [http://w3c.github.io/wai-eval-tools/#color-oracle Color Oracle], [http://w3c.github.io/wai-eval-tools/#contrast-checker Contrast Checker], [http://w3c.github.io/wai-eval-tools/#contrast-finder Contrast Finder]: Various tools that help in exploring color contrast<br>[http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-contrast.html Success Criteria 1.4.3 Contrast (Minimum)]: WCAG Success Criteria for color contrast<br>[http://www.w3.org/WAI/intro/people-use-web/stories#shopper Mr. Lee, Online shopper with color blindness]: Describes how a user with color discrimination experiences the Web<br />
* Don't use color alone to signify meaning<br />
* Ensure links and interactive elements have a hover and focus styling<br />
* Provide navigation that allows easy access to other website pages and clear indication of location in website<br />
* Provide visible controls for audio and video players<br />
* Ensure form elements include clearly associated labels, with space for important instructions<br />
* Present form errors in a block above the form and make the fields in error extremely obvious<br />
** ✓ {{Comment|I needed to Google “salient” – probably a less known word by non-native speakers?|Eric|1 May 2015}}<br />
* Structure text to include headers, not be too wide, and in a good font size<br />
** {{Comment|This is 3 tips in one and I think should be separated|Shawn|1 May 2015}}</span><br />
* Learn more about accessibility<br />
** {{Comment|This seems gratuitous. Without function related activity it will annoy readers. |Wayne May 2015}}<br />
* {{Comment|New: Ensure that it is easy to distinguish between page sections|Eric|1 May 2015}}<br />
* {{Comment|New: Provide text alternatives or visible labels for icons|Eric|1 May 2015}}<br />
* {{Comment|New: something on images|Melody, Sharron, Vicki|1 May 2015}}<br />
<br />
== Developing ==<br />
<br />
Front-end developer, or programmer.<br />
<br />
=== Tips ===<br />
<br />
* Ensure good semantic mark-up; e.g. if it looks like a header, mark it up with a header element<br />
* Ensure all form elements have an associated label<br />
** The &lt;label&gt; element is associated with form elements using the ''for'' and ''id'' attributes. Where a design does not include a visible label, provide one but position it offscreen using CSS.<br />
*** Example:<br><code>&lt;label for="username"&gt;<br>&lt;input id="username" type="text"&gt;</code><br />
*** Learn more:<br>[http://www.w3.org/WAI/tutorials/forms/labels/ Labelling controls]: Provides more involved help on how to label form controls and elements<br>[http://www.w3.org/TR/UNDERSTANDING-WCAG20/minimize-error-cues.html Success Criteria 3.3.2 Labels or Instructions]: WCAG Success Criteria for labels<br>[http://www.w3.org/WAI/intro/people-use-web/browsing#navigation Design solutions - navigating and finding content]: Explores how providing labels benefits people with disabilities<br />
* Use HTML5 structural elements<br />
* Match the reading order and the code order<br />
* Use ARIA to provide meaning to non-standard interactive elements<br />
* Ensure that all interactive elements are keyboard accessible<br />
* Check your code validates<br />
* Learn more about accessibility<br />
**{Actually I do think this is important. It just needs specifics |Wayne 2015}<br />
<br />
== Authoring ==<br />
<br />
Content author, or content manager.<br />
<br />
=== Tips ===<br />
<br />
* Keep it short and simple<br />
* Avoid using 'click here'<br />
* Provide short, meaningful headings to break-up long text blocks<br />
* Ensure that captions are provided for audio/visual content<br />
* Avoid using complex words and sentence structures<br />
* Ensure all pages are provided with a meaningful title<br />
* File download link text should include file type and size<br />
* Learn more about accessibility<br />
<br />
== Evaluating ==<br />
<br />
QA, tester, or evaluator.<br />
<br />
=== Tips ===<br />
<br />
* Use Easy Checks for early quick reviews<br />
* Run evaluation sessions with real people<br />
* Review QA process to incorporate early evaluations<br />
* Review evaluation methodology in line with WCAG-EM<br />
* Incorporate WCAG-EM Reporting Tool into QA process<br />
* Develop and maintain database of commonly identified issues<br />
* Learn more about accessibility<br />
<br />
== Advocating ==<br />
<br />
Champion, or spokesperson.<br />
<br />
=== Tips ===<br />
<br />
* Learn more about accessibility<br />
* Create awareness for accessibility through presentation and outreach<br />
* Develop accessibility business case<br />
* Secure management support for accessibility activities<br />
* Communicate accessibility wins<br />
* Create an internal and external feedback mechanism<br />
* Use Easy Checks to develop a general appreciation for key website accessibility<br />
* Actively seek input from people with disabilities<br />
<br />
== Project managing ==<br />
<br />
Project managers or website owners<br />
<br />
=== Tips ===<br />
<br />
* Secure buy-in from senior management<br />
** Support from management helps ensure budget and resources are available for accessibility activities. A strong business case, tailored to organizational goals, will help.<br />
*** Learn more:<br>[http://www.w3.org/WAI/bcase/Overview.html Developing a Web Accessibility Business Case for Your Organization]: Provides information on how to create a business case<br>[http://www.w3.org/WAI/impl/#goal Determine Your Goal and Gather Support]: Section of Strategic Planning document that discusses broad area of securing management support.<br />
* Provide accessibility awareness training<br />
* Appoint at least one accessibility specialist<br />
* Plan for regular accessibility checks<br />
* Create an accessibility policy<br />
* Provide a publicly available website accessibility statement<br />
* Involve users with disability in any usability testing<br />
* Learn more about accessibility<br />
<br />
== Feedback ==<br />
<br />
This document was raised for general feedback in the [https://www.w3.org/2002/09/wbs/35532/eowg27042015/results#xq12 27 April Survey] and discussed on [http://www.w3.org/2015/05/01-eo-minutes.html 1 May meeting].<br />
<br />
=== General points for discussion ===<br />
<br />
* {{Comment|Maybe change from role-based (eg. "tips for designers") to task-based (eg. "tips for designing")?|Shadi|30 Apr 2015}}<br>{{Comment|User Experience Designer is also missing as an audience.|Melody|27 Apr 2015}}<br />
** {{Comment|Need to seek a balance between classifying every role and ensuring a clear distinction between relevant tips. How should we create this balance?|Kevin|1 May 2015}}<br />
* {{Comment|Is this going to be in depth enough for evaluators? There is a wide spread of skill between advocate and developer/evaluator. How do we bridge that?|Wayne|30 Apr 2015}}<br />
** {{Comment|There is certainly a difference in level of detail required depending on level of activity. Should the aim be to try to balance the tips across all activity areas, or within an area, or not at all?|Kevin|1 May 2015}}<br />
* {{Comment|Keep this resource a simple sign-post to existing resources, rather than try to re-develop existing content.|Shadi|30 Apr 2015}}<br>{{Comment|I recall that the joys that everyone took in the biz card was it clarity and brevity.|Sharron|30 Apr 2015}}<br />
** {{Comment|This discussion point aims to explore what content should be included; the requirements have suggested a top, a short expansion paragraph, and optional example, benefits, and/or relevant resources|Kevin|1 May 2015}}<br />
<br />
=== Focused points for discussion ===<br />
<br />
* {{Comment|Designer: Hover styling doesn't apply to touch devices. Was "active" styling meant?|Melody|27 Apr 2015}}<br />
** {{Comment|I deliberately used 'hover' and 'focus' as 'active' is sometimes taken to apply to mouse interactions only. I agree that 'active' would be more accurate, but the terminology may be lost on some.|Kevin|28 Apr 2015}}<br />
* {{Comment|Designer and Developer: Missing guidance for images|Melody|27 Apr 2015}}<br>{{Comment|I believe authors should be responsible for non-text elements that require text (images, charts, etc).|Jon|30 Apr 2015}}<br />
** {{Comment|Someone needs to take responsibility for ensuring all imagery has appropriate alternative text. The difficulty is that the responsibility for this is likely to vary quite a bit. Perhaps a note of this is required in multiple places, possibly including Author?|Kevin|28 Apr 2015}}<br />
* {{Comment|Isn't it a bit redundant to recommend that people "Learn more about accessibility?" I mean, isn't that why they're here?|Jon|30 Apr 2015}}<br />
** {{Comment|The aim of this tip was to highlight that this was not the end of the journey but just the beginning, and to signpost to other more detailed resources. It might benefit with more clarification.|Kevin|1 May 2015}}<br />
<br />
=== Previous feedback ===<br />
<br />
* {{LongComment|summary=Also helps with...|comment=Might be worth also including a short snippet that highlights the value this activity brings to a broader audience|by=Andrew/Kevin|date=10 Apr 2015}}</div>Wdickhttps://www.w3.org/WAI/EO/wiki/index.php?title=Quick_Start_Guides/Structure_and_Content&diff=12726Quick Start Guides/Structure and Content2015-05-06T22:31:02Z<p>Wdick: /* Tips */</p>
<hr />
<div>{{TOClimit|2}}<br />
<br />
This page captures the proposed content for the Quick Start guides. Each task area has a set of topics that should be succinct and actionable.<br />
<br />
See [[Quick Start Guides/Requirements Analysis#Approach]] and [[Quick Start Guides/Design]] for more information on how this will be structured.<br />
<br />
== EOWG editing notes ==<br />
<br />
Below are suggestions for formatting your ideas for rewording, [your comments that aren't a direct rewording], and your ideas for a new tip:<br />
<br />
* Tip from original draft<br />
** {{Comment|Reword: Suggestion for rewording the tip above|your name|dd MMM YYYY}}<br />
* Tip from original draft<br />
** {{Comment|Comment on this tip that's not rewording|your name|dd MMM YYYY}}<br />
* {{Comment|New:New tip suggestion|your name|dd MMM YYYY}}<br />
<br />
== Designing ==<br />
<br />
Visual or interface designers<br />
<br />
=== Tips ===<br />
<br />
* Ensure color palette is high contrast<br />
** {{Comment|Reword: Provide sufficient contrast between text and background colors|Shawn|1 May 2015}}<br />
** For each text foreground/background color combination, including on buttons, check that the contrast between the two colors has sufficient contrast. For text presented over a background image take a sample of dominant colors or provide some way to make the text stand out.<br />
*** Learn more:<br>[http://w3c.github.io/wai-eval-tools/#accessibility-color-wheel Accessibility Color Wheel], [http://w3c.github.io/wai-eval-tools/#color-oracle Color Oracle], [http://w3c.github.io/wai-eval-tools/#contrast-checker Contrast Checker], [http://w3c.github.io/wai-eval-tools/#contrast-finder Contrast Finder]: Various tools that help in exploring color contrast<br>[http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-contrast.html Success Criteria 1.4.3 Contrast (Minimum)]: WCAG Success Criteria for color contrast<br>[http://www.w3.org/WAI/intro/people-use-web/stories#shopper Mr. Lee, Online shopper with color blindness]: Describes how a user with color discrimination experiences the Web<br />
* Don't use color alone to signify meaning<br />
* Ensure links and interactive elements have a hover and focus styling<br />
* Provide navigation that allows easy access to other website pages and clear indication of location in website<br />
* Provide visible controls for audio and video players<br />
* Ensure form elements include clearly associated labels, with space for important instructions<br />
* Present form errors in a block above the form and make the fields in error extremely obvious<br />
** ✓ {{Comment|I needed to Google “salient” – probably a less known word by non-native speakers?|Eric|1 May 2015}}<br />
* Structure text to include headers, not be too wide, and in a good font size<br />
** {{Comment|This is 3 tips in one and I think should be separated|Shawn|1 May 2015}}</span><br />
* Learn more about accessibility<br />
** {{Comment|This seems gratuitous. Without function related activity it will annoy. |Wayne May 2015}}<br />
* {{Comment|New: Ensure that it is easy to distinguish between page sections|Eric|1 May 2015}}<br />
* {{Comment|New: Provide text alternatives or visible labels for icons|Eric|1 May 2015}}<br />
* {{Comment|New: something on images|Melody, Sharron, Vicki|1 May 2015}}<br />
<br />
== Developing ==<br />
<br />
Front-end developer, or programmer.<br />
<br />
=== Tips ===<br />
<br />
* Ensure good semantic mark-up; e.g. if it looks like a header, mark it up with a header element<br />
* Ensure all form elements have an associated label<br />
** The &lt;label&gt; element is associated with form elements using the ''for'' and ''id'' attributes. Where a design does not include a visible label, provide one but position it offscreen using CSS.<br />
*** Example:<br><code>&lt;label for="username"&gt;<br>&lt;input id="username" type="text"&gt;</code><br />
*** Learn more:<br>[http://www.w3.org/WAI/tutorials/forms/labels/ Labelling controls]: Provides more involved help on how to label form controls and elements<br>[http://www.w3.org/TR/UNDERSTANDING-WCAG20/minimize-error-cues.html Success Criteria 3.3.2 Labels or Instructions]: WCAG Success Criteria for labels<br>[http://www.w3.org/WAI/intro/people-use-web/browsing#navigation Design solutions - navigating and finding content]: Explores how providing labels benefits people with disabilities<br />
* Use HTML5 structural elements<br />
* Match the reading order and the code order<br />
* Use ARIA to provide meaning to non-standard interactive elements<br />
* Ensure that all interactive elements are keyboard accessible<br />
* Check your code validates<br />
* Learn more about accessibility<br />
**{Actually I do think this is important. It just needs specifics |Wayne 2015}<br />
<br />
== Authoring ==<br />
<br />
Content author, or content manager.<br />
<br />
=== Tips ===<br />
<br />
* Keep it short and simple<br />
* Avoid using 'click here'<br />
* Provide short, meaningful headings to break-up long text blocks<br />
* Ensure that captions are provided for audio/visual content<br />
* Avoid using complex words and sentence structures<br />
* Ensure all pages are provided with a meaningful title<br />
* File download link text should include file type and size<br />
* Learn more about accessibility<br />
<br />
== Evaluating ==<br />
<br />
QA, tester, or evaluator.<br />
<br />
=== Tips ===<br />
<br />
* Use Easy Checks for early quick reviews<br />
* Run evaluation sessions with real people<br />
* Review QA process to incorporate early evaluations<br />
* Review evaluation methodology in line with WCAG-EM<br />
* Incorporate WCAG-EM Reporting Tool into QA process<br />
* Develop and maintain database of commonly identified issues<br />
* Learn more about accessibility<br />
<br />
== Advocating ==<br />
<br />
Champion, or spokesperson.<br />
<br />
=== Tips ===<br />
<br />
* Learn more about accessibility<br />
* Create awareness for accessibility through presentation and outreach<br />
* Develop accessibility business case<br />
* Secure management support for accessibility activities<br />
* Communicate accessibility wins<br />
* Create an internal and external feedback mechanism<br />
* Use Easy Checks to develop a general appreciation for key website accessibility<br />
* Actively seek input from people with disabilities<br />
<br />
== Project managing ==<br />
<br />
Project managers or website owners<br />
<br />
=== Tips ===<br />
<br />
* Secure buy-in from senior management<br />
** Support from management helps ensure budget and resources are available for accessibility activities. A strong business case, tailored to organizational goals, will help.<br />
*** Learn more:<br>[http://www.w3.org/WAI/bcase/Overview.html Developing a Web Accessibility Business Case for Your Organization]: Provides information on how to create a business case<br>[http://www.w3.org/WAI/impl/#goal Determine Your Goal and Gather Support]: Section of Strategic Planning document that discusses broad area of securing management support.<br />
* Provide accessibility awareness training<br />
* Appoint at least one accessibility specialist<br />
* Plan for regular accessibility checks<br />
* Create an accessibility policy<br />
* Provide a publicly available website accessibility statement<br />
* Involve users with disability in any usability testing<br />
* Learn more about accessibility<br />
<br />
== Feedback ==<br />
<br />
This document was raised for general feedback in the [https://www.w3.org/2002/09/wbs/35532/eowg27042015/results#xq12 27 April Survey] and discussed on [http://www.w3.org/2015/05/01-eo-minutes.html 1 May meeting].<br />
<br />
=== General points for discussion ===<br />
<br />
* {{Comment|Maybe change from role-based (eg. "tips for designers") to task-based (eg. "tips for designing")?|Shadi|30 Apr 2015}}<br>{{Comment|User Experience Designer is also missing as an audience.|Melody|27 Apr 2015}}<br />
** {{Comment|Need to seek a balance between classifying every role and ensuring a clear distinction between relevant tips. How should we create this balance?|Kevin|1 May 2015}}<br />
* {{Comment|Is this going to be in depth enough for evaluators? There is a wide spread of skill between advocate and developer/evaluator. How do we bridge that?|Wayne|30 Apr 2015}}<br />
** {{Comment|There is certainly a difference in level of detail required depending on level of activity. Should the aim be to try to balance the tips across all activity areas, or within an area, or not at all?|Kevin|1 May 2015}}<br />
* {{Comment|Keep this resource a simple sign-post to existing resources, rather than try to re-develop existing content.|Shadi|30 Apr 2015}}<br>{{Comment|I recall that the joys that everyone took in the biz card was it clarity and brevity.|Sharron|30 Apr 2015}}<br />
** {{Comment|This discussion point aims to explore what content should be included; the requirements have suggested a top, a short expansion paragraph, and optional example, benefits, and/or relevant resources|Kevin|1 May 2015}}<br />
<br />
=== Focused points for discussion ===<br />
<br />
* {{Comment|Designer: Hover styling doesn't apply to touch devices. Was "active" styling meant?|Melody|27 Apr 2015}}<br />
** {{Comment|I deliberately used 'hover' and 'focus' as 'active' is sometimes taken to apply to mouse interactions only. I agree that 'active' would be more accurate, but the terminology may be lost on some.|Kevin|28 Apr 2015}}<br />
* {{Comment|Designer and Developer: Missing guidance for images|Melody|27 Apr 2015}}<br>{{Comment|I believe authors should be responsible for non-text elements that require text (images, charts, etc).|Jon|30 Apr 2015}}<br />
** {{Comment|Someone needs to take responsibility for ensuring all imagery has appropriate alternative text. The difficulty is that the responsibility for this is likely to vary quite a bit. Perhaps a note of this is required in multiple places, possibly including Author?|Kevin|28 Apr 2015}}<br />
* {{Comment|Isn't it a bit redundant to recommend that people "Learn more about accessibility?" I mean, isn't that why they're here?|Jon|30 Apr 2015}}<br />
** {{Comment|The aim of this tip was to highlight that this was not the end of the journey but just the beginning, and to signpost to other more detailed resources. It might benefit with more clarification.|Kevin|1 May 2015}}<br />
<br />
=== Previous feedback ===<br />
<br />
* {{LongComment|summary=Also helps with...|comment=Might be worth also including a short snippet that highlights the value this activity brings to a broader audience|by=Andrew/Kevin|date=10 Apr 2015}}</div>Wdickhttps://www.w3.org/WAI/EO/wiki/index.php?title=Quick_Start_Guides/Structure_and_Content&diff=12725Quick Start Guides/Structure and Content2015-05-06T22:27:55Z<p>Wdick: /* Tips */</p>
<hr />
<div>{{TOClimit|2}}<br />
<br />
This page captures the proposed content for the Quick Start guides. Each task area has a set of topics that should be succinct and actionable.<br />
<br />
See [[Quick Start Guides/Requirements Analysis#Approach]] and [[Quick Start Guides/Design]] for more information on how this will be structured.<br />
<br />
== EOWG editing notes ==<br />
<br />
Below are suggestions for formatting your ideas for rewording, [your comments that aren't a direct rewording], and your ideas for a new tip:<br />
<br />
* Tip from original draft<br />
** {{Comment|Reword: Suggestion for rewording the tip above|your name|dd MMM YYYY}}<br />
* Tip from original draft<br />
** {{Comment|Comment on this tip that's not rewording|your name|dd MMM YYYY}}<br />
* {{Comment|New:New tip suggestion|your name|dd MMM YYYY}}<br />
<br />
== Designing ==<br />
<br />
Visual or interface designers<br />
<br />
=== Tips ===<br />
<br />
* Ensure color palette is high contrast<br />
** {{Comment|Reword: Provide sufficient contrast between text and background colors|Shawn|1 May 2015}}<br />
** For each text foreground/background color combination, including on buttons, check that the contrast between the two colors has sufficient contrast. For text presented over a background image take a sample of dominant colors or provide some way to make the text stand out.<br />
*** Learn more:<br>[http://w3c.github.io/wai-eval-tools/#accessibility-color-wheel Accessibility Color Wheel], [http://w3c.github.io/wai-eval-tools/#color-oracle Color Oracle], [http://w3c.github.io/wai-eval-tools/#contrast-checker Contrast Checker], [http://w3c.github.io/wai-eval-tools/#contrast-finder Contrast Finder]: Various tools that help in exploring color contrast<br>[http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-contrast.html Success Criteria 1.4.3 Contrast (Minimum)]: WCAG Success Criteria for color contrast<br>[http://www.w3.org/WAI/intro/people-use-web/stories#shopper Mr. Lee, Online shopper with color blindness]: Describes how a user with color discrimination experiences the Web<br />
* Don't use color alone to signify meaning<br />
* Ensure links and interactive elements have a hover and focus styling<br />
* Provide navigation that allows easy access to other website pages and clear indication of location in website<br />
* Provide visible controls for audio and video players<br />
* Ensure form elements include clearly associated labels, with space for important instructions<br />
* Present form errors in a block above the form and make the fields in error extremely obvious<br />
** ✓ {{Comment|I needed to Google “salient” – probably a less known word by non-native speakers?|Eric|1 May 2015}}<br />
* Structure text to include headers, not be too wide, and in a good font size<br />
** {{Comment|This is 3 tips in one and I think should be separated|Shawn|1 May 2015}}</span><br />
* Learn more about accessibility<br />
** {{This seems gratuitous. Without function related activity it will annoy. |Wayne May 2015}}<br />
* {{Comment|New: Ensure that it is easy to distinguish between page sections|Eric|1 May 2015}}<br />
* {{Comment|New: Provide text alternatives or visible labels for icons|Eric|1 May 2015}}<br />
* {{Comment|New: something on images|Melody, Sharron, Vicki|1 May 2015}}<br />
<br />
== Developing ==<br />
<br />
Front-end developer, or programmer.<br />
<br />
=== Tips ===<br />
<br />
* Ensure good semantic mark-up; e.g. if it looks like a header, mark it up with a header element<br />
* Ensure all form elements have an associated label<br />
** The &lt;label&gt; element is associated with form elements using the ''for'' and ''id'' attributes. Where a design does not include a visible label, provide one but position it offscreen using CSS.<br />
*** Example:<br><code>&lt;label for="username"&gt;<br>&lt;input id="username" type="text"&gt;</code><br />
*** Learn more:<br>[http://www.w3.org/WAI/tutorials/forms/labels/ Labelling controls]: Provides more involved help on how to label form controls and elements<br>[http://www.w3.org/TR/UNDERSTANDING-WCAG20/minimize-error-cues.html Success Criteria 3.3.2 Labels or Instructions]: WCAG Success Criteria for labels<br>[http://www.w3.org/WAI/intro/people-use-web/browsing#navigation Design solutions - navigating and finding content]: Explores how providing labels benefits people with disabilities<br />
* Use HTML5 structural elements<br />
* Match the reading order and the code order<br />
* Use ARIA to provide meaning to non-standard interactive elements<br />
* Ensure that all interactive elements are keyboard accessible<br />
* Check your code validates<br />
* Learn more about accessibility<br />
**{Actually I do think this is important. It just needs specifics |Wayne 2015}<br />
<br />
== Authoring ==<br />
<br />
Content author, or content manager.<br />
<br />
=== Tips ===<br />
<br />
* Keep it short and simple<br />
* Avoid using 'click here'<br />
* Provide short, meaningful headings to break-up long text blocks<br />
* Ensure that captions are provided for audio/visual content<br />
* Avoid using complex words and sentence structures<br />
* Ensure all pages are provided with a meaningful title<br />
* File download link text should include file type and size<br />
* Learn more about accessibility<br />
<br />
== Evaluating ==<br />
<br />
QA, tester, or evaluator.<br />
<br />
=== Tips ===<br />
<br />
* Use Easy Checks for early quick reviews<br />
* Run evaluation sessions with real people<br />
* Review QA process to incorporate early evaluations<br />
* Review evaluation methodology in line with WCAG-EM<br />
* Incorporate WCAG-EM Reporting Tool into QA process<br />
* Develop and maintain database of commonly identified issues<br />
* Learn more about accessibility<br />
<br />
== Advocating ==<br />
<br />
Champion, or spokesperson.<br />
<br />
=== Tips ===<br />
<br />
* Learn more about accessibility<br />
* Create awareness for accessibility through presentation and outreach<br />
* Develop accessibility business case<br />
* Secure management support for accessibility activities<br />
* Communicate accessibility wins<br />
* Create an internal and external feedback mechanism<br />
* Use Easy Checks to develop a general appreciation for key website accessibility<br />
* Actively seek input from people with disabilities<br />
<br />
== Project managing ==<br />
<br />
Project managers or website owners<br />
<br />
=== Tips ===<br />
<br />
* Secure buy-in from senior management<br />
** Support from management helps ensure budget and resources are available for accessibility activities. A strong business case, tailored to organizational goals, will help.<br />
*** Learn more:<br>[http://www.w3.org/WAI/bcase/Overview.html Developing a Web Accessibility Business Case for Your Organization]: Provides information on how to create a business case<br>[http://www.w3.org/WAI/impl/#goal Determine Your Goal and Gather Support]: Section of Strategic Planning document that discusses broad area of securing management support.<br />
* Provide accessibility awareness training<br />
* Appoint at least one accessibility specialist<br />
* Plan for regular accessibility checks<br />
* Create an accessibility policy<br />
* Provide a publicly available website accessibility statement<br />
* Involve users with disability in any usability testing<br />
* Learn more about accessibility<br />
<br />
== Feedback ==<br />
<br />
This document was raised for general feedback in the [https://www.w3.org/2002/09/wbs/35532/eowg27042015/results#xq12 27 April Survey] and discussed on [http://www.w3.org/2015/05/01-eo-minutes.html 1 May meeting].<br />
<br />
=== General points for discussion ===<br />
<br />
* {{Comment|Maybe change from role-based (eg. "tips for designers") to task-based (eg. "tips for designing")?|Shadi|30 Apr 2015}}<br>{{Comment|User Experience Designer is also missing as an audience.|Melody|27 Apr 2015}}<br />
** {{Comment|Need to seek a balance between classifying every role and ensuring a clear distinction between relevant tips. How should we create this balance?|Kevin|1 May 2015}}<br />
* {{Comment|Is this going to be in depth enough for evaluators? There is a wide spread of skill between advocate and developer/evaluator. How do we bridge that?|Wayne|30 Apr 2015}}<br />
** {{Comment|There is certainly a difference in level of detail required depending on level of activity. Should the aim be to try to balance the tips across all activity areas, or within an area, or not at all?|Kevin|1 May 2015}}<br />
* {{Comment|Keep this resource a simple sign-post to existing resources, rather than try to re-develop existing content.|Shadi|30 Apr 2015}}<br>{{Comment|I recall that the joys that everyone took in the biz card was it clarity and brevity.|Sharron|30 Apr 2015}}<br />
** {{Comment|This discussion point aims to explore what content should be included; the requirements have suggested a top, a short expansion paragraph, and optional example, benefits, and/or relevant resources|Kevin|1 May 2015}}<br />
<br />
=== Focused points for discussion ===<br />
<br />
* {{Comment|Designer: Hover styling doesn't apply to touch devices. Was "active" styling meant?|Melody|27 Apr 2015}}<br />
** {{Comment|I deliberately used 'hover' and 'focus' as 'active' is sometimes taken to apply to mouse interactions only. I agree that 'active' would be more accurate, but the terminology may be lost on some.|Kevin|28 Apr 2015}}<br />
* {{Comment|Designer and Developer: Missing guidance for images|Melody|27 Apr 2015}}<br>{{Comment|I believe authors should be responsible for non-text elements that require text (images, charts, etc).|Jon|30 Apr 2015}}<br />
** {{Comment|Someone needs to take responsibility for ensuring all imagery has appropriate alternative text. The difficulty is that the responsibility for this is likely to vary quite a bit. Perhaps a note of this is required in multiple places, possibly including Author?|Kevin|28 Apr 2015}}<br />
* {{Comment|Isn't it a bit redundant to recommend that people "Learn more about accessibility?" I mean, isn't that why they're here?|Jon|30 Apr 2015}}<br />
** {{Comment|The aim of this tip was to highlight that this was not the end of the journey but just the beginning, and to signpost to other more detailed resources. It might benefit with more clarification.|Kevin|1 May 2015}}<br />
<br />
=== Previous feedback ===<br />
<br />
* {{LongComment|summary=Also helps with...|comment=Might be worth also including a short snippet that highlights the value this activity brings to a broader audience|by=Andrew/Kevin|date=10 Apr 2015}}</div>Wdickhttps://www.w3.org/WAI/EO/wiki/index.php?title=Quick_Start_Guides/Structure_and_Content&diff=12724Quick Start Guides/Structure and Content2015-05-06T22:25:30Z<p>Wdick: /* Tips */</p>
<hr />
<div>{{TOClimit|2}}<br />
<br />
This page captures the proposed content for the Quick Start guides. Each task area has a set of topics that should be succinct and actionable.<br />
<br />
See [[Quick Start Guides/Requirements Analysis#Approach]] and [[Quick Start Guides/Design]] for more information on how this will be structured.<br />
<br />
== EOWG editing notes ==<br />
<br />
Below are suggestions for formatting your ideas for rewording, [your comments that aren't a direct rewording], and your ideas for a new tip:<br />
<br />
* Tip from original draft<br />
** {{Comment|Reword: Suggestion for rewording the tip above|your name|dd MMM YYYY}}<br />
* Tip from original draft<br />
** {{Comment|Comment on this tip that's not rewording|your name|dd MMM YYYY}}<br />
* {{Comment|New:New tip suggestion|your name|dd MMM YYYY}}<br />
<br />
== Designing ==<br />
<br />
Visual or interface designers<br />
<br />
=== Tips ===<br />
<br />
* Ensure color palette is high contrast<br />
** {{Comment|Reword: Provide sufficient contrast between text and background colors|Shawn|1 May 2015}}<br />
** For each text foreground/background color combination, including on buttons, check that the contrast between the two colors has sufficient contrast. For text presented over a background image take a sample of dominant colors or provide some way to make the text stand out.<br />
*** Learn more:<br>[http://w3c.github.io/wai-eval-tools/#accessibility-color-wheel Accessibility Color Wheel], [http://w3c.github.io/wai-eval-tools/#color-oracle Color Oracle], [http://w3c.github.io/wai-eval-tools/#contrast-checker Contrast Checker], [http://w3c.github.io/wai-eval-tools/#contrast-finder Contrast Finder]: Various tools that help in exploring color contrast<br>[http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-contrast.html Success Criteria 1.4.3 Contrast (Minimum)]: WCAG Success Criteria for color contrast<br>[http://www.w3.org/WAI/intro/people-use-web/stories#shopper Mr. Lee, Online shopper with color blindness]: Describes how a user with color discrimination experiences the Web<br />
* Don't use color alone to signify meaning<br />
* Ensure links and interactive elements have a hover and focus styling<br />
* Provide navigation that allows easy access to other website pages and clear indication of location in website<br />
* Provide visible controls for audio and video players<br />
* Ensure form elements include clearly associated labels, with space for important instructions<br />
* Present form errors in a block above the form and make the fields in error extremely obvious<br />
** ✓ {{Comment|I needed to Google “salient” – probably a less known word by non-native speakers?|Eric|1 May 2015}}<br />
* Structure text to include headers, not be too wide, and in a good font size<br />
** {{Comment|This is 3 tips in one and I think should be separated|Shawn|1 May 2015}}</span><br />
* Learn more about accessibility<br />
**{This seems gratuitous. Without function related activity drop it. |Wayne May 2015}<br />
* {{Comment|New: Ensure that it is easy to distinguish between page sections|Eric|1 May 2015}}<br />
* {{Comment|New: Provide text alternatives or visible labels for icons|Eric|1 May 2015}}<br />
* {{Comment|New: something on images|Melody, Sharron, Vicki|1 May 2015}}<br />
<br />
== Developing ==<br />
<br />
Front-end developer, or programmer.<br />
<br />
=== Tips ===<br />
<br />
* Ensure good semantic mark-up; e.g. if it looks like a header, mark it up with a header element<br />
* Ensure all form elements have an associated label<br />
** The &lt;label&gt; element is associated with form elements using the ''for'' and ''id'' attributes. Where a design does not include a visible label, provide one but position it offscreen using CSS.<br />
*** Example:<br><code>&lt;label for="username"&gt;<br>&lt;input id="username" type="text"&gt;</code><br />
*** Learn more:<br>[http://www.w3.org/WAI/tutorials/forms/labels/ Labelling controls]: Provides more involved help on how to label form controls and elements<br>[http://www.w3.org/TR/UNDERSTANDING-WCAG20/minimize-error-cues.html Success Criteria 3.3.2 Labels or Instructions]: WCAG Success Criteria for labels<br>[http://www.w3.org/WAI/intro/people-use-web/browsing#navigation Design solutions - navigating and finding content]: Explores how providing labels benefits people with disabilities<br />
* Use HTML5 structural elements<br />
* Match the reading order and the code order<br />
* Use ARIA to provide meaning to non-standard interactive elements<br />
* Ensure that all interactive elements are keyboard accessible<br />
* Check your code validates<br />
* Learn more about accessibility<br />
**{Actually I do think this is important. It just needs specifics |Wayne 2015}<br />
<br />
== Authoring ==<br />
<br />
Content author, or content manager.<br />
<br />
=== Tips ===<br />
<br />
* Keep it short and simple<br />
* Avoid using 'click here'<br />
* Provide short, meaningful headings to break-up long text blocks<br />
* Ensure that captions are provided for audio/visual content<br />
* Avoid using complex words and sentence structures<br />
* Ensure all pages are provided with a meaningful title<br />
* File download link text should include file type and size<br />
* Learn more about accessibility<br />
<br />
== Evaluating ==<br />
<br />
QA, tester, or evaluator.<br />
<br />
=== Tips ===<br />
<br />
* Use Easy Checks for early quick reviews<br />
* Run evaluation sessions with real people<br />
* Review QA process to incorporate early evaluations<br />
* Review evaluation methodology in line with WCAG-EM<br />
* Incorporate WCAG-EM Reporting Tool into QA process<br />
* Develop and maintain database of commonly identified issues<br />
* Learn more about accessibility<br />
<br />
== Advocating ==<br />
<br />
Champion, or spokesperson.<br />
<br />
=== Tips ===<br />
<br />
* Learn more about accessibility<br />
* Create awareness for accessibility through presentation and outreach<br />
* Develop accessibility business case<br />
* Secure management support for accessibility activities<br />
* Communicate accessibility wins<br />
* Create an internal and external feedback mechanism<br />
* Use Easy Checks to develop a general appreciation for key website accessibility<br />
* Actively seek input from people with disabilities<br />
<br />
== Project managing ==<br />
<br />
Project managers or website owners<br />
<br />
=== Tips ===<br />
<br />
* Secure buy-in from senior management<br />
** Support from management helps ensure budget and resources are available for accessibility activities. A strong business case, tailored to organizational goals, will help.<br />
*** Learn more:<br>[http://www.w3.org/WAI/bcase/Overview.html Developing a Web Accessibility Business Case for Your Organization]: Provides information on how to create a business case<br>[http://www.w3.org/WAI/impl/#goal Determine Your Goal and Gather Support]: Section of Strategic Planning document that discusses broad area of securing management support.<br />
* Provide accessibility awareness training<br />
* Appoint at least one accessibility specialist<br />
* Plan for regular accessibility checks<br />
* Create an accessibility policy<br />
* Provide a publicly available website accessibility statement<br />
* Involve users with disability in any usability testing<br />
* Learn more about accessibility<br />
<br />
== Feedback ==<br />
<br />
This document was raised for general feedback in the [https://www.w3.org/2002/09/wbs/35532/eowg27042015/results#xq12 27 April Survey] and discussed on [http://www.w3.org/2015/05/01-eo-minutes.html 1 May meeting].<br />
<br />
=== General points for discussion ===<br />
<br />
* {{Comment|Maybe change from role-based (eg. "tips for designers") to task-based (eg. "tips for designing")?|Shadi|30 Apr 2015}}<br>{{Comment|User Experience Designer is also missing as an audience.|Melody|27 Apr 2015}}<br />
** {{Comment|Need to seek a balance between classifying every role and ensuring a clear distinction between relevant tips. How should we create this balance?|Kevin|1 May 2015}}<br />
* {{Comment|Is this going to be in depth enough for evaluators? There is a wide spread of skill between advocate and developer/evaluator. How do we bridge that?|Wayne|30 Apr 2015}}<br />
** {{Comment|There is certainly a difference in level of detail required depending on level of activity. Should the aim be to try to balance the tips across all activity areas, or within an area, or not at all?|Kevin|1 May 2015}}<br />
* {{Comment|Keep this resource a simple sign-post to existing resources, rather than try to re-develop existing content.|Shadi|30 Apr 2015}}<br>{{Comment|I recall that the joys that everyone took in the biz card was it clarity and brevity.|Sharron|30 Apr 2015}}<br />
** {{Comment|This discussion point aims to explore what content should be included; the requirements have suggested a top, a short expansion paragraph, and optional example, benefits, and/or relevant resources|Kevin|1 May 2015}}<br />
<br />
=== Focused points for discussion ===<br />
<br />
* {{Comment|Designer: Hover styling doesn't apply to touch devices. Was "active" styling meant?|Melody|27 Apr 2015}}<br />
** {{Comment|I deliberately used 'hover' and 'focus' as 'active' is sometimes taken to apply to mouse interactions only. I agree that 'active' would be more accurate, but the terminology may be lost on some.|Kevin|28 Apr 2015}}<br />
* {{Comment|Designer and Developer: Missing guidance for images|Melody|27 Apr 2015}}<br>{{Comment|I believe authors should be responsible for non-text elements that require text (images, charts, etc).|Jon|30 Apr 2015}}<br />
** {{Comment|Someone needs to take responsibility for ensuring all imagery has appropriate alternative text. The difficulty is that the responsibility for this is likely to vary quite a bit. Perhaps a note of this is required in multiple places, possibly including Author?|Kevin|28 Apr 2015}}<br />
* {{Comment|Isn't it a bit redundant to recommend that people "Learn more about accessibility?" I mean, isn't that why they're here?|Jon|30 Apr 2015}}<br />
** {{Comment|The aim of this tip was to highlight that this was not the end of the journey but just the beginning, and to signpost to other more detailed resources. It might benefit with more clarification.|Kevin|1 May 2015}}<br />
<br />
=== Previous feedback ===<br />
<br />
* {{LongComment|summary=Also helps with...|comment=Might be worth also including a short snippet that highlights the value this activity brings to a broader audience|by=Andrew/Kevin|date=10 Apr 2015}}</div>Wdickhttps://www.w3.org/WAI/EO/wiki/index.php?title=Quick_Start_Guides/Structure_and_Content&diff=12723Quick Start Guides/Structure and Content2015-05-06T22:23:15Z<p>Wdick: /* Tips */</p>
<hr />
<div>{{TOClimit|2}}<br />
<br />
This page captures the proposed content for the Quick Start guides. Each task area has a set of topics that should be succinct and actionable.<br />
<br />
See [[Quick Start Guides/Requirements Analysis#Approach]] and [[Quick Start Guides/Design]] for more information on how this will be structured.<br />
<br />
== EOWG editing notes ==<br />
<br />
Below are suggestions for formatting your ideas for rewording, [your comments that aren't a direct rewording], and your ideas for a new tip:<br />
<br />
* Tip from original draft<br />
** {{Comment|Reword: Suggestion for rewording the tip above|your name|dd MMM YYYY}}<br />
* Tip from original draft<br />
** {{Comment|Comment on this tip that's not rewording|your name|dd MMM YYYY}}<br />
* {{Comment|New:New tip suggestion|your name|dd MMM YYYY}}<br />
<br />
== Designing ==<br />
<br />
Visual or interface designers<br />
<br />
=== Tips ===<br />
<br />
* Ensure color palette is high contrast<br />
** {{Comment|Reword: Provide sufficient contrast between text and background colors|Shawn|1 May 2015}}<br />
** For each text foreground/background color combination, including on buttons, check that the contrast between the two colors has sufficient contrast. For text presented over a background image take a sample of dominant colors or provide some way to make the text stand out.<br />
*** Learn more:<br>[http://w3c.github.io/wai-eval-tools/#accessibility-color-wheel Accessibility Color Wheel], [http://w3c.github.io/wai-eval-tools/#color-oracle Color Oracle], [http://w3c.github.io/wai-eval-tools/#contrast-checker Contrast Checker], [http://w3c.github.io/wai-eval-tools/#contrast-finder Contrast Finder]: Various tools that help in exploring color contrast<br>[http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-contrast.html Success Criteria 1.4.3 Contrast (Minimum)]: WCAG Success Criteria for color contrast<br>[http://www.w3.org/WAI/intro/people-use-web/stories#shopper Mr. Lee, Online shopper with color blindness]: Describes how a user with color discrimination experiences the Web<br />
* Don't use color alone to signify meaning<br />
* Ensure links and interactive elements have a hover and focus styling<br />
* Provide navigation that allows easy access to other website pages and clear indication of location in website<br />
* Provide visible controls for audio and video players<br />
* Ensure form elements include clearly associated labels, with space for important instructions<br />
* Present form errors in a block above the form and make the fields in error extremely obvious<br />
** ✓ {{Comment|I needed to Google “salient” – probably a less known word by non-native speakers?|Eric|1 May 2015}}<br />
* Structure text to include headers, not be too wide, and in a good font size<br />
** {{Comment|This is 3 tips in one and I think should be separated|Shawn|1 May 2015}}</span><br />
* Learn more about accessibility<br />
**{This seems gratuitous. Without function related activity drop it. |Wayne May 2015}<br />
* {{Comment|New: Ensure that it is easy to distinguish between page sections|Eric|1 May 2015}}<br />
* {{Comment|New: Provide text alternatives or visible labels for icons|Eric|1 May 2015}}<br />
* {{Comment|New: something on images|Melody, Sharron, Vicki|1 May 2015}}<br />
<br />
== Developing ==<br />
<br />
Front-end developer, or programmer.<br />
<br />
=== Tips ===<br />
<br />
* Ensure good semantic mark-up; e.g. if it looks like a header, mark it up with a header element<br />
* Ensure all form elements have an associated label<br />
** The &lt;label&gt; element is associated with form elements using the ''for'' and ''id'' attributes. Where a design does not include a visible label, provide one but position it offscreen using CSS.<br />
*** Example:<br><code>&lt;label for="username"&gt;<br>&lt;input id="username" type="text"&gt;</code><br />
*** Learn more:<br>[http://www.w3.org/WAI/tutorials/forms/labels/ Labelling controls]: Provides more involved help on how to label form controls and elements<br>[http://www.w3.org/TR/UNDERSTANDING-WCAG20/minimize-error-cues.html Success Criteria 3.3.2 Labels or Instructions]: WCAG Success Criteria for labels<br>[http://www.w3.org/WAI/intro/people-use-web/browsing#navigation Design solutions - navigating and finding content]: Explores how providing labels benefits people with disabilities<br />
* Use HTML5 structural elements<br />
* Match the reading order and the code order<br />
* Use ARIA to provide meaning to non-standard interactive elements<br />
* Ensure that all interactive elements are keyboard accessible<br />
* Check your code validates<br />
* Learn more about accessibility<br />
<br />
== Authoring ==<br />
<br />
Content author, or content manager.<br />
<br />
=== Tips ===<br />
<br />
* Keep it short and simple<br />
* Avoid using 'click here'<br />
* Provide short, meaningful headings to break-up long text blocks<br />
* Ensure that captions are provided for audio/visual content<br />
* Avoid using complex words and sentence structures<br />
* Ensure all pages are provided with a meaningful title<br />
* File download link text should include file type and size<br />
* Learn more about accessibility<br />
<br />
== Evaluating ==<br />
<br />
QA, tester, or evaluator.<br />
<br />
=== Tips ===<br />
<br />
* Use Easy Checks for early quick reviews<br />
* Run evaluation sessions with real people<br />
* Review QA process to incorporate early evaluations<br />
* Review evaluation methodology in line with WCAG-EM<br />
* Incorporate WCAG-EM Reporting Tool into QA process<br />
* Develop and maintain database of commonly identified issues<br />
* Learn more about accessibility<br />
<br />
== Advocating ==<br />
<br />
Champion, or spokesperson.<br />
<br />
=== Tips ===<br />
<br />
* Learn more about accessibility<br />
* Create awareness for accessibility through presentation and outreach<br />
* Develop accessibility business case<br />
* Secure management support for accessibility activities<br />
* Communicate accessibility wins<br />
* Create an internal and external feedback mechanism<br />
* Use Easy Checks to develop a general appreciation for key website accessibility<br />
* Actively seek input from people with disabilities<br />
<br />
== Project managing ==<br />
<br />
Project managers or website owners<br />
<br />
=== Tips ===<br />
<br />
* Secure buy-in from senior management<br />
** Support from management helps ensure budget and resources are available for accessibility activities. A strong business case, tailored to organizational goals, will help.<br />
*** Learn more:<br>[http://www.w3.org/WAI/bcase/Overview.html Developing a Web Accessibility Business Case for Your Organization]: Provides information on how to create a business case<br>[http://www.w3.org/WAI/impl/#goal Determine Your Goal and Gather Support]: Section of Strategic Planning document that discusses broad area of securing management support.<br />
* Provide accessibility awareness training<br />
* Appoint at least one accessibility specialist<br />
* Plan for regular accessibility checks<br />
* Create an accessibility policy<br />
* Provide a publicly available website accessibility statement<br />
* Involve users with disability in any usability testing<br />
* Learn more about accessibility<br />
<br />
== Feedback ==<br />
<br />
This document was raised for general feedback in the [https://www.w3.org/2002/09/wbs/35532/eowg27042015/results#xq12 27 April Survey] and discussed on [http://www.w3.org/2015/05/01-eo-minutes.html 1 May meeting].<br />
<br />
=== General points for discussion ===<br />
<br />
* {{Comment|Maybe change from role-based (eg. "tips for designers") to task-based (eg. "tips for designing")?|Shadi|30 Apr 2015}}<br>{{Comment|User Experience Designer is also missing as an audience.|Melody|27 Apr 2015}}<br />
** {{Comment|Need to seek a balance between classifying every role and ensuring a clear distinction between relevant tips. How should we create this balance?|Kevin|1 May 2015}}<br />
* {{Comment|Is this going to be in depth enough for evaluators? There is a wide spread of skill between advocate and developer/evaluator. How do we bridge that?|Wayne|30 Apr 2015}}<br />
** {{Comment|There is certainly a difference in level of detail required depending on level of activity. Should the aim be to try to balance the tips across all activity areas, or within an area, or not at all?|Kevin|1 May 2015}}<br />
* {{Comment|Keep this resource a simple sign-post to existing resources, rather than try to re-develop existing content.|Shadi|30 Apr 2015}}<br>{{Comment|I recall that the joys that everyone took in the biz card was it clarity and brevity.|Sharron|30 Apr 2015}}<br />
** {{Comment|This discussion point aims to explore what content should be included; the requirements have suggested a top, a short expansion paragraph, and optional example, benefits, and/or relevant resources|Kevin|1 May 2015}}<br />
<br />
=== Focused points for discussion ===<br />
<br />
* {{Comment|Designer: Hover styling doesn't apply to touch devices. Was "active" styling meant?|Melody|27 Apr 2015}}<br />
** {{Comment|I deliberately used 'hover' and 'focus' as 'active' is sometimes taken to apply to mouse interactions only. I agree that 'active' would be more accurate, but the terminology may be lost on some.|Kevin|28 Apr 2015}}<br />
* {{Comment|Designer and Developer: Missing guidance for images|Melody|27 Apr 2015}}<br>{{Comment|I believe authors should be responsible for non-text elements that require text (images, charts, etc).|Jon|30 Apr 2015}}<br />
** {{Comment|Someone needs to take responsibility for ensuring all imagery has appropriate alternative text. The difficulty is that the responsibility for this is likely to vary quite a bit. Perhaps a note of this is required in multiple places, possibly including Author?|Kevin|28 Apr 2015}}<br />
* {{Comment|Isn't it a bit redundant to recommend that people "Learn more about accessibility?" I mean, isn't that why they're here?|Jon|30 Apr 2015}}<br />
** {{Comment|The aim of this tip was to highlight that this was not the end of the journey but just the beginning, and to signpost to other more detailed resources. It might benefit with more clarification.|Kevin|1 May 2015}}<br />
<br />
=== Previous feedback ===<br />
<br />
* {{LongComment|summary=Also helps with...|comment=Might be worth also including a short snippet that highlights the value this activity brings to a broader audience|by=Andrew/Kevin|date=10 Apr 2015}}</div>Wdickhttps://www.w3.org/WAI/EO/wiki/index.php?title=EOWG_Meetings&diff=10100EOWG Meetings2014-06-10T05:32:10Z<p>Wdick: </p>
<hr />
<div>==Upcoming Meetings==<br />
Each week:<br />
* Find homework on [https://www.w3.org/WAI/EO/wiki/Action_Items Action Items] page. Search for your name. Then search for highlighted words "Who else:" Complete items that are marked "Everyone". If time and interest, do things indicated "Anyone".<br />
* If you miss a meeting, read summary on this page and add your name as [done]<br />
* Update your [http://www.w3.org/2002/09/wbs/35532/availability/ Availability for Upcoming EOWG Teleconferences]<br />
<br />
===13 June 2014 teleconference===<br />
* [https://w3c.github.io/wai-tutorials/ Tutorials] - discuss follow-up to open issues started last week: [[Tutorials/Feedback/EO2014-06-06]]<br />
* [https://www.w3.org/WAI/EO/wiki/Feature_requirements_for_Interactive_Guide_to_Assist_Managing_Web_Accessibility_Evaluations WCAG-EM Report Tool]<br />
<br />
===Coming Soon===<br />
* '''20 June 2014 teleconference'''<br />
* '''27 June 2014 teleconference'''<br />
* ''4 July 2014 teleconference - tentative''<br />
* '''11 July 2014 teleconference'''<br />
* ...<br />
<br />
==Past Meetings==<br />
'''Prior to 28 March 2014, agendas and summaries are only includes in the Minutes, which are listed in the [http://www.w3.org/WAI/EO/Minutes EOWG Minutes Archive].'''<br />
<br />
===6 June 2014 teleconference===<br />
====Agenda====<br />
* [https://w3c.github.io/wai-tutorials/ Tutorials] - discuss any open issues -> [[Tutorials/Feedback/EO2014-06-06]]<br />
<br />
====Summary====<br />
The meeting began with brief introductions of new EO participants [http://lists.w3.org/Archives/Public/w3c-wai-eo/2014AprJun/0054.html Jonathan Metz] and [http://lists.w3.org/Archives/Public/w3c-wai-eo/2014AprJun/0049.html Kevin White]. The rest of meeting was spent considering the [http://lists.w3.org/Archives/Public/w3c-wai-eo/2014AprJun/0043.html WCAG-WG comments on the Tutorials]. Eric brought to EO those comments that needed group considerations including the following:<br />
* Tables Tutorials organization: Noting that the overlap was not entirely clear between "simple" tables and those we have called "irregular" or "complex," WCAG-WG suggested reorganization. Discussion included consideration of how far a tutorial should go in explaining the difference between how code should render and the inadequacies of certain AT and/or browsers. Recognizing the need to separate best practice from requirements, it was agreed that Eric will draft a revision in which <th> is used alone only on the first example, will introduce <scope> in second example and will pull in Example 1 from "Irregular."<br />
* Image Maps: The question here was whether the Note that image maps do not always render properly on mobile and the attendant suggestion of redundant links was seen by WCAG-WG as unnecessary due to it being a more general problem rather than a specific accessibility barrier. After Bim's observation that a mandate for WAI-ACT was to address mobile technologies, EO decided to keep the reference with some modification and Eric will justify the decision based on discussion.<br />
* Table Summary: Comment was that HTML summary attribute should not be given such emphasis and HTML5 solutions could be given more. Eric will include more varied ways to provide table summary.<br />
* ARIA references The comment from WCAG-WG began with a note about groups of images which was then generalized to include a desire for more ARIA references throughout. EOWG agreed to better clarify that it is OK to use ARIA with HTML4 and that it will probably render OK with most browsers and AT but you may have code validation errors. We also expect that as the topics become more complex, we will use ARIA references in context and as appropriate.<br />
* Cognitive Load: Discussion tabled until next week when AndrewA will be at the meeting<br />
* FAQ for Images Tutorial: Considered Shadi's suggestion to have a Q to address the question of text-only sites. Agreed if it is worded so as *NOT* to inadvertently reinforce the myth that it is a good accessibility solution.<br />
<br />
EOWG participants are advised to stay alert to Eric's edits this week and be available to respond quickly. Thanks all!<br />
<br />
[http://www.w3.org/2014/06/06-eo-minutes 06 June Minutes]<br />
<br />
====Participants====<br />
* Present: Kevin, Sharron, Shawn, Bim, EricE, AnnaBelle, Jonathan, Jan, Paul, Howard, Sylvie Duchateau<br />
* Regrets: Wayne, Andrew, Shadi, Denis, Helle, Vicki. (No survey results from Anthony, Liam)<br />
Read summary & skimmed minutes ''(people who missed the meeting)'':<br />
* [done] Wayne, 9 June 2014<br />
* [done], name, date<br />
<br />
===30 May 2014 teleconference===<br />
====Agenda====<br />
* [https://www.w3.org/WAI/EO/wiki/WCAG_Techniques_for_Specific_Technologies_-_Archived Techniques for Technologies wording & location] - Discuss with WCAG WG folks<br />
* Actions reminder:<br />
** [https://www.w3.org/2002/09/wbs/1/TutorialTablesP/ Tables WBS] - complete approval questionnaire<br />
** [https://www.w3.org/2002/09/wbs/1/ImagesTutorialP2/ Images WBS] - complete approval questionnaire<br />
** [https://w3c.github.io/wai-tutorials/ Tutorials main page] - suggest edits - in github, e-mail, or [https://www.w3.org/WAI/EO/wiki/Tutorials/Feedback/Cover_Page wiki page for cover]<br />
====Summary====<br />
The Education and Outreach Working Group (EOWG) met with the Web Content Accessibility Guidelines Working Group (WCAG WG) to discuss and reach consensus on wording that EOWG previously submitted for Understanding WCAG.<br />
<br />
'''Background: [https://www.w3.org/WAI/EO/wiki/WCAG_Techniques_for_Specific_Technologies_-_Archived Techniques for Specific Technologies]''' has notes on EOWG's original discussion, EOWG proposed wording, WCAG WG's edited wording, and EOWG's additional discussion.<br />
<br />
Judy Brewer acted as neutral facilitator, allowing co-chairs to participate in the discussion without having to represent their full WGs. After much discussion, the following language was agreed upon, with the caveat that today's participants must seek approval from their full groups:<br />
<blockquote>Publication of techniques for a specific technology does not imply that the technology can be used in all situations to create content that meets WCAG 2.0 success criteria and conformance criteria. Developers need to be aware of the limitations of specific technologies and provide content in a way that is accessible to people with disabilities.</blockquote><br />
''[post meeting note: "conformance criteria" should be "conformance requirements"]''<br />
<br />
EO further suggested that the language be placed in numerous instances where specific technology techniques were offered. By the time this was suggested, however, several WCAG reps had left the meeting and after a brief exchange of perspectives on that question, it was determined that EO would submit the suggestion as a separate matter for WCAG consideration. Judy thanked everyone and she and remaining WCAG participants left the meeting.<br />
<br />
EO participants remained to discuss the timeline and extended deadline for participants to [http://lists.w3.org/Archives/Public/w3c-wai-eo/2014AprJun/0031.html complete the Tutorials surveys]. Shawn asked that everyone be sure to do that and to provide as well edit suggestions for the [https://w3c.github.io/wai-tutorials main Tutorials landing page] with marketing and messaging in mind. Suggestions are welcome on GitHub and/or on the wiki or by email to the list.<br />
<br />
[http://www.w3.org/2014/05/30-eo-minutes 30 May minutes]<br />
<br />
====Participants====<br />
* Present: Bruce Bailey, Judy Brewer, AnnaBelle, David MacDonald, Shawn, Paul Schantz, Sharron, Andrew Kirkpatrick, Sylvie Duchateau, Joshue, Marc Johlic, Andrew Arch, Michael Cooper, Howard Kramer, Denis Boudreau, Liam M, Jan, Wayne<br />
* Regrets: Eric, Shadi, Bim, Helle, Vicki<br />
* Availability survey empty: Anthony<br />
<br />
Read summary & skimmed minutes ''(people who missed the meeting)'':<br />
* [done] Vicki, June 3, 2014<br />
* [done] name, date<br />
<br />
===23 May 2014 teleconference===<br />
====Agenda====<br />
* [https://w3c.github.io/wai-tutorials/ Tutorials] - discuss any open issues (which Eric will send in advance)<br />
** Follow up on changes from 16 May EOWG telecon<br />
** Discuss [https://w3c.github.io/wai-tutorials/ Cover page ''(to be updated)'']<br />
====Summary====<br />
<p>Shadi led the meeting and began by observing how few people had managed to complete the survey. He and Eric asked if participants would be able to meet an extended deadline for completing the acceptance [http://w3.org/mid/53736E3D.6020707@w3.org questionnaires for the Tutorial work] to date. Those in attendance agreed that they would meet the deadline which was extended to June 2 with strong encouragement to complete before that date. Looking at the comments that were made, the group discussed copyedits to the Concepts page of the Tables section, improvements to the Irregular Tables section, considered a suggestion to say sometimes tables are "impossible" rather than "hard" to understand, and more. Considering the overall Tutorials introduction, it was determined that greater emphasis is needed of the fact that for many content providers the CMS will become an important determining factor of success. Rather than try to make disclaimers throughout the tutorials, it was suggested to make a stronger case on the overall Tutorials introduction with supporting references in the individual topics as needed. Tables is an example where accessibility features made with an authoring tool may not be carried over in conversion to the web. In addition, there was support for encouraging Project Managers to think about the Tutorials as a way to provide leadership and resources to their teams. In closing, Eric asks for specific comments on the alt text of the table icons as people do their review. Shadi thanked Eric for his dedication and progress and gave kudos all around to how the group works together. <br />
</p><br />
[http://www.w3.org/2014/05/23-eo-minutes 23 May minutes]<br />
<br />
====Participants====<br />
* Present: <br />
* Regrets:<br />
* Availability survey empty:<br />
<br />
Read summary & skimmed minutes ''(people who missed the meeting)'':<br />
* [done] Shawn, 28 May 2014<br />
<br />
===16 May 2014 Teleconference===<br />
====Agenda====<br />
<ol><br />
<li>[https://w3c.github.io/wai-tutorials/ Tutorials] - discuss:<br />
<ul><br />
<li>[http://lists.w3.org/Archives/Public/w3c-wai-eo/2014AprJun/0032.html Indicating permalinks]</li><br />
<li>[https://github.com/w3c/wai-tutorials/issues/66 Table Concepts - images of tables]</li><br />
<li>[https://github.com/w3c/wai-tutorials/issues/68 Tables Concepts page intro too scarey/advanced?]?</li><br />
<li>Any other open issues on Tables or Images (which Eric will send in advance)</li><br />
<li>Cover page</li><br />
<li>[http://lists.w3.org/Archives/Public/w3c-wai-eo/2014AprJun/0031.html approval schedule]</li><br />
</ul></li><br />
<li>[http://www.w3.org/TR/indie-ui-requirements/ IndieUI Requirements] - discuss [https://www.w3.org/WAI/EO/wiki/IndieUI_Requirements_Review#.22use_cases.22_versus_.22scenarios.22 EOWG comment on use cases not scenarios]</li><br />
<li>[https://www.w3.org/2002/09/wbs/35532/availability/ Availability for Upcoming EOWG Teleconferences] & discussion with WCAG WG on [https://www.w3.org/WAI/EO/wiki/WCAG_review#Techniques_for_Specific_Technologies Techniques for Technologies wording & location] on 30 May or 6 June</li><br />
</ol><br />
====Summary====<br />
<p>In review of the Tables Tutorials the group was generally pleased with how the icons have evolved. Suggestions were made for possible alternatives to positioning, link status, number of icons for each example, bulleted text and more. On the question of linked icons, it was agreed that there should be no linking to internal page content, but rather to the general background and overview of each table type. Eric quickly mocked up examples for all to see and it was agreed to make clickable icons, floated left, with only one example of each type, and no bullets. </p><br />
<br />
<p>Consideration was given to the question of the opening language being "too scary" for those who are not coders. Several said that, well, in fact it IS for coders and don't want to try to make the language so simple it is no longer useful to primary audience. All agreed that language could be clarified and somewhat simplified without being dumbed down. Goal is to be useful to primary users while being less intimidating to users of CMS who may not be coders. Discussion of series of large chain link images with "Permalink" designation in alt text led to conclusion that first the large images were distracting and second the term permalink may be confusing to many. Eric will work on alternative visual presentation and wording. The Tutorials cover page emphasis was to be copy edited with an emphasis on the goal of these materials to help make the web "more accessible to all users." </p><br />
<br />
<p>The group agreed to recommend to Indie-UI the use of the term "use case" throughout and that they NOT use scenario. Most availability for co-meeting with WCAG-WG was May 30. Shawn reminded everyone to stay alert to comments on the wiki and to complete the questionnaire.</p><br />
<br />
[http://www.w3.org/2014/05/16-eo-minutes 16 May 2014 Minutes]<br />
====Participants====<br />
* Present: Sharron, Bim, AnnaBelle, Shawn, EricE, Paul, Wayne, Jan, Sylvie, Vicki<br />
* Regrets: Helle, Shadi, Howard, Andrew <br />
* Availability survey empty: Liam, Anthony<br />
<br />
Read summary & skimmed minutes ''(people who missed the meeting)'':<br />
* [done] {Andrew, 2014.05.30}<br />
* [done] {name, date}<br />
<br />
===9 May 2014 Teleconference===<br />
====Agenda====<br />
<ol><br />
<li>[https://w3c.github.io/wai-tutorials/tables/ Tables tutorial] - discuss any open issues (which Eric will prepare for discussion)</li><br />
<li>Coming soon: "WBS" questionnaires for approval to publish Tutorials cover page, Images Tutorial, Tables Tutorial - please schedule time for these</li><br />
<li>[https://www.w3.org/WAI/EO/wiki/Action_Items#IndieUI_Requirements_Review_-_May IndieUI Requirements] -<br />
<ul><br />
<li>discuss [http://lists.w3.org/Archives/Public/w3c-wai-eo/2014AprJun/0027.html Wayne's comments]</li><br />
<li>other reviewers? and input on [https://www.w3.org/WAI/EO/wiki/IndieUI_Requirements_Review#.22use_cases.22_versus_.22scenarios.22 "use cases" versus "scenarios"]</li><br />
</ul></li><br />
<li>Worksession - for those who want to refine the [https://w3c.github.io/wai-tutorials/ Tutorials cover page]<br />
</ol><br />
<br />
====Summary====<br />
<p>The first discussion and majority of meeting time was devoted to the Tutorials - examining the open issues from the Tables Tutorial and wrapping up the Images Tutorial comments. There was some discussion of the Tables thumbnail icons, how detailed they should be, how they should be placed, and what alt text was appropriate. Eric thanked AnnaBelle for her excellent copy-edits to the Images Tutorials and felt confident that Images is in good shape for final review. Shawn told everyone to look for a questionnaire and to please make the time to complete it since the goal is to have these completed in may. With the expectation that there will be more comments, suggested changes to Tables Tutorials, Eric asked that those be the priority when completing the questionnaire. Next was a discussion of the Indie-UI Requirements draft and Wayne's comments. Some general comments from Wayne and Liam will be submitted by them as individuals and Sharron took the action to submit one comment from the group. That is the observation that terms "use case" and "scenario" seem to be used randomly. We propose that Indie-UI refer only to "use cases" since that is the more accurate term in this context. Finally, for those who are more productive in working group activities, some participants remained to discuss the Tutorials Cover Page and others left to work on their own.</p> <br />
<br />
[http://www.w3.org/2014/05/09-eo-minutes 9 May 2014 Minutes]<br />
<br />
====Participants====<br />
* Present: Shawn, Sharron, Wayne, Bim, EricE, Jan, Andrew, LiamM<br />
* Regrets: Shadi, Helle, AnnaBelle, Sylvie<br />
* Availability survey empty: Anthony, Howard, Paul<br />
<br />
Read summary & skimmed minutes ''(people who missed the meeting)'':<br />
* [done] {Sylvie, 6 June, 2014}<br />
* [done] {name, date}<br />
<br />
===2 May 2014 Worksession===<br />
<br />
Optional worksession to review [https://w3c.github.io/wai-tutorials/tables/ Tables tutorial]. Put changes in GitHub or comments in [https://www.w3.org/WAI/EO/wiki/Tutorials/Feedback/Tables Tables wiki page].<br />
<br />
[http://www.w3.org/2014/05/02-eo-minutes 2 May 2014 worksession notes]<br />
<br />
===25 April 2014 teleconference===<br />
====Agenda====<br />
<ol><br />
<li>[https://w3c.github.io/wai-tutorials/tables/ Tables tutorial] - discuss issues in [https://www.w3.org/WAI/EO/wiki/Tutorials/Feedback/Tables Tables wiki page]</li><br />
<li>[http://lists.w3.org/Archives/Public/w3c-wai-ig/2014AprJun/0091.html IndieUI Requirements] - volunteers to review (and/or comment on [https://www.w3.org/WAI/EO/wiki/IndieUI_Requirements_Review#.22use_cases.22_versus_.22scenarios.22 "use cases" versus "scenarios"]): Wayne, ?</li><br />
<li>EO work focusing on Tutorials - plan your 2 hours for that most weeks</li><br />
</ol><br />
<br />
====Summary====<br />
<p>In looking at Eric's progress on the [https://w3c.github.io/wai-tutorials/tables/ Tables tutorial], Shawn noted that only she and Vicki had made documented comments. Helle said she had looked at the Table Tutorial but had trouble navigating the [https://github.com/w3c/wai-tutorials/issues GitHub interface]. Shawn reminded everyone they could still use the wiki and/or email to comment. Eric suggested the group take a look now during the meeting and offer comments. One major concern is the question of how to promote best practice (for example with table captions) while making the distinction clear between what is required and what is recommended as a best practice. Discussion included the observation that loading the tutorials with disclaimers and W3C "normative" jargon could seriously undermine the pedagogy of these which are meant to be teaching documents. The group agreed that we want to avoid "noise:" and yet we must make the distinction clear. Several suggestions were offered and Eric will incorporate them for group consideration. Concern was offered as well about the use of terms like "ambiguous tables," Multi-level tables" etc and the group asked for greater clarity, suggesting perhaps the use of "irregular." Next was Shawn's request for volunteers to review the draft of "Indie-UI" with particular attention to the way they reference "use cases" and "scenarios." Jan, Helle and Wayne agreed to review. Helle asked that meeting dates be put back on the EO home page, it was agreed to do so. Sharron asked for an update on the WAI response to a request for anayltics. Shawn said Sharron and Liam should submit the questions that they want answered and she will see what we can do. Denis asked for a meeting to continue the Tables tutorial review in real time as a group and they settled on a time on May 2 for anyone wishing to join. </p><br />
<br />
[http://www.w3.org/2014/04/25-eo-minutes 25 April 2014 Minutes]<br />
<br />
====Participants====<br />
* Present: Shawn, Sharron, EricE, Shadi, Helle, Jan, Denis, Bim, PaulSchantz, Wayne<br />
* Regrets: Sylvie, Andrew<br />
* Availability survey empty: Liam, Howard, Anthony<br />
<br />
Read summary & skimmed minutes ''(people who missed the meeting)'':<br />
* [done] {Vicki, June 3, 2014}<br />
* [done] {name, date}<br />
<br />
===18 April 2014 - no teleconference===<br />
<br />
===11 April 2014===<br />
====Agenda====<br />
# ATAG promo debrief and ATAG status update<br />
# Introduction for those interested in providing [https://github.com/w3c/wai-tutorials/blob/master/README.md GitHub Tutorial feedback] and a review of [https://www.w3.org/WAI/EO/wiki/Tutorials/Feedback Tutorials feedback on the EO wiki] <br />
# [https://www.w3.org/WAI/EO/wiki/Procurement_Resources#Accessible_Procurement_Resources Procurement Resources] - discuss draft and what's needed before moving it to WAI-Engage wiki<br />
# Review and discuss content of [http://www.w3.org/WAI/yourWAI Finding Your WAI] page. "New Resources" are not so new...and what else could be improved from an outreach perspective?<br />
# Discuss Michael Ellidge's [http://lists.w3.org/Archives/Public/wai-eo-editors/2014Apr/0000.html suggestion for Easy Checks] on WAI-editors list<br />
# [https://www.w3.org/WAI/EO/wiki/Action_Items Actions reminders]<br />
#* Each week, search for your name. Then search for highlighted words "Who else:" Complete items that are marked "Everyone". If time and interest, do things indicated "Anyone".<br />
#* When you miss a meeting, read summary on this page and add your name as [done]<br />
====Summary====<br />
First on the agenda was to hear from Jeanne about the [https://www.w3.org/WAI/EO/wiki/Outreach_for_ATAG_2.0#Cards_for_CSUN_2014 ATAG outreach at CSUN] with the buttons and cards. Jeanne reported great success, more than 13 people volunteered to test and more applications are still coming in. She now has more than 20 testers. Implementation outreach was good as well, although they are slower to be finalized. Jeanne is hoping for implementers using Drupal and Wayne and Paul will help her find those within CSU system. Andrew will put Jeanne in touch with Drupal authors using modules for accessibility. Jeanne thanks ed everyone for their efforts and will consider what else to ask EO for, including the possibility of creating a WAI-Engage project to keep the momentum moving forward and to manage volunteer engagement. Next Eric reviewed the ways to comment on the Tutorials, first through [https://github.com/w3c/wai-tutorials/blob/master/README.md GitHub Tutorial feedback] and second through the [https://www.w3.org/WAI/EO/wiki/Tutorials/Feedback Tutorials feedback page of the EO wiki]. Links to the specific tutorials as well as GitHub links are maintained on that wiki page. Eric emphasized that no one needs to feel obligated to participate in GitHub, although Liam encouraged everyone to try, especially for editing typos and other trivial items. Wayne introduced the fact that GitHub was actually easier for him to navigate than the wiki. He requested that all EO participants try to do their EO homework within the wiki enlarged to 200%. Eric has sent Wayne a revised styles sheet and we will check in to see how that is working. Sylvie and Bim emphasized the fact that dates and clear sectioning help navigate the wiki with a screenreader.<br />
<br />
Next the group considered the status of the [https://www.w3.org/WAI/EO/wiki/Procurement_Resources#Accessible_Procurement_Resources Procurement Resources wiki page] and its readiness to go to WAI-Engage. Sharron voiced a concern that we have not had success putting things on WAI-Engage in the past and would like EO to think about how to launch it with incentives for participation. Sharron and Wayne will talk with procurement people in universities and state agencies to see if we can get commitment to participate when the project moves to the public wiki. The next item was a consideration the [http://www.w3.org/WAI/yourWAI Finding Your WAI] page on the main WAI website. Highlighted items are dated and we need to think about the purpose of the page and how well it is succeeding. What does this page do that is not done on Getting Started, the site map, or What's New? EO participants are asked to comment on the [[YourWAI]] wiki page. In the meantime, Eric will ask Shawn and Shadi about including some open source analytic tools. Next the group considered the response to an EasyChecks solution posted to WAI editor's list and agreed to thank Michael for his input and add his suggestions to a list of future improvements. The meeting ended with a reminder that EO will not meet on April 18th.<br />
====Participants====<br />
* '''Present: Sharron, Jeanne, Jan, Wayne, Eric, Bim, Sylvie, Paul, Andrew, Liam, <br />
* Regrets: Shawn, Shadi, AnnaBelle, Denis, Vicki, Helle<br />
* Availability survey empty: Howard, Anthony<br />
<br />
Read summary & skimmed minutes ''(people who missed the meeting)'':<br />
* [done] Shawn, 15 April 2014<br />
* [done] Helle, 23 April 2014<br />
* [done] Vicki, 24 April 2014<br />
* [done] Anna Belle, 29 April 2014<br />
<br />
===04 April 2014===<br />
====Agenda====<br />
# [http://www.w3.org/WAI/alt/ Resources for|on Alternative Text for Images] - [https://www.w3.org/WAI/EO/wiki/Alt_guidance#Draft_page Draft page comments in wiki]<br />
# [http://www.w3.org/WAI/EO/Drafts/eval/checks#domore Easy Checks disclaimer] - [https://www.w3.org/WAI/EO/wiki/Easy_Checks#Suggested:_More_visible.2C_stronger_this_is_not_definitive.2C_have_to_do_more discuss comments] and finalize<br />
# [https://www.w3.org/WAI/EO/wiki/Evaluation_tool_guidance Evaluation Tool Guidance] - discuss new title idea<br />
# [http://www.w3.org/WAI/tutorials/ Tutorials] cover page - discuss comments in [https://www.w3.org/WAI/EO/wiki/Tutorials#Cover_page wiki] and [https://github.com/w3c/wai-tutorials Github] as needed<br />
# [https://www.w3.org/WAI/EO/wiki/Tutorial_Concepts Tutorial Concepts] - debrief from F2F and discuss ideas<br />
# ''(if time)'' [https://www.w3.org/WAI/EO/wiki/Procurement_Resources#Accessible_Procurement_Resources Procurement Resources] - plan for developing it more and moving it to WAI-Engage wiki<br />
# [https://www.w3.org/WAI/EO/wiki/Action_Items Actions reminders]<br />
#* Every week, search for your name. Then search for "Who else:", which is highlighted and do all things indicated "Everyone". If time and interest, do things indicated "Anyone".<br />
#* When you miss a meeting, read the Sharron's ever so helpful summary on this page and add your name as [done]<br />
====Summary====<br />
We tabled the first agenda item, the discussion of the [http://www.w3.org/WAI/alt/ HTML5 Images resource page], until Mark could join, later in the meeting. Next on the agenda was consideration of the [http://www.w3.org/WAI/EO/Drafts/eval/checks#domore Easy Checks disclaimer]. Discussion resolved with approval of the shaded box for the text but a decision to place the disclaimer in just one location on the page, right before the Expand All option. Otherwise the feeling was that it creates to much visual noise and distraction if placed in front of each and every check. Next was a discussion of [https://www.w3.org/WAI/EO/wiki/Evaluation_tool_guidance wiki Eval tool comments] regarding the title of the Tool Developer Guide. EO felt that the title had been significantly improved to be "Developer (or Developer's or Developers')Guide to Features of Web Accessibility Evaluation Tools" and left the final grammatical decision to Shadi's WG to decide. Also approved the acronym "WAET Guide." Next up was a discussion of the [http://www.w3.org/WAI/tutorials/ Tutorials cover page] and a recap of [https://www.w3.org/WAI/EO/wiki/Tutorial_Concepts the Tutorials Concept work] done at CSUN F2F. Eric appreciated the wiki input and asked for everyone to continue adding thoughts and comments. Discussion followed about the additions and final disposition of the [https://www.w3.org/WAI/EO/wiki/Procurement_Resources#Accessible_Procurement_Resources Procurement Resources] on the EO wiki. While the intent is to polish the page a bit more and add to the WAI-Engage wiki, questions arose about how to promote wider participation. Citing lack of response to past efforts to engage people through WAI-Engage, a need was expressed to develop a more active outreach effort if we try this again. Sharron and Wayne will reach out to people they know with procurement responsibility to try to get their commitment of active engagement before we post the resource to WAI-Engage. In the meantime EO participants are encouraged to continue to post resources.<br />
<br />
Mark joined the call and thanked EO for the wiki comments. He debriefed the group on the background of the HTML5 Images guide and the group expressed their appreciation of the document. [http://www.w3.org/2014/04/04-eo-minutes.html#item07 Suggestions were made] including: consider expanding the topics that are covered by this type of resource; if so, provide an additional folder with a common root; consider if there is a relationship to [http://www.w3.org/WAI/yourWAI yourWAI]; if so consider page type more closely related to Tutorials or WAI. Mark said there was little chance that other topics could be included at this time since HTML5 is progressing rapidly but will take suggestions for future consideration.<br />
<br />
The meeting closed with a discussion of the new [https://www.w3.org/WAI/EO/wiki/Main_Page#Main_Things EO wiki structure], specifically the consolidation of meeting agendas, minute summaries and action items. While this is generally acceptable and even preferable for most participants, some expressed a preference for having at least some brief info about meetings on the EO home page. Additional discussion of the wiki in general surfaced problems with way-finding - what is supposed be commented upon and where to comment? - as well as the fact that pages grow to unwieldy lengths and become hard to navigate. Wayne reminded the group that he was entirely unable to navigate or use the wiki and felt that he missed a great deal of interaction - comments and responses - by being unable to use the wiki platform. Sharron will take these matters up with Shawn and welcomes further input about how to manage participation.<br />
<br />
====Participants====<br />
* '''Present: Sharron, Shadi, Wayne, Denis, Eric, Bim, Vicki, Sylvie, Howard, Jan, Andrew, Liam, Helle, Mark_Sadecki<br />
* Regrets: Shawn, AnnaBelle, <br />
* Availability survey empty: Suzette, Anthony, Emmanuelle, Howard <br />
<br />
Read summary & skimmed minutes ''(people who missed the meeting)'':<br />
* [done] Shawn, 15 April 2014<br />
* [done] Anna Belle, 29 April 2014<br />
<br />
===28 March 2014===<br />
====Agenda====<br />
# CSUN debrief<br />
# Easy Checks - discuss [https://www.w3.org/WAI/EO/wiki/Easy_Checks#March_2014_changes March changes]<br />
# [https://www.w3.org/WAI/EO/wiki/Alt_guidance Alt guidance] - OK for EOWG to be in critical path?<br />
# [https://www.w3.org/WAI/EO/wiki/Evaluation_tool_guidance Evaluation tool guidance] - comments on [http://www.w3.org/WAI/ER/WD-AERT/ED-AERT Features of web accessibility evaluation tools: Guidance on the development and selection of tools]<br />
# [https://www.w3.org/WAI/EO/wiki/Procurement_Resources Procurement Resources] - discuss issues with seeding WAI-Engage wiki page<br />
# [https://www.w3.org/WAI/EO/wiki/WCAG_review#Techniques_for_Specific_Technologies Techniques for Specific Technologies] - comment for April discussion<br />
# [https://www.w3.org/WAI/EO/wiki/Action_Items Actions reminders] - every week, search for your name, then search for "Who else:", which is highlighted.<br />
# [https://www.w3.org/2002/09/wbs/35532/availability/ Availability for Upcoming EOWG Teleconferences] - why not filling out?<br />
<br />
====Summary====<br />
<p>The meeting began with a recap of CSUN highlights shared by those who had attended, including increased attention to procurement resources, great interest in Easy Checks, and a general feeling that the field was maturing. Because there was such low attendance at the F2F, the group must consider whether we want to plan to meet at CSUN again next year (so that space can be reserved) or pass and find other venues for face to face meetings. Next Shadi asked the group to consider the development of a [http://www.w3.org/2014/03/28-eo-minutes.html#item04 new document for helping toolmakers include accessibility evaluation features]. Shadi particularly asked for help with the framing of the document, especially the title, the abstract and the introduction. The group brainstormed titles that more clearly targeted the audience of tools makers. Discussion followed about seeding the WAI-Engage wiki with [http://www.w3.org/2014/03/28-eo-minutes.html#item05 policy and procurement resources]. Caution was expressed about being clear that this is not legal advice and to steer clear of contract language. Otherwise, the idea seems useful and will be pursued. In exploring why the availability survey was not being completed, we found several people locked out from their log-in. Once that is solved, Shawn urged everyone to keep the [https://www.w3.org/2002/09/wbs/35532/availability/ EO participant attendance survey] up to date. Next the group looked at the [http://www.w3.org/WAI/EO/wiki/Main_Page#Main_Things newly organized EO wiki] and associated actions - now structured by topic rather than by person. Members are encouraged to visit the wiki once or twice a week, search for your name associated with a topic and then search for "Who Else." If it says everyone, a response is required; if it says anyone, you are encouraged to comment - even to agree with previous comments or say you have no opinion. Going forward, the [http://www.w3.org/WAI/EO/wiki/EOWG_Meetings meeting agendas and summaries] will also be found on the wiki for your convenience.</p><br />
<br />
In [https://www.w3.org/WAI/EO/wiki/WCAG_review#Techniques_for_Specific_Technologies Techniques for Specific Technologies], read Background and Notes. Comment under "Additional Discussion on Wording" and "Location". (+1 is enough of a comment)<br />
<br />
[http://www.w3.org/2014/03/28-eo-minutes Rough minutes 28-March-2014]<br />
<br />
====Participants====<br />
<br />
* '''Present: Shawn, Sharron, Jan, Andrew, PaulSchantz, Bim, Helle, Shadi, Howard (second part)'''<br />
* Regrets: AnnaBelle, Vicki, Howard, Eric, Liam, Sylvie, Wayne <br />
* Availability survey empty: Wayne, Denis <br />
<br />
Read summary & skimmed minutes: <br />
* [done] Vicki, 24-April-2014<br />
* [done] Anna Belle, 29-April-2014</div>Wdickhttps://www.w3.org/WAI/EO/wiki/index.php?title=IndieUI_Requirements_Review&diff=9949IndieUI Requirements Review2014-05-15T20:23:08Z<p>Wdick: /* "use cases" versus "scenarios" */</p>
<hr />
<div><p>'''[http://www.w3.org/TR/indie-ui-requirements/ IndieUI Requirements] First Public Working Draft''' ([http://lists.w3.org/Archives/Public/w3c-wai-ig/2014AprJun/0091.html e-mail announcement])</p><br />
==Schedule==<br />
<ul><br />
<li>by 6 May - draft comments available for EOWG review</li><br />
<li>through 8 May - EOWG review comments</li><br />
<li>9 May - EOWG discuss</li><br />
<li>revise comments to submit</li><br />
<li>16 May - EOWG approve</li><br />
<li>by 23 May - submit comments</li><br />
</ul><br />
<br />
==Comments to submit==<br />
''Please make these clear and polished.''<br />
<br />
* ...<br />
<br />
* Typos and minor copyediting:<br />
**...<br />
<br />
==Comments for EOWG Discussion==<br />
<br />
<ul><br />
<li>(Liam) Just trying to review standard UI widgets available in Jquery UI and Kendo... here's my list so far.<ul><br />
<br />
<li>Accordion / Panel Bar<br />
<li>Action Sheet / To Do List<br />
<li>Autocomplete<br />
<li>Barcode<br />
<li>Button<br />
<li>Button Group<br />
<li>Calendar<br />
<li>Captcha<br />
<li>Chart<br />
<li>Color Picker<br />
<li>Combo Box (select)<br />
<li>Date Picker<br />
<li>Dialog<br />
<li>Diagram<br />
<li>Dockable Panel<br />
<li>Drawer / Peek Menu<br />
<li>Editor<br />
<li>Expand / Collapse Panel<br />
<li>Gauges<br />
<li>Grid<br />
<li>List View<br />
<li>Map<br />
<li>Menu<br />
<li>Multi Select<br />
<li>Nest Panel<br />
<li>Numeric Text Box<br />
<li>Popover<br />
<li>Progress Bar<br />
<li>QR Code<br />
<li>Resizable Panel<br />
<li>Scheduler<br />
<li>Scroller<br />
<li>Scroller infinite / lazy load<br />
<li>Slider<br />
<li>Spinner (for numbers/dates)<br />
<li>Split Panel<br />
<li>Stock Chart<br />
<li>Tabs / Tab Strip<br />
<li>Time Picker<br />
<li>Tooltip<br />
<li>Treeview<br />
<li>Upload<br />
<br />
</ul><br />
<br />
And same again for interactions:<br />
<br />
<ul><br />
<br />
<li>Drag<br />
<li>Drop<br />
<li>Resize<br />
<li>Select<br />
<li>Sort<br />
<br />
</ul><br />
<br />
And again same for effects<br />
<br />
<ul><br />
<li>Add/remove class<br />
<li>Colour animation<br />
<li>Animation effect<br />
<li>Show/Hide<br />
<li>Switch class<br />
<li>Toggle class<br />
</ul><br />
<br />
Can we match which are dealt with in IndieUI? Do we think that IndieUI needs to provide for all of these use cases/scenarios? Any more UI libs that people can think of offhand? I guess that this may be a bigger deal for IndieUI UserContext than for IndieUI Events.<br />
</li><br />
<br />
</ul><br />
<br />
==="use cases" versus "scenarios"===<br />
The draft document uses both terms. Would you consider these one or the other? Is there reason to use just one term?<br />
<br />
<ul><br />
<li>(Wayne) I was thinking very technically. Use case is a term from the UML design process. <br />
This process generally is viewed from the point of view of an "actor", who is presented with a given situation. <br />
This abstract actor has choices and these are analyzed. Scenarios tend to me more story like.<br />
I don't know if the distinction is essential, but use case is more exact.</li><br />
<li>...</li><br />
</ul></div>Wdickhttps://www.w3.org/WAI/EO/wiki/index.php?title=IndieUI_Requirements_Review&diff=9948IndieUI Requirements Review2014-05-15T20:21:35Z<p>Wdick: /* "use cases" versus "scenarios" */</p>
<hr />
<div><p>'''[http://www.w3.org/TR/indie-ui-requirements/ IndieUI Requirements] First Public Working Draft''' ([http://lists.w3.org/Archives/Public/w3c-wai-ig/2014AprJun/0091.html e-mail announcement])</p><br />
==Schedule==<br />
<ul><br />
<li>by 6 May - draft comments available for EOWG review</li><br />
<li>through 8 May - EOWG review comments</li><br />
<li>9 May - EOWG discuss</li><br />
<li>revise comments to submit</li><br />
<li>16 May - EOWG approve</li><br />
<li>by 23 May - submit comments</li><br />
</ul><br />
<br />
==Comments to submit==<br />
''Please make these clear and polished.''<br />
<br />
* ...<br />
<br />
* Typos and minor copyediting:<br />
**...<br />
<br />
==Comments for EOWG Discussion==<br />
<br />
<ul><br />
<li>(Liam) Just trying to review standard UI widgets available in Jquery UI and Kendo... here's my list so far.<ul><br />
<br />
<li>Accordion / Panel Bar<br />
<li>Action Sheet / To Do List<br />
<li>Autocomplete<br />
<li>Barcode<br />
<li>Button<br />
<li>Button Group<br />
<li>Calendar<br />
<li>Captcha<br />
<li>Chart<br />
<li>Color Picker<br />
<li>Combo Box (select)<br />
<li>Date Picker<br />
<li>Dialog<br />
<li>Diagram<br />
<li>Dockable Panel<br />
<li>Drawer / Peek Menu<br />
<li>Editor<br />
<li>Expand / Collapse Panel<br />
<li>Gauges<br />
<li>Grid<br />
<li>List View<br />
<li>Map<br />
<li>Menu<br />
<li>Multi Select<br />
<li>Nest Panel<br />
<li>Numeric Text Box<br />
<li>Popover<br />
<li>Progress Bar<br />
<li>QR Code<br />
<li>Resizable Panel<br />
<li>Scheduler<br />
<li>Scroller<br />
<li>Scroller infinite / lazy load<br />
<li>Slider<br />
<li>Spinner (for numbers/dates)<br />
<li>Split Panel<br />
<li>Stock Chart<br />
<li>Tabs / Tab Strip<br />
<li>Time Picker<br />
<li>Tooltip<br />
<li>Treeview<br />
<li>Upload<br />
<br />
</ul><br />
<br />
And same again for interactions:<br />
<br />
<ul><br />
<br />
<li>Drag<br />
<li>Drop<br />
<li>Resize<br />
<li>Select<br />
<li>Sort<br />
<br />
</ul><br />
<br />
And again same for effects<br />
<br />
<ul><br />
<li>Add/remove class<br />
<li>Colour animation<br />
<li>Animation effect<br />
<li>Show/Hide<br />
<li>Switch class<br />
<li>Toggle class<br />
</ul><br />
<br />
Can we match which are dealt with in IndieUI? Do we think that IndieUI needs to provide for all of these use cases/scenarios? Any more UI libs that people can think of offhand? I guess that this may be a bigger deal for IndieUI UserContext than for IndieUI Events.<br />
</li><br />
<br />
</ul><br />
<br />
==="use cases" versus "scenarios"===<br />
The draft document uses both terms. Would you consider these one or the other? Is there reason to use just one term?<br />
<br />
<ul><br />
<li>(Wayne) I was thinking very technically. Use case is a term from UML design process. <br />
They generally from the point of view of an "actor", who is presented with a given situation. <br />
This abstract actor has choices and these are analyzed. Scenarios tend to me more story like.<br />
I don't know if the distinction is essential, but use case is more exact.</li><br />
<li>...</li><br />
</ul></div>Wdickhttps://www.w3.org/WAI/EO/wiki/index.php?title=WCAG-EM_review&diff=8947WCAG-EM review2014-02-28T14:29:45Z<p>Wdick: </p>
<hr />
<div>Nav: [[Main Page|EOWG wiki main page]]<br />
<br />
__TOC__<br />
Links:<br />
* [http://www.w3.org/TR/WCAG-EM/ WCAG-EM document] - latest published Working Draft<br />
* [http://www.w3.org/WAI/ER/2011/eval/track/issues/open Open Issues] - Eval Task Force issue tracking<br />
* [[WCAG-EM review 2012-2013]] - archive of previous comments<br />
<br />
EOWG review reminder:<br />
* See [http://www.w3.org/WAI/EO/wiki/Main_Page#Technical_Document_Review Notes under Technical Document Review] for info on reviewing and commenting.<br />
* EOWG will focus on the types of questions below under [[https://www.w3.org/WAI/EO/wiki/WCAG-EM_review_2012-2013#Comments_submitted_on_22_October_2012 Comments submitted on 22 October 2012]]. If you have comments on specific technical points in the document, you can submit them directly yourself -- that is, e-mail them to public-wai-evaltf@w3.org 22 <br />If you're not sure, feel free to put your comments here and the Group will decide if they are ones you should send yourself.<br />
<br />
=Comments on 30 January 2014 Draft=<br />
<ul class="listspaced1"><br />
<li>'''&quot;Web page states<br />
&quot;'''<br />
<ul><br />
<li>Location: &quot;Terms and definitions&quot;, [http://www.w3.org/TR/WCAG-EM/#states Web page states]. This definition seems to be very jargony to me. EOWG: Suggestions for improving understandability?<br />
<blockquote><br />
<p>Web pages with dynamic content can have different states (changes to the Document Object Model - DOM); for example, they might generate different content and provide different presentation or functionality depending on the particular user and on actions initiated by the user. In the context of this methodology, web page states can be treated as ancillary to web pages (i.e., recorded as an additional state of a web page in a web page sample) or as individual web pages. </p><br />
</blockquote><br />
<p><span class="quiet">{Sylvie, 10 February}</span></p><br />
<br />
<ul class="listspaced05"><br />
<li>maybe we can request a concrete example? (For instance is an expanded section in 'easy checks' a different 'state' from the loaded page?) They also suggest that the different states can be treated in two different ways - maybe they should have a recommended way? <span class="quiet">{Andrew, 21 Feb}</span><br>Would be good if could supply our own, but don't have time<span class="quiet">{Shawn, Feb. 28}</span></li><br />
<li>“state” is really general – in that definition is a drop down menu a new state as it changes the DOM? <span class="quiet">{Eric, Feb. 27}</span></li><br />
<li>Too vague and technically too broad. Perhaps "change of context" terminology from WCAG might work <span class="quiet">{EO Discussion, Feb. 28}</span></li><br />
</ul><br />
</li><br />
<li>In [http://www.w3.org/TR/WCAG-EM/#step2a step 2.a]: &quot;Identify Common Web Pages of the Website&quot;, I'm not sure I understand what &quot;web page states&quot; is. <br /><br />
Sentence: &quot;Identify the common web pages, which may be web page states, of the target website.&quot;<br /><br />
I can't remember if it was in the previous version but explanations on this would be appreciated. Same question for web applications further in the text. <span class="quiet">{Sylvie, 19 February}</span><br />
<ul class="listspaced05"><br />
<li>+1. Is it not possible to make this simpler e.g. "Identiy the common web pages, including sample dynamic web pages, of the target website."<span class="quiet">{Vicki, 20 February}</span></li><br />
<li>'''Proposed comment to Eval TF:''' Generally EOWG thinks you should *not* link all terms to their definitions; however, since this one is not a well understood term, we recommend that you do link to the definition for the first use of the term in each section. <span class="quiet">{Shawn}</span></li><br />
<li>+1 for the link since "web page states" is not clear. <span class="quiet">{Vicki - 20 Feb.}</span></li><br />
<li>+1 also for linking "web page states". <span class="quiet">{Andrew, 21 Feb}</span></li><br />
<li>+1 also for linking "web page states" - this threw me also<span class="quiet">{Howard, 26 Feb}</span></li><br />
<li>+1 for linking – this is really hard to understand otherwise <span class="quiet">{Eric, Feb. 27}</span></li><br />
<li>+1 to proposed change to linking from "web page states" <span class="quiet">{Bim 28 Feb }</span></li><br />
<li>comment <span class="quiet">{name}</span></li> </ul><br />
</li><br />
</ul><br />
</li><br />
<hr/><br />
<li>[No comment] '''Supersede''' - Can we use &quot;Succeed&quot; or &quot;Overtake&quot; instead of the word &quot;Supersede&quot;, its difficult to understand for some users <span class="quiet">{Anthony, 12, February}</span><br />
<ul class="listspaced05"><br />
<li>It's used in the [http://www.w3.org/TR/WCAG-EM/#abstract abstract], first paragraph, last sentence: &quot;This document is one of a series of informative W3C/WAI resources about Evaluating Websites for Accessibility that complements the WCAG 2.0 Documents. It does not define additional WCAG 2.0 requirements nor does it replace or supersede it in any way.&quot; I think &quot;supersede&quot; is the proper term here and since it says &quot;replace or superseded&quot; I think it's OK. <em>(It's also in the Status of the Document, which is boilerplate language that we cannot easily change.)</em><span class="quiet">{shawn}</span></li><br />
<li>+1 to leave as is <span class="quiet">{Andrew, 21 Feb}</span></li><br />
<li>+1 to leave as is <span class="quiet">{Sylvie, 25 Feb}</span></li><br />
<li>+1 to leave as is <span class="quiet">{Howard, 26 Feb}</span></li><br />
<li>+1 to leave as is <span class="quiet">{Eric, Feb. 27}</span></li><br />
<li>+1 to leave as is <span class="quiet">{Bim 28 Feb}</span></li><br />
<li>comment <span class="quiet">{name}</span></li> </ul> </li><br />
<hr/><br />
<li>[submit wording change but don't submit end-to-end comment] '''clarity''' - location : &quot;[http://www.w3.org/TR/WCAG-EM/#specialcases Particular Types of Websites]&quot;, in bullet &quot;Web Applications&quot; note: &quot;Web applications will typically require more time and effort to evaluate, and larger web page samples to reflect the different types of content, functionality, and processes.&quot; <span class="quiet">Maybe a word is missing, the sentence is not clear. {Sylvie, 10 February}</span><br />
<ul class="listspaced05"><br />
<li>Can this be fixed by: &quot;Web applications will typically require more time and effort to evaluate, and they will need larger web page samples to reflect the different types of content, functionality, and processes.&quot; ? <span class="quiet">{Shawn}</span></li><br />
<li>+1 <span class="quiet">{Vicki - 20 Feb.}</span></li><br />
<li>Shawn's suggestion is a good suggestion to clarify what they have said, but aren't applications are meant to be tested from end-to-end? (see http://www.w3.org/TR/WCAG20/#cc3) <span class="quiet">{Andrew, 21 Feb}</span></li><br />
<li>+1 to include that web apps must be tested from end-to-end and that a “larger web page sample” might not be enough <span class="quiet">{Eric, Feb. 27}</span></li><br />
<li>+1 for end-to-end evaluation (all functionality plus all supporting pages) of web applications. <span class="quiet">{Bim, 28 Feb}</span></li><br />
<li>A Web application can have multiple complete processes - for example, think of webmail client. Complete processes is covered in step 4.b <span class="quiet">{Shadi, 28 Feb}</span></li><br />
<li>comment <span class="quiet">{name}</span></li><br />
</ul> </li><br />
<hr/><br />
<li>[No comment] '''In [http://www.w3.org/TR/WCAG-EM/#step2c Step 2.c:]''', &quot;Content that change appearance, behavior,&quot; is covered in rest of the points? If so we can remove this part<span class="quiet"> {Anthony, 12, February}</span><br />
<ul class="listspaced05"><br />
<li>I think not necessarily covered in the other bullets and so it's good to leave it there. <span class="quiet">{Shawn}</span></li><br />
<li>The bullet is related to others, but different from them as it is specifically about 'states' <span class="quiet">{Andrew, 21, Feb}</span></li><br />
<li>+1 to keep <span class="quiet">{Eric, Feb. 27}</span></li><br />
<li>comment <span class="quiet">{name}</span></li><br />
</ul> </li><br />
<hr/><br />
<li>[submit comment] '''In [http://www.w3.org/TR/WCAG-EM/#step2d Step 2.d:]''', &quot;During this step the web technologies relied upon (for conformance) to provide the website are identified.&quot; is not clear to me<span class="quiet"> {Anthony, 12, February}</span><br />
<ul class="listspaced05"><br />
<li>This is related to WCAG directly. At the end of the paragraph, it says, &quot;The outcome of this step is a list of technologies that are [http://www.w3.org/TR/WCAG20/#reliedupondef relied upon according to WCAG 2.0].&quot; Is that enough of an explanation, given the audience (who will have to understand how WCAG works for conformance), or do we need someting more &amp;/or something at the start of the paragraph? <span class="quiet">{shawn}</span></li><br />
<li>+1 to Shawn <span class="quiet">{Andrew, 21 Feb}</span></li><br />
<li>In the same section, the second sentence in the Note might be better worded as: "For web applications in particular, much of the accessibility support is built into these libraries and components ..." <span class="quiet">{Andrew, 21 Feb}</span></li><br />
<li>+1 to Shawn and Andrew <span class="quiet">{Eric, Feb. 27}</span></li><br />
<li>Remove the parentheses. Delete phrase "to provide the website." Consider moving the WCAG link to 1st sentenced <span class="quiet">{EO Group, Feb. 28}</span></li><br />
<li>comment <span class="quiet">{name}</span></li><br />
</ul> </li><br />
<hr/><br />
<li>[submit comment] '''[http://www.w3.org/TR/WCAG-EM/#step3 Introduction of step 3]''' seems complicated to me. I have to read each sentence several times to understand. Is there a way to make it more simple? I don't know what to suggest to make this easier to read. <span class="quiet">{Sylvie, 20 February}</span><br />
<ul class="listspaced05"><br />
<li>I find it to be relatively easy to understand. <span class="quiet">{Eric, Feb. 27}</span></li><br />
<li>The purpose of this selection is to ensure that the evaluation results reflect the accessibility performance of the website with reasonable confidence. -> The purpose of this selection is to provide reasonable confidence that the evaluation results reflect the accessibility performance of the website. <span class="quiet">{EO Group, Feb. 28}</span></li><br />
<li>Perhaps the term certainty would be better than confidence. That would remove any confusion with the technical meaning of confidence in statistical experiment design. {Wayne Dick, Feb 28}</li><br />
<li>In cases where it is feasible to evaluate all web pages, you can skip this sampling procedure, then the "selected sample" in the remaining steps of the conformance evaluation procedure is the entire website. <span class="quiet">{EO Group, Feb. 28}</span></li><br />
<li>comment <span class="quiet">{name}</span></li><br />
</ul> </li><br />
<hr/><br />
<li>[submit comment] '''In [http://www.w3.org/TR/WCAG-EM/#step3b step 3B]''', I am not sure to what the web pages are relevant.<br />
<blockquote>Include all other web pages and web page states that are relevant to people with disabilities and accessibility of the website into the selected sample.</blockquote><br />
<span class="quiet">{Sylvie, 20 February}</span><br />
<ul class="listspaced05"><br />
<li>Probably they mean pages like an accessibility statement or if you got special ticket prices for people with disabilities. – Seems a little bit redundant to me, as those shouldn’t be more special than other pages on the website. <span class="quiet">{Eric, Feb. 27}</span></li><br />
<li>Consider making those dependencies more clear and consider reducing such dependencies where possible <span class="quiet">{EO Group, Feb. 28}</span></li><br />
<li>comment <span class="quiet">{name}</span></li><br />
@@@ABL this is where we are<br />
</ul> </li><br />
<hr/><br />
<li>'''Whole step 3:''' It may be clearer to include concrete examples in each bullet and not in paragraphs following each bullet. <br /><br />
Example: &quot;Include all common web pages and web page states that were identified in Step 2.a: Identify Common Web Pages of the Website into the selected sample for evaluation.&quot;<br /><br />
has a repetition of web pages, web pages states, web sites. May be give examples of pages that could be included. <span class="quiet">{Sylvie, 20 February}</span><br />
<ul class="listspaced05"><br />
<li>Too much jargon here, also it would be easier to read if the step title would be in brackets: “Include all common web pages and web page states that were identified in Step 2.a (Identify Common Web Pages of the Website) into the selected sample for evaluation.”<br><br>I wonder if many of those steps could just be summarized with “Include all web pages (and web page states) that were identified in Step 2.a-e.”? <span class="quiet">{Eric, Feb. 27}</span></li><br />
<li>comment <span class="quiet">{name}</span></li><br />
</ul> </li><br />
<hr/><br />
<li>'''Document titles''' (throughout) - Quoting document titles or displaying them in a certain way so that they can be better identified. <br /><br />
The document links to many resources. While reading it, it is sometimes difficult to distinguish the document title from the surrounding text. Is there a visual difference to see the document titles? While reading with a screen reader, for example, it is not always evident to identify the single document titles. For example:<br />
<blockquote>&quot;[http://www.w3.org/WAI/eval/users Involving Users in Web Accessibility Evaluation] provides further guidance beyond the scope of this document.&quot;</blockquote><br />
<span class="quiet">{Sylvie, 10 February}</span><br />
<ul class="listspaced05"><br />
<li>Visually the underlined link text clearly indicates the document titles (and additionally the capitalization provides a clue). I have wondered about this issue throughout the WAI website. One option would be to put the document titles in italics, but I don't think that would help with screen readers. Another option would be to put quotes around the doc title &mdash; but would that help or not given more screen reader common verbosity settings for reading punctuation. What are other options?<span class="quiet">{Shawn}</span></li><br />
<li>As we said in EO Feb. 21st, there is little we can do about that… <span class="quiet">{Eric, Feb. 27}</span></li><br />
<li>comment <span class="quiet">{name}</span></li><br />
</ul> </li><br />
<hr/><br />
<li>'''Purpose of this Methodology - second sentence''' "Periodic evaluation is also useful for monitoring the accessibility performance of websites over time." - Suggest replacing "useful". Rationale: periodic evaluation is more than just useful, it is necessary. Suggested re-wording (removing "also") and use either "important" or "required" or "necessary" so that we gently emphasize that this is not a one-off: "Periodic evaluation is necessary for monitoring the accessibility performance of websites over time". <span class="quiet">{Vicki - 20 February }</span> <br />
<ul class="listspaced05"><br />
<li>'''Purpose of this Methodology - 5th bullet''' "Web accessibility monitoring activities who want to benchmark or compare the accessibility conformance over time." - Suggest replacing with "Web accessibility monitoring *entities* who want to benchmark or compare the accessibility conformance over time. Rationale: I'm sure I mentioned this last time - "who" should refer to a person or group of persons, not an activity. <span class="quiet">{Howard, 26 February }</span> </li><br />
<li>+1 to both changes <span class="quiet">{Eric, Feb. 27}</span></li><br />
<li>+1 to both suggestions.<span class="quiet">{Bim 28 Feb}</span></li><br />
<li>comment <span class="quiet">{name}</span></li> </ul></li><br />
<hr/><br />
<li>[pending] '''Scoring''' - I have read the part on scoring, but I need to ask around what people think. I may send a separate comment on that issue if I get response. <span class="quiet">{Sylvie, 20 February}</span><br />
<ul><br />
<li>I’m not a fan of such scoring systems as they are only quantitative, not qualitative which may lead to good scores for mediocre websites. <span class="quiet">{Eric, Feb. 27}</span></li><br />
</ul><br />
</li><br />
<hr/><br />
<li>comment <span class="quiet">{name}</span></li><br />
</ul><br />
==Grammar &amp; Typos==<br />
<ul class="listspaced1"><br />
<li>Add comma after dependent introductory clauses. For example: &quot;If only a specific website area, such as the &quot;Courseware Application&quot;, is defined as the target for evaluation, then all the parts of this area are within the scope of the evaluation.&quot; Also commas would be helpful here: &quot;Involving people with disabilities, including people with aging-related impairments, helps identify additional accessibility barriers that are not easily discovered by expert evaluation alone.&quot; <span class="quiet">{Sylvie, 10 February}</span></li><br />
<li>In Step 2.c:<br />
<ul class="listspaced05"><br />
<li>&quot;Content that '''are''' created using different coding styles&quot; should be changed as &quot;Content that '''is''' created using different coding styles&quot; <span class="quiet">{Anthony, 12, February}</span></li><br />
<li>&quot;Content that change appearance, behavior, and content depending on the user, device, browser, context, and settings;&quot; -&gt; &quot;Content that change<strong>s</strong> appearance, behavior, and content depending on the user, device, browser, context, and settings;&quot; (third word change-&gt;changes) <span class="quiet">{Shawn</span>}</li><br />
</ul><br />
</li><br />
<li>typos:<br />
<ul class="listspaced05"><br />
<li>evalaute instead of evaluate.</li><br />
<li>In 5.C: Provide an statement: replace by Provide a statement.</li><br />
<li>In 5C: satisifed instead of satisfied.</li><br />
<li>In 5C: validty instead of validity</li><br />
<li>In 5D: failire instead of failure.</li><br />
<li>Procceses instead of processes.</li><br />
<li>(please do a spell check to look for others)</li><br />
</ul><br />
</li><br />
<li>2nd paragraph under http://www.w3.org/TR/WCAG-EM/#introduction - remove comma after "This methodology". <span class="quiet">{Howard, 26 Febuary</span>}</li><br />
</ul><br />
<br />
=Comments on the Overview page=<br />
'''[http://www.w3.org/WAI/eval/conformance WCAG-EM Overview page]'''<br />
<ul class="listspaced1"><br />
<li>Should we do more to set expectations that this is an overall approach, rather than detailed procedure to evaluate each SC? <span class="quiet">{EOWG 31 Jan teleconference}</span><br /><br />
If so, please suggest wording:<br />
<ul><br />
<li>WCAG-EM provides for an overall approach to evaluate web sites rather than a detailed procedure to evaluate each Success Criteria <span class="quiet"> {Vicki - February 13}</span></li><br />
</ul><br />
</li><br />
<br />
<li>'''Introduction''': '''Second paragraph''': I would inverse the sentences in order to continue the focus on WCAG-EM <span class="quiet"> {Vicki - February 13}</span> </li><br />
<li>'''last sentence''' needs to be modified to past tense if it was published as a W3C WG Note in 2013 <span class="quiet"> {Vicki - February 13}</span> <br />It's still a draft so it needs to be changed from 2013 to 2014. :-)</li><br />
<li>'''last sentence''': is it supposed to be &quot;investing time and resources&quot; or just &quot;investing in&quot; <span class="quiet"> {Vicki - February 13}</span></li><br />
<li>'''Scope''': '''3rd paragraph''': Simplify the first sentence, remove the extra noise by removing &quot;in related pages of the&quot; so as to read &quot;Other aspects of evaluation are addressed in the Evaluating Web Accessibility resource suite&quot;. <span class="quiet"> {Vicki - February 13}</span></li><br />
<li>'''Second sentence''': last part of the sententce. Suggestion: &quot;and evaluate if accessibility solutions are effective by Involving Users in Evaluating Web Accessibility.&quot; <span class="quiet"> {Vicki - February 13}</span></li><br />
</ul></div>Wdickhttps://www.w3.org/WAI/EO/wiki/index.php?title=Education_%26_Outreach:Community_Portal&diff=6626Education & Outreach:Community Portal2013-08-23T05:12:12Z<p>Wdick: Created page with "<h1>Removal of Example 2: Tagged PDF from G140 Description.</h1> <p>Issue: “Example 2: Tagged PDF” confuses rather than clarifies the concept of separating information and s…"</p>
<hr />
<div><h1>Removal of Example 2: Tagged PDF from G140 Description.</h1><br />
<br />
<p>Issue: “Example 2: Tagged PDF” confuses rather than clarifies<br />
the concept of separating information and structure from<br />
presentation. The text of the example describes content that is<br />
partially separated, not fully separated. In particular, the<br />
example describes blobs of data in PDF content consisting of,<br />
“mostly of the content embedded with formatting information.”<br />
This diverges markedly from the model that most web developers<br />
associate with separating information and structure from<br />
presentation. In addition, it does not appear to support one key<br />
objective of the G140: The ability to, "Modify the presentation<br />
of content by substituting alternate presentation rules attached<br />
to structural features." </p><br />
<p><strong>Motivation</strong>: Most web professionals know the<br />
separation principle as a foundational concept of web standards.<br />
In fact, this concept motivated the invention of markup language<br />
starting with SGML forty years ago. When web professionals think<br />
of separating information and structure from presentation their<br />
mental model looks like the <em>CSS Zen Garden</em> of Dave<br />
Shea —clean HTML in one file separated from CSS in another. Now,<br />
this is not the only model of data separation, but it is the<br />
model that most web professionals will have in mind when they<br />
first approach the problem. </p><br />
<p>If “Example 2: Tagged PDF” is to be a successful teaching<br />
example that is included in the WCAG 2.0 Techniques, it must<br />
bridge the gap between the objectives of the <em>CSS Zen Garden</em><br />
model and the same techniques using PDF. The example must<br />
demonstrate how to modify the presentation of content by<br />
substituting alternate presentation rules attached to structural<br />
features. Until the author of "Example 2: Tagged PDF" can<br />
accomplish this task, the example should be removed from the<br />
WCAG 2.0 Techniques.</p><br />
<p>PDF has inline elements that express text level semantics. The<br />
example should show how the PDF inline elements can be used<br />
effectively to modify presentation. Web developers already know<br />
how well in-line, text-level, semantic elements work for HTML.<br />
They know how to use elements like (cite, code, dfn, em, kbd,<br />
samp, strong, sub, sup and var) to modify presentation rules.<br />
The <em>CSS Zen Garden</em> is full of these examples. Web<br />
developers want to know how they can do the same things with<br />
PDF. Example 2 doesn’t show how these transformations can be<br />
programmatically determined.</p><br />
<h2>Sample Problem: The solution to a problem like this should be<br />
demonstrated in Example 2. </h2><br />
<p>The Modern Language Association (MLA) Style Guide requires that<br />
the reference to a journal must appear in the italic variant of<br />
the running text in an article. It is well documented, that the<br />
italic format variant poses difficultly for most people with<br />
print disabilities. In HTML one can change this presentation.<br />
The running text (text in paragraphs etc.) could be changed to<br />
the APHont font from the American Printing House for the Blind.<br />
The emphasized text could be changed to a typewriter font like<br />
Courier Bold. This would be much more readable and it would give<br />
the reader with a print disability access equal access to the<br />
denotational semantics of the text and the structural semantics<br />
indicated by the formatting. How could this Zen Garden<br />
transformation be supported with PDF? A reasonable web<br />
programmer with little experience in accessibility but lots of<br />
experience in web standards would like to know how this is done.<br />
Note: This is an important example because PDF is used so<br />
extensively to transmit professional articles on the web.</p><br />
[[File:G140P1.jpg]<br />
<p><strong>Figure 1:</strong> A bibliographic item in standard MLA<br />
format</p><br />
[[File:G140P2.jpg]]<br />
<p><strong>Figure 2:</strong> The same bibliographic item<br />
transformed in the Zen Garden style. Until Example 2 in G140 can<br />
explain how this kind of transformation can be performed, the<br />
example should be removed from the explanation of G140</p><br />
<br />
<br />
<p>Prepared by Wayne Dick for EOWG</p></div>Wdickhttps://www.w3.org/WAI/EO/wiki/index.php?title=Tutorial_-_Images&diff=6147Tutorial - Images2013-07-19T11:41:40Z<p>Wdick: /* Complex images page */</p>
<hr />
<div>Nav: [[Main Page|EOWG wiki main page]] > [[Tutorials|Tutorials main page]]<br />
<br />
==Images tutorial overall==<br />
<br />
''NOTE: If you have comments that apply to all tutorials &mdash; e.g., on the navigation design &mdash; please put them in the main [[Tutorials]] wiki page.''<br />
<br />
<ul><br />
<li style="padding-bottom:1em">comment <span style="color:#808080;">{name}</span></li><br />
<li style="padding-bottom:1em"><br />
This is a remarkable section, from overview to coding details. It all follows, and develops a good introductory course on accessibility. It is not exhaustive and it is not a dictionary of techniques, but one can read an individual topic. The overview page gives a clear description of what one can expect if one is looking to read the entire topic.<br />
<span style="color:#808080;">{Wayne}</span></li><br />
</ul><br />
<br />
==[http://www.w3.org/WAI/EO/Drafts/app-notes/images/ Image concepts page]==<br />
<br />
<ul><br />
<li style="padding-bottom:1em">comment <span style="color:#808080;">{name}</span></li><br />
<li style="padding-bottom:1em">LOVE this page! Comprehensive overview that I'm going to point people to, as the question comes up frequently with stakeholders of all stripes in my organization. Especially like the benefits section, it's nice to see use cases other than screen readers. With the exception of a couple very minor nit-picky things, I think it's ready to publish.<span style="color:#808080;"> { Paul 7/18 }</span></li><br />
<li>Also really like this new look. It's all in one bundle: clear, concise at the top of the page with pointers to more detailed info, improved navigation, pleasant design. Very nice - bravo!<span style="color:#808080;"> { Vicki 19/7 }</span></li><br />
<li style="padding-bottom:1em">Minor edit under "Why is this important?" I think, in the first sentence, "illustration" should be plural <span style="color:#808080;">{Vicki 19/7}</span></li><br />
<li style="padding-bottom:1em">I agree with previous comments, that this page is clear. I only have a reading difficulty of following sentence in the bullet about image maps. I had to read it several times to understand the content. <blockquote>"Image maps: Used to provide multiple selectable regions within an image - text alternative for the image should provide a context while the text alternatives for the selectable <area> elements need to describe the purpose or destination of the links;"</blockquote> <span style="color:#808080;">{Sylvie, 19 June}</span></li><br />
</ul><br />
<br />
==[http://www.w3.org/WAI/EO/Drafts/app-notes/images/functional Functional images page]==<br />
<br />
<ul><br />
<li style="padding-bottom:1em">comment <span style="color:#808080;">{name}</span></li><br />
<li style="padding-bottom:1em">The very first sentence, although proper, reads awkwardly to me. <span style="color:#808080;"> { Paul, 7/18 }</span></li><br />
<li>Suggestion for less awkward first sentence:<br />
"Functional images are images which perform an action, e.g. a button, an icon to open a Word document, a shopping cart.<span style="color:#808080;"> { Vicki, 19/7 }</span></li><br />
<br />
<li style="padding-bottom:1em">Second sentence needs a comma after "initiated". <span style="color:#808080;"> { Paul, 7/18 }</span></li><br />
<li style="padding-bottom:1em">Suggested minor edit to second sentence:<br />
<br />
"In this case, the text alternative for the image ...." (replacing "an image" by "the image") <span style="color:#808080;"> { Vicki, 7/19 }</span></li><br />
<li style="padding-bottom:1em">Suggested minor edit to second sentence:<br />
"that will be initiated, rather than a description of the image." (replacing "to describe the image itself". Simpler style.)<br />
<span style="color:#808080;"> { Vicki, 7/19 }</span></li><br />
<li style="padding-bottom:1em">Printer icon image missing from Example 2 (I know, it's just a placeholder) <span style="color:#808080;"> { Paul, 7/18 }</span></li><br />
<li style="padding-bottom:1em">Does it make sense to hide the code snippets with "show more" links? They're in the right places and they're not complicated, but they do break the text flow and might be distracting for readers who are not coders. <span style="color:#808080;"> { Paul, 7/18 }</span></li><br />
<br />
<li>Like as is <span style="color:#808080;"> { Vicki, 7/19 }</span></li><br />
</ul><br />
<br />
==[http://www.w3.org/WAI/EO/Drafts/app-notes/images/textual Images of text page]==<br />
<br />
<ul><br />
<li style="padding-bottom:1em">comment <span style="color:#808080;">{name}</span></li><br />
<li style="padding-bottom:1em">Suggestion for first sentence:<br />
Images of text are images which display readable text.<span style="color:#808080;">{Vicki 19/7}</span></li><br />
<li style="padding-bottom:1em">Missing comma after "In this case," <span style="color:#808080;">{Vicki 19/7}</span></li><br />
<li style="padding-bottom:1em">Example 1, second sentence should probably be split into two sentences. Maybe also mention what is meant by NOT describing the decorative effects used in the Citylights example image (i.e. - thin greenish script). <span style="color:#808080;">{ Paul, 7/18 }</span></li><br />
<li style="padding-bottom:1em">Suggestion for second sentence under Example 2:<br />
Instead of "It has the text alternative...", use "The text alternative is "Contact us". Simple style. <span style="color:#808080;">{Vicki 19/7}</span></li><br />
<li style="padding-bottom:1em">Structure question: the note about best practice is structured with an h2. Would it be better to tag it with a P? Otherwise, no comments on this page. <span style="color:#808080;">{Sylvie, June 19}</span></li><br />
</ul><br />
<br />
==[http://www.w3.org/WAI/EO/Drafts/app-notes/images/inform Informative images page]==<br />
<br />
<ul><br />
<li style="padding-bottom:1em">comment <span style="color:#808080;">{name}</span></li><br />
<li style="padding-bottom:1em">Great example of when to use null alt attribute. This page is ready to publish, in my opinion. <span style="color:#808080;"> { Paul, 7/18 }</span></li><br />
<li style="padding-bottom:1em">Missing capital on "i" at second sentence. <span style="color:#808080;">{Vicki 19/7}</span></li><br />
<li style="padding-bottom:1em">Missing comma in second sentence after "In this case" <span style="color:#808080;">{Vicki 19/7}</span></li><br />
<li style="padding-bottom:1em">Example 1: I understand the example. But for sighted readers who wouldn't know the breed, how do they get that info :) <span style="color:#808080;">{Vicki 19/7}</span></li><br />
<li style="padding-bottom:1em">Example 2: <br />
Minor edit: after "Note:" capital "T" on "this" <span style="color:#808080;">{Vicki 19/7}</span><br />
<li style="padding-bottom:1em">Unsure/uncomfortable about the explanation given in "Note" - it makes me think twice. Can it be simpler? E.g. "This technique is the most accessible. The image in this case can be considered as decorative. All the required information (in this case, the breed of the dog)is available within the text. Therefore, the user does not need to rely on the image to fully understand the text." Still a bit clumsy.</li><br />
<li style="padding-bottom:1em">Suggestion Example 3: <br />
Note: I would provide an example to illustrate this case since I immediately looked at Example 2 for how PDF is written as part of the text since the Note states "As shown in example 2".<span style="color:#808080;">{Vicki 19/7}</span></li><br />
<li style="padding-bottom:1em">Minor edit: after "Note:" capital "T" on "this" <span style="color:#808080;">{Vicki 19/7}</span></li><br />
<li style="padding-bottom:1em">I don't understand the note under example 3. Make it clearer. <span style="color:#808080;">{Sylvie, June 19}</span></li><br />
</ul><br />
<br />
==[http://www.w3.org/WAI/EO/Drafts/app-notes/images/complex Complex images page]==<br />
<br />
<ul><br />
<li style="padding-bottom:1em">comment <span style="color:#808080;">{name}</span></li><br />
<li style="padding-bottom:1em">Very often a graph, diagram or image convey an objective of the exposition. This objective and how the figure illustrates this objective should be stated explicitly. Example: The Gauss Flux Theorem justifies the visualization of lines of force for electromagnetic fields. This visual concept must be explained in words, even though a sighted person can perceive it at a glance. <span style="color:#808080;">{Wayne}</span></li><br />
<li style="padding-bottom:1em">Thank you for including the parenthetical note about MathML! Need to close the parens. <span style="color:#808080;"> { Paul, 7/18 }</span><br />
<br><strong>Reply: </strong>Thanks for spotting it, now fixed.<span style="color:#808080;"> { Bim, July 19 }</span><br />
</li><br />
<li style="padding-bottom:1em">Example 3, suggest changing the dummy URL to something like longdesc="2012-profits-chart-long-description.html" to make it clear that the longdesc alt attribute can point to any URL, and does not literally have to be longdesc.html<span style="color:#808080;"> { Paul, 7/18 }</span><br />
<br><strong>Reply: </strong>Ah, I didn't think of that ... I've changed the filename now ... it is a real file. <span style="color:#808080;"> { Bim, July 19 }</span></li><br />
<li style="padding-bottom:1em">:) Missing comma after "In this case" <span style="color:#808080;">{Vicki 19/7}</span></li><br />
<br />
<li style="padding-bottom:1em">:) Missing "s" at last word of last sentence in first paragraph "descriptions" <span style="color:#808080;">{Vicki 19/7}</span></li><br />
<li style="padding-bottom:1em">:) Not 100% sure but should there be an "s" added to "The types of image" on "image"? <span style="color:#808080;">{Vicki 19/7}</span></li><br />
<li style="padding-bottom:1em">Example 1: I would remove the comma in the first sentence after "the text alternative,".</li> <br />
<li style="padding-bottom:1em">Space between theResults and after below"identifies <span style="color:#808080;">{Vicki 19/7}</span></li><br />
<li style="padding-bottom:1em">Example 3: missing comm "In this example" add comma<span style="color:#808080;">{Vicki 19/7}</span></li><br />
</ul><br />
<br />
==[http://www.w3.org/WAI/EO/Drafts/app-notes/images/imagemap Image maps page]==<br />
<br />
<ul><br />
<li style="padding-bottom:1em">comment <span style="color:#808080;">{name}</span></li><br />
<li style="padding-bottom:1em">;) Missing comma, second sentence: In this case, comma <span style="color:#808080;">{Vicki 19/7}</span></li><br />
<li style="padding-bottom:1em">Example 1: Minor edit. Remove the comma after "link" in second sentence. Add closing brackeet. <span style="color:#808080;">{Vicki 19/7}</span></li><br />
</ul><br />
<br />
==[http://www.w3.org/WAI/EO/Drafts/app-notes/images/decorative Decorative images page]==<br />
<br />
<ul><br />
<li style="padding-bottom:1em">comment <span style="color:#808080;">{name}</span></li><br />
<li style="padding-bottom:1em">Looks good, ready to publish in my opinion. <span style="color:#808080;"> { Paul, 7/18 }</span></li><br />
<li style="padding-bottom:1em">Except for the missing comma in the second sentence :), after "In these cases", excellent, also ready to publish in my opinion. <span style="color:#808080;"> { Vicki, 7/19 }</span></li><br />
</ul><br />
<br />
==[http://www.w3.org/WAI/EO/Drafts/app-notes/images/faq Tips and FAQ page]==<br />
<br />
<ul><br />
<li style="padding-bottom:1em">comment <span style="color:#808080;">{name}</span></li><br />
</ul><br />
<br />
__NOINDEX__</div>Wdickhttps://www.w3.org/WAI/EO/wiki/index.php?title=Tutorial_-_Images&diff=6146Tutorial - Images2013-07-19T11:33:24Z<p>Wdick: /* Images tutorial overall */</p>
<hr />
<div>Nav: [[Main Page|EOWG wiki main page]] > [[Tutorials|Tutorials main page]]<br />
<br />
==Images tutorial overall==<br />
<br />
''NOTE: If you have comments that apply to all tutorials &mdash; e.g., on the navigation design &mdash; please put them in the main [[Tutorials]] wiki page.''<br />
<br />
<ul><br />
<li style="padding-bottom:1em">comment <span style="color:#808080;">{name}</span></li><br />
<li style="padding-bottom:1em"><br />
This is a remarkable section, from overview to coding details. It all follows, and develops a good introductory course on accessibility. It is not exhaustive and it is not a dictionary of techniques, but one can read an individual topic. The overview page gives a clear description of what one can expect if one is looking to read the entire topic.<br />
<span style="color:#808080;">{Wayne}</span></li><br />
</ul><br />
<br />
==[http://www.w3.org/WAI/EO/Drafts/app-notes/images/ Image concepts page]==<br />
<br />
<ul><br />
<li style="padding-bottom:1em">comment <span style="color:#808080;">{name}</span></li><br />
<li style="padding-bottom:1em">LOVE this page! Comprehensive overview that I'm going to point people to, as the question comes up frequently with stakeholders of all stripes in my organization. Especially like the benefits section, it's nice to see use cases other than screen readers. With the exception of a couple very minor nit-picky things, I think it's ready to publish.<span style="color:#808080;"> { Paul 7/18 }</span></li><br />
<li>Also really like this new look. It's all in one bundle: clear, concise at the top of the page with pointers to more detailed info, improved navigation, pleasant design. Very nice - bravo!<span style="color:#808080;"> { Vicki 19/7 }</span></li><br />
<li style="padding-bottom:1em">Minor edit under "Why is this important?" I think, in the first sentence, "illustration" should be plural <span style="color:#808080;">{Vicki 19/7}</span></li><br />
<li style="padding-bottom:1em">I agree with previous comments, that this page is clear. I only have a reading difficulty of following sentence in the bullet about image maps. I had to read it several times to understand the content. <blockquote>"Image maps: Used to provide multiple selectable regions within an image - text alternative for the image should provide a context while the text alternatives for the selectable <area> elements need to describe the purpose or destination of the links;"</blockquote> <span style="color:#808080;">{Sylvie, 19 June}</span></li><br />
</ul><br />
<br />
==[http://www.w3.org/WAI/EO/Drafts/app-notes/images/functional Functional images page]==<br />
<br />
<ul><br />
<li style="padding-bottom:1em">comment <span style="color:#808080;">{name}</span></li><br />
<li style="padding-bottom:1em">The very first sentence, although proper, reads awkwardly to me. <span style="color:#808080;"> { Paul, 7/18 }</span></li><br />
<li>Suggestion for less awkward first sentence:<br />
"Functional images are images which perform an action, e.g. a button, an icon to open a Word document, a shopping cart.<span style="color:#808080;"> { Vicki, 19/7 }</span></li><br />
<br />
<li style="padding-bottom:1em">Second sentence needs a comma after "initiated". <span style="color:#808080;"> { Paul, 7/18 }</span></li><br />
<li style="padding-bottom:1em">Suggested minor edit to second sentence:<br />
<br />
"In this case, the text alternative for the image ...." (replacing "an image" by "the image") <span style="color:#808080;"> { Vicki, 7/19 }</span></li><br />
<li style="padding-bottom:1em">Suggested minor edit to second sentence:<br />
"that will be initiated, rather than a description of the image." (replacing "to describe the image itself". Simpler style.)<br />
<span style="color:#808080;"> { Vicki, 7/19 }</span></li><br />
<li style="padding-bottom:1em">Printer icon image missing from Example 2 (I know, it's just a placeholder) <span style="color:#808080;"> { Paul, 7/18 }</span></li><br />
<li style="padding-bottom:1em">Does it make sense to hide the code snippets with "show more" links? They're in the right places and they're not complicated, but they do break the text flow and might be distracting for readers who are not coders. <span style="color:#808080;"> { Paul, 7/18 }</span></li><br />
<br />
<li>Like as is <span style="color:#808080;"> { Vicki, 7/19 }</span></li><br />
</ul><br />
<br />
==[http://www.w3.org/WAI/EO/Drafts/app-notes/images/textual Images of text page]==<br />
<br />
<ul><br />
<li style="padding-bottom:1em">comment <span style="color:#808080;">{name}</span></li><br />
<li style="padding-bottom:1em">Suggestion for first sentence:<br />
Images of text are images which display readable text.<span style="color:#808080;">{Vicki 19/7}</span></li><br />
<li style="padding-bottom:1em">Missing comma after "In this case," <span style="color:#808080;">{Vicki 19/7}</span></li><br />
<li style="padding-bottom:1em">Example 1, second sentence should probably be split into two sentences. Maybe also mention what is meant by NOT describing the decorative effects used in the Citylights example image (i.e. - thin greenish script). <span style="color:#808080;">{ Paul, 7/18 }</span></li><br />
<li style="padding-bottom:1em">Suggestion for second sentence under Example 2:<br />
Instead of "It has the text alternative...", use "The text alternative is "Contact us". Simple style. <span style="color:#808080;">{Vicki 19/7}</span></li><br />
<li style="padding-bottom:1em">Structure question: the note about best practice is structured with an h2. Would it be better to tag it with a P? Otherwise, no comments on this page. <span style="color:#808080;">{Sylvie, June 19}</span></li><br />
</ul><br />
<br />
==[http://www.w3.org/WAI/EO/Drafts/app-notes/images/inform Informative images page]==<br />
<br />
<ul><br />
<li style="padding-bottom:1em">comment <span style="color:#808080;">{name}</span></li><br />
<li style="padding-bottom:1em">Great example of when to use null alt attribute. This page is ready to publish, in my opinion. <span style="color:#808080;"> { Paul, 7/18 }</span></li><br />
<li style="padding-bottom:1em">Missing capital on "i" at second sentence. <span style="color:#808080;">{Vicki 19/7}</span></li><br />
<li style="padding-bottom:1em">Missing comma in second sentence after "In this case" <span style="color:#808080;">{Vicki 19/7}</span></li><br />
<li style="padding-bottom:1em">Example 1: I understand the example. But for sighted readers who wouldn't know the breed, how do they get that info :) <span style="color:#808080;">{Vicki 19/7}</span></li><br />
<li style="padding-bottom:1em">Example 2: <br />
Minor edit: after "Note:" capital "T" on "this" <span style="color:#808080;">{Vicki 19/7}</span><br />
<li style="padding-bottom:1em">Unsure/uncomfortable about the explanation given in "Note" - it makes me think twice. Can it be simpler? E.g. "This technique is the most accessible. The image in this case can be considered as decorative. All the required information (in this case, the breed of the dog)is available within the text. Therefore, the user does not need to rely on the image to fully understand the text." Still a bit clumsy.</li><br />
<li style="padding-bottom:1em">Suggestion Example 3: <br />
Note: I would provide an example to illustrate this case since I immediately looked at Example 2 for how PDF is written as part of the text since the Note states "As shown in example 2".<span style="color:#808080;">{Vicki 19/7}</span></li><br />
<li style="padding-bottom:1em">Minor edit: after "Note:" capital "T" on "this" <span style="color:#808080;">{Vicki 19/7}</span></li><br />
<li style="padding-bottom:1em">I don't understand the note under example 3. Make it clearer. <span style="color:#808080;">{Sylvie, June 19}</span></li><br />
</ul><br />
<br />
==[http://www.w3.org/WAI/EO/Drafts/app-notes/images/complex Complex images page]==<br />
<br />
<ul><br />
<li style="padding-bottom:1em">comment <span style="color:#808080;">{name}</span></li><br />
<li style="padding-bottom:1em">Thank you for including the parenthetical note about MathML! Need to close the parens. <span style="color:#808080;"> { Paul, 7/18 }</span><br />
<br><strong>Reply: </strong>Thanks for spotting it, now fixed.<span style="color:#808080;"> { Bim, July 19 }</span><br />
</li><br />
<li style="padding-bottom:1em">Example 3, suggest changing the dummy URL to something like longdesc="2012-profits-chart-long-description.html" to make it clear that the longdesc alt attribute can point to any URL, and does not literally have to be longdesc.html<span style="color:#808080;"> { Paul, 7/18 }</span><br />
<br><strong>Reply: </strong>Ah, I didn't think of that ... I've changed the filename now ... it is a real file. <span style="color:#808080;"> { Bim, July 19 }</span></li><br />
<li style="padding-bottom:1em">:) Missing comma after "In this case" <span style="color:#808080;">{Vicki 19/7}</span></li><br />
<br />
<li style="padding-bottom:1em">:) Missing "s" at last word of last sentence in first paragraph "descriptions" <span style="color:#808080;">{Vicki 19/7}</span></li><br />
<li style="padding-bottom:1em">:) Not 100% sure but should there be an "s" added to "The types of image" on "image"? <span style="color:#808080;">{Vicki 19/7}</span></li><br />
<li style="padding-bottom:1em">Example 1: I would remove the comma in the first sentence after "the text alternative,".</li> <br />
<li style="padding-bottom:1em">Space between theResults and after below"identifies <span style="color:#808080;">{Vicki 19/7}</span></li><br />
<li style="padding-bottom:1em">Example 3: missing comm "In this example" add comma<span style="color:#808080;">{Vicki 19/7}</span></li><br />
</ul><br />
<br />
==[http://www.w3.org/WAI/EO/Drafts/app-notes/images/imagemap Image maps page]==<br />
<br />
<ul><br />
<li style="padding-bottom:1em">comment <span style="color:#808080;">{name}</span></li><br />
<li style="padding-bottom:1em">;) Missing comma, second sentence: In this case, comma <span style="color:#808080;">{Vicki 19/7}</span></li><br />
<li style="padding-bottom:1em">Example 1: Minor edit. Remove the comma after "link" in second sentence. Add closing brackeet. <span style="color:#808080;">{Vicki 19/7}</span></li><br />
</ul><br />
<br />
==[http://www.w3.org/WAI/EO/Drafts/app-notes/images/decorative Decorative images page]==<br />
<br />
<ul><br />
<li style="padding-bottom:1em">comment <span style="color:#808080;">{name}</span></li><br />
<li style="padding-bottom:1em">Looks good, ready to publish in my opinion. <span style="color:#808080;"> { Paul, 7/18 }</span></li><br />
<li style="padding-bottom:1em">Except for the missing comma in the second sentence :), after "In these cases", excellent, also ready to publish in my opinion. <span style="color:#808080;"> { Vicki, 7/19 }</span></li><br />
</ul><br />
<br />
==[http://www.w3.org/WAI/EO/Drafts/app-notes/images/faq Tips and FAQ page]==<br />
<br />
<ul><br />
<li style="padding-bottom:1em">comment <span style="color:#808080;">{name}</span></li><br />
</ul><br />
<br />
__NOINDEX__</div>Wdickhttps://www.w3.org/WAI/EO/wiki/index.php?title=UAAG_review&diff=5765UAAG review2013-06-16T20:14:42Z<p>Wdick: /* Relationship with WCAG 2.0 */</p>
<hr />
<div>Nav: [[Main Page|EOWG wiki main page]]<br />
<br />
__TOC__<br />
<br />
Drafts:<br />
* [http://www.w3.org/TR/UAAG20/ UAAG 2.0]<br />
* [http://www.w3.org/TR/Implementing-UAAG20/ Implementing UAAG 2.0]<br />
* (also, fyi [http://www.w3.org/WAI/mobile/UAAGexamples Mobile Accessibility Examples from UAAG])<br />
<br />
<br />
==UAAG==<br />
<br />
===Overall===<br />
<ul><br />
<li style="padding-bottom:0.5em;">comment <span style="color:#808080;">{name}</span></li><br />
<li style="padding-bottom:0.5em;">Not sure where to add this comment that applies to UAAG and Implmenting: I find the summaries of each guideline really useful. <span style="color:#808080;">{Sylvie, 14 June}</span></li><br />
<li style="padding-bottom:0.5em;">Carefully consider what information should be in UAAG proper, and what should be in Implementing UAAG. Once UAAG is done, it cannot be changed; however, Implementing can be updated. Therefore, it might be wise to move some of the information from the Into of UAAG to Implementing. <span style="color:#808080;">{Shawn, 3 June}</span></li><br />
<li style="padding-bottom:0.5em;"><br />
Would the sections on Relationships to ATAG and WCAG be better in the Implementing document? Also, is there a reason why the "Guidelines" heading and each of the "Principles" headings are all at heading level H2?<br />
<span style="color:#808080;">{Bim 14 June}</span></li><br />
</ul><br />
<br />
===Abstract===<br />
[http://www.w3.org/TR/UAAG20/#abstract Abstract]<br />
<ul><br />
<li style="padding-bottom:0.5em;">comment <span style="color:#808080;">{name}</span></li><br />
<li style="padding-bottom:0.5em;">Second sentence in abstract: <br />"User agents include browsers and other types of software that retrieve and render Web content."<br /> It may be useful to indicate what "other types of software" is meant in addition to browsers.<span style="color:#808080;">{Sylvie, June 13} </span></li><br />
<li style="padding-bottom:0.5em;">Second paragraph, second sentence: "technologies for braille rendering) will be essential to ensuring Web access for some users with disabilities." <br />Perhaps it should be made clearer that the responsibility for Braille rendering will need to remain a function of the assistive technologies. .<span style="color:#808080;">{Bim, June 14} </span></li><br />
<li style="padding-bottom:0.5em;">Third paragraph, has a couple of errors in the acronyms: "the W3C" has "W3C" expanded to "the World Wide Web Consortium", so the word "the" is in both plain and title text (this happens elsewhere on the page too); "Web Accessibility Initiative" is written in full but its acronym is also expanded (incorrectly), so the output is "Web Accessibility Initiative the Web Access Initiative". <span style="color:#808080;">{Bim, June 14} </span></li><br />
</ul><br />
<br />
===Introduction===<br />
<ul><br />
<li style="padding-bottom:0.5em;">comment <span style="color:#808080;">{name}</span></li><br />
<br />
</ul><br />
<br />
===Overview===<br />
<ul><br />
<li style="padding-bottom:0.5em;">comment <span style="color:#808080;">{name}</span></li><br />
<li style="padding-bottom:0.5em;">May be the Working Group can bring more clarifications on the second sentence of follwoing paragraph, give an example of features concerned:<br />"Some UAAG 2.0 requirements may have security implications, such as communicating through Application Program Interfaces (API), or allowing programmatic read and write access to content and user interface control. UAAG 2.0 assumes that features required by UAAG 2.0 will be built on top of an underlying security architecture. " <span style="color:#808080;">{Sylvie, June 13} </span></li><br />
</ul><br />
<br />
===UAAG 2.0 Layers of Guidance===<br />
<ul><br />
<li style="padding-bottom:0.5em;"><br />
The Principles bullet should read, "At the top layer,"... Omitting the word layer caused me to trip while reading<br />
Principles 4 and 5 are new and need more than just naming. The meaning of <em>facilitate programmatic access</em> and comply with <em>specifications and conventions</em> is not clear, and a brief description does not appear for a very long time. Please give each a brief description when they first appear.<br />
<span style="color:#808080;">{Wayne}</span><br />
</li><br />
<li style="padding-bottom:0.5em;"><br />
Agree with Wayne, this isn't easy to read. Perhaps a nested list would help too because separation (and therefore an understanding) of principles 4 and 5 is complicated by the need to use the word "and" twice so closely together. On first reading this sounded like one principle to me. <br />
<span style="color:#808080;">{Bim 14 June}</span><br />
</li><br />
<li style="padding-bottom:0.5em;">The three different levels of conformance are not obvious to read, in particular level A. The way it is written, it makes believe that there is a highest level whereas the highest level is called A. therefore, it may be helpful to write that the lowest level is called A and the highest is called AAA.<br /> Text concerned: "Three levels of conformance meet the needs of different groups and different situations: A (lowest), AA, and AAA (highest). <span style="color:#808080;">{Sylvie June 13}</span></li><br />
</ul><br />
<br />
===UAAG 2.0 Supporting Documents===<br />
<ul><br />
<li style="padding-bottom:0.5em;">comment <span style="color:#808080;">{name}</span></li><br />
<br />
</ul><br />
<br />
===Components of Web Accessibility===<br />
<ul><br />
<li style="padding-bottom:0.5em;">comment <span style="color:#808080;">{name}</span></li><br />
<li style="padding-bottom:0.5em;"><br />
As this section directly references ATAG and WCAG, perhaps it should be followed by the sections that explain the relationship between UAAG and the other two sets of guidelines. Perhaps even move the "Relationship" sections into the Implementing document and link to them? <br />
<span style="color:#808080;">{Bim 14 June}</span></li><br />
<br />
</ul><br />
<br />
===Levels of Conformance===<br />
<ul><br />
<li style="padding-bottom:0.5em;">comment <span style="color:#808080;">{name}</span></li><br />
<li style="padding-bottom:0.5em;">I don't understand one of the "Factors that were considered in the process of determining the level to a success criterion", fourth bullet: <br /> "implementation difficulty – ranging from deterministic to inferential" <span style="color:#808080;">{Sylvie, June 13}</span></li><br />
<li style="padding-bottom:0.5em;"><br />
Agree with Sylvie, plainer terms would make the meaning clearer and easier to translate. <br />
<span style="color:#808080;">{Bim 14 June}</span></li><br />
<br />
</ul><br />
<br />
===Definition of User Agent===<br />
<ul><br />
<li style="padding-bottom:0.5em;"><br />
This appears to be identical to the "Definition of a User Agent" in the Implementing document. Could it be tersified in one or the other? <br />
<span style="color:#808080;">{Bim 14 June}</span></li><br />
<br />
<p>I had trouble with the What Qualifies section. The word order tends to make it more confusing than it needs to be. I understand that we need to include procedural as well as declarative languages, but is there any other kind of programming language. Are you making your point? Are you trying to say no programming language is excluded as a basis for generating user interface? {Wayne 16 June}</p><br />
<div class="techs-only"><br />
My revision.<br />
<h3>What qualifies as a User Agent?</h3><br />
<p>These guidelines employ the following tests to determine if software <br />
qualifies as a user agent. UAAG 2.0 divides potential user agents into</p><br />
<ul><br />
<li>platform-based application</li><br />
<li>extension or plug-in</li><br />
<li>web-based application </li><br />
</ul><br />
<p>If the following three conditions are met, then a platform-based application is a user agent:</p><br />
<ol><br />
<li>It is a standalone application, and</li><br />
<li>It interprets any W3C-specified language, and</li><br />
<li>It provides a user interface or interprets a procedural <br />
or declarative language that may be used to provide a user interface</li><br />
</ol><br />
<p><strong>Example Qual-1: </strong>A standard browser.<br><br />
</p><br />
<br />
<p>If the following two conditions are met then an extension or plug-in is a user agent:</p><br />
<ol><br />
<li>It is launched by, or extends the functionality of a platform-based application, and </li><br />
<li>Post-launch user interaction is included in, or is <br />
within the bounds (run time scope) of the platform-based application</li><br />
</ol><br />
<strong>Example Qual-2: </strong>Any media player or browser enhancing extension.<br><br />
<br><br />
If the following three conditions are met then web-based application is a user agent:<br />
<ol><li>The user interface is embedded in an application that renders web content, and</li><br />
<li>The user interface is generated by a procedural or declarative language; and</li><br />
<li>Either user interaction does <br />
not modify the Document Object Model of its containing document or it is controlled by a procedural or declarative language.</li><br />
</ol><br />
<p><strong>Example Qual-3:</strong> Don't have one.<br><br />
</p><br />
<br />
<hr><br />
<!-- techs-only --></div><br />
<br />
<br />
</ul><br />
<br />
===Modality Independence Principle===<br />
<ul><br />
<li style="padding-bottom:0.5em;">comment <span style="color:#808080;">{name}</span></li><br />
<br />
</ul><br />
<br />
[[Link title]]===Relationship with WCAG 2.0===<br />
<ul><br />
<li style="padding-bottom:0.5em;">comment <span style="color:#808080;"><br />
{}</span></li><br />
<li style="padding-bottom:0.5em;">comment <span style="color:#808080;"><br />
I think the confusion in this section springs from lack of examples, and this also springs from the lack of example of a web-app UA in implementing. The distinction between a general web app and a web app UA is not defined clearly, and maybe the concept is not well defined. That is, perhaps a web-app behaves like a UA sometimes and not at others<br />
{Wayne, 16 June}</span></li><br />
<li style="padding-bottom:0.5em;">The relationship between UAAG and WCAG is not very clear: when the application is considered to be a user agent and when not. As WCAG applies in both cases, why is it mentionned here? <span style="color:#808080;">{Sylvie, June 13} </span></li><br />
</ul><br />
<br />
===Relationship with ATAG 2.0===<br />
<ul><br />
<li style="padding-bottom:0.5em;">comment <span style="color:#808080;">{name}</span></li><br />
<br />
</ul><br />
<br />
<br />
==Implementing UAAG==<br />
<br />
===Overall (Implementing)===<br />
<ul><br />
<li style="padding-bottom:0.5em;">comment <span style="color:#808080;">{name}</span></li><br />
<li style="padding-bottom:0.5em;">Would it be possible to use structuring elements such as H5s to indicate sections like Intent of SC, Examples and resources? While comparing to the structure of [http://www.w3.org/WAI/GL/2011/WD-UNDERSTANDING-WCAG20-20110621/complete.html#contents Understanding WCAG 2.0], is there a W3C graphical design that could make each guideline document look similar? <span style="color:#808080;">{Sylvie, 14 June}</span></li><br />
<li style="padding-bottom:0.5em;"> Examples: change some of the names to be more diverse <span style="color:#808080;">{Shawn, 3 June}</span></li><br />
<br />
<li style="padding-bottom:0.5em;"> CSS to add more space between chunks of text, especially more space above new SC. Also, increase leading throughout. <span style="color:#808080;">{Shawn, 3 June}</span></li><br />
<br />
<li style="padding-bottom:0.5em;"> change "Return to Guideline" to @@ <span style="color:#808080;">{Shawn, 3 June}</span></li><br />
<br />
</ul><br />
<br />
===Introduction (Implementing)===<br />
<ul><br />
<li style="padding-bottom:0.5em;">comment <span style="color:#808080;">{name}</span></li><br />
<br />
</ul><br />
<br />
===Definition of User Agent (Implementing)===<br />
<ul><br />
<li style="padding-bottom:0.5em;">comment <span style="color:#808080;">{name}</span></li><br />
<li style="padding-bottom:0.5em;"><br />
Third paragraph: the link to "What Qualifies as a User Agent" is followed by the name of the current document in brackets, isn't this redundant? <br />
<span style="color:#808080;">{Bim 14 June}</span></li><br />
<br />
</ul><br />
<br />
===Implementing Guideline 1.1 - Provide access to alternative content.===<br />
<ul><br />
<li style="padding-bottom:0.5em;">comment <span style="color:#808080;">{name}</span></li><br />
<li style="padding-bottom:0.5em;">Several occurences in this guideline and may be elsewhere through the doc: in Intent of success criterion X, the document says that non text content is unusable, or <em>"painful"</em>. I have never seen this term elsewhere in W3C docs and wonder if it is appropriate. <br />Another example in intent of SC 1.2: <blockquote>"Some users with visual disabilities may wish to hide images in order to avoid those that are painful (such as those with high contrast)."</blockquote> <span style="color:#808080;">{Sylvie, 14 June}</span></li><br />
<li style="padding-bottom:0.5em;">In 1.1.3 Configurable Alternative Content Defaults, first example: <blockquote>"Sally is blind. In the browser's preferences dialog box, Sally specifies that she wants alt text displayed in place of images, and that the document should reflow to allow the entire alt text to be displayed rather than truncated."</blockquote> As screen readers retrieve the alt text content is it necessary for a blind user to request that the browser displays alt text rather than images? May be the example should be rewritten to reflect real use of alt text by blind users? <span style="color:#808080;">{Sylvie, 14 June}</span></li><br />
<li style="padding-bottom:0.5em;">In Examples of Success Criterion 1.1.6, the disability of the users is not always specified, (e.g. Maximilian or Tom. <span style="color:#808080;">{Sylvie, 14 June}</span></li><br />
</ul><br />
===Implementing Guideline 1.2 - Repair missing content.===<br />
<ul><br />
<li style="padding-bottom:0.5em;">comment <span style="color:#808080;">{name}</span></li><br />
<li style="padding-bottom:0.5em;">Examples of Success Criterion 1.2.2, first example:<br />The example talks about Franck who is called George in the next sentence. ^Try to check that the names remain the same in each example, in order to avoid confusing the reader. <span style="color:#808080;">{Sylvie, 14 June}</span></li><br />
</ul><br />
===Implementing Guideline 1.3 - Provide highlighting for selection, keyboard focus, enabled elements, visited links.===<br />
<ul><br />
<li style="padding-bottom:0.5em;">comment <span style="color:#808080;">{name}</span></li><br />
<li style="padding-bottom:0.5em;">SC 1.3.1 has three notes. I wonder if it is worth numbering them in note 1, note 2 ... or may be it does not make sense? <span style="color:#808080;">{Sylvie, 14 June}</span></li><br />
</ul><br />
===Implementing Guideline 1.4 - Provide text configuration.===<br />
<ul><br />
<li style="padding-bottom:0.5em;">comment <span style="color:#808080;">{name}</span></li><br />
<li style="padding-bottom:0.5em;">Typo: not sure whether we should indicate them in EOWG ^comments: Summary contains one word "<em>the</em>" that should not be there: <blockquote>"The user can control text font, color, and size (1.4.1), including whether all text should be the shown the same size (1.4.2).</blockquote><span style="color:#808080;">{Sylvie, 14 June}</span></li><br />
</ul><br />
===Implementing Guideline 1.7 - Enable Configuration of User Stylesheets.===<br />
<ul><br />
<li style="padding-bottom:0.5em;">comment <span style="color:#808080;">{name}</span></li><br />
<li style="padding-bottom:0.5em;">I wonder if it would be useful to explain acronyms such as in last "Examples of Success Criterion 1.7.1, 1.7.2 & 1.7.3". <br /><blockquote>"Mattias has ADHD and finds text easiest to read text·...</blockquote>explain what is ADHD? Is it clear to any reader? <span style="color:#808080;">{Sylvie, 14 June}</span></li><br />
</ul></div>Wdickhttps://www.w3.org/WAI/EO/wiki/index.php?title=UAAG_review&diff=5764UAAG review2013-06-16T19:04:05Z<p>Wdick: /* Definition of User Agent */</p>
<hr />
<div>Nav: [[Main Page|EOWG wiki main page]]<br />
<br />
__TOC__<br />
<br />
Drafts:<br />
* [http://www.w3.org/TR/UAAG20/ UAAG 2.0]<br />
* [http://www.w3.org/TR/Implementing-UAAG20/ Implementing UAAG 2.0]<br />
* (also, fyi [http://www.w3.org/WAI/mobile/UAAGexamples Mobile Accessibility Examples from UAAG])<br />
<br />
<br />
==UAAG==<br />
<br />
===Overall===<br />
<ul><br />
<li style="padding-bottom:0.5em;">comment <span style="color:#808080;">{name}</span></li><br />
<li style="padding-bottom:0.5em;">Not sure where to add this comment that applies to UAAG and Implmenting: I find the summaries of each guideline really useful. <span style="color:#808080;">{Sylvie, 14 June}</span></li><br />
<li style="padding-bottom:0.5em;">Carefully consider what information should be in UAAG proper, and what should be in Implementing UAAG. Once UAAG is done, it cannot be changed; however, Implementing can be updated. Therefore, it might be wise to move some of the information from the Into of UAAG to Implementing. <span style="color:#808080;">{Shawn, 3 June}</span></li><br />
<li style="padding-bottom:0.5em;"><br />
Would the sections on Relationships to ATAG and WCAG be better in the Implementing document? Also, is there a reason why the "Guidelines" heading and each of the "Principles" headings are all at heading level H2?<br />
<span style="color:#808080;">{Bim 14 June}</span></li><br />
</ul><br />
<br />
===Abstract===<br />
[http://www.w3.org/TR/UAAG20/#abstract Abstract]<br />
<ul><br />
<li style="padding-bottom:0.5em;">comment <span style="color:#808080;">{name}</span></li><br />
<li style="padding-bottom:0.5em;">Second sentence in abstract: <br />"User agents include browsers and other types of software that retrieve and render Web content."<br /> It may be useful to indicate what "other types of software" is meant in addition to browsers.<span style="color:#808080;">{Sylvie, June 13} </span></li><br />
<li style="padding-bottom:0.5em;">Second paragraph, second sentence: "technologies for braille rendering) will be essential to ensuring Web access for some users with disabilities." <br />Perhaps it should be made clearer that the responsibility for Braille rendering will need to remain a function of the assistive technologies. .<span style="color:#808080;">{Bim, June 14} </span></li><br />
<li style="padding-bottom:0.5em;">Third paragraph, has a couple of errors in the acronyms: "the W3C" has "W3C" expanded to "the World Wide Web Consortium", so the word "the" is in both plain and title text (this happens elsewhere on the page too); "Web Accessibility Initiative" is written in full but its acronym is also expanded (incorrectly), so the output is "Web Accessibility Initiative the Web Access Initiative". <span style="color:#808080;">{Bim, June 14} </span></li><br />
</ul><br />
<br />
===Introduction===<br />
<ul><br />
<li style="padding-bottom:0.5em;">comment <span style="color:#808080;">{name}</span></li><br />
<br />
</ul><br />
<br />
===Overview===<br />
<ul><br />
<li style="padding-bottom:0.5em;">comment <span style="color:#808080;">{name}</span></li><br />
<li style="padding-bottom:0.5em;">May be the Working Group can bring more clarifications on the second sentence of follwoing paragraph, give an example of features concerned:<br />"Some UAAG 2.0 requirements may have security implications, such as communicating through Application Program Interfaces (API), or allowing programmatic read and write access to content and user interface control. UAAG 2.0 assumes that features required by UAAG 2.0 will be built on top of an underlying security architecture. " <span style="color:#808080;">{Sylvie, June 13} </span></li><br />
</ul><br />
<br />
===UAAG 2.0 Layers of Guidance===<br />
<ul><br />
<li style="padding-bottom:0.5em;"><br />
The Principles bullet should read, "At the top layer,"... Omitting the word layer caused me to trip while reading<br />
Principles 4 and 5 are new and need more than just naming. The meaning of <em>facilitate programmatic access</em> and comply with <em>specifications and conventions</em> is not clear, and a brief description does not appear for a very long time. Please give each a brief description when they first appear.<br />
<span style="color:#808080;">{Wayne}</span><br />
</li><br />
<li style="padding-bottom:0.5em;"><br />
Agree with Wayne, this isn't easy to read. Perhaps a nested list would help too because separation (and therefore an understanding) of principles 4 and 5 is complicated by the need to use the word "and" twice so closely together. On first reading this sounded like one principle to me. <br />
<span style="color:#808080;">{Bim 14 June}</span><br />
</li><br />
<li style="padding-bottom:0.5em;">The three different levels of conformance are not obvious to read, in particular level A. The way it is written, it makes believe that there is a highest level whereas the highest level is called A. therefore, it may be helpful to write that the lowest level is called A and the highest is called AAA.<br /> Text concerned: "Three levels of conformance meet the needs of different groups and different situations: A (lowest), AA, and AAA (highest). <span style="color:#808080;">{Sylvie June 13}</span></li><br />
</ul><br />
<br />
===UAAG 2.0 Supporting Documents===<br />
<ul><br />
<li style="padding-bottom:0.5em;">comment <span style="color:#808080;">{name}</span></li><br />
<br />
</ul><br />
<br />
===Components of Web Accessibility===<br />
<ul><br />
<li style="padding-bottom:0.5em;">comment <span style="color:#808080;">{name}</span></li><br />
<li style="padding-bottom:0.5em;"><br />
As this section directly references ATAG and WCAG, perhaps it should be followed by the sections that explain the relationship between UAAG and the other two sets of guidelines. Perhaps even move the "Relationship" sections into the Implementing document and link to them? <br />
<span style="color:#808080;">{Bim 14 June}</span></li><br />
<br />
</ul><br />
<br />
===Levels of Conformance===<br />
<ul><br />
<li style="padding-bottom:0.5em;">comment <span style="color:#808080;">{name}</span></li><br />
<li style="padding-bottom:0.5em;">I don't understand one of the "Factors that were considered in the process of determining the level to a success criterion", fourth bullet: <br /> "implementation difficulty – ranging from deterministic to inferential" <span style="color:#808080;">{Sylvie, June 13}</span></li><br />
<li style="padding-bottom:0.5em;"><br />
Agree with Sylvie, plainer terms would make the meaning clearer and easier to translate. <br />
<span style="color:#808080;">{Bim 14 June}</span></li><br />
<br />
</ul><br />
<br />
===Definition of User Agent===<br />
<ul><br />
<li style="padding-bottom:0.5em;"><br />
This appears to be identical to the "Definition of a User Agent" in the Implementing document. Could it be tersified in one or the other? <br />
<span style="color:#808080;">{Bim 14 June}</span></li><br />
<br />
<p>I had trouble with the What Qualifies section. The word order tends to make it more confusing than it needs to be. I understand that we need to include procedural as well as declarative languages, but is there any other kind of programming language. Are you making your point? Are you trying to say no programming language is excluded as a basis for generating user interface? {Wayne 16 June}</p><br />
<div class="techs-only"><br />
My revision.<br />
<h3>What qualifies as a User Agent?</h3><br />
<p>These guidelines employ the following tests to determine if software <br />
qualifies as a user agent. UAAG 2.0 divides potential user agents into</p><br />
<ul><br />
<li>platform-based application</li><br />
<li>extension or plug-in</li><br />
<li>web-based application </li><br />
</ul><br />
<p>If the following three conditions are met, then a platform-based application is a user agent:</p><br />
<ol><br />
<li>It is a standalone application, and</li><br />
<li>It interprets any W3C-specified language, and</li><br />
<li>It provides a user interface or interprets a procedural <br />
or declarative language that may be used to provide a user interface</li><br />
</ol><br />
<p><strong>Example Qual-1: </strong>A standard browser.<br><br />
</p><br />
<br />
<p>If the following two conditions are met then an extension or plug-in is a user agent:</p><br />
<ol><br />
<li>It is launched by, or extends the functionality of a platform-based application, and </li><br />
<li>Post-launch user interaction is included in, or is <br />
within the bounds (run time scope) of the platform-based application</li><br />
</ol><br />
<strong>Example Qual-2: </strong>Any media player or browser enhancing extension.<br><br />
<br><br />
If the following three conditions are met then web-based application is a user agent:<br />
<ol><li>The user interface is embedded in an application that renders web content, and</li><br />
<li>The user interface is generated by a procedural or declarative language; and</li><br />
<li>Either user interaction does <br />
not modify the Document Object Model of its containing document or it is controlled by a procedural or declarative language.</li><br />
</ol><br />
<p><strong>Example Qual-3:</strong> Don't have one.<br><br />
</p><br />
<br />
<hr><br />
<!-- techs-only --></div><br />
<br />
<br />
</ul><br />
<br />
===Modality Independence Principle===<br />
<ul><br />
<li style="padding-bottom:0.5em;">comment <span style="color:#808080;">{name}</span></li><br />
<br />
</ul><br />
<br />
===Relationship with WCAG 2.0===<br />
<ul><br />
<li style="padding-bottom:0.5em;">comment <span style="color:#808080;">{name}</span></li><br />
<li style="padding-bottom:0.5em;">The relationship between UAAG and WCAG is not very clear: when the application is considered to be a user agent and when not. As WCAG applies in both cases, why is it mentionned here? <span style="color:#808080;">{Sylvie, June 13} </span></li><br />
</ul><br />
<br />
===Relationship with ATAG 2.0===<br />
<ul><br />
<li style="padding-bottom:0.5em;">comment <span style="color:#808080;">{name}</span></li><br />
<br />
</ul><br />
<br />
<br />
==Implementing UAAG==<br />
<br />
===Overall (Implementing)===<br />
<ul><br />
<li style="padding-bottom:0.5em;">comment <span style="color:#808080;">{name}</span></li><br />
<li style="padding-bottom:0.5em;">Would it be possible to use structuring elements such as H5s to indicate sections like Intent of SC, Examples and resources? While comparing to the structure of [http://www.w3.org/WAI/GL/2011/WD-UNDERSTANDING-WCAG20-20110621/complete.html#contents Understanding WCAG 2.0], is there a W3C graphical design that could make each guideline document look similar? <span style="color:#808080;">{Sylvie, 14 June}</span></li><br />
<li style="padding-bottom:0.5em;"> Examples: change some of the names to be more diverse <span style="color:#808080;">{Shawn, 3 June}</span></li><br />
<br />
<li style="padding-bottom:0.5em;"> CSS to add more space between chunks of text, especially more space above new SC. Also, increase leading throughout. <span style="color:#808080;">{Shawn, 3 June}</span></li><br />
<br />
<li style="padding-bottom:0.5em;"> change "Return to Guideline" to @@ <span style="color:#808080;">{Shawn, 3 June}</span></li><br />
<br />
</ul><br />
<br />
===Introduction (Implementing)===<br />
<ul><br />
<li style="padding-bottom:0.5em;">comment <span style="color:#808080;">{name}</span></li><br />
<br />
</ul><br />
<br />
===Definition of User Agent (Implementing)===<br />
<ul><br />
<li style="padding-bottom:0.5em;">comment <span style="color:#808080;">{name}</span></li><br />
<li style="padding-bottom:0.5em;"><br />
Third paragraph: the link to "What Qualifies as a User Agent" is followed by the name of the current document in brackets, isn't this redundant? <br />
<span style="color:#808080;">{Bim 14 June}</span></li><br />
<br />
</ul><br />
<br />
===Implementing Guideline 1.1 - Provide access to alternative content.===<br />
<ul><br />
<li style="padding-bottom:0.5em;">comment <span style="color:#808080;">{name}</span></li><br />
<li style="padding-bottom:0.5em;">Several occurences in this guideline and may be elsewhere through the doc: in Intent of success criterion X, the document says that non text content is unusable, or <em>"painful"</em>. I have never seen this term elsewhere in W3C docs and wonder if it is appropriate. <br />Another example in intent of SC 1.2: <blockquote>"Some users with visual disabilities may wish to hide images in order to avoid those that are painful (such as those with high contrast)."</blockquote> <span style="color:#808080;">{Sylvie, 14 June}</span></li><br />
<li style="padding-bottom:0.5em;">In 1.1.3 Configurable Alternative Content Defaults, first example: <blockquote>"Sally is blind. In the browser's preferences dialog box, Sally specifies that she wants alt text displayed in place of images, and that the document should reflow to allow the entire alt text to be displayed rather than truncated."</blockquote> As screen readers retrieve the alt text content is it necessary for a blind user to request that the browser displays alt text rather than images? May be the example should be rewritten to reflect real use of alt text by blind users? <span style="color:#808080;">{Sylvie, 14 June}</span></li><br />
<li style="padding-bottom:0.5em;">In Examples of Success Criterion 1.1.6, the disability of the users is not always specified, (e.g. Maximilian or Tom. <span style="color:#808080;">{Sylvie, 14 June}</span></li><br />
</ul><br />
===Implementing Guideline 1.2 - Repair missing content.===<br />
<ul><br />
<li style="padding-bottom:0.5em;">comment <span style="color:#808080;">{name}</span></li><br />
<li style="padding-bottom:0.5em;">Examples of Success Criterion 1.2.2, first example:<br />The example talks about Franck who is called George in the next sentence. ^Try to check that the names remain the same in each example, in order to avoid confusing the reader. <span style="color:#808080;">{Sylvie, 14 June}</span></li><br />
</ul><br />
===Implementing Guideline 1.3 - Provide highlighting for selection, keyboard focus, enabled elements, visited links.===<br />
<ul><br />
<li style="padding-bottom:0.5em;">comment <span style="color:#808080;">{name}</span></li><br />
<li style="padding-bottom:0.5em;">SC 1.3.1 has three notes. I wonder if it is worth numbering them in note 1, note 2 ... or may be it does not make sense? <span style="color:#808080;">{Sylvie, 14 June}</span></li><br />
</ul><br />
===Implementing Guideline 1.4 - Provide text configuration.===<br />
<ul><br />
<li style="padding-bottom:0.5em;">comment <span style="color:#808080;">{name}</span></li><br />
<li style="padding-bottom:0.5em;">Typo: not sure whether we should indicate them in EOWG ^comments: Summary contains one word "<em>the</em>" that should not be there: <blockquote>"The user can control text font, color, and size (1.4.1), including whether all text should be the shown the same size (1.4.2).</blockquote><span style="color:#808080;">{Sylvie, 14 June}</span></li><br />
</ul><br />
===Implementing Guideline 1.7 - Enable Configuration of User Stylesheets.===<br />
<ul><br />
<li style="padding-bottom:0.5em;">comment <span style="color:#808080;">{name}</span></li><br />
<li style="padding-bottom:0.5em;">I wonder if it would be useful to explain acronyms such as in last "Examples of Success Criterion 1.7.1, 1.7.2 & 1.7.3". <br /><blockquote>"Mattias has ADHD and finds text easiest to read text·...</blockquote>explain what is ADHD? Is it clear to any reader? <span style="color:#808080;">{Sylvie, 14 June}</span></li><br />
</ul></div>Wdickhttps://www.w3.org/WAI/EO/wiki/index.php?title=Easy_Checks&diff=5763Easy Checks2013-06-14T23:19:12Z<p>Wdick: /* Comments on Linearize */</p>
<hr />
<div>Nav: [[Main Page|EOWG wiki main page]] > [[Main_Page#Evaluation_pages | Evaluation Pages ]]<br /><br />
[[http://www.w3.org/WAI/EO/wiki/Web_Accessibility_Preliminary_Evaluation Old Web Accessibility Preliminary Evaluation page]]<br />
<br />
<br />
= Easy Checks - A First Look at Web Accessibility=<br />
<br />
<p><strong>Related pages:</strong></p><br />
<ul><br />
<li><strong>[http://www.w3.org/WAI/eval/preliminary Easy Checks &quot;published&quot; draft]</strong></li><br />
<li><strong>[http://www.w3.org/WAI/EO/Drafts/eval/checks#forms Forms bullet version], <br />[http://www.w3.org/WAI/EO/Drafts/eval/check-forms Forms prose version]</strong></li><br />
</ul><br />
<br />
<br />
__TOC__<br />
<br />
<p><strong>Related pages:</strong></p><br />
<ul><br />
<li><strong>[http://www.w3.org/WAI/eval/preliminary Easy Checks &quot;published&quot; draft]</strong></li><br />
<li><strong>[http://www.w3.org/WAI/EO/Drafts/eval/checks#forms Forms bullet version], <br />[http://www.w3.org/WAI/EO/Drafts/eval/check-forms Forms prose version]</strong></li><br />
</ul><br />
<br />
==To Do==<br />
<br />
[http://www.w3.org/WAI/eval/preliminary#titles Page titles]<br />
<ul><br />
<li>[OPEN action] Find a keyboard way to display the full page title in IE 9 and later and chrome. </li><br />
</ul><br />
[http://www.w3.org/WAI/eval/preliminary#interaction Keyboard access and visual focus]<br />
<ul><br />
<li>[EOWG thoughts?] Is it specific and clear enough to write: "To select a specific item within an element such as a drop-down list, press the Enter key or Space bar."</li><br />
<li>[EOWG thoughts?] In "what to do", visual focus: <br /><br />
"Check that the focus indicator is clearly visible as you tab through the elements, that is, you can tell which element has focus, for example, because it is highlighted. (A common problem is that the default focus indicator is turned off in CSS [@@ too jargony?] or elements are styled with borders that overlap or hide the focus indicator.)"</li><br />
</ul><br />
[http://www.w3.org/WAI/eval/preliminary#forms Forms and error messages ]<br />
<ul><br />
<li>[EOWG thoughts?] In "required fields" we may need to explain group label in the beginning.</li><br />
<li>[OPEN action] In "error messages", need to say more specifically how to check if the focus is at the error message.</li><br />
</ul><br />
[http://www.w3.org/WAI/eval/preliminary#media Multimedia (video, audio) alternatives]<br />
<ul><br />
<li>[OPEN action] In Section "captions", look for a way to turn on open captions with the keyboard, for example in Youtube activating the CC button.</li><br />
<li>[EOWG thoughts?] think of other examples for important noise, especially positive ones (instead of slamming and breaking:)</li><br />
</ul><br />
Throughout:<br />
<ul><br />
<li>Check img alts - some might have @@</li><br />
<li>Decide if we want more images for the steps. Search for [image].</li><br />
<li>Search for other open things in [brackets].</li><br />
<li>Search throughout for the perspective that the content needs to work, rather than the user has a limitation. e.g., 'users need to be able to' vs. 'websites need to enable users to' <span style="color:#808080;">{Shawn}</span></li><br />
</ul><br />
<br />
Misc:<br />
* Ask [http://ncdae.org/resources/cheatsheets/accessibility.php Identifying Web Accessibility Issues] to link to Easy Checks when it's more done.<br />
<br />
==Public Comments==<br />
<br />
===Jim Allan 6 June===<br />
<ul><br />
<li style="margin-bottom:0.5em;">Comment: Color/Contrast channeling Jared's &lt;rant&gt;!!! can we have an example of wretched grey text on a white background. Folks forget that grey and white are colors and may not think to check it.<br /><br />
[EOWG thoughts:<br />
<ul><br />
<li>comment <span style="color:#808080;">{name, date}</span><br />
<li>We could just change the first one to white background rather than adding another example. <span style="color:#808080;">{Shawn, 6 June}</span></li><br />
</ul><br />
</li><br />
<li style="margin-bottom:0.5em;">[closed?] Comment: zooming if you control+ in FF the images also get bigger. IE can change text size only (but with limits) main menu - view&gt;text size in windows with wheel mouse, can zoom using control and mouse wheel (forward for larger, backward for smaller)<br />
<br /><br />
<em><strong>Resolution proposal:</strong></em> No changes. We have in the instructions for FF for text-only "From the menubar, select View > Zoom Text Only or, View > Zoom > Zoom Text Only". Jim must have missed that on quick read. For IE, we previously decided that it was too different across IE versions and also do not want to require mouse wheel for a check.<br />
<br /><br />
[EOWG thoughts:<br />
<ul><br />
<li>comment <span style="color:#808080;">{name, date}</span><br />
</ul><br />
</li><br />
<li style="margin-bottom:0.5em;">[closed?] Comment: you need to describe &quot;visual focus&quot; - something like &quot;usually seen as a dotted rectangle surrounding a link. &quot; Visual focus is jargony<br />
<br /><br />
[EOWG thoughts:<br />
<ul><br />
<li>comment <span style="color:#808080;">{name, date}</span><br />
<li>previous wording was: "Check that the focus indicator is clearly visible as you tab through the elements, that is, you can tell which element has focus, for example, because it is highlighted." ... maybe Jim just missed that in quick read?<br />
<br /><br />
<em><strong>Resolution proposal:</strong></em> Edited it to : "Check that the focus indicator is clearly visible as you tab through the elements, that is, you can tell which element has focus, for example, links have a gray outline around them or are highlighted."<br /><br />
''Is that good enough?''<br />
</ul><br />
</li><br />
<li style="margin-bottom:0.5em; color:#585858;">[closed pending EOWG OK] Comment: Page title: you mention checking with WAT toolbar in IE...need a link and what is WAT? Alt text (or anywhere in the page): need links to all mentioned toolbars Also, FF toolbar??? - which one - the one from UIUC, or Pendrick developers, or ??? +1 Wave is linked!!<br /><br />
<em><strong>Resolution:</strong></em> Made the headings under &quot;Using these Easy Checks&quot; always visible and added &quot;FF Toolbar and IE WAT &quot; to &quot;Tools&quot;</li><br />
<li style="margin-bottom:0.5em; color:#585858;">[closed pending EOWG OK] Comment: in section: To practice checking alt text in BAD - what is BAD (I know, but newbies won't), make the link provided active<br /><br />
<em><strong>Resolution:</strong></em> Made the headings under &quot;Using these Easy Checks&quot; always visible so &quot;Practicing with BAD, the Before-After Demo&quot; is visible. Also linked all BAD page URIs.</li><br />
<li style="margin-bottom:0.5em; color:#585858;">[closed pending EOWG OK] Comment: keyboard access and visual focus a test page would be useful<br />
<br /><br />
<em><strong>Resolution:</strong></em> Added "[http://www.w3.org/WAI/eval/preliminary#visualfocusBAD To see visual focus with BAD]" section<br />
</li><br />
</ul><br />
<br />
===Other===<br />
<br />
[http://webaim.org/discussion/mail_message?id=23392 6 June, Ryan]<br />
<br />
==Overall Comments==<br />
<ul><br />
<br />
<li>Any edits based on input from [http://lists.w3.org/Archives/Public/w3c-wai-eo/2013AprJun/0058.html Tom J. (Wayne's forwarded e-mail)] ?<br />
<ul><br />
<li>comment <span style="color:#808080;">{name}</span></li><br />
<li>[in-progress] I agree with Tom's following thought: <br />"Looking for an even simpler FIRST check, I've tried this one:<br />FF Toolbar, Miscellaneous -> Linearize Page; Images -> Replace Images<br />
With Alt Attributes; CSS -> Disable Styles -> Disable All Styles.<br />
This is almost a visual "voice reader" simulation, except of course it<br />
doesn't say "image," "link," and so on. But if the page looks good this<br />
way (headings, organization, sensible alt text, etc.), it's probably<br />
close. If it doesn't make sense this way, then more thorough analysis<br />
is in order. (Try it on the inaccessible BAD Home page.)"<span style="color:#808080;">{Sylvie}</span></li><br />
<li><span style="color:#808080;">[closed] Tom writes: "I understand why they've had<br />
to include multiple systems (IE + FF), although FF can be used on any OS."<br />Sylvie: It can be useful to evaluate with at least two browsers as they do not behave the same. For that reason, I think it is important to talk about IE and FF. {Sylvie}</span></li><br />
<li>[http://www.w3.org/WAI/EO/wiki/Easy_Checks#Linearize_Page_.28Optional.29 Here is a draft] to add at the end of the current page if the group thinks it is useful and not beyond the scope of an "Easy Check" {Sharron June 4}</li><br />
</ul><br />
</li><br />
</ul><br />
<br />
==Comments on Linearize==<br />
Drafts:<br />
* [http://www.w3.org/WAI/EO/Drafts/eval/checks#l Draft 3 in draft web page]<br />
* [http://www.w3.org/WAI/EO/wiki/Easy_Checks#Linearize_the_Page_for_Experiential_Learning_.28Optional.29 Draft 2 below "Linearize the Page for Experiential Learning (Optional)"]<br />
* [http://www.w3.org/WAI/EO/wiki/Easy_Checks#Linearize_Page_.28Optional.29 Draft 1 below "Linearize Page (Optional)"]<br />
<br />
<span style="background:yellow;">[EOWG comment]</span><br/><br />
'''''Do we want to include something like this at the end? <br/>What are the benefits? <br/>What are the cons? <br/>If we do, what comments do you have on the draft text? <br />What should we call this section? (it's more than linearize, it turns off images & CSS as well)'''''<br />
<br />
* comment <span style="color:#808080;">{name, date}</span><br />
* I like the idea of this section - it adds something more to the checks than just yes/no <br /> Benefits - gives a little experiential flavour of what some people experience <br /> Cons - not about 'checking' ''per se'', so could add confusion for readers <br /> I'm not sure about the text that implies that screen reader users get linearised tables - if data tables are marked up correctly, then they make much more sense that what I see with a linearised table. <span style="color:#808080;">{Andrew, 13 June}</span><br />
* I am ok with draft 3 which simplifies draft 2 a bit. Nevertheless, I think the words "some people" are written too many times. I suggest following rewording in mixing drafts 2 and 3: <br />While the other checks on this page focus on specific success criteria in WCAG 2.0, this check is more broad. It helps you understand how some people "see" the web page in other ways as usual. Frequently, web pages are designed with multiple columns and sections, colors, etc, that makes their content difficult to understand for users who are blind and listen to the page with a screen reader. Many users with low vision and others change the way the page is presented so they can read it; for example, change from multiple columns to one column, change the text size, and more. If you have no access to a screen reader or the knowledge of how to work with one, you may approximate the experience of a screen reader user by "linearizing" the page, removing images and styles. This check gives you an idea of how people who are blind and others who get a linearized view experience the web page you are checking.<br />Note: BAD provides a clear example of how the plain text view reveals accessibility barriers. (It's also a bit funny, and we suggest you check it out, per the BAD instructions below.) <span style="color:#808080;">{Sylvie, June 13}</span><br />
* I think this section could be helpful for people who need to have a quick look at a page without styles and images. this draft is not too long and clear. <span style="color:#808080;">{Sylvie, June 6}</span><br />
<br />
{Wayne June 14} <br />
== Safari Plain Text ==<br />
Safari does not supply a linearize page option either natively or through an extension.<br />
<br />
For the best approximation of a linear page do the following from <br />
the Develop Menue on the main menu bar. Select:<br />
<br />
* Develop > Disable Images<br />
* Develop > Disable Styles<br />
<br />
For Keyboard access press<br />
* ctl+f2 > d > press down arrow until Delete Images<br />
* ctl+f2 > d > press down arrow until Delete Styles<br />
<br />
If your Safari lacks a Develop menu go to Safari preferences, choose the Advanced Tab and on the last check box on the control select, "Show Developer Menu."<br />
<br />
==Linearize Page (Optional)==<br />
<br />
Not everyone has access to a screen reader or the knowledge of how to work with one. You may approximate the experience of a screen reader user by "linearizing" the page, removing images and styles so that the reading order and text alternatives are exposed and can be evaluated.<br />
<br />
===What to do:===<br />
<br />
The checks below provide instructions with different browsers for how to:<br />
<br />
* Expose text alternatives by removing images<br />
* Reveal the reading order by turning off the associated style sheets<br />
* Examine the resulting page display for an approximation of a screen reader experience.<br />
<br />
====To linearize with IE WAT==== <br />
# Open the page you are checking in the IE browser<br />
# Using the toolbar, choose Images > Remove Images<br />
# Next choose CSS > Disable CSS<br />
<ul><br />
<li>comment <span style="color:#808080;">{name}</span></li><br />
<li>Shortcuts in WAT toolbar are: <br /> With keyboard press ctrl+alt+shift+s to display the options dialog box and uncheck the boxes "Images" and "CSS", then select "ok".. <br /><span style="color:#808080;">{Sylvie, June 6}</span></li><br />
</ul><br />
<br />
====To linearize with FF web developer toolbar==== <br />
# Open the page you are checking in the FF browser<br />
# Using the toolbar, choose Images > Disable Images<br />
# Next choose CSS > Disable Styles > Disable All Styles<br />
<ul><br />
<li>comment <span style="color:#808080;">{name}</span></li><br />
<li>In the French Web Developer version the keyboard shortcut to hide CSS is alt+shift+a, but I am not sure if it is the same in the English one. For disabling images, I only have the French version's shortcuts here. <span style="color:#808080;">{Sylvie, June 6} </span></li><br />
</ul><br />
<br />
===What to check for:===<br />
<br />
Read through the resulting display and notice the following:<br />
<br />
* Make sure that there is text in place of any meaningful images and that the text provides the same information as the original. (review alt text section above)<br />
* Verify that the reading order is logical, complete, and makes sense.<br />
<br />
<br /><br />
<hr/><br />
<br />
<p> Comment: {Wayne Dick} The inclusion of the linearizatin is important to the easy checks. I liked Sharron's start, but it was not inclusive enough, nor did it motivate linerization sufficiently. Quite simply accessibility is not achievable without the ability to linearize content in a semantically faithful way. Sharron, I hope I expanded you piece to meet your approval</p><br />
<br />
==Linearize the Page for Experiential Learning (Optional)==<br />
<p><br />
When a page is converted form text to speech, to Braille, or to very <br />
large print, the author's two dimensional presentation format breaks <br />
down. Before a page can be converted to an appropriate medium it must be<br />
reduced to a one dimensional information stream. This process is called<br />
linearizing the page.<br />
</p><br />
<p><br />
Not everyone has access to a screen reader, or powerful text <br />
customization tools required to experience linearized content as it is <br />
used, but a linearized presentation of content is easy to simulate using<br />
the tools we have introduced so far. This can give the fully sighted <br />
reader an understanding of the day to day experience of users with <br />
blindness or low vision.<br />
</p><br />
<p><br />
Linearization does not focus on any one success criterion, instead it <br />
reveals how well a page is organized to support accessibility. <br />
Example: Read the linearized view of the inaccessible version <br />
in the BAD Demo. That will be fun, and it reveals a lot of what can go <br />
wrong. <br><br />
</p><br />
<p><br />
The checks below provide instructions with different browsers for how to:<br />
</p><br />
<ol><br />
<li> Unclutter the linear view and expose text alternatives by removing images</li><br />
<li> Reveal the reading order by turning off the associated style sheets,</li><br />
<li>Expose navigation support for a one dimensional content format, and<br><br />
</li><br />
<li> Reveal the resulting page display for an approximation of a screen reader / customized text experience.</li><br />
</ol><br />
<h3><br />
To linearize with IE WAT<br />
</h3><br />
<ol><br />
<li> Open the page you are checking in the IE browser</li><br />
<li> Using the toolbar, choose Images &gt; Remove Images</li><br />
<li> Next choose CSS &gt; Disable CSS</li><br />
</ol><br />
<p><br />
Shortcuts in WAT toolbar are:<br />
With keyboard press ctrl+alt+shift+s to display the options dialog <br />
box and uncheck the boxes "Images" and "CSS", then select "ok"..<br />
{Sylvie, June 6}<br />
</p><br />
<h3>To linearize with FF web developer toolbar<br />
</h3><br />
<ol><br />
<li> Open the page you are checking in the FF browser</li><br />
<li> Using the toolbar, choose Images &gt; Disable Images</li><br />
<li> Next choose CSS &gt; Disable Styles &gt; Disable All Styles</li><br />
</ol><br />
<p><br />
In the French Web Developer version the keyboard shortcut to hide <br />
CSS is alt+shift+a, but I am not sure if it is the same in the English <br />
one. For disabling images, I only have the French version's shortcuts <br />
here. {Sylvie, June 6}. This doesn't work in the English version {Wayne,<br />
June 11}<br><br />
</p><br />
<h3>What to check for:</h3><br />
<p><br />
Read through the resulting display and notice the following:<br />
</p><br />
<ol><br />
<li> Make sure that there is text in place of any meaningful images <br />
and that the text provides the same information as the original. (review<br />
alt text section above)</li><br />
<li> Verify that the reading order is logical, complete, and makes sense.</li><br />
<li> <new> Make sure that there are reasonable ways to skip around <br />
long lists of links and other boiler plate content that is repeated on <br />
every page in the site. </new></li><br />
</ol><br />
<br />
==Introduction==<br />
'''[http://www.w3.org/WAI/EO/Drafts/eval/checks#introduction Introduction in WAI draft page]'''<br />
<br />
Status:<br />
* '''Complete, ready for detailed review.'''<br />
* no major edits since February<br />
<br />
Comments:<br />
<br />
* comment <span style="color: #808080;">{name, date}</span><br />
<br />
==Page title==<br />
<br />
'''[http://www.w3.org/WAI/EO/Drafts/eval/checks#title Page title in WAI draft page]'''<br />
<br />
Status:<br />
* '''Complete, ready for detailed review.'''<br />
* OPEN: a couple things listed in "To be implemented" below<br />
<div style="color:#808080;"><br />
* 30 May edit: significantly edited the first part.<br />
* 24 May edits: changed images.<br />
* 21 March edit: changed "Best practice is for titles to be "front-loaded" with the important and unique identifying information first..."<br />
</div><br />
Comments:<br />
<br />
* comment <span style="color:#808080;">{name, 00 month}</span><br />
<br />
==Image text alternatives ("alt text")==<br />
<br />
'''[http://www.w3.org/WAI/EO/Drafts/eval/checks#images alt text in WAI draft page]'''<br />
<br />
Status:<br />
* '''Complete, ready for detailed review.'''<br />
* only minor edits since February<br />
<br />
Comments:<br />
<br />
* comment <span style="color:#808080;">{name}</span><br />
<br />
==Headings==<br />
'''[http://www.w3.org/WAI/EO/Drafts/eval/checks#headings Headings in WAI draft page]'''<br />
<br />
Status:<br />
* '''Complete, ready for detailed review.'''<br />
* 30 May edits: changed 'What to check for' from questions to statements to be consistent with other sections.<br />
* 21 March edits: combined instructions under each tool<br />
<br />
Comments:<br />
<br />
* comment <span style="color:#808080;">{name}</span><br />
<br />
==Luminosity Contrast==<br />
'''[http://www.w3.org/WAI/EO/Drafts/eval/checks#contrast Visual contrast in WAI draft page]'''<br />
<br />
Status:<br />
* '''Overall flow, instructions, text is complete and ready for review.'''<br />
* OPEN: Needs someone to fill in some details on using the tools. - Vicki will do it<br />
<div style="color:#808080;"><br />
* 10 May edit: changed heading from [Luminosity Contrast ("color contrast")] to [Contrast Ratio ("color contrast")]<br />
* 22 March edit: changed heading to Luminosity Contrast ("color contrast")<br />
* 21 March edits:<br />
** changed heading to Visual contrast ("color contrast", luminosity contrast)<br />
** tweaked wording a bit and added: This accessibility requirement is sometimes called sufficient "color contrast"; however, that is incorrect — technically it's "luminosity contrast".<br />
* 7 March edit: moved the 3 options with pros & cons from under "To check contrast with IE WAT" up a level to apply to all.<br />
</div><br />
Comments:<br />
* <span style="color:#808080;">[closed] I think right above "Download the Color Contrast Analyzer" the heading needs to have the word "Windows" added so it changes to "To check contrast with any Windows browser." <span style="color:#808080;">{Anna Belle}</span><br />reply: a mac version is available - http://www.paciellogroup.com/node/18?q=node/20#macdownload <span style="color:#808080;">{Andrew, 15/March}</span><br/>'''Questions: '''Is "you don't need to install it so should be able to do even in environments where you cannot install software." true for that TPG Windows & Mac versions as well? The current link goes to Vision Australia page with "Color Contrast Analyzer". The TPG version is called "Contrast Analyser" - which is better. Should we just point to that one? <br />'''Reply: '''The CA and CCA are the same - when installed, the CA2.2a from TPG is actually 'Colour Contrast Analyser version 2.2a'. Also, the TPG and the Vision Australia downloads are the same tool - it was originally developed at Vision Australia then Steve moved it to TPG when he moved - VA retain up-to-dates version on their site. I don't know if the Mac version needs to be 'installed' or not. <span style="color:#808080;">{Andrew, 22/March}</span><br /><span style="background:yellow;">[open action for Mac]</span> Someone please check if "you don't need to install it so should be able to do even in environments where you cannot install software." is true for that TPG Windows & Mac versions?<br />I tried on a Mac and the link on the page (unlike Andrew's link) sends me to a download page that's for Windows not Mac. That's even when I'm on a Mac. Maybe have a second link for Mac?<span style="color:#808080;">{Anna Belle. May 30}</span><br />The Windows one required me to be admin as well, so I just deleted this all together. {Shawn}</span><br />
<br />
==Zoom==<br />
'''[http://www.w3.org/WAI/EO/Drafts/eval/checks#zoom Zoom in WAI draft page]'''<br />
<br />
Status:<br />
* '''Complete, ready for detailed review.'''<br />
<div style="color:#808080;"><br />
* 8 March edit: Added "If possible, you should check zoom text only." and moved "To check zoom text only" up.<br />
* 7 March edits were mostly minor. Note new second sentence in first paragraph: "Some need to change other aspects of text display: font, space between lines, and more." This is important so that readers don't think simple zoom covers all user needs (like in the color section we mention the need for low luminosity).<br />
</div><br />
Comments:<br />
<br />
* comment <span style="color:#808080;">{name}</span><br />
<br />
==Keyboard access, content order, visual focus==<br />
'''[http://www.w3.org/WAI/EO/Drafts/eval/checks#interaction Keyboard, etc. in WAI draft page]'''<br />
<br />
Status:<br />
* '''Complete, ready for detailed review.'''<br />
* 14 May: significant edits.<br />
<br />
Comments:<br />
<br />
* comment <span style="color:#808080;">{name}</span><br />
<br />
* Illustrations of focus indication would be useful. Shall I send screen shots to the list or how to provide? <span style="color:#808080;">{Sharron}</span><br />Send them to Shawn & she'll upload them :) <span style="color:#808080;">{Shawn}</span><br />
<br />
==Forms, form labels, and error messages==<br />
'''[http://www.w3.org/WAI/EO/Drafts/eval/checks#forms Forms in WAI draft page]'''<br />
<br />
Status:<br />
* 16 May: significant edits.<br />'''''Note: more updates coming'''''<br />
<br />
===Comments '''after''' 14 June===<br />
<br />
* comment <span style="color:#808080;">{name}</span><br />
<br />
<div style="color:#808080;"><br />
===Comments '''after''' 10 June===<br />
* Background: [http://lists.w3.org/Archives/Public/w3c-wai-eo/2013AprJun/0074.html Forms e-mail 10 June]. Given that easy checks can not tell you pass or fail for labels, and the liklihood of false failures, do we still want to include labels? See [http://www.w3.org/WAI/EO/wiki/Eval_Analysis#Criteria_for_checks Criteria for what to include].<br />
** I understand the arguments, but they are so common and so often badly done (i.e. inaccessible) that it would be a shame to drop them. Maybe we need a 'not-so-easy checks' page to follow on with :) <span style="color:#808080;">{Andrew, 13/June}</span> <br /> Anna Belle moaned when I mentioned that option. :) Remember that we added a section on [http://www.w3.org/WAI/EO/Drafts/eval/checks#next things that are not included in the easy checks] <span style="color:#808080;">{Shawn, 13 June}</span><br />
** I've been checking the method of clicking on the label to perform the check. I haven't found any false positives nor the opposite; and it seems to work on buttons, textarea, checkboxes, radio buttons, etc. <span style="color:#808080;">{Howard, 14 June}</span><br />It works when the label is implicit. Is this false pass? Explicit labels were required with WCAG 1.0 &mdash; although not exactly in WCAG 2.0. We should research this more. <span style="color:#808080;">{Shawn}</span><br /> well, [http://www.w3.org/TR/2012/NOTE-WCAG20-TECHS-20120103/H65 H65] says "Using the title attribute to identify form controls when the label element cannot be used" impying that the label ellemnt shouod be used whenever possible. Which is what most of us advise. <span style="color:#808080;">{Andrew, 13/June}</span><br />
* Is there a way to check label markup with FF toolbar? If not, should we not have a FF section at all?<br />
** As far as I can see, FF toolbar can only display/highlight forms fields ''without'' labels: '''F'''orms > '''O'''utline Form Fields Without Labels <span style="color:#808080;">{Andrew, 13/June}</span><br />Right. I've got that in the draft and note: "Some fields without labels will get a thin red border. (Note that this only works for some text fields and buttons, not for radio buttons, checkboxes, and drop-down boxes.) [@@ true? seems so with BAD anyway. also, i find it a bit hard to see the thin red border. With these limitations, is it worth including this step?]" <span style="color:#808080;">{Shawn, 13 June}</span><br />
** I don't fine the red outline that hard to see. Also, what about the Wave toolbar to check labels or the AIS toolbar (see http://html.cita.illinois.edu/nav/form/form-test-ais.php) Or are these types of toolbars too complicated for Easy Checks? <span style="color:#808080;">{Howard, 14 June}</span> <br />We decided to limit the number of tools and I don't think we want to add AIS. Some people find WAVE difficult to use; however, we do use it in one other place. It also has the implicit label issue. We should research this more. Maybe WAVE is a good option here. <span style="color:#808080;">{Shawn}</span><br />
</div><br />
<br />
===''Comments before 10 June''===<br />
<br />
* <span style="color:#808080;">[done] say explicti lables on radio buttons make the whole thing clickable! <span style="color:#808080;">{Shawn, Paul}</span><br />
* [closed? added to [http://www.w3.org/WAI/EO/Drafts/eval/checks#forms current draft] intro sentence with all issues] The prose version is a significant improvement over the bullet version. The former leads off with a clear introductory sentence and then proceeds with a nice overview of the issues, providing a rationale for the more detailed instructions that follow. The bullet version starts right off with specifics which is jarring and disorientating. <span style="color:#808080;">{Howard, 6 June}</span><br />
<br />
<ul><li><br />
Other observations/feedback: <span style="color:#808080;">{Howard, 6 June}</span><br />
<ul><br />
<br />
<li><span style="color:#808080;">[done. fixed] the link to the "preliminary" page is broken</span></li><br />
<br />
<li>'''<span style="background:yellow;">[EOWG open </span> - heading for this section simply "Forms?" or more?]'''<br />Title on current version is "Forms and Error Messages" but in this wiki it's "Forms, Form Labels, and Error Messages." I prefer the latter <ul><li>Currently the section covers: Labels, Keyboard Access, Instructions, and Error Handling" Maybe keep it short and just use "Forms" ? <span style="color:#808080;">{Shawn 10 June}</span></li></ul></li><br />
<br />
<li><span style="color:#808080;">[closed. [http://www.w3.org/WAI/EO/Drafts/eval/checks#forms current draft] has "Find forms on the page."] <em>"Find Forms"</em> header under "What to do" seems too open. Suggest: "Find the forms on the page" (too wordy?); or "Find form elements" (too technical?)</span> <ul><span style="color:#808080;">I agree. I like first suggestion and would add to this that we move "If there are forms on the page ...." sentence to below the bullet points and right above what it refers to. {Anna Belle, 8 June}</span></ul></li><br />
<br />
<li>[closed? [http://www.w3.org/WAI/EO/Drafts/eval/checks#forms current draft] has bullets under the subheads] This section, being lengthier than the others, calls for additional indentation - under the brown headers, such as "What to do", "What to check for", etc. Too much lines up along one left margin. Some additional indentation would add readability. (Perhaps once images are added, this will help subdivide the section)</li><br />
<br />
<li><span style="color:#808080;">[closed [http://www.w3.org/WAI/EO/Drafts/eval/checks#forms current draft] covers it in keyboard section] Maybe the "submit button" section could be replaced with a statement such as: <br />"Form data should not be submitted without user confirmation" (followed by more detailed instructions?)</span></li><br />
<br />
<li>[closed? edited in [http://www.w3.org/WAI/EO/Drafts/eval/checks#forms current draft]] I think error messages should be addressed in "to learn more about forms." Otherwise, this section is getting to lengthy and thus no longer an "easy check".</li><br />
<li>@@As mentioned under "to do items," the group label is not sufficiently explained. Maybe have a link from "group label" where it can be further explained.</li><br />
</ul></ul><br />
<br />
* As discussed in EOWG's 31 May teleconference, I suggest changing the checks order as proposed below: <br /><ol> <li>Labels</li><li>Instructions</li><li>Keyboard access and reading order</li><li>Submit buttons</li><li>Data input and error messages</li></ol><span style="color:#808080;">{Sylvie June 4, 2013}</span><br />
<br />
* In section "error messages", we should give clear instructions on what to look for, avoiding asking for judgement.<br /><ul><li>Check that there is guidance to help user understand and fix the error.</li><li>The focus moves to the error message</li><li>Error information is not located at the end of the form, but rather at the beginning.</li><li>The user is not requested to fill in the whole form again, but only the error fields.</li><li>If the error concerns a format, such as date, time, address, suggestions are made to enter the correct format.</li><li>If a required field has been forgotten, that this field is indicated with colour and text such as "mandatory" or *.</li></ul><span style="color:#808080;">{Sylvie June 4, 2013}</span><br />
* <span style="background:yellow;">[EOWG discuss]</span> '''Are these easy checks?''' I wonder if all of what's currently in the Forms section qualifies as easy checks? For example, <br />- Is "Instructions" too soft/unclear/nonspecific? <br />- Indicating required fields is a bit tricky. Do we say enough here? Or is it too complex for an easy check? ... oh, I see now that required is in the Instructions subsection and the Labels section. <br />- Is "Data input and error messages" too hard for an easy check? <br />Also: My preference would be *not to have any specific instructions* under "2. Keyboard access and reading order" but instead have just a point to the keyboard access section above (and make sure it clearly includes keyboard access issues for forms). If y'all disagree, we can talk about that in EOWG telecon. <br />Also: "4. Submit buttons" is already covered in the keyboard access section above. I don't think we want to repeat it. (also, most of these wouldn't have buttons labeled "submit", they'd be something like "go to Page") <br />'''Perhaps we want to re-focus this section to just Form Labels?''' <span style="color:#808080;">{shawn}</span><br />
<br />
* Reconsider the "What to do" section. Remember we've positioned this Easy Checks as applying to ONE web page (so "Check through the web pages to look for examples of forms." is not relevant). Can you make that section more succinct? Do we even need it at all? (Maybe to point out that a search box is a form?) <span style="color:#808080;">{Shawn}</span><br />
<br />
* BAD: Rather than having a link to BAD in the "To learn more about forms" section without any explanation of what to look for in BAD, perhaps it would be useful to have a section on using BAD to check forms issues -- for example, like this one for alt: <http://www.w3.org/WAI/EO/Drafts/eval/checks#bad-alt> ? <span style="color:#808080;">{shawn}</span><br />
<br />
* <span style="color:#808080;">[closed] Suggest changing:<br />Forms are used for interacting with websites and are common across the Web. They are used for activities such as search, login, registration, contact, booking, purchasing, banking, and interacting with government and other organizations. <br />to: <br />Forms are used for SUBMITTING DATA TO websites and are common across the Web. They are used for OPERATIONS such as search, login, registration, contact, booking, purchasing, banking, and interacting with government and other organizations. <span style="color:#808080;">{Howard 23 May}</span> <br />Suggest changing: <br />Forms are made up of controls such as text entry fields, check boxes, radio buttons, drop-down boxes and finish with submit buttons. <br />to: <br />Forms CONSIST of data entry fields, including text fields, check boxes, radio buttons, drop-down boxes and controls, usually consisting of a submit button. <span style="color:#808080;">{Howard 23 May}</span> <br />Actually, '''I think the introduction should take a different approach &mdash; not to introduce forms per se, but to introduce some of the accessibility issues with forms &mdash; like the other sections do.''' {Shawn 24 May}</span><br />
<br />
* <span style="color:#808080;">[closed] Suggest changing: <br />For longer or unusual forms, check for instructions. <br />to <br />For long or complex forms, check for instructions.</span><br />
<br />
* Suggest deleting: <br />Instructions are usually needed to explain how to fill out the form.<span style="color:#808080;">{Vicki 24 May}</span><br />
<br />
* <span style="color:#808080;">[closed] Suggest changing: <br />Are there instructions at appropriate places in the form (usually at the beginning and the start of discrete sections) that clearly explain how to fill out the form? <br />to <br />Are the instructions positioned appropriately (usually at the beginning of the form and/or at the start of specific sections)? <br />Do the instructions clearly explain how to fill out the form?</span><br />
<br />
* Suggest changing: <br />Are required fields explained in the instructions and clearly identified throughout the form? <br />to <br />Are the required (mandatory) fields explained in the instructions and clearly identified? <br /><span style="color:#808080;">{Vicki 24 May}</span><br />
<br />
* SK/MC case study - Good to have forms, but new post form was not available for public view. Really need to have a developers toolbar or IE WAT or WAVE to test this easily. Developer could not access tools from his machine and I could not access the page from my machine! We looked at BAD in order to consider the principles, having an example really helps. <span style="color:#808080;">{Suzette}</span><br />
<br />
==Multimedia (video, audio) alternatives==<br />
'''[http://www.w3.org/WAI/EO/Drafts/eval/checks#media Multimedia in WAI draft page]'''<br />
<br />
Status:<br />
* '''Complete, ready for detailed review.'''<br />
<div style="color:#808080;"><br />
* 24 May minor edits.<br />
* 21 March: significant edits.<br />
</div><br />
<br />
Comments:<br />
<br />
* comment <span style="color:#808080;">{name}</span><br />
* for other captioned sounds, suggest: <br />
Important sound other than dialogue — e.g., door slamming, broken glass, <em>water dripping, applause, laughter, writing on blackboard, tires squealing, etc.</em>[@@other examples of important noise, especially positive ones (instead of slamming and breaking:)] — is included. <span style="color:#808080;">{Howard, 6 June}</span><br />
<br />
* accessing cc with keyboard:<br />
<ul><ul><li>with nvda in firefox<li>'O' to find embedded object. Flash player announced as "embedded object, clickable"; (note: took me some moving and tabbing around the page before 'o' worked to find embedded objects)</li><li> pressing the enter key brings you to player controls;</li> <li>down-arrow will then take you to the closed captioning on/off control.</li><br /><br />
<li>Note: Without the screenreader could not really tell where I was on the youtube page using the keyboard. Not sure if these instructions can be made clear or definitive enough to be useful.</li><br />
<li>helpful youtube keyboard shortcut page: http://support.google.com/youtube/bin/answer.py?hl=en&answer=189278</li></ul></ul><span style="color:#808080;">{Howard, 6 June}</span><br />
<br />
* <span style="color:#808080;">[done] suggest changing <br /> "Most video on the web that provides captions has "closed captions" that need to be turned on." <br /> to: <br /> "Most video on the web that provides captions has "closed captions" that can be turned on and off". {Howard - May 31}</span><br />
<br />
==Next Steps==<br />
'''[http://www.w3.org/WAI/EO/Drafts/eval/checks#next Next Steps in WAI draft page]''' <br />
<br />
Status:<br />
* '''Complete ready for review''' - updated 4 June<br />
<br />
'''Comments on Next Steps'''<br />
* comment <span style="color:#808080;">{name, date}</span><br />
* maybe summarize other things that need to be checked that aren't covered on this page? <span style="color:#808080;">{Shawn, 7 June}</span><br />Potential things to list:<br />
** comment <span style="color:#808080;">{name, date}</span><br />
<br />
==Contributors==<br />
Thanks to:<br />
* Those who participated in the F2F before CSUN in February: Andrew, Anna Belle, Helle, Jennifer, Shadi, Sharron, Shawn, Wayne<br />
* Those who edited in December and January: Suzette (forms, @@), Sharron (Intro, @@), Shawn (Intro, page titles, headings, alt text), Ian (zoom n text resize).<br />
* Those who commented in December and January: Sylvie, Wayne, Anna Belle, ...<br />
* Those who drafted checks 16-28 November:<br />
** Sharron for drafting {list sections!}<br />
** Suzette for drafting : Check usable with page zoomed and text enlarged, Check color contrast, Check color coding and shape coding, {?other sections}<br />
** Wayne for drafting {list sections!}<br />
* Andrew & Shawn for editing the [http://www.w3.org/WAI/EO/wiki/Web_Accessibility_Preliminary_Evaluation#Check_keyboard_access_and_visual_focus_.5Bmostly_drafted.5D keyboard access & visual focus section] in early Nov.<br />
* Ian, Suzette, Vicki, Sylvie, Helle, Shawn for working on an early draft at the [http://www.w3.org/2012/11/02-eo-minutes f2f in Nov].<br />
* Sharron for help making all the early drafts and versions less confusing.<br />
* Wayne and Ian for sharing colleagues' related work.<br />
* Denis for edits to the old page content.<br />
<br />
testing image: http://www.w3.org/WAI/images/search-icon.png<br />
<br />
=Internal Notes=<br />
<br />
==Illustrations==<br />
<br />
'''Note:'''<br />
* '''To see all illustrations''', make sure to "expand all sections" because some of the illustrations are in collapsed sections. ''(however, keep in mind that most of the images will be collapsed by default)''<br />
* '''Make sure to evaluate the images in context''', that is, read the text around it and imagine you are a user.<br />
<br />
'''Questions:''' How is the current use of images for illustrations throughout the draft? Too much? Not enough? Mostly helpful? Too cluttering? Feel free to comment in general, and on specific images.<br />
<br />
<ul><br />
<li>comment <span style="color:#808080;">{name}</span></li><br />
<li>From [http://www.w3.org/2013/05/24-eo-minutes 24 May teleconference]:<br />
<ul><br />
<li>Generally the conceptual images are useful for [http://www.w3.org/WAI/EO/Drafts/eval/checks#contrast contrast] and [http://www.w3.org/WAI/EO/Drafts/eval/checks#zoom zoom]; simply the [http://www.w3.org/WAI/EO/Drafts/eval/checks#title page title images] {done 24 May}.</li><br />
<li>Mixed perspectives on the images showing menu items and such. For some people they are just clutter, the word instructions are clear enough. For other people, the images really help.</li><br />
<li>For now:<br />
<ul><br />
<li>Include images showing menu items and such judiciously &mdash; if in doubt, do not include an image.</li><br />
<li>'''Crop or gray out all unnecessary clutter in images'''. (for example, [http://www.w3.org/WAI/images/easychecks/page-title-tab-popup.png page-title-image] has the content of the web page grayed out.)</li><br />
</ul><br />
</li><br />
</ul><br />
</li><br />
</ul><br />
<br />
'''Strategy:''' I'd like to discuss strategy for illustrations. <span style="color:#808080;">{Anna Belle, June 9}</span> Here are questions to consider:<br />
<br />
<ul><br />
<li style="padding-top:1em;">Do we want to use captions? Always? Sometimes? If sometimes, then what distinguishes when they are needed?<br />
<ul><br />
<li>I think it is visually simplier without captions. The images are all illustrations of specific points and the images are right after the points, then I don't think they need captions. <span style="color:#808080;">{Shawn, 12 June}</span> Agree <span style="color:#808080;">{Andrew, 13 June}</span></li><br />
</ul><br />
</li><br />
<li style="padding-top:1em;">If we use captions, then how? E.g. do we give a 10 pixel padding with a border that encloses both image and captions?</li><br />
<li style="padding-top:1em;">Do we have images embedded in the text flow or do we separate them out (e.g. float to right)?<br />
<ul><br />
<li>I suggest embedded in the text flow. <span style="color:#808080;">{Shawn, 12 June}</span> Agree <span style="color:#808080;">{Andrew, 13 June}</li><br />
</ul><br />
</li><br />
<li style="padding-top:1em;">In some images do we want to use embedded explanatory text and arrows? This may be necessary if we aren't using captions. And even if we do use captions, for some concepts it may illustrate the point more clearly.<br />
<ul><br />
<li>I suggest keep them simple -- both for the users reading the page and for us developing the images. I think it would be best to crop and gray out an irrelevant information in the images, and not have to use arrows. Also, if the images are embedded and they are illustrating the text right above them, then they shouldn't need explanatory text. <span style="color:#808080;">{Shawn, 12 June}</span></li><br />
</ul><br />
</li><br />
<li style="padding-top:1em;">What is the maximum width for an image?<br />
<ul><br />
<li>We previously decided to make most images 700px wide. We can revisit that decision. <span style="color:#808080;">{Shawn, 12 June}</span></li><br />
</ul><br />
</li><br />
<li style="padding-top:1em;">If width is narrow (e.g. 350 pixels), some images will need to be shrunk to a size where detail may be lost. Is that okay? Or do we want to offer a link to a larger version of the image in such cases?<br />
<ul><br />
<li>I vote let's try to make the images useable in the page, and not add the complexity of linking to a larger image. <span style="color:#808080;">{Shawn, 12 June}</span></li><br />
</ul><br />
</li><br />
<li style="padding-top:1em;">Do we want to number illustrations? Thus in the text we could say, "See Figure 3" multiple times if Figure 3 is relevant multiple times.<br />
<ul><br />
<li>If we were referring to a single image multiple times, then we would need to do something like this. However, I think we don't refer to an image more than once. Also, currently the images are embedded in the text right after what they illustrate. Therefore, I think it would add unnecessary complexity (both for users and for us ;-) to number the illustrations. <span style="color:#808080;">{Shawn, 12 June} Agree <span style="color:#808080;">{Andrew, 13 June}</span></li><br />
</ul><br />
</li><br />
<li style="padding-top:1em;">Do we want to incorporate all illustrations into the expand sections button? Or perhaps have a separate "See illustrations" button? (I dislike both of these ideas, by the way.)<br />
<ul><br />
<li>Currently there are 3 types of images: <br />1. Illustrate the concept (e.g., page titles, contrast, zoom). <br />2. Illustrate the toolbar things to click. <br />3. Illustrate the results from the tool, e.g., alt text next to images. <br />Currently the concept images (1) are always shown, and the toolbar images (2 &amp; 3) are shown only when that specific checks step is expanded. I think this works well. [Agree <span style="color:#808080;">{Andrew, 13 June}]<br /><br />
For the checks steps, we could have the illustrations not visible by default and a button to show illustrations. That might be best for usability; however, I don't think it's a high enough priority for our time. We do not currently have such functionality developed so it would be a new thing to do. <span style="color:#808080;">{Shawn, 12 June}</span> [Agree - and we don't need more delays in releasing <span style="color:#808080;">{Andrew, 13 June}]</li><br />
</ul><br />
</li><br />
<li style="padding-top:1em;">Do we want to limit illustrations to one per concept? If the concept is tricky to illustrate (e.g. how to see titles) do we want to offer the option of clicking through to more illustrations?<br />
<ul><br />
<li>I don't think we want the complexity (for the users or for us) of adding the option to get more illusrations on a different page. Right now we have the following concept images:<br />
<ul><br />
<li>Page titles - 1. shows page title in title bar and cut off in tabs. 2. shows how to get the title from the tab when there is not a title bar. <em>[@@ we need to redo this image with a browser that does not have a title bar :-]</em></li><br />
<li>Contrast - several images that show different color combinations that are mentioned in the text.</li><br />
<li>Zoom - 2 that show a page not zoomed and zoomed.</li><br />
</ul><br />
I don't think it makes sense to put these one a separate page. <span style="color:#808080;">{Shawn, 12 June}</span></li><br />
</ul><br />
</li><br />
<li style="padding-top:1em;">Do we want to standardize the format to the image? JPG? SVG? PNG?<br />
<ul><br />
<li> I think png <span style="color:#808080;">{Shawn, 12 June}</span></li><br />
</ul><br />
</li><br />
<li style="padding-top:1em;">Would it be helpful to specifically state the goal for each illustration in the wiki? E.g. with titles, is it to show people how to see the title at the top of a browser (whether embedded in a tab or not)?<br />
<ul><br />
<li> Yes. Please do! ;-) <span style="color:#808080;">{Shawn, 12 June}</span></li><br />
</ul><br />
</li><br />
</ul><br />
<br />
==Case study notes==<br />
<br />
'''See [http://www.w3.org/WAI/EO/wiki/Prelim_Eval_2013-May-30#SK.2FMC_Case_Study_Notes SK/MC Case Study Notes] in the 30 May 2013 snapshot<br />
'''<br />
<br />
==Consider for Later==<br />
<br />
* The text says: "The first thing screen readers say when the user goes to a different web page is the page title. Page titles are important for orientation — to help users know where they are and move between open pages."<br />Would it be useful to have a sound clip of the screen reader going through page titles? Low priority, but maybe neat for people who don't know screen readers? {Shawn}<br />
<br />
==previous versions, etc.==<br />
* '''[http://www.w3.org/WAI/EO/Drafts/eval/checks WAI draft page]'''<br />
* [http://www.w3.org/WAI/EO/wiki/Eval_Analysis#Title_ideas title ideas]<br />
* '''For tasks, example use cases with audience, and focus for this and related documents, see the [[Eval Analysis]] page, including the table at the top and the specific [http://www.w3.org/WAI/EO/wiki/Eval_Analysis#Preliminary_Evaluation_Analysis Analysis] section at the bottom'''<br />
* A template for the check items is at the top of the [http://www.w3.org/WAI/EO/wiki/Talk:Web_Accessibility_Preliminary_Evaluation discussion tab].<br />
* For previous drafts and contributed material, see:<br />
** [[Prelim Eval 2013-May-30]] - snapshot of draft on 30 May 2013 -- '''includes [http://www.w3.org/WAI/EO/wiki/Prelim_Eval_2013-May-30#SK.2FMC_Case_Study_Notes SK/MC case study info]'''<br />
** [[Prelim Eval 2013-March-7]] - snapshot of draft on 7 March 2013<br />
** [[Prelim Eval 2013-Feb-26]] - snapshot of draft on 26 February 2013 - end of f2f before more edits<br />
** [[Prelim Eval 2013-Feb-21]] - snapshot of draft on 21 February 2013<br />
** [[Prelim Eval 2013-Feb-08]] - snapshot of draft on 8 February 2013 in the middle of edits<br />
** [[Prelim Eval 2013-Feb-01]] - snapshot of draft on 1 February 2013 before edits<br />
** [[Prelim Eval 2013-Jan-24]] - snapshot of draft on 24 January 2013<br />
** [[Prelim Eval 2013-Jan-17]] - snapshot of draft on 17 January 2013<br />
** Extensive revisions and suggestions at [[Archived_Work_on_PreLimEval]] ([http://www.w3.org/WAI/EO/wiki/Archived_Work_on_PreLimEval#Check_link_text_.5B15:_probably_not.5D_.5Bpartly_drafted.5D Links section])<br />
** From Wayne & Tom [[Prelim Eval input: Smart analysis simplified]]<br />
** Old page with Denis' edits and Ian's input in [[Preliminary Eval - old notes]]</div>Wdickhttps://www.w3.org/WAI/EO/wiki/index.php?title=UAAG_review&diff=5714UAAG review2013-06-12T23:46:33Z<p>Wdick: </p>
<hr />
<div>Nav: [[Main Page|EOWG wiki main page]]<br />
<br />
__TOC__<br />
<br />
Drafts:<br />
* [http://www.w3.org/TR/UAAG20/ UAAG 2.0]<br />
* [http://www.w3.org/TR/Implementing-UAAG20/ Implementing UAAG 2.0]<br />
* (also, fyi [http://www.w3.org/WAI/mobile/UAAGexamples Mobile Accessibility Examples from UAAG])<br />
<br />
<br />
==UAAG==<br />
<br />
===Overall===<br />
<ul><br />
<li style="padding-bottom:0.5em;">comment <span style="color:#808080;">{name}</span></li><br />
<br />
<li style="padding-bottom:0.5em;">Carefully consider what information should be in UAAG proper, and what should be in Implementing UAAG. Once UAAG is done, it cannot be changed; however, Implementing can be updated. Therefore, it might be wise to move some of the information from the Into of UAAG to Implementing. <span style="color:#808080;">{Shawn, 3 June}</span></li><br />
<br />
</ul><br />
<br />
===Abstract===<br />
[http://www.w3.org/TR/UAAG20/#abstract Abstract]<br />
<ul><br />
<li style="padding-bottom:0.5em;">comment <span style="color:#808080;">{name}</span></li><br />
<br />
</ul><br />
<br />
===Introduction===<br />
<ul><br />
<li style="padding-bottom:0.5em;">comment <span style="color:#808080;">{name}</span></li><br />
<br />
</ul><br />
<br />
===Overview===<br />
<ul><br />
<li style="padding-bottom:0.5em;">comment <span style="color:#808080;">{name}</span></li><br />
<br />
</ul><br />
<br />
===UAAG 2.0 Layers of Guidance===<br />
<ul><br />
<li style="padding-bottom:0.5em;">comment <span style="color:#808080;">{Wayne}</span><br />
<br />
The Principles bullet should read, "At the top layer,"... Omitting the word layer caused me to trip while reading<br />
<br />
Principles 4 and 5 are new and need more than just naming. The meaning of <em>facilitate programmatic access</em> and comply with <em>specifications and conventions</em> is not clear, and a brief description does not appear for a very long time. Please give each a brief description when they first appear.<br />
<br />
</li><br />
<br />
</ul><br />
<br />
===UAAG 2.0 Supporting Documents===<br />
<ul><br />
<li style="padding-bottom:0.5em;">comment <span style="color:#808080;">{name}</span></li><br />
<br />
</ul><br />
<br />
===Components of Web Accessibility===<br />
<ul><br />
<li style="padding-bottom:0.5em;">comment <span style="color:#808080;">{name}</span></li><br />
<br />
</ul><br />
<br />
===Levels of Conformance===<br />
<ul><br />
<li style="padding-bottom:0.5em;">comment <span style="color:#808080;">{name}</span></li><br />
<br />
</ul><br />
<br />
===Definition of User Agent===<br />
<ul><br />
<li style="padding-bottom:0.5em;">comment <span style="color:#808080;">{name}</span></li><br />
<br />
</ul><br />
<br />
===Modality Independence Principle===<br />
<ul><br />
<li style="padding-bottom:0.5em;">comment <span style="color:#808080;">{name}</span></li><br />
<br />
</ul><br />
<br />
===Relationship with WCAG 2.0===<br />
<ul><br />
<li style="padding-bottom:0.5em;">comment <span style="color:#808080;">{name}</span></li><br />
<br />
</ul><br />
<br />
===Relationship with ATAG 2.0===<br />
<ul><br />
<li style="padding-bottom:0.5em;">comment <span style="color:#808080;">{name}</span></li><br />
<br />
</ul><br />
<br />
<br />
==Implementing UAAG==<br />
<br />
===Overall (Implementing)===<br />
<ul><br />
<li style="padding-bottom:0.5em;">comment <span style="color:#808080;">{name}</span></li><br />
<br />
<li style="padding-bottom:0.5em;"> Examples: change some of the names to be more diverse <span style="color:#808080;">{Shawn, 3 June}</span></li><br />
<br />
<li style="padding-bottom:0.5em;"> CSS to add more space between chunks of text, especially more space above new SC. Also, increase leading throughout. <span style="color:#808080;">{Shawn, 3 June}</span></li><br />
<br />
<li style="padding-bottom:0.5em;"> change "Return to Guideline" to @@ <span style="color:#808080;">{Shawn, 3 June}</span></li><br />
<br />
</ul><br />
<br />
===Introduction (Implementing)===<br />
<ul><br />
<li style="padding-bottom:0.5em;">comment <span style="color:#808080;">{name}</span></li><br />
<br />
</ul><br />
<br />
===Definition of User Agent (Implementing)===<br />
<ul><br />
<li style="padding-bottom:0.5em;">comment <span style="color:#808080;">{name}</span></li><br />
<br />
</ul></div>Wdickhttps://www.w3.org/WAI/EO/wiki/index.php?title=UAAG_review&diff=5713UAAG review2013-06-12T23:16:21Z<p>Wdick: /* UAAG 2.0 Layers of Guidance */</p>
<hr />
<div>Nav: [[Main Page|EOWG wiki main page]]<br />
<br />
__TOC__<br />
<br />
Drafts:<br />
* [http://www.w3.org/TR/UAAG20/ UAAG 2.0]<br />
* [http://www.w3.org/TR/Implementing-UAAG20/ Implementing UAAG 2.0]<br />
* (also, fyi [http://www.w3.org/WAI/mobile/UAAGexamples Mobile Accessibility Examples from UAAG])<br />
<br />
<br />
==UAAG==<br />
<br />
===Overall===<br />
<ul><br />
<li style="padding-bottom:0.5em;">comment <span style="color:#808080;">{name}</span></li><br />
<br />
<li style="padding-bottom:0.5em;">Carefully consider what information should be in UAAG proper, and what should be in Implementing UAAG. Once UAAG is done, it cannot be changed; however, Implementing can be updated. Therefore, it might be wise to move some of the information from the Into of UAAG to Implementing. <span style="color:#808080;">{Shawn, 3 June}</span></li><br />
<br />
</ul><br />
<br />
===Abstract===<br />
[http://www.w3.org/TR/UAAG20/#abstract Abstract]<br />
<ul><br />
<li style="padding-bottom:0.5em;">comment <span style="color:#808080;">{name}</span></li><br />
<br />
</ul><br />
<br />
===Introduction===<br />
<ul><br />
<li style="padding-bottom:0.5em;">comment <span style="color:#808080;">{name}</span></li><br />
<br />
</ul><br />
<br />
===Overview===<br />
<ul><br />
<li style="padding-bottom:0.5em;">comment <span style="color:#808080;">{name}</span></li><br />
<br />
</ul><br />
<br />
===UAAG 2.0 Layers of Guidance===<br />
<ul><br />
<li style="padding-bottom:0.5em;">comment <span style="color:#808080;">{Wayne}</span><br />
<p>The Principles bullet should read, "At the top layer,"... Omitting the word layer caused me to trip while reading</p><br />
<p>Principles 4 and 5 are new and need more than just naming. The meaning of <em>facilitate programmatic access</em> and comply with <em>specifications and conventions</em> is not clear, and a brief description does not appear for a very long time. Please give each a brief description when they first appear.</p><br />
</li><br />
<br />
</ul><br />
<br />
===UAAG 2.0 Supporting Documents===<br />
<ul><br />
<li style="padding-bottom:0.5em;">comment <span style="color:#808080;">{name}</span></li><br />
<br />
</ul><br />
<br />
===Components of Web Accessibility===<br />
<ul><br />
<li style="padding-bottom:0.5em;">comment <span style="color:#808080;">{name}</span></li><br />
<br />
</ul><br />
<br />
===Levels of Conformance===<br />
<ul><br />
<li style="padding-bottom:0.5em;">comment <span style="color:#808080;">{name}</span></li><br />
<br />
</ul><br />
<br />
===Definition of User Agent===<br />
<ul><br />
<li style="padding-bottom:0.5em;">comment <span style="color:#808080;">{name}</span></li><br />
<br />
</ul><br />
<br />
===Modality Independence Principle===<br />
<ul><br />
<li style="padding-bottom:0.5em;">comment <span style="color:#808080;">{name}</span></li><br />
<br />
</ul><br />
<br />
===Relationship with WCAG 2.0===<br />
<ul><br />
<li style="padding-bottom:0.5em;">comment <span style="color:#808080;">{name}</span></li><br />
<br />
</ul><br />
<br />
===Relationship with ATAG 2.0===<br />
<ul><br />
<li style="padding-bottom:0.5em;">comment <span style="color:#808080;">{name}</span></li><br />
<br />
</ul><br />
<br />
<br />
==Implementing UAAG==<br />
<br />
===Overall (Implementing)===<br />
<ul><br />
<li style="padding-bottom:0.5em;">comment <span style="color:#808080;">{name}</span></li><br />
<br />
<li style="padding-bottom:0.5em;"> Examples: change some of the names to be more diverse <span style="color:#808080;">{Shawn, 3 June}</span></li><br />
<br />
<li style="padding-bottom:0.5em;"> CSS to add more space between chunks of text, especially more space above new SC. Also, increase leading throughout. <span style="color:#808080;">{Shawn, 3 June}</span></li><br />
<br />
<li style="padding-bottom:0.5em;"> change "Return to Guideline" to @@ <span style="color:#808080;">{Shawn, 3 June}</span></li><br />
<br />
</ul><br />
<br />
===Introduction (Implementing)===<br />
<ul><br />
<li style="padding-bottom:0.5em;">comment <span style="color:#808080;">{name}</span></li><br />
<br />
</ul><br />
<br />
===Definition of User Agent (Implementing)===<br />
<ul><br />
<li style="padding-bottom:0.5em;">comment <span style="color:#808080;">{name}</span></li><br />
<br />
</ul></div>Wdickhttps://www.w3.org/WAI/EO/wiki/index.php?title=Easy_Checks&diff=5697Easy Checks2013-06-11T21:14:29Z<p>Wdick: /* Next Steps */</p>
<hr />
<div>Nav: [[Main Page|EOWG wiki main page]] > [[Main_Page#Evaluation_pages | Evaluation Pages ]]<br /><br />
[[http://www.w3.org/WAI/EO/wiki/Web_Accessibility_Preliminary_Evaluation Old Web Accessibility Preliminary Evaluation page]]<br />
<br />
<br />
= Easy Checks - A First Look at Web Accessibility=<br />
<br />
<p><strong>Related pages:</strong></p><br />
<ul><br />
<li><strong>[http://www.w3.org/WAI/eval/preliminary Easy Checks &quot;published&quot; draft]</strong></li><br />
<li><strong>[http://www.w3.org/WAI/EO/Drafts/eval/checks#forms Forms bullet version], <br />[http://www.w3.org/WAI/EO/Drafts/eval/check-forms Forms prose version]</strong></li><br />
</ul><br />
<br />
<br />
__TOC__<br />
<br />
<p><strong>Related pages:</strong></p><br />
<ul><br />
<li><strong>[http://www.w3.org/WAI/eval/preliminary Easy Checks &quot;published&quot; draft]</strong></li><br />
<li><strong>[http://www.w3.org/WAI/EO/Drafts/eval/checks#forms Forms bullet version], <br />[http://www.w3.org/WAI/EO/Drafts/eval/check-forms Forms prose version]</strong></li><br />
</ul><br />
<br />
==To Do==<br />
<br />
[http://www.w3.org/WAI/eval/preliminary#titles Page titles]<br />
<ul><br />
<li>[OPEN action] Find a keyboard way to display the full page title in IE 9 and later and chrome. </li><br />
</ul><br />
[http://www.w3.org/WAI/eval/preliminary#interaction Keyboard access and visual focus]<br />
<ul><br />
<li>[EOWG thoughts?] Is it specific and clear enough to write: "To select a specific item within an element such as a drop-down list, press the Enter key or Space bar."</li><br />
<li>[EOWG thoughts?] In "what to do", visual focus: <br /><br />
"Check that the focus indicator is clearly visible as you tab through the elements, that is, you can tell which element has focus, for example, because it is highlighted. (A common problem is that the default focus indicator is turned off in CSS [@@ too jargony?] or elements are styled with borders that overlap or hide the focus indicator.)"</li><br />
</ul><br />
[http://www.w3.org/WAI/eval/preliminary#forms Forms and error messages ]<br />
<ul><br />
<li>[EOWG thoughts?] In "required fields" we may need to explain group label in the beginning.</li><br />
<li>[OPEN action] In "error messages", need to say more specifically how to check if the focus is at the error message.</li><br />
</ul><br />
[http://www.w3.org/WAI/eval/preliminary#media Multimedia (video, audio) alternatives]<br />
<ul><br />
<li>[OPEN action] In Section "captions", look for a way to turn on open captions with the keyboard, for example in Youtube activating the CC button.</li><br />
<li>[EOWG thoughts?] think of other examples for important noise, especially positive ones (instead of slamming and breaking:)</li><br />
</ul><br />
Throughout:<br />
<ul><br />
<li>Check img alts - some might have @@</li><br />
<li>Decide if we want more images for the steps. Search for [image].</li><br />
<li>Search for other open things in [brackets].</li><br />
<li>Search throughout for the perspective that the content needs to work, rather than the user has a limitation. e.g., 'users need to be able to' vs. 'websites need to enable users to' <span style="color:#808080;">{Shawn}</span></li><br />
</ul><br />
<br />
Misc:<br />
* Ask [http://ncdae.org/resources/cheatsheets/accessibility.php Identifying Web Accessibility Issues] to link to Easy Checks when it's more done.<br />
<br />
==Public Comments==<br />
<br />
===Jim Allan 6 June===<br />
<ul><br />
<li style="margin-bottom:0.5em;">Comment: Color/Contrast channeling Jared's &lt;rant&gt;!!! can we have an example of wretched grey text on a white background. Folks forget that grey and white are colors and may not think to check it.<br /><br />
[EOWG thoughts:<br />
<ul><br />
<li>comment <span style="color:#808080;">{name, date}</span><br />
<li>We could just change the first one to white background rather than adding another example. <span style="color:#808080;">{Shawn, 6 June}</span></li><br />
</ul><br />
</li><br />
<li style="margin-bottom:0.5em;">[closed?] Comment: zooming if you control+ in FF the images also get bigger. IE can change text size only (but with limits) main menu - view&gt;text size in windows with wheel mouse, can zoom using control and mouse wheel (forward for larger, backward for smaller)<br />
<br /><br />
<em><strong>Resolution proposal:</strong></em> No changes. We have in the instructions for FF for text-only "From the menubar, select View > Zoom Text Only or, View > Zoom > Zoom Text Only". Jim must have missed that on quick read. For IE, we previously decided that it was too different across IE versions and also do not want to require mouse wheel for a check.<br />
<br /><br />
[EOWG thoughts:<br />
<ul><br />
<li>comment <span style="color:#808080;">{name, date}</span><br />
</ul><br />
</li><br />
<li style="margin-bottom:0.5em;">[closed?] Comment: you need to describe &quot;visual focus&quot; - something like &quot;usually seen as a dotted rectangle surrounding a link. &quot; Visual focus is jargony<br />
<br /><br />
[EOWG thoughts:<br />
<ul><br />
<li>comment <span style="color:#808080;">{name, date}</span><br />
<li>previous wording was: "Check that the focus indicator is clearly visible as you tab through the elements, that is, you can tell which element has focus, for example, because it is highlighted." ... maybe Jim just missed that in quick read?<br />
<br /><br />
<em><strong>Resolution proposal:</strong></em> Edited it to : "Check that the focus indicator is clearly visible as you tab through the elements, that is, you can tell which element has focus, for example, links have a gray outline around them or are highlighted."<br /><br />
''Is that good enough?''<br />
</ul><br />
</li><br />
<li style="margin-bottom:0.5em; color:#585858;">[closed pending EOWG OK] Comment: Page title: you mention checking with WAT toolbar in IE...need a link and what is WAT? Alt text (or anywhere in the page): need links to all mentioned toolbars Also, FF toolbar??? - which one - the one from UIUC, or Pendrick developers, or ??? +1 Wave is linked!!<br /><br />
<em><strong>Resolution:</strong></em> Made the headings under &quot;Using these Easy Checks&quot; always visible and added &quot;FF Toolbar and IE WAT &quot; to &quot;Tools&quot;</li><br />
<li style="margin-bottom:0.5em; color:#585858;">[closed pending EOWG OK] Comment: in section: To practice checking alt text in BAD - what is BAD (I know, but newbies won't), make the link provided active<br /><br />
<em><strong>Resolution:</strong></em> Made the headings under &quot;Using these Easy Checks&quot; always visible so &quot;Practicing with BAD, the Before-After Demo&quot; is visible. Also linked all BAD page URIs.</li><br />
<li style="margin-bottom:0.5em; color:#585858;">[closed pending EOWG OK] Comment: keyboard access and visual focus a test page would be useful<br />
<br /><br />
<em><strong>Resolution:</strong></em> Added "[http://www.w3.org/WAI/eval/preliminary#visualfocusBAD To see visual focus with BAD]" section<br />
</li><br />
</ul><br />
<br />
===Other===<br />
<br />
[http://webaim.org/discussion/mail_message?id=23392 6 June, Ryan]<br />
<br />
==Overall Comments==<br />
<ul><br />
<br />
<li>Any edits based on input from [http://lists.w3.org/Archives/Public/w3c-wai-eo/2013AprJun/0058.html Tom J. (Wayne's forwarded e-mail)] ?<br />
<ul><br />
<li>comment <span style="color:#808080;">{name}</span></li><br />
<li>[in-progress] I agree with Tom's following thought: <br />"Looking for an even simpler FIRST check, I've tried this one:<br />FF Toolbar, Miscellaneous -> Linearize Page; Images -> Replace Images<br />
With Alt Attributes; CSS -> Disable Styles -> Disable All Styles.<br />
This is almost a visual "voice reader" simulation, except of course it<br />
doesn't say "image," "link," and so on. But if the page looks good this<br />
way (headings, organization, sensible alt text, etc.), it's probably<br />
close. If it doesn't make sense this way, then more thorough analysis<br />
is in order. (Try it on the inaccessible BAD Home page.)"<span style="color:#808080;">{Sylvie}</span></li><br />
<li><span style="color:#808080;">[closed] Tom writes: "I understand why they've had<br />
to include multiple systems (IE + FF), although FF can be used on any OS."<br />Sylvie: It can be useful to evaluate with at least two browsers as they do not behave the same. For that reason, I think it is important to talk about IE and FF. {Sylvie}</span></li><br />
<li>[http://www.w3.org/WAI/EO/wiki/Easy_Checks#Linearize_Page_.28Optional.29 Here is a draft] to add at the end of the current page if the group thinks it is useful and not beyond the scope of an "Easy Check" {Sharron June 4}</li><br />
</ul><br />
</li><br />
</ul><br />
<br />
==Linearize Page (Optional)==<br />
<br />
Not everyone has access to a screen reader or the knowledge of how to work with one. You may approximate the experience of a screen reader user by "linearizing" the page, removing images and styles so that the reading order and text alternatives are exposed and can be evaluated.<br />
<br />
===What to do:===<br />
<br />
The checks below provide instructions with different browsers for how to:<br />
<br />
* Expose text alternatives by removing images<br />
* Reveal the reading order by turning off the associated style sheets<br />
* Examine the resulting page display for an approximation of a screen reader experience.<br />
<br />
====To linearize with IE WAT==== <br />
# Open the page you are checking in the IE browser<br />
# Using the toolbar, choose Images > Remove Images<br />
# Next choose CSS > Disable CSS<br />
<ul><br />
<li>comment <span style="color:#808080;">{name}</span></li><br />
<li>Shortcuts in WAT toolbar are: <br /> With keyboard press ctrl+alt+shift+s to display the options dialog box and uncheck the boxes "Images" and "CSS", then select "ok".. <br /><span style="color:#808080;">{Sylvie, June 6}</span></li><br />
</ul><br />
<br />
====To linearize with FF web developer toolbar==== <br />
# Open the page you are checking in the FF browser<br />
# Using the toolbar, choose Images > Disable Images<br />
# Next choose CSS > Disable Styles > Disable All Styles<br />
<ul><br />
<li>comment <span style="color:#808080;">{name}</span></li><br />
<li>In the French Web Developer version the keyboard shortcut to hide CSS is alt+shift+a, but I am not sure if it is the same in the English one. For disabling images, I only have the French version's shortcuts here. <span style="color:#808080;">{Sylvie, June 6} </span></li><br />
</ul><br />
<br />
===What to check for:===<br />
<br />
Read through the resulting display and notice the following:<br />
<br />
* Make sure that there is text in place of any meaningful images and that the text provides the same information as the original. (review alt text section above)<br />
* Verify that the reading order is logical, complete, and makes sense.<br />
<br />
<br /><br />
<hr/><br />
<br />
====Comments on Linearize'''====<br />
'''''Do we want to include something like this at the end? <br/>What are the benefits? <br/>What are the cons? <br/>If we do, what comments do you have on this first draft text above? What should we call it?'''''<br />
<br />
* comment <span style="color:#808080;">{name, date}</span><br />
* I think this section could be helpful for people who need to have a quick look at a page without styles and images. this draft is not too long and clear. <span style="color:#808080;">{Sylvie, June 6}</span><br />
<br /><br />
<hr/><br />
<br />
==Introduction==<br />
'''[http://www.w3.org/WAI/EO/Drafts/eval/checks#introduction Introduction in WAI draft page]'''<br />
<br />
Status:<br />
* '''Complete, ready for detailed review.'''<br />
* no major edits since February<br />
<br />
Comments:<br />
<br />
* comment <span style="color: #808080;">{name, date}</span><br />
<br />
==Page title==<br />
<br />
'''[http://www.w3.org/WAI/EO/Drafts/eval/checks#title Page title in WAI draft page]'''<br />
<br />
Status:<br />
* '''Complete, ready for detailed review.'''<br />
* OPEN: a couple things listed in "To be implemented" below<br />
<div style="color:#808080;"><br />
* 30 May edit: significantly edited the first part.<br />
* 24 May edits: changed images.<br />
* 21 March edit: changed "Best practice is for titles to be "front-loaded" with the important and unique identifying information first..."<br />
</div><br />
Comments:<br />
<br />
* comment <span style="color:#808080;">{name, 00 month}</span><br />
<br />
==Image text alternatives ("alt text")==<br />
<br />
'''[http://www.w3.org/WAI/EO/Drafts/eval/checks#images alt text in WAI draft page]'''<br />
<br />
Status:<br />
* '''Complete, ready for detailed review.'''<br />
* only minor edits since February<br />
<br />
Comments:<br />
<br />
* comment <span style="color:#808080;">{name}</span><br />
<br />
==Headings==<br />
'''[http://www.w3.org/WAI/EO/Drafts/eval/checks#headings Headings in WAI draft page]'''<br />
<br />
Status:<br />
* '''Complete, ready for detailed review.'''<br />
* 30 May edits: changed 'What to check for' from questions to statements to be consistent with other sections.<br />
* 21 March edits: combined instructions under each tool<br />
<br />
Comments:<br />
<br />
* comment <span style="color:#808080;">{name}</span><br />
<br />
==Luminosity Contrast==<br />
'''[http://www.w3.org/WAI/EO/Drafts/eval/checks#contrast Visual contrast in WAI draft page]'''<br />
<br />
Status:<br />
* '''Overall flow, instructions, text is complete and ready for review.'''<br />
* OPEN: Needs someone to fill in some details on using the tools. - Vicki will do it<br />
<div style="color:#808080;"><br />
* 10 May edit: changed heading from [Luminosity Contrast ("color contrast")] to [Contrast Ratio ("color contrast")]<br />
* 22 March edit: changed heading to Luminosity Contrast ("color contrast")<br />
* 21 March edits:<br />
** changed heading to Visual contrast ("color contrast", luminosity contrast)<br />
** tweaked wording a bit and added: This accessibility requirement is sometimes called sufficient "color contrast"; however, that is incorrect — technically it's "luminosity contrast".<br />
* 7 March edit: moved the 3 options with pros & cons from under "To check contrast with IE WAT" up a level to apply to all.<br />
</div><br />
Comments:<br />
* <span style="color:#808080;">[closed] I think right above "Download the Color Contrast Analyzer" the heading needs to have the word "Windows" added so it changes to "To check contrast with any Windows browser." <span style="color:#808080;">{Anna Belle}</span><br />reply: a mac version is available - http://www.paciellogroup.com/node/18?q=node/20#macdownload <span style="color:#808080;">{Andrew, 15/March}</span><br/>'''Questions: '''Is "you don't need to install it so should be able to do even in environments where you cannot install software." true for that TPG Windows & Mac versions as well? The current link goes to Vision Australia page with "Color Contrast Analyzer". The TPG version is called "Contrast Analyser" - which is better. Should we just point to that one? <br />'''Reply: '''The CA and CCA are the same - when installed, the CA2.2a from TPG is actually 'Colour Contrast Analyser version 2.2a'. Also, the TPG and the Vision Australia downloads are the same tool - it was originally developed at Vision Australia then Steve moved it to TPG when he moved - VA retain up-to-dates version on their site. I don't know if the Mac version needs to be 'installed' or not. <span style="color:#808080;">{Andrew, 22/March}</span><br /><span style="background:yellow;">[open action for Mac]</span> Someone please check if "you don't need to install it so should be able to do even in environments where you cannot install software." is true for that TPG Windows & Mac versions?<br />I tried on a Mac and the link on the page (unlike Andrew's link) sends me to a download page that's for Windows not Mac. That's even when I'm on a Mac. Maybe have a second link for Mac?<span style="color:#808080;">{Anna Belle. May 30}</span><br />The Windows one required me to be admin as well, so I just deleted this all together. {Shawn}</span><br />
<br />
==Zoom==<br />
'''[http://www.w3.org/WAI/EO/Drafts/eval/checks#zoom Zoom in WAI draft page]'''<br />
<br />
Status:<br />
* '''Complete, ready for detailed review.'''<br />
<div style="color:#808080;"><br />
* 8 March edit: Added "If possible, you should check zoom text only." and moved "To check zoom text only" up.<br />
* 7 March edits were mostly minor. Note new second sentence in first paragraph: "Some need to change other aspects of text display: font, space between lines, and more." This is important so that readers don't think simple zoom covers all user needs (like in the color section we mention the need for low luminosity).<br />
</div><br />
Comments:<br />
<br />
* comment <span style="color:#808080;">{name}</span><br />
<br />
==Keyboard access, content order, visual focus==<br />
'''[http://www.w3.org/WAI/EO/Drafts/eval/checks#interaction Keyboard, etc. in WAI draft page]'''<br />
<br />
Status:<br />
* '''Complete, ready for detailed review.'''<br />
* 14 May: significant edits.<br />
<br />
Comments:<br />
<br />
* comment <span style="color:#808080;">{name}</span><br />
<br />
* Illustrations of focus indication would be useful. Shall I send screen shots to the list or how to provide? <span style="color:#808080;">{Sharron}</span><br />Send them to Shawn & she'll upload them :) <span style="color:#808080;">{Shawn}</span><br />
<br />
==Forms, form labels, and error messages==<br />
'''[http://www.w3.org/WAI/EO/Drafts/eval/checks#forms Forms in WAI draft page]'''<br />
<br />
Status:<br />
* 16 May: significant edits.<br />'''''Note: more updates coming'''''<br />
<br />
===Comments '''after''' 10 June===<br />
<br />
* comment <span style="color:#808080;">{name}</span><br />
<br />
<br />
===''Comments before 10 June''===<br />
<br />
* <span style="color:#808080;">[done] say explicti lables on radio buttons make the whole thing clickable! <span style="color:#808080;">{Shawn, Paul}</span><br />
* [closed? added to [http://www.w3.org/WAI/EO/Drafts/eval/checks#forms current draft] intro sentence with all issues] The prose version is a significant improvement over the bullet version. The former leads off with a clear introductory sentence and then proceeds with a nice overview of the issues, providing a rationale for the more detailed instructions that follow. The bullet version starts right off with specifics which is jarring and disorientating. <span style="color:#808080;">{Howard, 6 June}</span><br />
<br />
<ul><li><br />
Other observations/feedback: <span style="color:#808080;">{Howard, 6 June}</span><br />
<ul><br />
<br />
<li><span style="color:#808080;">[done. fixed] the link to the "preliminary" page is broken</span></li><br />
<br />
<li>'''<span style="background:yellow;">[EOWG open </span> - heading for this section simply "Forms?" or more?]'''<br />Title on current version is "Forms and Error Messages" but in this wiki it's "Forms, Form Labels, and Error Messages." I prefer the latter <ul><li>Currently the section covers: Labels, Keyboard Access, Instructions, and Error Handling" Maybe keep it short and just use "Forms" ? <span style="color:#808080;">{Shawn 10 June}</span></li></ul></li><br />
<br />
<li><span style="color:#808080;">[closed. [http://www.w3.org/WAI/EO/Drafts/eval/checks#forms current draft] has "Find forms on the page."] <em>"Find Forms"</em> header under "What to do" seems too open. Suggest: "Find the forms on the page" (too wordy?); or "Find form elements" (too technical?)</span> <ul><span style="color:#808080;">I agree. I like first suggestion and would add to this that we move "If there are forms on the page ...." sentence to below the bullet points and right above what it refers to. {Anna Belle, 8 June}</span></ul></li><br />
<br />
<li>[closed? [http://www.w3.org/WAI/EO/Drafts/eval/checks#forms current draft] has bullets under the subheads] This section, being lengthier than the others, calls for additional indentation - under the brown headers, such as "What to do", "What to check for", etc. Too much lines up along one left margin. Some additional indentation would add readability. (Perhaps once images are added, this will help subdivide the section)</li><br />
<br />
<li><span style="color:#808080;">[closed [http://www.w3.org/WAI/EO/Drafts/eval/checks#forms current draft] covers it in keyboard section] Maybe the "submit button" section could be replaced with a statement such as: <br />"Form data should not be submitted without user confirmation" (followed by more detailed instructions?)</span></li><br />
<br />
<li>[closed? edited in [http://www.w3.org/WAI/EO/Drafts/eval/checks#forms current draft]] I think error messages should be addressed in "to learn more about forms." Otherwise, this section is getting to lengthy and thus no longer an "easy check".</li><br />
<li>@@As mentioned under "to do items," the group label is not sufficiently explained. Maybe have a link from "group label" where it can be further explained.</li><br />
</ul></ul><br />
<br />
* As discussed in EOWG's 31 May teleconference, I suggest changing the checks order as proposed below: <br /><ol> <li>Labels</li><li>Instructions</li><li>Keyboard access and reading order</li><li>Submit buttons</li><li>Data input and error messages</li></ol><span style="color:#808080;">{Sylvie June 4, 2013}</span><br />
<br />
* In section "error messages", we should give clear instructions on what to look for, avoiding asking for judgement.<br /><ul><li>Check that there is guidance to help user understand and fix the error.</li><li>The focus moves to the error message</li><li>Error information is not located at the end of the form, but rather at the beginning.</li><li>The user is not requested to fill in the whole form again, but only the error fields.</li><li>If the error concerns a format, such as date, time, address, suggestions are made to enter the correct format.</li><li>If a required field has been forgotten, that this field is indicated with colour and text such as "mandatory" or *.</li></ul><span style="color:#808080;">{Sylvie June 4, 2013}</span><br />
* <span style="background:yellow;">[EOWG discuss]</span> '''Are these easy checks?''' I wonder if all of what's currently in the Forms section qualifies as easy checks? For example, <br />- Is "Instructions" too soft/unclear/nonspecific? <br />- Indicating required fields is a bit tricky. Do we say enough here? Or is it too complex for an easy check? ... oh, I see now that required is in the Instructions subsection and the Labels section. <br />- Is "Data input and error messages" too hard for an easy check? <br />Also: My preference would be *not to have any specific instructions* under "2. Keyboard access and reading order" but instead have just a point to the keyboard access section above (and make sure it clearly includes keyboard access issues for forms). If y'all disagree, we can talk about that in EOWG telecon. <br />Also: "4. Submit buttons" is already covered in the keyboard access section above. I don't think we want to repeat it. (also, most of these wouldn't have buttons labeled "submit", they'd be something like "go to Page") <br />'''Perhaps we want to re-focus this section to just Form Labels?''' <span style="color:#808080;">{shawn}</span><br />
<br />
* Reconsider the "What to do" section. Remember we've positioned this Easy Checks as applying to ONE web page (so "Check through the web pages to look for examples of forms." is not relevant). Can you make that section more succinct? Do we even need it at all? (Maybe to point out that a search box is a form?) <span style="color:#808080;">{Shawn}</span><br />
<br />
* BAD: Rather than having a link to BAD in the "To learn more about forms" section without any explanation of what to look for in BAD, perhaps it would be useful to have a section on using BAD to check forms issues -- for example, like this one for alt: <http://www.w3.org/WAI/EO/Drafts/eval/checks#bad-alt> ? <span style="color:#808080;">{shawn}</span><br />
<br />
* <span style="color:#808080;">[closed] Suggest changing:<br />Forms are used for interacting with websites and are common across the Web. They are used for activities such as search, login, registration, contact, booking, purchasing, banking, and interacting with government and other organizations. <br />to: <br />Forms are used for SUBMITTING DATA TO websites and are common across the Web. They are used for OPERATIONS such as search, login, registration, contact, booking, purchasing, banking, and interacting with government and other organizations. <span style="color:#808080;">{Howard 23 May}</span> <br />Suggest changing: <br />Forms are made up of controls such as text entry fields, check boxes, radio buttons, drop-down boxes and finish with submit buttons. <br />to: <br />Forms CONSIST of data entry fields, including text fields, check boxes, radio buttons, drop-down boxes and controls, usually consisting of a submit button. <span style="color:#808080;">{Howard 23 May}</span> <br />Actually, '''I think the introduction should take a different approach &mdash; not to introduce forms per se, but to introduce some of the accessibility issues with forms &mdash; like the other sections do.''' {Shawn 24 May}</span><br />
<br />
* <span style="color:#808080;">[closed] Suggest changing: <br />For longer or unusual forms, check for instructions. <br />to <br />For long or complex forms, check for instructions.</span><br />
<br />
* Suggest deleting: <br />Instructions are usually needed to explain how to fill out the form.<span style="color:#808080;">{Vicki 24 May}</span><br />
<br />
* <span style="color:#808080;">[closed] Suggest changing: <br />Are there instructions at appropriate places in the form (usually at the beginning and the start of discrete sections) that clearly explain how to fill out the form? <br />to <br />Are the instructions positioned appropriately (usually at the beginning of the form and/or at the start of specific sections)? <br />Do the instructions clearly explain how to fill out the form?</span><br />
<br />
* Suggest changing: <br />Are required fields explained in the instructions and clearly identified throughout the form? <br />to <br />Are the required (mandatory) fields explained in the instructions and clearly identified? <br /><span style="color:#808080;">{Vicki 24 May}</span><br />
<br />
* SK/MC case study - Good to have forms, but new post form was not available for public view. Really need to have a developers toolbar or IE WAT or WAVE to test this easily. Developer could not access tools from his machine and I could not access the page from my machine! We looked at BAD in order to consider the principles, having an example really helps. <span style="color:#808080;">{Suzette}</span><br />
<br />
==Multimedia (video, audio) alternatives==<br />
'''[http://www.w3.org/WAI/EO/Drafts/eval/checks#media Multimedia in WAI draft page]'''<br />
<br />
Status:<br />
* '''Complete, ready for detailed review.'''<br />
<div style="color:#808080;"><br />
* 24 May minor edits.<br />
* 21 March: significant edits.<br />
</div><br />
<br />
Comments:<br />
<br />
* comment <span style="color:#808080;">{name}</span><br />
* for other captioned sounds, suggest: <br />
Important sound other than dialogue — e.g., door slamming, broken glass, <em>water dripping, applause, laughter, writing on blackboard, tires squealing, etc.</em>[@@other examples of important noise, especially positive ones (instead of slamming and breaking:)] — is included. <span style="color:#808080;">{Howard, 6 June}</span><br />
<br />
* accessing cc with keyboard:<br />
<ul><ul><li>with nvda in firefox<li>'O' to find embedded object. Flash player announced as "embedded object, clickable"; (note: took me some moving and tabbing around the page before 'o' worked to find embedded objects)</li><li> pressing the enter key brings you to player controls;</li> <li>down-arrow will then take you to the closed captioning on/off control.</li><br /><br />
<li>Note: Without the screenreader could not really tell where I was on the youtube page using the keyboard. Not sure if these instructions can be made clear or definitive enough to be useful.</li><br />
<li>helpful youtube keyboard shortcut page: http://support.google.com/youtube/bin/answer.py?hl=en&answer=189278</li></ul></ul><span style="color:#808080;">{Howard, 6 June}</span><br />
<br />
* <span style="color:#808080;">[done] suggest changing <br /> "Most video on the web that provides captions has "closed captions" that need to be turned on." <br /> to: <br /> "Most video on the web that provides captions has "closed captions" that can be turned on and off". {Howard - May 31}</span><br />
<br />
==Next Steps==<br />
'''[http://www.w3.org/WAI/EO/Drafts/eval/checks#next Next Steps in WAI draft page]''' <br />
<br />
Status:<br />
* '''Complete ready for review''' - updated 4 June<br />
<br />
'''Comments on Next Steps'''<br />
* comment <span style="color:#808080;">{name, date}</span><br />
* maybe summarize other things that need to be checked that aren't covered on this page? <span style="color:#808080;">{Shawn, 7 June}</span><br />Potential things to list:<br />
** comment <span style="color:#808080;">{name, date}</span><br />
<br />
<br /><br />
<hr/><br />
<p> Comment: {Wayne Dick} The inclusion of the linearizatin is important to the easy checks. I liked Sharron's start, but it was not inclusive enough, nor did it motivate linerization sufficiently. Quite simply accessibility is not achievable without the ability to linearize content in a semantically faithful way. Sharron, I hope I expanded you piece to meet your approval</p><br />
<h2>Linearize the Page for Experiential Learning (Optional)<br />
</h2><br />
<p><br />
When a page is converted form text to speech, to Braille, or to very <br />
large print, the author's two dimensional presentation format breaks <br />
down. Before a page can be converted to an appropriate medium it must be<br />
reduced to a one dimensional information stream. This process is called<br />
linearizing the page.<br />
</p><br />
<p><br />
Not everyone has access to a screen reader, or powerful text <br />
customization tools required to experience linearized content as it is <br />
used, but a linearized presentation of content is easy to simulate using<br />
the tools we have introduced so far. This can give the fully sighted <br />
reader an understanding of the day to day experience of users with <br />
blindness or low vision.<br />
</p><br />
<p><br />
Linearization does not focus on any one success criterion, instead it <br />
reveals how well a page is organized to support accessibility. <br />
Example: Read the linearized view of the inaccessible version <br />
in the BAD Demo. That will be fun, and it reveals a lot of what can go <br />
wrong. <br><br />
</p><br />
<p><br />
The checks below provide instructions with different browsers for how to:<br />
</p><br />
<ol><br />
<li> Unclutter the linear view and expose text alternatives by removing images</li><br />
<li> Reveal the reading order by turning off the associated style sheets,</li><br />
<li>Expose navigation support for a one dimensional content format, and<br><br />
</li><br />
<li> Reveal the resulting page display for an approximation of a screen reader / customized text experience.</li><br />
</ol><br />
<h3><br />
To linearize with IE WAT<br />
</h3><br />
<ol><br />
<li> Open the page you are checking in the IE browser</li><br />
<li> Using the toolbar, choose Images &gt; Remove Images</li><br />
<li> Next choose CSS &gt; Disable CSS</li><br />
</ol><br />
<p><br />
Shortcuts in WAT toolbar are:<br />
With keyboard press ctrl+alt+shift+s to display the options dialog <br />
box and uncheck the boxes "Images" and "CSS", then select "ok"..<br />
{Sylvie, June 6}<br />
</p><br />
<h3>To linearize with FF web developer toolbar<br />
</h3><br />
<ol><br />
<li> Open the page you are checking in the FF browser</li><br />
<li> Using the toolbar, choose Images &gt; Disable Images</li><br />
<li> Next choose CSS &gt; Disable Styles &gt; Disable All Styles</li><br />
</ol><br />
<p><br />
In the French Web Developer version the keyboard shortcut to hide <br />
CSS is alt+shift+a, but I am not sure if it is the same in the English <br />
one. For disabling images, I only have the French version's shortcuts <br />
here. {Sylvie, June 6}. This doesn't work in the English version {Wayne,<br />
June 11}<br><br />
</p><br />
<h3>What to check for:</h3><br />
<p><br />
Read through the resulting display and notice the following:<br />
</p><br />
<ol><br />
<li> Make sure that there is text in place of any meaningful images <br />
and that the text provides the same information as the original. (review<br />
alt text section above)</li><br />
<li> Verify that the reading order is logical, complete, and makes sense.</li><br />
<li> <new> Make sure that there are reasonable ways to skip around <br />
long lists of links and other boiler plate content that is repeated on <br />
every page in the site. </new></li><br />
</ol><br />
<br />
==Contributors==<br />
Thanks to:<br />
* Those who participated in the F2F before CSUN in February: Andrew, Anna Belle, Helle, Jennifer, Shadi, Sharron, Shawn, Wayne<br />
* Those who edited in December and January: Suzette (forms, @@), Sharron (Intro, @@), Shawn (Intro, page titles, headings, alt text), Ian (zoom n text resize).<br />
* Those who commented in December and January: Sylvie, Wayne, Anna Belle, ...<br />
* Those who drafted checks 16-28 November:<br />
** Sharron for drafting {list sections!}<br />
** Suzette for drafting : Check usable with page zoomed and text enlarged, Check color contrast, Check color coding and shape coding, {?other sections}<br />
** Wayne for drafting {list sections!}<br />
* Andrew & Shawn for editing the [http://www.w3.org/WAI/EO/wiki/Web_Accessibility_Preliminary_Evaluation#Check_keyboard_access_and_visual_focus_.5Bmostly_drafted.5D keyboard access & visual focus section] in early Nov.<br />
* Ian, Suzette, Vicki, Sylvie, Helle, Shawn for working on an early draft at the [http://www.w3.org/2012/11/02-eo-minutes f2f in Nov].<br />
* Sharron for help making all the early drafts and versions less confusing.<br />
* Wayne and Ian for sharing colleagues' related work.<br />
* Denis for edits to the old page content.<br />
<br />
testing image: http://www.w3.org/WAI/images/search-icon.png<br />
<br />
=Internal Notes=<br />
<br />
==Illustrations==<br />
<br />
'''Note:'''<br />
* '''To see all illustrations''', make sure to "expand all sections" because some of the illustrations are in collapsed sections. ''(however, keep in mind that most of the images will be collapsed by default)''<br />
* '''Make sure to evaluate the images in context''', that is, read the text around it and imagine you are a user.<br />
<br />
'''Questions:''' How is the current use of images for illustrations throughout the draft? Too much? Not enough? Mostly helpful? Too cluttering? Feel free to comment in general, and on specific images.<br />
<br />
<ul><br />
<li>comment <span style="color:#808080;">{name}</span></li><br />
<li>From [http://www.w3.org/2013/05/24-eo-minutes 24 May teleconference]:<br />
<ul><br />
<li>Generally the conceptual images are useful for [http://www.w3.org/WAI/EO/Drafts/eval/checks#contrast contrast] and [http://www.w3.org/WAI/EO/Drafts/eval/checks#zoom zoom]; simply the [http://www.w3.org/WAI/EO/Drafts/eval/checks#title page title images] {done 24 May}.</li><br />
<li>Mixed perspectives on the images showing menu items and such. For some people they are just clutter, the word instructions are clear enough. For other people, the images really help.</li><br />
<li>For now:<br />
<ul><br />
<li>Include images showing menu items and such judiciously &mdash; if in doubt, do not include an image.</li><br />
<li>'''Crop or gray out all unnecessary clutter in images'''. (for example, [http://www.w3.org/WAI/images/easychecks/page-title-tab-popup.png page-title-image] has the content of the web page grayed out.)</li><br />
</ul><br />
</li><br />
</ul><br />
</li><br />
</ul><br />
<br />
'''Strategy:''' I'd like to discuss strategy for illustrations. <span style="color:#808080;">{Anna Belle, June 9}</span> Here are questions to consider:<br />
<br />
<ul><br />
<li>Do we want to use captions? Always? Sometimes? If sometimes, then what distinguishes when they are needed? </li><br />
<li>If we use captions, then how? E.g. do we give a 10 pixel padding with a border that encloses both image and captions?</li><br />
<li>Do we have images embedded in the text flow or do we separate them out (e.g. float to right)?</li><br />
<li>In some images do we want to use embedded explanatory text and arrows? This may be necessary if we aren't using captions. And even if we do use captions, for some concepts it may illustrate the point more clearly.</li><br />
<li>What is the maximum width for an image?</li><br />
<li>If width is narrow (e.g. 350 pixels), some images will need to be shrunk to a size where detail may be lost. Is that okay? Or do we want to offer a link to a larger version of the image in such cases?</li><br />
<li>Do we want to number illustrations? Thus in the text we could say, "See Figure 3" multiple times if Figure 3 is relevant multiple times.</li><br />
<li>Do we want to incorporate all illustrations into the expand sections button? Or perhaps have a separate "See illustrations" button? (I dislike both of these ideas, by the way.)</li><br />
<li>Do we want to limit illustrations to one per concept? If the concept is tricky to illustrate (e.g. how to see titles) do we want to offer the option of clicking through to more illustrations?</li><br />
<li>Do we want to standardize the format to the image? JPG? SVG? PNG?</li><br />
<li>Would it be helpful to specifically state the goal for each illustration in the wiki? E.g. with titles, is it to show people how to see the title at the top of a browser (whether embedded in a tab or not)?</li><br />
</ul><br />
<br />
==Case study notes==<br />
<br />
'''See [http://www.w3.org/WAI/EO/wiki/Prelim_Eval_2013-May-30#SK.2FMC_Case_Study_Notes SK/MC Case Study Notes] in the 30 May 2013 snapshot<br />
'''<br />
<br />
==Consider for Later==<br />
<br />
* The text says: "The first thing screen readers say when the user goes to a different web page is the page title. Page titles are important for orientation — to help users know where they are and move between open pages."<br />Would it be useful to have a sound clip of the screen reader going through page titles? Low priority, but maybe neat for people who don't know screen readers? {Shawn}<br />
<br />
==previous versions, etc.==<br />
* '''[http://www.w3.org/WAI/EO/Drafts/eval/checks WAI draft page]'''<br />
* [http://www.w3.org/WAI/EO/wiki/Eval_Analysis#Title_ideas title ideas]<br />
* '''For tasks, example use cases with audience, and focus for this and related documents, see the [[Eval Analysis]] page, including the table at the top and the specific [http://www.w3.org/WAI/EO/wiki/Eval_Analysis#Preliminary_Evaluation_Analysis Analysis] section at the bottom'''<br />
* A template for the check items is at the top of the [http://www.w3.org/WAI/EO/wiki/Talk:Web_Accessibility_Preliminary_Evaluation discussion tab].<br />
* For previous drafts and contributed material, see:<br />
** [[Prelim Eval 2013-May-30]] - snapshot of draft on 30 May 2013 -- '''includes [http://www.w3.org/WAI/EO/wiki/Prelim_Eval_2013-May-30#SK.2FMC_Case_Study_Notes SK/MC case study info]'''<br />
** [[Prelim Eval 2013-March-7]] - snapshot of draft on 7 March 2013<br />
** [[Prelim Eval 2013-Feb-26]] - snapshot of draft on 26 February 2013 - end of f2f before more edits<br />
** [[Prelim Eval 2013-Feb-21]] - snapshot of draft on 21 February 2013<br />
** [[Prelim Eval 2013-Feb-08]] - snapshot of draft on 8 February 2013 in the middle of edits<br />
** [[Prelim Eval 2013-Feb-01]] - snapshot of draft on 1 February 2013 before edits<br />
** [[Prelim Eval 2013-Jan-24]] - snapshot of draft on 24 January 2013<br />
** [[Prelim Eval 2013-Jan-17]] - snapshot of draft on 17 January 2013<br />
** Extensive revisions and suggestions at [[Archived_Work_on_PreLimEval]] ([http://www.w3.org/WAI/EO/wiki/Archived_Work_on_PreLimEval#Check_link_text_.5B15:_probably_not.5D_.5Bpartly_drafted.5D Links section])<br />
** From Wayne & Tom [[Prelim Eval input: Smart analysis simplified]]<br />
** Old page with Denis' edits and Ian's input in [[Preliminary Eval - old notes]]</div>Wdickhttps://www.w3.org/WAI/EO/wiki/index.php?title=WCAG-EM_review&diff=4674WCAG-EM review2013-04-11T01:15:36Z<p>Wdick: /* other */</p>
<hr />
<div>Nav: [[Main Page|EOWG wiki main page]]<br />
<br />
__TOC__<br />
Links:<br />
* [http://www.w3.org/TR/WCAG-EM/ WCAG-EM document] - latest published Working Draft<br />
* [http://www.w3.org/WAI/ER/2011/eval/track/issues/open Open Issues] - Eval Task Force issue tracking<br />
<br />
Reminder: EOWG will focus on the types of questions below under [[#Comments submitted on 22 October 2012]]. If you have comments on specific technical points in the document, you can submit them directly yourself -- that is, e-mail them to public-wai-evaltf@w3.org 22 <br />If you're not sure, feel free to put your comments here and the Group will decide if they are ones you should send yourself.<br />
<br />
=March 2013 Comments on 26 February 2013 Working Draft=<br />
<br />
==General==<br />
<br />
<ul><br />
<br />
<li style="padding-bottom:1em">'''Location/Summary:''' Change.<br/>''Rationale: ''<span style="color: #808080;">{Name}</span></li><br />
<br />
</ul><br />
<br />
<br /><hr /><br />
<br />
<div style="color:#808080;"><br />
===EOWG discussed comments (General):===<br />
<ul><br />
<li style="padding-bottom:1em">'''Table of Contents:''' Change headings to something like: "Contents Summary" and "Detailed Contents". Include the Appendices in the Detailed Contents list, rather than under a separate heading.<br />
<ul><li>''initial comment: I wonder if it is necessary to list the main section in an "overview" heading, then to list all sections in a "sections heading" and have a list of appendices at last. Why not displaying a classical "table of contents" as in WCAG or other W3C documents? May be give the ability to expand/collapse the different sections (in the table of contents)? <span style="color: #808080;">{Sylvie 22/March}</span>''</li><br />
<li>''additional exchange: I think an expand/collapse menu could work <span style="color: #808080;">{Vicki - March 31}</span><br />This is to follow the W3C TR format, and I don't think it's worth pushing for adding the expand collapse here. OK? <span style="color: #808080;">{Shawn}</span> <br />Ok - cool with that <span style="color: #808080;">{Vicki - 3 April}</span>''</li></ul><br />
</li><br />
<li style="padding-bottom:1em">'''Step headings and "Methodology Requirement":'''<br />
<ol><br />
<li>Differentiate the Step headings from the statement that follows. Maybe make the headings even more terse, e.g.,<br />"Define the Scope of the Website"->"Define the Scope", <br />"Define the Goal of the Evaluation"->"Define the Goal", <br />"Define the Conformance Target"->"Define the Conformance", <br />"Define the Techniques and Failures to be Used (Optional)"->"Define the Techniques and Failures (optional)"</li><br />
<li>Delete "Methodology Requirement" and the colon so it's like:<br /><br />
&lt;h4&gt;Step 1.a. Define the Scope<br /><br />
&lt;p class="req"&gt;1.a. Define the scope of the website.<br />
</li><br />
</ol><br />
<ul><br />
<li>''initial comment: I don't understand the difference between h4: "Step 1.a: Define the Scope of the Website" and the following sentence: "Methodology Requirement 1.a: Define the scope of the website." When you listen to it, it sounds redundant but there may be a reason for this redundancy. I think this question is repeated over all the section. <span style="color: #808080;">{Sylvie 22/March}</span>''</li><br />
</ul></li><br />
<br />
<li style="padding-bottom:1em">'''Statement under Steps''' ''(e.g., "Methodology Requirement 1: Define the evaluation scope according to Methodology Requirement 1.a, Methodology Requirement 1.b, Methodology Requirement 1.c, and optionally Methodology Requirement 1.d.")'': remove the links to the sub-steps so it's:<br />&lt;p class="req"&gt;1. Define the evaluation scope<br />&lt;p class="req"&gt;2. Explore the website to be evaluated<br />&lt;p class="req"&gt;3. Select a representative sample of web pages from the website<br />&lt;p class="req"&gt;4. Audit the selected sample of web pages<br />&lt;p class="req"&gt;5. Document the evaluation findings<br />
<ul><br />
<li>''rationale:'' They are long, redundant, and the links are distracting.</li><br />
</ul><br />
</li><br />
<br />
<li style="padding-bottom:1em">'''Definition lists:''' Change the definition lists in some places where it would be better to use different markup. For specific places and rationale, see [http://lists.w3.org/Archives/Public/w3c-wai-eo/2013JanMar/0068.html e-mail] <span style="color: #808080;">{Bim}</span></li><br />
<br />
<li style="padding-bottom:1em">'''Summary sheet:''' Provide a one-page summary in multiple formats, e.g., HTML, RTF, spreadsheet, pretty PDF for printing. (EOWG can help with this.)</li><br />
<br />
</ul><br />
<br />
</div><br />
<br />
==[http://www.w3.org/TR/WCAG-EM/#abstract Abstract]==<br />
<ul><br />
<li style="padding-bottom:1em">'''Location/Summary:''' Change.<br/>''Rationale: ''<span style="color: #808080;">{Name}</span></li><br />
</ul><br />
<br /><hr /><br />
<br />
<div style="color:#808080;"><br />
===EOWG discussed comments (Abstract):===<br />
Eval TF note: Comments on the abstract also apply to the similar sentence in the main document.<br />
<ul><br />
<li style="padding-bottom:1em">Replace &quot;one possible approach&quot; with something that gives it more credibility and more strongly recommends it, e.g., &quot;one established approach&quot;. see brainstorms in [approach - EOWG minutes 5 April]<br /><br />
<ul>''initial comments:''<br />
<li>''Rationale: It sounds too tenuous and it seems we could be more encouraging. Something like “one proven method” or something. <span style="color: #808080;">{Sharron 28 March}</span>''</li><br />
</ul><br />
</li><br />
<li>Replace &quot;However, this methodology does not replace the need for quality assurance measures that are implemented throughout the design, development, and maintenance of websites to ensure their accessibility conformance.&quot; <br />with: &quot;This methodology does not replace the need for quality assurance measures implemented throughout design, development, and maintenance.&quot;<br />''<span style="color: #808080;">{initial comment: Sharron}</span>''</li><br />
</ul><br />
<br />
</div><br />
<br />
==Introduction section==<br />
<ul><br />
<li style="padding-bottom:1em">'''Location/Summary:''' Change.<br/>''Rationale: '' <span style="color: #808080;">{Name}</span></li><br />
<br />
<li style="padding-bottom:1em">[<span style="color: #808080;"><span style="background:yellow;">Wayne</span> - here's a placeholder for your comment]</span><br />'''[http://www.w3.org/TR/WCAG-EM/#audience Purpose of the Document] (and maybe elsewhere):''' @@Clarify that this is not required methodology for most developers.<br/>''Rationale: ''@@ <span style="color: #808080;">{Wayne}</span></li><br />
<br />
</ul><br />
<br />
<br /><hr /><br />
===EOWG discussed comments (Introduction):===<br />
<br />
<div style="color:#808080;"><br />
<ul><br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#terms Terms and Definitions], Common Functionality.''' Change the term &quot;Common Functionality&quot;.<br />
See brainstorms in [common terms shortlist - EOWG minutes 5 April] and [common discussion - EOWG minutes 5 April]<br />
<ul>''initial comments''<br />
<li>''Not clear about the term &quot;common functionality&quot;. Common to what? Could another term be used that denotes the completion of a task - &quot;Task achievement&quot; perhaps? <br/><br />
''Rationale: &quot;Common&quot; is not the right word for this and authors do not want to use &quot;essential&quot;'' <span style="color: #808080;">{Sharron 28 March}</span>''</li><br />
</ul><br />
</li><br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#reading Background Reading], linked headings:''' (minor issue) Unlink the headings and add those links in the lists.<br/> ''Rationale: It's inconsistent and a bit cludgy for the some headings to be links and not others. Also, it would be best to properly indicate the link to the WCAG Oveview. Also, people with some link indicators turned off (e.g., underlining) will miss that the headings are links. <span style="color: #808080;">{initial comment: Shawn}</span>''</li><br />
<li style="padding-bottom:1em"><br />
'''[http://www.w3.org/TR/WCAG-EM/#introduction Introduction] "need"'''. Replace the words &quot;need&quot; and &quot;needs&quot;. Probably replacing with &quot;should&quot; would be simpliest; however, we understand there issues with that word. <br />
See brainstorms in [needs - EOWG minutes 5 April]<br />
<ul>''initial comments''<br />
<li>''Don't like the repetition of &quot;need,&quot; &quot;needs to&quot;<br />Rationale: It doesn't actually make sense, seem true. Better to use &quot;should&quot;<span style="color: #808080;"> {Sharron, 28/March}</span>''</li><br />
</ul><br />
</li><br />
<li style="padding-bottom:1em"> '''[http://www.w3.org/TR/WCAG-EM/#introduction Introduction] Later on.''' From the second sentence, remove the words &quot;Later on&quot;<br />
<ul>''initial comments''<br />
<li> ''Rationale: content could well be in the process of being written or content could already be available. In other words, content creation may not necessarily take place later on. <span style="color: #808080;">{Vicki -31 March}</span>''</li><br />
</ul><br />
</li><br />
<li style="padding-bottom:1em">'''Abstract/Intro/Scope:''' - Tighten it up. It should be a short summary. Best if the whole this is not exactly the same wording as later in doc.<br />
<ul>''initial comments'' <li>''A large part of the Abstract is repeated in the Introduction and Scope section. Is this really intentional?<br/>Rationale: I think documents like these are already long enough, without some content being repeated. <span style="color:#808080;">{Denis 29 March}</span>''<br /><br />
''I think it's common practice for the Abstract to be a summary of material from the main document, and therefore should repeat info.<span style="color: #808080;">{Shawn}</span>''</li><br />
</ul><br />
</li> <br />
</ul><br />
<br />
<ul><br />
<br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#audience Purpose of the Document]:''' Re-write the list to be more clear, and to focus on the most common uses first. fyi, see [http://www.w3.org/WAI/eval/conformance#for Who WCAG-EM is for] in Overview page.<br/>''Rationale:'' As written, the repetition of words makes it quite difficult to parse. Also, we are concerned about having "website developers" as the first item. See: Shadi (for discussion in [http://www.w3.org/2013/02/26-eo-minutes#item01 EOWG f2f before CSUN]).<br />(Below are a couple ideas from individuals. EOWG didn't have time to work through these.)</li><br />
<br />
<ul>''initial comments:''<br />
<br />
<li style="padding-bottom:1em">''The readability of the "Purpose of this Document" section seems difficult. Because the bullet items are long, they seem too bunched together at their current spacing and too wide for easy reading of a list. Also, many of the lines begin with very similar wording: "web accessibility" begins 4 of the 8 lines; web or website begins every line. Lists with similar wording, especially at the beginning reduce readability since it's difficult to distinguish one line from another. Perhaps some lines could start with a distinct function instead of the type of user. Or set up the list as a table with the type of user on the left column and the function or purpose in the right column.<br />
<br />
For example:''<br />
<br />
<table width="80%" border="1" cellspacing="1" cellpadding="1" style="color:#808080;"><br />
<tr><br />
<th scope="column">Function</th><br />
<th scope="column">Example</th><br />
</tr><br />
<tr><br />
<td><strong>An evaluation tool</strong></td><br />
<td><strong>Web developers</strong> who want to evaluate the accessibility conformance of their websites<br />
[Suggested Change] Web Developers who's primary duties include evaluation for web accessibility conformance</td><br />
</tr><br />
<tr><br />
<td><strong>Analysis &amp; reporting</strong></td><br />
<td><strong>Consultants</strong> who want to report the accessibility conformance of websites to their owners</td><br />
</tr><br />
<tr><br />
<td><strong>A learning tool</strong></td><br />
<td><strong>Accessibility researchers</strong> and disability advocates who want to learn accessibility conformance practices</td><br />
</tr><br />
<tr><br />
<td><strong>A teaching tool</strong></td><br />
<td> <strong>Trainers and educators</strong> who want to teach methods and approaches for web accessibility evaluation</td><br />
</tr><br />
<tr><br />
<td><strong>Accessibility Benchmarking</strong></td><br />
<td><strong>Individuals</strong> who want to benchmark or compare the accessibility conformance of websites</td><br />
</tr><br />
</table><br />
<br />
''I'm not sure I know the best solution, only that the readability of this section is problematic. <span style="color: #808080;">{Howard, 21/March }''</span></li><br />
<li><p>The claim that WCAG-EM is for web developers who are interested in accessibility, will probably discourage more developers than it will encourage. WCAG-EM is for developers who specialize in accessibility or who want to specialize in accessibility. It is way to exhaustive for a general web developer who wants to write accessible code. I fear that casting the net too broadly will discourage many well meaning developers, and may inhibit adoption by people who need it. </p><br />
<p><b>Possible Danger:</b> Administrators who are ignorant of the divisions of labor in a web development project may assign this document to all developers, and accidentally cause push back from developers who do not need and cannot tolerate this level of detail. </p>{Wayne}</li><br />
<br />
<li>''[further comment] Agree with the difficulty of reading. Very much like the table.<span style="color: #808080;">{Sharron, 28/March }</span>''</li><br />
<br />
<li>''The "who" refers back to a process, not a person, in the bullet item "Web accessibility monitoring activities who want to benchmark or compare the accessibility conformance of websites" under "Purpose of Document." One possible solution: change "monitoring activities" to "monitors."<span style="color: #808080;">{Howard, 21/March }</span>''</li><br />
<li>''Observation: The list indicates use cases that "want" to perform an activity, how about "need" to perform an activity? Possibly, by shortening the items for easier reading, and including some "need" to perform activities, the list might not seem repetitive (i.e. 4x starting with "Web accessibility...") and may be easier to read. (I would even remove the repeated instances in the bullet points "of websites" since it it's clear in the context of the document that the reference is to accessibility conformance "of websites"). Suggested rewording with shorter sentences:<br /><br />
<br />
• Accessibility evaluation service providers who need to evaluate websites for accessibility conformance <br /><br />
• Experts performing accessibility monitoring activities who need to benchmark or compare the accessibility conformance of websites<br /><br />
• Consultants who need to analyze and report on accessibility conformance of websites<br /><br />
• Developers who want to evaluate accessibility conformance of their websites to monitor or improve them<br /><br />
• Website owners, procurers, and suppliers who want to learn about the accessibility conformance of their websites<br /><br />
• Researchers and disability advocates who want to explore accessibility conformance practices<br /><br />
• Accessibility trainers and educators who want to teach methods and approaches for web accessibility evaluation<br /><br />
• Web masters, content authors, designers, and others who want to learn more about web accessibility and evaluation<br /><br />
<span style="color: #808080;">{Vicki - 1 April }</span>''</li><br />
</ul><br /></li><br />
<br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#scope Scope of this Document], first sentence: '''Format it as a list.<br />
<ul><li>''initial comment: the first para under 'Scope' would be easier to read as a list rather than a ';' separating parts of a long para <span style="color: #808080;">{Andrew, 15/March}</span>''</li><br />
<li>''[further comment: Scope: Yes, agree, presentation using a list style would make the scope more readable <span style="color: #808080;">{Vicki - 31 March}</span>''</li><br />
</ul></li><br />
<br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#audience Purpose of this document], last sentence:''' Delete the sentence starting with "Complementary resources on ..." and add those resources to the next section "Background Reading".<br />
<ul><li><br />
''initial comment: I agree with the readability difficulties. It could also be improved in the paragraph beginning with "Complementary resources on" <br />Suggestion: Begin with: For further information, see complementary resources below." Then list those resources in a bulleted list. <span style="color: #808080;">{Sylvie 22/March}</span>''<br />
</li></ul></li><br />
</ul><br />
<br />
</div><br />
<br />
==Using this Methodology section==<br />
<ul><br />
<br />
<li style="padding-bottom:1em">'''Location/Summary:''' Change.<br/>''Rationale: '' <span style="color: #808080;">{Name}</span></li><br />
<br />
<li style="padding-bottom:1em">[http://www.w3.org/TR/WCAG-EM/#usage Using this methodology], first paragraph: Reword to be more positive and be in-line with [http://www.w3.org/WAI/EO/Drafts/eval/checks Easy Checks] (which will replace the old Preliminary Eval page)</span><br />
<ul><br />
<li>[OPEN] '''Suggested rewording:''' A preliminary review can be quite useful to identify obvious errors although it will not check every accessibility issue and will likely not catch all of the problems on a site. Nevertheless, to develop a rough understanding of the overall performance of the website, reviewers may conduct such an exploration using WAI's [http://www.w3.org/WAI/eval/preliminary.html Easy Checks - A First Review of Web Accessibility]<br/>''Rationale: Emphasizes usefulness rather than "cursory" '' <span style="color: #808080;">{Sharron 28 March}</span></li><br />
<br />
''initial comments:''<br />
<li>''In second sentence: "A more cursory approach for exploring the accessibility of a website", the term "cursory approach" is not clear to me. Is it jargony? Why not using a term that everyone can better understand? <span style="color: #808080;">{Sylvie 22/March}</span>''</li><br />
<li>''For better readability, it may better to split following sentence in two: <br />Actual text: "In many cases it is advisable to carry out such preliminary reviews before applying this methodology, for example to identify obvious errors and to develop a rough understanding of the overall performance of the website."<br />Suggestion: "In many cases it is advisable to carry out such preliminary reviews before applying this methodology. For example, identify obvious errors and develop a rough understanding of the overall performance of the website. <span style="color: #808080;">{Sylvie 22/March}</span>''</li><br />
</ul><br />
</li><br />
</ul><br />
<br />
<br /><hr /><br />
<div style="color:#808080;"><br />
<br />
===EOWG discussed comments (Using this Methodology):===<br />
<ul><br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#applicability Scope of Applicability]'''<br />
<br />
Needs clarification.<br />
<ul><br />
''initial comment:''<br />
<li>''Confused between paragraph above &quot;Example of a website diagram&quot; and one below. Above paragraph seems to indicate that a self-contained subsection of a website would qualify for this evaluation as a &quot;self-enclosed&quot; site. In the paragraph below the diagram, the implication is that &quot;sub-sections&quot; of a university site may not be considered self-enclosed sites: &quot;In the example above, none of the depicted parts may be excluded from the scope of evaluation in the context of this methodology, if it is to be applied to the university website.&quot; Perhaps this is referring to evaluating the entire university site as a whole. Anyway - it's a confusing section. I can't offer a rewording until I know for sure the exact meaning trying to be conveyed. <span style="color: #808080;">(Howard 4 April)</span>''</li><br />
</ul><br />
</li><br />
<li style="padding-bottom:1em"> '''Duplicate sentence: ''' [http://www.w3.org/TR/WCAG-EM/#teams Review Teams] and immediately following section, [http://www.w3.org/TR/WCAG-EM/#users Involving Users] both begin with the same sentence. &quot;The methodology defined by this document can be carried out by an individual evaluator with the skills described in section Required Expertise.&quot; Reconsider if this sentence is really necessay in both places. If so, consider that it will look like an error to some people, so see if there's aother way to cover the information.<br />
<ul><br />
''initial comment:''<br />
<li>''Is this really necessary?''<br/><br />
''Rationale: I don't understand what it adds to the point of either of these sections. <span style="color: #808080;">{Sharron 28 March}</span>''</li><br />
</ul><br />
</li><br />
<br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#specialcases Particular Types of Websites], Web Applications section:''' Rewrite to be more clear.<br />(Below are a couple ideas from individuals. EOWG didn't have time to work through these.)<br />
<ul><br />
<li>''initial comment: In second bullet "Web Applications", the note of this part is very long due to the many links and few sentences. Is it possible to make it clearer? After I read it twice, I still try to understand it. <span style="color: #808080;">{Sylvie 22/March}</span>''</li><br />
<li>''I can understand why the definition may be difficult to understand. Below is a suggested abridged version:''<br/ ><br />
''Websites with a limited number of pages which dynamically generate content are considered as a single website (or part of a larger site). Each state of a web page and content-generated web page for the purpose of this document should be included as a candidate for sampling. <span style="color: #808080;">{Vicki - 1 April}</span>''</li><br />
</ul></li><br />
</ul><br />
<br />
</div><br />
<br />
==Conformance Evaluation Procedure section==<br />
<ul><br />
<br />
<li style="padding-bottom:1em">'''Location/Summary:''' Change.<br />
<br> <br />
The paragraph describing the flow diagram has visual dependencies. Change to:<br />
"The workflow diagram depicts each of the steps defined in this<br />
section. Work flow starts with the first step and proceeds to the last<br />
step in order. In addition, the diagram permits evaluators to return<br />
to any preceding step in the process whenever the evaluation reveals a<br />
need to rework a sequence of steps."<br />
<br/>''Rationale: '' <span style="color: #808080;">{Wayne}</span></li><br />
Describing arrows. The new description is a functional description of the picture.<br />
</ul><br />
===Step 1: Define the Evaluation Scope Section===<br />
<ul><br />
<br />
<li style="padding-bottom:1em">'''Location/Summary:''' Change.<br/>''Rationale: '' <span style="color: #808080;">{Name}</span></li><br />
<br />
<li style="padding-bottom:1em">[EOWG sees the need for the sentence. since some found it confusing, please look to see if can make it more clear.]<br /><br />
'''[http://www.w3.org/TR/WCAG-EM/#step1a Step 1a]''' Sentence: "This scope definition may not contradict the terms established in section Scope of Applicability." Comment: I find this sentence somewhat confusing. Is it really necessary? <span style="color: #808080;">{Vicki - 1 April}</span><br />
<br />Replacing "may" with "should" makes this clearer to me.<span style="color: #808080;">{Anna Belle - 4 April}</span><br />
</li><br />
<br />
<li style="padding-bottom:1em">[EOWG - need to come up with better terms for each and better explanations. the main explanation should be in one place, it's confusing to have as it currently is in two places. see minutes for brainstorms.]<br />'''[http://www.w3.org/TR/WCAG-EM/#step1b Step 1b]:''' Defining the Goal. I am not sure I agree that there is sufficient difference in the two in-depth reports to require three categories. Seems clearer to stick to 2 - basic and detailed and maybe say a bit about the fact that the amount of detail is good to be part of the definition as well.<br/>''Rationale: It may be splitting hairs but it seems that once you have made the decision to go beyond a statement of conformance, there is an entire spectrum of detail and nuance. Why not four categories then? or more?'' <span style="color: #808080;">{Sharron 28 March}</span><br />I thought the problem lay in the label; the 3 definitions seemed distinct but "detailed report" did not seem to accurately reflect the 2nd report according to its description since there's no detail. Perhaps "Statistical Report" or "Itemized Page Report" would be a better fit. "Basic Report" - not sure this fits the description either. Perhaps "Pass / Fail Rating" would be more appropriate.<span style="color: #808080;">{Howard 4 April}</span></li><br />
<br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#step1d Step 1d]''' says "However, it is not necessary to use these particular techniques. In fact, in some situations, such as in a closed network, it may be necessary to use techniques that are specifically developed to the particular needs of the users of that network. Individuals and organizations developing techniques have to employ methods for establishing the technique's ability to meet the WCAG 2.0 Success Criteria." without support .<br/>''Rationale:Wouldn't it be useful to provide one or two examples of this? So it makes more sense to those reading this document? '' <span style="color: #808080;">{Denis 28 March}</span></li><br />
<li style="padding-bottom:1em">In addition to providing examples, this should not be an optional part of the methodology. It seems critical for the reviewer to define what techniques are being used to measure conformance or nonconformance to the SC. The section could make note of the fact that reviewers are not bound by previously established W3C Techniques and Failures, but it should still require that some documentation is needed of just what Techniques are being used. Could also encourage the addition of those new Techniques to the existing library.<br/>''Rationale: '' Without techniques being defined, the review is in danger of becoming undocumented opinion rather than measurement of conformance to a standard. <span style="color: #808080;">{Sharron 3 April}</span></li><br />
</ul><br />
<br />
===Step 2: Explore the Target Website Section===<br />
<br />
<ul><br />
<li style="padding-bottom:1em">'''Location/Summary:''' Change.<br/>''Rationale: '' <span style="color: #808080;">{Name}</span></li><br />
<br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#step2b Step2b]:Identify Common Functionality.'''I keep reading the definition of "common functionality) and I'm just not sure what it is we're talking about here. Are we talking about main navigation, header, footers and so on? Specific features that is used site wide? <br/><br />
''Rationale:'' Wouldn't it be helpful to refer to "common functionalities" as representative testing use cases for the evaluation of the website? <span style="color: #808080;">{Denis 28 March}</span></li><br />
<br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#step2b Step2b]:''' . As noted above, I believe "common" to be the wrong word here. Suggest authors think of a word more likely to convey the sense of ability to complete the task at hand.<br/>''Rationale: '' "Common" is just not the right word for what I think this is trying to mean.<span style="color: #808080;">{Sharron 28 March}</span></li><br />
<br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#step2b Step2b]:''' . Not simple. <br /><br />
Brainstorming: "core functionality", "key functionality", "site functionality" or would "purpose and functionality" work (i.e., looking at what follows in the second paragraph)? <span style="color: #808080;">{Vicki - 2 April}</span></li><br />
<br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#step2d Step2d]:''' .Sentence: "Only the web technologies that are relied upon to provide the website need to be identified for evaluation."<br/ ><br />
Comment: I feel a word is missing, can we add "functionality" after the word website so that it reads :<br/ ><br />
"Only the web technologies that are relied upon to provide the website functionality need to be identified for evaluation." <span style="color: #808080;">{Vicki - 2 April}</span><br /><br />
+1 <span style="color: #808080;">{Sharron - 3 April}</span></li><br />
<br />
<br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#step2d Step2d]:''' . Would change "provide" in "Identify the technologies relied upon to provide the website." to "render" or "produce." ''Rationale:'' You "provide" food or lodging but not a website. <span style="color: #808080;">{Howard - 4 April}</span></li><br />
<br />
</ul><br />
<br />
===Step 3: Select a Representative Sample Section===<br />
<ul><br />
<li style="padding-bottom:1em">'''Location/Summary:''' Change.<br/>''Rationale: '' <span style="color: #808080;">{Name}</span></li><br />
<br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#step3 Section Overview]:''' What is the point of the '''Note'''? Since it is to be covered in a later section, it seems redundant to mention here .<br/>''Rationale: Tersification. It is an entire unnecessary paragraph '' <span style="color: #808080;">{Sharron March 28}</span></li><br />
<br />
</ul><br />
<br />
<div style="color:#808080"><br />
====outside EOWG scope (step 3)====<br />
<ul><br />
<li style="padding-bottom:1em">[outside EOWG scope] '''[http://www.w3.org/TR/2012/WD-WCAG-EM-20120920/#step3 Step 3 Intro]:''' Instead of creating pressure on orgs to consider assessment of ALL pages, why not focus on trying to get them to think about selecting the best possible samples within reasonable scope, rather than have them perceive this selection as a failure because they can't afford to cover all pages? <br />
<br/>''Rationale: ''I know we mention it's usually not possible to evaluate all pages, but if we can recognize that it's rarely possible, then why say ideally it should be all pages? That creates unrealistic expectations and a pressure most people do not need to deal with. I feel this is wishful thinking - we need to be more realistic about this. Most accessibility evaluation do not cover all pages and no organization can ever afford to run a complete evaluation of all their pages, except for very small sites (and even then, if they have a small site, their accessibility budgets will tend to be proportionally small) <span style="color: #808080;">{Denis 28 March}</span></li><br />
<br />
<li style="padding-bottom:1em">[outside EOWG scope]'''[http://www.w3.org/TR/2012/WD-WCAG-EM-20120920/#step3e Step 3e]: Random Sample''' 5% seems a little low to me, even when the sample contains over 30 to 50 pages total (WCAG-EM implies it should always be more than this). I would suggest around 10-15% (where 50 pages would include another 5-7 random pages to complete the sample).<span style="color: #808080;">{Denis 28 March}</span><br />
<ul><br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#step3e Step3e]:''' Random Sample. I actually disagree with Denis' email objection to the 5% sample. I think %5 is an adequate number of random pages to add to the mix.<br/>''Rationale:'' If the reviewer has followed the advice and chosen the samples well, it is unlikely that the random sample will provide much (or any) value. But it is good to do as a process check.<span style="color: #808080;">{Sharron 29 March}</span></li><br />
</ul></li><br />
</ul><br />
</div><br />
<br />
===Step 4: Audit the Selected Sample Section===<br />
<ul><br />
<li style="padding-bottom:1em">'''Location/Summary:''' Change.<br/>''Rationale: '' <span style="color: #808080;">{Name}</span></li><br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#step4 Step 4] Note 1''' We should suggest isolating template findings from the rest of the findings related to main content of a page or pages, so findings/issues related to templates can be referenced globally for all related pages, rather than repeating the findings every time.<br/>''Rationale:By doing this, once the template findings are covered, all subsequent pages could only be covering the main content issues, making the whole process simpler and more organized. '' <span style="color: #808080;">{Denis 28 March}</span></li><br />
<br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#step4 Step 4] Note 2''' Add text to say: "Note: According to WCAG 2.0, Success Criteria to which there is no matching content are deemed to have been satisfied. An outcome such as 'Not Applicable' may be used to denote the particular situation where Success Criteria were satisfied because no relevant content was applicable,<span style="background:yellow;">but WCAG 2.0 does not require this. A Success Criteria that is either validated or not applicable, for whatever reason, is considered satisfied."</span> <br/>''Rationale: To explain more completely ><span style="color: #808080;">{Denis 28 March}</span></li><br />
<br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#step4c Step 4c]:''' Use Techniques and Failures should not be Optional. The section title already says "where possible." Backing away from established techniques and failures reduces confidence in the usefulness of the Techniques. Rewrite to emphasize that the Techniques allow for new ways to meet the SCs but should be followed in general.<br/>''Rationale: '' For consistency, predictability of results, etc. Could also remind evaluators to add to the Techniques if they find previously undocumented ways to meet the SC. <span style="color: #808080;">{Sharron 3 April}</span><br />There are reasons behind this. It's outside EOWG to debate the reasons; however, I think it '''is''' within EOWG scope to discuss how to effectively communicate the issue. <span style="color: #808080;">{Shawn}</li><br />
<br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#step4e Step 4e]''' Again I do not understand the reason for this being optional. Surely a conformance review should be replicable. Recent experience shows significantly different outcomes based on tools and testing environments. Tools documentation should be part of the report - period.<br/>''Rationale: '' I cannot think of an example where the tools and platform are irrelevant to the testing results. If someone can think of such an exception, perhaps provide that as a Note. But in general, the tools etc are an important part of the result. <span style="color: #808080;">{Sharron 3 April}</span></li><br />
<br />
</ul><br />
<br />
===Step 5: Report the Evaluation Findings Section===<br />
<ul><br />
<li style="padding-bottom:1em">'''Location/Summary:''' Change.<br/>''Rationale: '' <span style="color: #808080;">{Name}</span></li><br />
<br />
<li>'''[http://www.w3.org/TR/WCAG-EM/#step5b Step 5.b]: Conformance Evaluation Statement (Optional)''' Change <blockquote> "As per the requirements for WCAG 2.0 conformance claims, also accessibility evaluation statements have to include the following information:"</blockquote> to instead read:<br />
<blockquote>"As per the requirements for WCAG 2.0 conformance claims, accessibility evaluation statements also have to include the following information:".</blockquote>''Rationale: Grammar '' <span style="color: #808080;">{Dennis 28 March}</span></li><br />
<br />
<li>'''Step 5.b Note''' The note states:<br />
<blockquote>"It is not possible to make an accessibility evaluation statement for a website that is still in development."</blockquote><br />
But would be improved by saying: <blockquote> "An accessibility evaluation statement should not be made for a website that is still in development."</blockquote><br />
''Rationale: Again, WCAG-EM is not a dogma or a law. We shouldn't impose anything. Rather than prohibit making an accessibility evaluation statement for a website that is still under development, maybe it would be better to suggest not to.'' <span style="color: #808080;">{Denis 28 March}</span><br />
<li>Sounds better, i.e., less heavy<span style="color: #808080;">{Vicki - 2 April}</span></li> <br />
<br />
</ul><br />
<br />
==Considerations for Particular Situations section==<br />
<br />
<ul><br />
<br />
<li style="padding-bottom:1em">'''Location/Summary:''' Change.<br/>''Rationale: '' <span style="color: #808080;">{Name}</span></li><br />
</ul><br />
<br />
<div style="color:#808080;"><br />
====outside EOWG scope (considerations)====<br />
<ul><br />
<br />
<li style="padding-bottom:1em">[outside EOWG scope] '''[http://www.w3.org/TR/WCAG-EM/#divide Evaluating a Large Website with Separate Parts]:''' Would it be useful here to suggest personas? To think about the different uses that people will have for the large website and to define those pathways? For example, a government agency site may have people coming who are looking for general information, or they may be seeking specific services. There could be a robust series of pages that do not require log-ins as well as those that do. Interest/interaction may be regional and there is likely to be a different series of pages for agency staff. <br/>''Rationale: '' I have found that if the commissioner of the review will define the stakeholder/constiuent groups who most frequently use the site and what they do there, it can help define critical pathways for various tasks. <span style="color: #808080;">{Sharron 3 April}</span></li><br />
<br />
<li>[outside EOWG scope] '''[http://www.w3.org/TR/WCAG-EM/#rerun Re-Running a Website Conformance Evaluation]:''' <br />
I would like to suggest a proportion of 60%/40% between portion of web pages that were in the original sample and additional new web pages that were not in the original sample.<br/>''Rationale:'' to get significant distinction between old pages and new ones and measure how well they compare once remediation has been applied to webpages. <span style="color: #808080;">{Denis 28 March}</span></li><br />
</ul><br />
</div><br />
<br />
==Application of this Methodology section==<br />
<ul><br />
<br />
<li style="padding-bottom:1em">'''Location/Summary:''' Change.<br/>''Rationale: '' <span style="color: #808080;">{Name}</span></li><br />
<br />
</ul><br />
<br />
<hr /><br />
==Copyedits & things that probably don't need discussion==<br />
<br />
<ul><br />
<br />
<li style="padding-bottom:1em">'''Location:''' Problem: @@. Current wording: @@. Revised wording: @@. <span style="color: #808080;">{Name}</span></li><br />
<br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#step4b Step 4b]''' Small typo - including "sufficient technqiues" - s/technqiues/techniques. <span style="color: #808080;">{Denis 28 March}</span></li><br />
<br />
<li style="padding-bottom:1em">In first sentence of second paragraph of Abstract, should be comma after "for example"<span style="color: #808080;">{Howard}</span></li><br />
<li style="padding-bottom:1em">Typo: (may be several times in document): technqiues instead of techniques. <span style="color: #808080;">{Sylvie 22/March}</span></li><br />
<li style="padding-bottom:1em">'''Consistency of section headings:''' The link text of sections (steps) that are referred to are not always the same as the sections titles. For example, at the end of section step 5.A, there is a link to "Step 5.b: Provide and Accessibility Statement)". First there need to be corrected in "an accessibility Statement". Second, the title of the heading is: "Step 5.b: Provide a Conformance Evaluation Statement (Optional)", whereas the Methodology Requirement 5.B is entitled: "Provide an accessibility conformance evaluation statement (Optional).". <span style="color: #808080;">{Sylvie 22/March}</span></li><br />
<li style="padding-bottom:1em">Typo: Sucess criteria instead of Success criteria (several occurences)<span style="color: #808080;">{Sylvie 22/March}</span></li><br />
<br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#step1 Define Scope Overview]:''' Well done in explaining the relationship/role of the reviewer, the commissioner, and the owner.<br/>''Rationale: Important distinction, well made up front.'' <span style="color: #808080;">{Sharron 28 March}</span></li><br />
<br />
</ul><br />
<br />
==other==<br />
<br />
===fyi, Comments that individuals sent directly (not through EOWG)===<br />
<br />
<ul><br />
<li style="padding-bottom:1em">[http://lists.w3.org/Archives/Public/public-wcag-em-comments/2013Mar/0000.html Suzette] Excess use of 'per' especially in section 5. I'm not sure how to do an archive link but have sent the following direct:<br />
"I have read through WCAG EM and congratulate you on its progress. On a small point of language I noticed is an outbreak of the word 'per' - especially in section 5, which I would suggest could inhibit ease of understanding and is also unnecessary. I would propose removing all 'per' and using a plain language alternative, if necessary.<br />
<br />
FYI:<br />
I researched the opinions of others via Google, and here is one of the more<br />
interesting discussions on the use of per and as per:<br />
http://www.businesswritingblog.com/business_writing/2009/05/your-help-please-with-as-per.html<br />
<br />
<br />
Per and 'as per' is a pseudo-latin construction. Opinions appear to divide between clarity, efficiency, and improper use. There are however alternatives which are more natural.<br />
<br />
The only examples that fit well in my head is taking medicine 'per<br />
day', or sharing pencils 'one per child' and 'per your instructions'. The use of 'Per website' and 'per web page' (WCAG EM methodological requirement 5c) seem particularly puzzling and drove me to Google to find out why. <br />
<span style="color: #808080;">{Suzette}</span></li><br />
<br />
<li>[http://lists.w3.org/Archives/Public/public-wcag-em-comments/2013Apr/0001.html Sylvie & friends]</li><br />
</ul><br />
<br />
===Archived Notes (not for Eval TF)===<br />
<ul><br />
<li style="padding-bottom:1em">[closed. updated [[Style]] with rationale for putting periods and commas outside of quoted terms.] This may need discussion, but I'm not sure where else to put it. According the ''Chicago Manual of Style'' Rule 6.8: "Periods and commas precede closing quotation marks, whether double or single." The way I did the previous sentence conforms to that. Things like "not "magnifying glass"." don't. We use this pattern a lot, but that means we're consistent. It just may be consistently wrong. OTOH, it would be an incorrect pattern in code, so coders may cringe if we adopt the Chicago rule. (3/20/13) <span style="color: #808080;">{Anna Belle}</span></li><br />
<li><br />
Overall Comment: This is thorough. That is a good thing. Tom and I agreed that this would have been great for us when we started our giant accessibility project at the California State University. We had to discover so much of this on our own. The WCAG-EM group managed to pull together a lot of hard earned experience into a truly useful guideline for someone who needs to bring a site into complete Level 2 conformance. Overall, it reads well. EO has caught most of the bumps. Combined with the Easy Check from EO (for work-a-day) review. This is a powerful package. {Wayne Dick and Tom Jewett 4/10}<br />
</li><br />
</ul><br />
<br />
<br />
<br /><hr /><br /><br />
<br />
<div style="color:#808080;"><br />
<br />
=<span style="color:#808080;">Comments submitted on 22 October 2012</span>=<br />
<br />
==Readability & Usability==<br />
'''What specific revisions will make the document more readable and usable?'''<br />
<br />
<ul><br />
<li style="padding-bottom:1em" id="reply">'''linked terms distracting'''- Every time a term is mentioned, there's a link to the definition e.g. "web pages",websites, I find this quite distracting and I think it reduces the readability <span style="color: #808080;">{Vicki}</span>.<br />
<br />Strongly agree. Some ideas: just link it the first time in the document, or a new section. OR provide an option for users to turn off these links. <span style="color: #808080;">{shawn}</span></li><br />
<br />
<li style="padding-bottom:1em">'''linked references in sentences''' - the linked reference (e.g. "3.5 Step 5: Report the Evaluation Findings") in the middle of a sentence is also a little distracting and breaks the reading. <span style="color: #808080;">{Vicki}</span></li><br />
<br />
<li style="padding-bottom:1em">'''examples matching use cases''' - readability, section 1.1 scope and 1.2 audience. I think this is a difficult read for the intended audience. To improve usability I would suggest there is a need for better tailored use cases that match 1.2 and are then addressed consistently. There seem to be some examples included about commerce but I think it needs to use a better defined range - that better capture the context of the audience be it large scale government sites, large commercial sites, banks and utilities, and big agencies through to smaller operators eg a local school, a local charity, small organic food retailer. <span style="color: #808080;">{Suzette}</span></li><br />
<br />
<li style="padding-bottom:1em">'''Delete text from Abstract''' - Abstract current wording: "This work is part of complementary W3C/WAI activities on Web Accessibility Evaluation and Testing that address different W3C/WAI guidelines and specifications."<br />Comment: This leads reads off the page to 2 separate places. Suggest not having it in the Abstract. OK in the intro, but in the abstract, I think it takes the focus off this document too much. <span style="color: #808080;">{Shawn}</span></li><br />
<br />
<li style="padding-bottom:1em">'''Section numbering''' - Please consider not numbering every section. "3.4 Step 4:" etc adds complexity. It would be much simpler to just have "Step 4:" <span style="color: #808080;">{shawn}</span></li><br />
<br />
<li style="padding-bottom:1em">[minor] delete "W3C/WAI" where you can</li><br />
<li style="padding-bottom:1em">[minor] add "(WCAG-EM)" to the title, abstract, and introduction</li><br />
<br />
</ul><br />
<br />
==Scope==<br />
'''Is it clear that this set of methodologies is only for websites after they are built and does not address methodologies that might be used prior to and during development? If not, please suggest ways to clarify the scope.'''<br />
<ul><br />
<li style="padding-bottom:1em"> Given that the title is about Compliance evaluation, I have no problem with clarifying that the scope is what educationalists call summative assessment (like the final exam!) rather that formative assessment (feedback you can learn from). I noted a number of mentions in the opening sections about the benefits or effects of iterative testing during the design process. <br />
<br />
My suggestion is to keep the two types of testing separate because they relate to substantially different scenarios. Developers probably should not do their own formal compliance testing. I would suggest that the EM has a short paragraph to discuss the difference so that the reader is aware of this and can chose whether the Compliance EM document is relevant or if they need to go to the less formal 'Design_and_ Evaluation' section. <span style="color: #808080;">{Suzette}</span></li><br />
</ul><br />
<br />
[http://www.w3.org/TR/WCAG-EM/#scope 1.1 Scope of this Document] - second and third paragraphs, cited below:<br />
<br />
"However, this methodology only addresses evaluation of website conformance to WCAG 2.0 after its development. Complementary resources from W3C/WAI on evaluation provide guidance on evaluation in other situations, and complementary W3C/WAI activities on Web Accessibility Evaluation and Testing address different W3C/WAI guidelines and specifications."<br />
<br />
"Also, WCAG 2.0 conformance requirements apply to individual web pages. However, on most websites it is not feasible to evaluate every web page with reasonable effort. To ensure conformance of a website to WCAG 2.0 it is necessary to ensure that this is considered throughout the development process. Following this methodology helps assess the level of conformance with reasonable confidence where it is not feasible to evaluate every web page."<br />
<br />
* I prefer not to restrict the evaluation to "only" sites after development. <br />
* I find the second paragraph starting "Also, WCAG 2.0 conformance....etc." somewhat puzzling. In the first paragraph, there is mention that the evaluation methodology is only for sites after development but, on the other hand, in the second paragraph, there is mention of the importance of conformance during the development process and following "this methodology" (which in the first para is stated as only for after development) helps assess the conformance.<br />
<br />
Suggestion (if the scope is fixed on already developed sies):<br />
<br />
This methodology is best used to address evaluation of website conformance to WCAG 2.0 after development. WCAG 2.0 conformance requirements apply to individual web pages. On most websites, it can be challenging to evaluate every single web page. This methodology helps assess the level of conformance with reasonable confidence where it is not feasible to evaluate every web page. <br />
<br />
Complementary resources from W3C/WAI on evaluation provide guidance on evaluation in other situations, and complementary W3C/WAI activities on Web Accessibility Evaluation and Testing address different W3C/WAI guidelines and specifications.<br />
<br />
It is noted that conformance which is considered during the development process reduces significantly the costs of evaluation after development. <br />
<span style="color: #808080;">{Vicki}</span><br />
<br />
'''[important]''' The only one comment I do feel somewhat concerned about is the "Scope" and restricting the document to "only" sites after development. I look at it from the point of view of someone e.g. a developer coming across the document through a search and, with the patience (rather lack of it) that we have on the web, it might be disregarded by the restrictive focus. It is also a document which could still be useful to someone who might perform iterative evaluation through the development process. Therefore, I would recommend being more receptive to a wider audience by changing the wording somewhat. <span style="color: #808080;">{Vicki via Sharron}</span><br />
<br />
==Evaluate throughout==<br />
'''How should we communicate the importance of evaluating throughout website development, not just at the end?'''<br />
<ul><br />
<li style="padding-bottom:1em">'''Abstract'''<br />''Abstract current wording:'' (in a paragraph) However, ensuring and maintaining accessibility requires that accessibility is considered throughout the development process. Complementary resources from W3C/WAI on evaluation provide guidance for other situations.<br /><br />
''Abstract suggested text:'' '''(separate paragraph)''' When developing or redesigning a website, accessibility should be considered early and throughout the design and development process. This is addressed in [http://www.w3.org/WAI/EO/wiki/Eval_in_process a new resource under development] ''<span style="color: #808080;">{which EOWG expects to have drafted for the next WCAG-EM draft so you can put the actual title of the page here}</span>''.<br /><br />
<span style="color: #808080;">{Shawn}</span></li><br />
<br />
<li style="padding-bottom:1em"><br />
'''Introduction, Scope, middle paragraph:'''<br /><br />
''Current text:'' "However, this methodology only addresses evaluation of website conformance to WCAG 2.0 after its development. Complementary resources from W3C/WAI on evaluation provide guidance on evaluation in other situations, and complementary W3C/WAI activities on Web Accessibility Evaluation and Testing address different W3C/WAI guidelines and specifications."<br /><br />
''Suggested text:'' This methodology only addresses evaluating an existing website's conformance to WCAG 2.0. When developing or redesigning a website, accessibility should be considered early and throughout the design and development process. This is addressed in [http://www.w3.org/WAI/EO/wiki/Eval_in_process a new resource under development] ''<span style="color: #808080;">{which EOWG expects to have drafted for the next WCAG-EM draft so you can put the actual title of the page here}</span>''.<br /><br />
'''(new paragraph)''' Related information outside the scope of this document is provided in [http://www.w3.org/WAI/eval/ Evaluating Websites for Accessibility], [http://www.w3.org/WAI/eval/ W3C WAI Web Accessibility Evaluation and Testing Activities], and [http://www.w3.org/WAI/guid-tech.html WAI Guidelines and Techniques]. <br /><br />
<span style="color: #808080;">{shawn}</span></li><br />
<br />
</ul><br />
<br />
==Missing?==<br />
'''Are there any major considerations that we have overlooked or misrepresented?'''<br />
<ul><br />
<li style="padding-bottom:1em">'''Updates, maintenance, drift:''' An accessibility audit is static - a snapshot in time. By contrast, contemporary websites are organic - constantly evolving and growing. New material and novel features can be added by people who were not part of the original development team and these authors may have very limited editorial skills, and knowledge of development. As part of EM, I would suggest that that we should make a strong case for planned reviews to maintain standards and avoid the effect of drift that has been observed by researchers. <span style="color: #808080;">{Suzette}</span></li><br />
</ul><br />
<br />
==Related material==<br />
'''How much should we refer to and link to existing material as reference and how much should we include directly in the new material? Balance the inconvenience of jumping back and forth between existing documents against our reluctance to unnecessarily duplicate information.'''<br/><br />
'''How should we align the WCAG-EM work with the [http://www.w3.org/WAI/EO/wiki/Web_Accessibility_Preliminary_Evaluation Preliminary Evaluation document] now in process at EOWG?<br />What should the [http://www.w3.org/WAI/eval/conformance.html Conformance Evaluation] page be in relation to WCAG-EM?''' (see also [[Eval Analysis]])<br />
<ul><br />
<li style="padding-bottom:1em">EOWG is currently planning to update the [http://www.w3.org/WAI/eval/preliminary.html old Preliminary Eval page], edit the [http://www.w3.org/WAI/eval/conformance.html old Conformance Eval] page to be something like a "WCAG-EM light", and develop a page on [http://www.w3.org/WAI/EO/wiki/Eval_in_process Evaluating throughout the process]. See more in [[Eval Analysis]]. We look forward to talking with the Eval TF about this approach.</li><br />
</ul><br />
<br />
==Other==<br />
''These comments were entered before we had the structure above, so might apply to above or not.''<br />
<ul><br />
<li style="padding-bottom:1em">'''[Very Important]''' '''[http://www.w3.org/TR/WCAG-EM/#step1d Methodology Requirement 1.d]''' - This requirement appears to claim that the website owner and evaluator are free to choose which users may be excluded. Human rights do not work that way. What reasonable base technologies are required for conformance? This is particularly disturbing within the context of intranets where employers may choose to limit users to assistive technologies the employer can purchase cheaply. The note at the end is not sufficient.<br/><br />
Example, many sites prescribe large print with high contrast to be a universal cure for low vision. This discounts the need for albinos to have lower luminosity. Without high luminosity, high contrast is not possible. <span style="color: #808080;">{Wayne Dick}</span></li><br />
<li style="padding-bottom:1em">'''[important]''' '''[http://www.w3.org/TR/WCAG-EM/#step1e 3.1.5 Step d]''' - appeared to invite employer determined prescription of assistive techonolgy and accessibility support. The result will be employer defined necessary employment discrimination. <span style="color: #808080;">{Wayne Dick}</span></li><br />
<li style="padding-bottom:1em">[minor] '''Relied Upon''' - Just hangs there without inclusion in the context of accessibility supported. <span style="color: #808080;">{Wayne Dick}</span></li><br />
<li style="padding-bottom:1em">[Med] The note to (Web Applications): It may not be feasible to exhaustively examine all possible settings, but sampling should apply just as any website. <span style="color: #808080;">{Wayne Dick}</span></li><br />
<li style="padding-bottom:1em">3.1.5 Step 3. The evaluation commissioner, must be informed that if the self defined sufficient techniques are used then a future accessibility audit may ask for a proof of sufficiency. <span style="color: #808080;">{Wayne Dick}</span></li><br />
<li style="padding-bottom:1em">Throughout 3.1.5 PDF and Silver light are basic web technologies. They are no more technologie than docx or raw text. They as basic web technologies. The accessibility open question.<br/><br />
This issue is particularly important if this document is going to be normative. I do specific reference to Adobe or Microsoft products as basic web technologies is serious vendor preference. <span style="color: #808080;">{Wayne Dick}</span></li><br />
<li style="padding-bottom:1em">[http://www.w3.org/TR/WCAG-EM/#step3 3.3 Step 3]: Select a Representative Sample, (First sentence) &#34;While ideally every web page of a web site is evaluated, usually this is not possible on most web sites.&#34;<br/><br />
I feel that stating "usually this is not possible on most web sites" sounds somewhat contradictory (to our objective).<br/><br />
Suggested text: &#34;While ideally every web page of a website should be evaluated, this may not be possible for very large websites.&#34; <span style="color: #808080;">{Vicki}</span></li><br />
<li style="padding-bottom:1em">[http://www.w3.org/TR/WCAG-EM/#step3 3.3 Step 3]: Select a Representative Sample - website with many heterogeneous sub-university example, the sample selection include users. Focus groups are an effective probably necessary.<br/><br />
Large heterogenous sites behave more like a set of independent sites placed under one URL. As such it is important to organize focus groups within the different autonomous site owners to determine usage patterns and prioritize pages for evaluation. When organizing the CSU System, 23 Campuses, each having more than 50 academic departments, and more administrative departments, we found that the IT unit could not get a handle on usage patterns on its own. Individual site owners had to give direct input on priority and usage. Example: At CSU Long Beach the Computer Science lab invokes the Computer Science Department Website every time a student logs into a lab machine. That makes the Computer Science Department the most referenced site on the Campus. But it is not the most important. <span style="color: #808080;">{Wayne Dick}</span></li><br />
<li style="padding-bottom:1em">Responding to the term &#34;with reasonable confidence&#34;: I have no problem with the term. Alternatively, if the above term is a point of discussion, you could simply modify the sentence to &#34;that is representative of the entire target website&#34;. <span style="color: #808080;">{Vicki}</span></li><br />
<li style="padding-bottom:1em">[http://www.w3.org/TR/WCAG-EM/#users 2.5 Involving Users (Optional)]- Second last sentence. &#34;While not required, it is strongly recommended to involve real people covering a wide range of abilities....&#34;<br/><br />
Suggest removing &#34;real&#34;. <span style="color: #808080;">{Vicki}</span></li><br />
<li style="padding-bottom:1em">[http://www.w3.org/TR/WCAG-EM/#step3 3.1.4 Methodology Requirement 1.d:] Third paragraph: second last sentence. &#34;For example, ….., then the website is effectively not accessible for some users.&#34;<br/><br />
Suggest adding something about conformance for emphasis e.g., &#34;and therefore does not conform to the specified conformance level of WCAG 2.0. ([http://www.w3.org/TR/WCAG-EM/#step1c 3.1.3 Step 1.c.])&#34; <span style="color: #808080;">{Vicki}</span></li><br />
<li style="padding-bottom:1em">[http://www.w3.org/TR/WCAG-EM/#functionality Term "Common Functionality"]<br />
Feedback was requested on the definition on &#34;Common Functionality&#34;. <br />
Having read through the document, I don’t have a problem with the term &#34;common functionality. However, it might pose a question mark to some. Therefore, I’ve put forth a few options below depending on what you mean and if you wish to be more specific:<br/><br />
If it is the general functionality of the site, you could simply leave out the word &#34;common&#34; or use &#34;basic functionality&#34;<br/><br />
If &#34;common functionality&#34; has a more technical connotation (referring to the style sheets, javascript, classes, i.e., the technical mandatory requirements for multiple device support and functionality), leave it as &#34;common&#34;<br/><br />
Another suggestion in the line of &#34;common&#34; and &#34;key&#34; is “core”.<br/><br />
Suggestion to modify the description (in line with the &#34;Note&#34;):<br/><br />
Functionality of a website includes tasks that users of a website perform in order to achieve a goal. <span style="color: #808080;">{Vicki}</span> </li><br />
<br />
<li style="padding-bottom:1em">'''3.5.3 Step 5.c''': Provide a Performance Score (optional) I think there are good reasons for offering a score in addition to or as an alternative to the absolute measure of pass/fail. I have read this section several times, and tried really hard to construct a formula to help me comprehend the differences but I am currently confused. Maybe my basic scenario is wrong, so perhaps a worked example would help? Eg what would the score show where some form elements are consistently incorrectly marked and are affecting 5 out of 10 pages tested. <span style="color: #808080;">{Suzette}</span></li><br />
<br />
<li style="padding-bottom:1em">Term "sub-site" : do you want to add the definition to the terms and definitions? <span style="color: #808080;">{Vicki}</span></li><br />
<li style="padding-bottom:1em">Section step 1.A, last paragraphis not clear to me. What is necessary there? May be it could be easier to understand with concrete examples. <quote>"The outcome of this step is an unambiguous definition for the target website, so that for each web page it can be determined whether it is within the scope of evaluation or not. Where possible, it is recommended to use formalizations such as regular expressions or listings of Universal Resource Identifiers that define the web pages<br />
that are within the scope of evaluation (part of the target website)."</quote> <span style="color: #808080;">{Sylvie}</span></li><br />
<br />
<li style="padding-bottom:1em"> <br />
'''1.3 Background Reading, Accessible Web Design''' <br /><br />
This section doesn't feel right. For example, my first reaction was that some relevant documents are missing, such as [http://www.w3.org/WAI/impl/improving.html Improving the Accessibility of Your Website] – and that some included here are maybe not more important than others that weren't included, e.g., [http://www.w3.org/WAI/older-users/developing Developing Websites for Older People] & [http://www.w3.org/WAI/mobile/overlap.html Web Content Accessibility and Mobile Web] seem less important in this context.<br/><br/><br />
Please reconsider the purpose of this list in the context of WCAG-EM. (Remember this section starts with "It is assumed that the reader of this document is familiar with the following related resources from W3C/WAI:") I can see that Essential Components of Web Accessibility and How People with Disabilities Use the Web are particularly important for evaluation &mdash; perhaps only list those 2 &mdash; and not under the heading "Accessible Web Design" but something more directly related to understanding evaluation in the bigger context. <br /><br />
(minor point: This section is not parallel with the others above it &mdash; although I don't think that's a big deal. minor edit:link change: [http://www.w3.org/WAI/mobile/overlap.html Web Content Accessibility and Mobile Web])<br />
<br /><span style="color: #808080;">{Shawn}</span></li><br />
<br />
<li style="padding-bottom:1em">'''Background Reading'''. <br /><br />
''current wording:'' "It is assumed that the reader of this document is familiar with the following related resources from W3C/WAI:" <br /><br />
''Ideas for edited wording:'' "To effectively use this methodology, you should be familiar with the following related information." <br /><br />
''or'' "The information below related to WCAG 2.0 and evaluation is important background for using this methodology. "<br />
<span style="color: #808080;">{Shawn}</span></li><br />
<br />
</ul><br />
<br />
<br />
<br />
<ul><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#scope paragraph 1 ] I think Howard may have made this suggestion already, but instead of using semicolons, use an unordered list instead.<br /><br /><br />
<br />
The methodology described in this document, WCAG-EM, provides guidance on:<br />
<ul><br />
<li>defining parameters for the evaluation scope</li><br />
<li>exploring and understanding websites including their key features and functionality</li><br />
<li>sampling representative web pages from websites where it is not feasible to evaluate all web pages of a website</li><br />
<li>evaluating the conformance of these selected web pages to the target level of WCAG 2.0 conformance</li><br />
<li>documenting and reporting the findings from such evaluation</li><br />
</ul><br />
<span style="color: #808080;">{Paul}</span></li><br />
</ul><br />
<br />
<ul><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#procedure ] I know this was discussed on the last call - description of diagram should be an ordered list. <span style="color: #808080;">{Paul}</span></li><br />
</ul><br />
<br />
<ul><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#reports Appendix C, "For In-Depth…" last paragraph ] There are a lot of unordered lists in this section already, so it may be overkill.<br />
<br /><br /><br />
Change:<br />
<br /><br /><br />
Reports could also indicate the impact of issues found and specifically identify any high impact issues that are easy to fix. This could include: Any accessibility issues that interfere with the user completing tasks, issues that affect navigation and orientation, issues that occur very frequently and issues that can cause any loss or harm to a user. A lot of the important but technical information could be put in an appendix (such as documentation of each outcome of the steps as per Step 5.a: Provide Documentation for Each Step).<br />
<br /><br /><br />
to:<br />
<br /><br /><br />
Reports could also indicate the impact of issues found and specifically identify any high impact issues that are easy to fix. This could include:<br />
<ul><br />
<li>Any accessibility issues that interfere with the user completing tasks</li><br />
<li>issues that affect navigation and orientation</li><br />
<li>issues that occur very frequently</li><br />
<li>issues that can cause any loss or harm to a user.</li><br />
</ul><br />
A lot of the important but technical information could be put in an appendix (such as documentation of each outcome of the steps as per Step 5.a: Provide Documentation for Each Step).<br />
<span style="color: #808080;">{Paul}</span></li><br />
</ul><br />
<br />
==Copyedits & things that probably don't need discussion==<br />
<br />
<ul><br />
<li style="padding-bottom:0.5em">[http://www.w3.org/TR/WCAG-EM/#step1b 3.1.2 Step 1.b.] In-Depth Analysis. End of last sentence is missing a fullstop. <span style="color: #808080;">{Vicki}</span></li><br />
<li style="padding-bottom:0.5em">3.2.3 "Note: This step is intended to identify groups of web page instances, including in web applications."<br/>Suggest drop the "in" as in "including web applications" or add "including those in web applications". <span style="color: #808080;">{Vicki}</span></li><br />
<br />
<li>[ http://www.w3.org/TR/WCAG-EM/#introduction paragraph 2 ] "This methodology can also be useful for other purposes," (add comma) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#introduction paragraph 3 ] "…and complements existing WCAG 2.0 resources," (add comma) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#audience bullet 5 ] Change "…monitoring activities who want to benchmark…" to "…monitoring activities that benchmark…" <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#usage last sentence ] Change "…of the overall performance of the website…" to "…of the overall conformance of the website…" <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#specialcases Small Websites ] "For websites with few web pages," (add comma) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#specialcases Web Applications Note ] Change "These individual states of web page" to "These individual states of web pages" <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#specialcases Web Applications Note ] Change "…to generate these states of web page and generated web page" to "…to generate these states of web pages and generated web pages" <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#specialcases Website with Separable Areas ] Consider adding example of "site administration" to (extranet) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step2 Methodology Requirement 2 Note ] Change "…other aspects of the implementation that makes" to "…other aspects of the implementation that make" <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step3 third paragraph ] Change "…and in many cases these web pages may have different design to others" to "…and in many cases these web pages may have different design than others" <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step3 third paragraph ] Change "…can significantly reduce the required sample size while..." to "…can significantly reduce the required sample size, while..." (add comma) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step4a Note ] Change "…used to create many web pages, sometimes entire parts..." to "…used to create many web pages, sometimes entire sections..." <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step4c Reminder paragraph 1 ] Change "And you can use..." to "Evaluators can use..." <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step4c Reminder bullet 1 ] Change "…by the WCAG 2.0 Success Criterion at least..." to "…by the WCAG 2.0 Success Criterion, at least..." (add comma) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step5 bullet 7 ] Change "web pages" to "Web pages" (capitalization) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step5a Note after In-Depth Analysis Report ] Change "(see Step 5.b: Provide and Accessibility Statement)" to "(see Step 5.b: Provide an Accessibility Statement)" (misspelling) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step5b ] Change "As per the requirements for WCAG 2.0 conformance claims, also accessibility evaluation statements have to include the following information:" to "As per the requirements for WCAG 2.0 conformance claims, accessibility evaluation statements also have to include the following information:" (change word order for clarity)<span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step5c paragraph 2 ] Change "The type of scoring system used has to be indicated along with..." to "The type of scoring system used has to be indicated, along with..." (added comma) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step5c ] "Currently the following scoring approaches are provided by this methodology:" The word "Currently" suggests other scoring approaches will be added to this document in the future. Does it make sense to remove it?<span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step5c Per Website bullet point 2 ] Change "During the evaluation mark the..." to "During the evaluation, mark the…" (added comma) <span style="color: #808080;">{Paul}</span></li><br />
<li> http://www.w3.org/TR/WCAG-EM/#step5c Per Website bullet point 3 ] Change "After the evaluation calculate..." to "After the evaluation, calculate…" (added comma) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step5c Per Web Page paragraph 1 ] occasional (misspelling) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step5c Per Web Page paragraph 1 ] Change "…such as occasional oversight but does not..." to "…such as occasional oversight, but does not..." (added comma) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step5c Per Web Page paragraph 1 ] consistently (misspelling) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step5c Per Web Page paragraph 1 ] Change "…may still have a high score even though..." to "…may still have a high score, even though..." (added comma) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step5c Per Web Page bullet 2 ] Change "During the evaluation mark..." to "During the evaluation, mark..." (added comma) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step5c Per Web Page bullet 3 ] Change "After the evaluation calculate..." to "After the evaluation, calculate..." <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step5c Per Instance paragraph 1 ] occasional (misspelling) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step5c Per Instance bullet 1 ] Change "Select a Representative Sample) calculate..." to "Select a Representative Sample), calculate..." <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step5c Per Instance bullet 3 ] Change "After the evaluation calculate..." to "After the evaluation, calculate..." (added comma) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#divide paragraph 2 ] Change "…web pages of the main website plus two..." to "…web pages of the main website, plus two…" (added comma) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#reports Appendix C introduction ] Change "…three different levels of reporting following..." to "…three different levels of reporting, following…" (added comma) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#reports Appendix C, "For In-Depth…" bullet 1 ] Change "...the report identifies if it is met or not met and provide minimally one example..." to "the report identifies if it is met or not met and at a minimum provides..." <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#reports Appendix C, "For In-Depth…" bullet 3 ] Change "Provide suggestions for improving the overall accessibility of the website and if possible suggesting guidance for the future;" to "Provide suggestions for improving the overall accessibility of the website, and if possible, suggest guidance for the future;" <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#terms Terms and Definition ] Headings that have anchors leading to them end up underlined, or behave differently in some browsers (they turn red when clicked in Safari, underlined in others), because they are coded like so: &lt;h3&gt;&lt;a id="terms" name="terms"&gt;Terms and Definitions&lt;/a&gt;&lt;/h3&gt;. Either modify how it's coded to &lt;h3&gt;&lt;a id="terms" name="terms"&gt;&lt;!-- anchor --&gt;&lt;/a&gt;Terms and Definitions&lt;/h3&gt;, or change the stylesheet to make sure they remain styled like headings only. <span style="color: #808080;">{Denis}</span> </li><br />
</ul><br />
<br />
==Comments sent directly (not through EOWG)== <br />
<ul><br />
<li style="padding-bottom:0.5em">Jennifer (2012_09_29): Submitted this [http://lists.w3.org/Archives/Public/public-wai-evaltf/2012Sep/0088.html comment on WACG-EM 1.0 -- use of internal links] independently -- meaning that I did not post on behalf of EOWG.</li><br />
</ul><br />
<br />
</div><br />
<br />
__NOINDEX__</div>Wdickhttps://www.w3.org/WAI/EO/wiki/index.php?title=WCAG-EM_review&diff=4673WCAG-EM review2013-04-11T00:49:55Z<p>Wdick: /* EOWG discussed comments (Introduction): */</p>
<hr />
<div>Nav: [[Main Page|EOWG wiki main page]]<br />
<br />
__TOC__<br />
Links:<br />
* [http://www.w3.org/TR/WCAG-EM/ WCAG-EM document] - latest published Working Draft<br />
* [http://www.w3.org/WAI/ER/2011/eval/track/issues/open Open Issues] - Eval Task Force issue tracking<br />
<br />
Reminder: EOWG will focus on the types of questions below under [[#Comments submitted on 22 October 2012]]. If you have comments on specific technical points in the document, you can submit them directly yourself -- that is, e-mail them to public-wai-evaltf@w3.org 22 <br />If you're not sure, feel free to put your comments here and the Group will decide if they are ones you should send yourself.<br />
<br />
=March 2013 Comments on 26 February 2013 Working Draft=<br />
<br />
==General==<br />
<br />
<ul><br />
<br />
<li style="padding-bottom:1em">'''Location/Summary:''' Change.<br/>''Rationale: ''<span style="color: #808080;">{Name}</span></li><br />
<br />
</ul><br />
<br />
<br /><hr /><br />
<br />
<div style="color:#808080;"><br />
===EOWG discussed comments (General):===<br />
<ul><br />
<li style="padding-bottom:1em">'''Table of Contents:''' Change headings to something like: "Contents Summary" and "Detailed Contents". Include the Appendices in the Detailed Contents list, rather than under a separate heading.<br />
<ul><li>''initial comment: I wonder if it is necessary to list the main section in an "overview" heading, then to list all sections in a "sections heading" and have a list of appendices at last. Why not displaying a classical "table of contents" as in WCAG or other W3C documents? May be give the ability to expand/collapse the different sections (in the table of contents)? <span style="color: #808080;">{Sylvie 22/March}</span>''</li><br />
<li>''additional exchange: I think an expand/collapse menu could work <span style="color: #808080;">{Vicki - March 31}</span><br />This is to follow the W3C TR format, and I don't think it's worth pushing for adding the expand collapse here. OK? <span style="color: #808080;">{Shawn}</span> <br />Ok - cool with that <span style="color: #808080;">{Vicki - 3 April}</span>''</li></ul><br />
</li><br />
<li style="padding-bottom:1em">'''Step headings and "Methodology Requirement":'''<br />
<ol><br />
<li>Differentiate the Step headings from the statement that follows. Maybe make the headings even more terse, e.g.,<br />"Define the Scope of the Website"->"Define the Scope", <br />"Define the Goal of the Evaluation"->"Define the Goal", <br />"Define the Conformance Target"->"Define the Conformance", <br />"Define the Techniques and Failures to be Used (Optional)"->"Define the Techniques and Failures (optional)"</li><br />
<li>Delete "Methodology Requirement" and the colon so it's like:<br /><br />
&lt;h4&gt;Step 1.a. Define the Scope<br /><br />
&lt;p class="req"&gt;1.a. Define the scope of the website.<br />
</li><br />
</ol><br />
<ul><br />
<li>''initial comment: I don't understand the difference between h4: "Step 1.a: Define the Scope of the Website" and the following sentence: "Methodology Requirement 1.a: Define the scope of the website." When you listen to it, it sounds redundant but there may be a reason for this redundancy. I think this question is repeated over all the section. <span style="color: #808080;">{Sylvie 22/March}</span>''</li><br />
</ul></li><br />
<br />
<li style="padding-bottom:1em">'''Statement under Steps''' ''(e.g., "Methodology Requirement 1: Define the evaluation scope according to Methodology Requirement 1.a, Methodology Requirement 1.b, Methodology Requirement 1.c, and optionally Methodology Requirement 1.d.")'': remove the links to the sub-steps so it's:<br />&lt;p class="req"&gt;1. Define the evaluation scope<br />&lt;p class="req"&gt;2. Explore the website to be evaluated<br />&lt;p class="req"&gt;3. Select a representative sample of web pages from the website<br />&lt;p class="req"&gt;4. Audit the selected sample of web pages<br />&lt;p class="req"&gt;5. Document the evaluation findings<br />
<ul><br />
<li>''rationale:'' They are long, redundant, and the links are distracting.</li><br />
</ul><br />
</li><br />
<br />
<li style="padding-bottom:1em">'''Definition lists:''' Change the definition lists in some places where it would be better to use different markup. For specific places and rationale, see [http://lists.w3.org/Archives/Public/w3c-wai-eo/2013JanMar/0068.html e-mail] <span style="color: #808080;">{Bim}</span></li><br />
<br />
<li style="padding-bottom:1em">'''Summary sheet:''' Provide a one-page summary in multiple formats, e.g., HTML, RTF, spreadsheet, pretty PDF for printing. (EOWG can help with this.)</li><br />
<br />
</ul><br />
<br />
</div><br />
<br />
==[http://www.w3.org/TR/WCAG-EM/#abstract Abstract]==<br />
<ul><br />
<li style="padding-bottom:1em">'''Location/Summary:''' Change.<br/>''Rationale: ''<span style="color: #808080;">{Name}</span></li><br />
</ul><br />
<br /><hr /><br />
<br />
<div style="color:#808080;"><br />
===EOWG discussed comments (Abstract):===<br />
Eval TF note: Comments on the abstract also apply to the similar sentence in the main document.<br />
<ul><br />
<li style="padding-bottom:1em">Replace &quot;one possible approach&quot; with something that gives it more credibility and more strongly recommends it, e.g., &quot;one established approach&quot;. see brainstorms in [approach - EOWG minutes 5 April]<br /><br />
<ul>''initial comments:''<br />
<li>''Rationale: It sounds too tenuous and it seems we could be more encouraging. Something like “one proven method” or something. <span style="color: #808080;">{Sharron 28 March}</span>''</li><br />
</ul><br />
</li><br />
<li>Replace &quot;However, this methodology does not replace the need for quality assurance measures that are implemented throughout the design, development, and maintenance of websites to ensure their accessibility conformance.&quot; <br />with: &quot;This methodology does not replace the need for quality assurance measures implemented throughout design, development, and maintenance.&quot;<br />''<span style="color: #808080;">{initial comment: Sharron}</span>''</li><br />
</ul><br />
<br />
</div><br />
<br />
==Introduction section==<br />
<ul><br />
<li style="padding-bottom:1em">'''Location/Summary:''' Change.<br/>''Rationale: '' <span style="color: #808080;">{Name}</span></li><br />
<br />
<li style="padding-bottom:1em">[<span style="color: #808080;"><span style="background:yellow;">Wayne</span> - here's a placeholder for your comment]</span><br />'''[http://www.w3.org/TR/WCAG-EM/#audience Purpose of the Document] (and maybe elsewhere):''' @@Clarify that this is not required methodology for most developers.<br/>''Rationale: ''@@ <span style="color: #808080;">{Wayne}</span></li><br />
<br />
</ul><br />
<br />
<br /><hr /><br />
===EOWG discussed comments (Introduction):===<br />
<br />
<div style="color:#808080;"><br />
<ul><br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#terms Terms and Definitions], Common Functionality.''' Change the term &quot;Common Functionality&quot;.<br />
See brainstorms in [common terms shortlist - EOWG minutes 5 April] and [common discussion - EOWG minutes 5 April]<br />
<ul>''initial comments''<br />
<li>''Not clear about the term &quot;common functionality&quot;. Common to what? Could another term be used that denotes the completion of a task - &quot;Task achievement&quot; perhaps? <br/><br />
''Rationale: &quot;Common&quot; is not the right word for this and authors do not want to use &quot;essential&quot;'' <span style="color: #808080;">{Sharron 28 March}</span>''</li><br />
</ul><br />
</li><br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#reading Background Reading], linked headings:''' (minor issue) Unlink the headings and add those links in the lists.<br/> ''Rationale: It's inconsistent and a bit cludgy for the some headings to be links and not others. Also, it would be best to properly indicate the link to the WCAG Oveview. Also, people with some link indicators turned off (e.g., underlining) will miss that the headings are links. <span style="color: #808080;">{initial comment: Shawn}</span>''</li><br />
<li style="padding-bottom:1em"><br />
'''[http://www.w3.org/TR/WCAG-EM/#introduction Introduction] "need"'''. Replace the words &quot;need&quot; and &quot;needs&quot;. Probably replacing with &quot;should&quot; would be simpliest; however, we understand there issues with that word. <br />
See brainstorms in [needs - EOWG minutes 5 April]<br />
<ul>''initial comments''<br />
<li>''Don't like the repetition of &quot;need,&quot; &quot;needs to&quot;<br />Rationale: It doesn't actually make sense, seem true. Better to use &quot;should&quot;<span style="color: #808080;"> {Sharron, 28/March}</span>''</li><br />
</ul><br />
</li><br />
<li style="padding-bottom:1em"> '''[http://www.w3.org/TR/WCAG-EM/#introduction Introduction] Later on.''' From the second sentence, remove the words &quot;Later on&quot;<br />
<ul>''initial comments''<br />
<li> ''Rationale: content could well be in the process of being written or content could already be available. In other words, content creation may not necessarily take place later on. <span style="color: #808080;">{Vicki -31 March}</span>''</li><br />
</ul><br />
</li><br />
<li style="padding-bottom:1em">'''Abstract/Intro/Scope:''' - Tighten it up. It should be a short summary. Best if the whole this is not exactly the same wording as later in doc.<br />
<ul>''initial comments'' <li>''A large part of the Abstract is repeated in the Introduction and Scope section. Is this really intentional?<br/>Rationale: I think documents like these are already long enough, without some content being repeated. <span style="color:#808080;">{Denis 29 March}</span>''<br /><br />
''I think it's common practice for the Abstract to be a summary of material from the main document, and therefore should repeat info.<span style="color: #808080;">{Shawn}</span>''</li><br />
</ul><br />
</li> <br />
</ul><br />
<br />
<ul><br />
<br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#audience Purpose of the Document]:''' Re-write the list to be more clear, and to focus on the most common uses first. fyi, see [http://www.w3.org/WAI/eval/conformance#for Who WCAG-EM is for] in Overview page.<br/>''Rationale:'' As written, the repetition of words makes it quite difficult to parse. Also, we are concerned about having "website developers" as the first item. See: Shadi (for discussion in [http://www.w3.org/2013/02/26-eo-minutes#item01 EOWG f2f before CSUN]).<br />(Below are a couple ideas from individuals. EOWG didn't have time to work through these.)</li><br />
<br />
<ul>''initial comments:''<br />
<br />
<li style="padding-bottom:1em">''The readability of the "Purpose of this Document" section seems difficult. Because the bullet items are long, they seem too bunched together at their current spacing and too wide for easy reading of a list. Also, many of the lines begin with very similar wording: "web accessibility" begins 4 of the 8 lines; web or website begins every line. Lists with similar wording, especially at the beginning reduce readability since it's difficult to distinguish one line from another. Perhaps some lines could start with a distinct function instead of the type of user. Or set up the list as a table with the type of user on the left column and the function or purpose in the right column.<br />
<br />
For example:''<br />
<br />
<table width="80%" border="1" cellspacing="1" cellpadding="1" style="color:#808080;"><br />
<tr><br />
<th scope="column">Function</th><br />
<th scope="column">Example</th><br />
</tr><br />
<tr><br />
<td><strong>An evaluation tool</strong></td><br />
<td><strong>Web developers</strong> who want to evaluate the accessibility conformance of their websites<br />
[Suggested Change] Web Developers who's primary duties include evaluation for web accessibility conformance</td><br />
</tr><br />
<tr><br />
<td><strong>Analysis &amp; reporting</strong></td><br />
<td><strong>Consultants</strong> who want to report the accessibility conformance of websites to their owners</td><br />
</tr><br />
<tr><br />
<td><strong>A learning tool</strong></td><br />
<td><strong>Accessibility researchers</strong> and disability advocates who want to learn accessibility conformance practices</td><br />
</tr><br />
<tr><br />
<td><strong>A teaching tool</strong></td><br />
<td> <strong>Trainers and educators</strong> who want to teach methods and approaches for web accessibility evaluation</td><br />
</tr><br />
<tr><br />
<td><strong>Accessibility Benchmarking</strong></td><br />
<td><strong>Individuals</strong> who want to benchmark or compare the accessibility conformance of websites</td><br />
</tr><br />
</table><br />
<br />
''I'm not sure I know the best solution, only that the readability of this section is problematic. <span style="color: #808080;">{Howard, 21/March }''</span></li><br />
<li><p>The claim that WCAG-EM is for web developers who are interested in accessibility, will probably discourage more developers than it will encourage. WCAG-EM is for developers who specialize in accessibility or who want to specialize in accessibility. It is way to exhaustive for a general web developer who wants to write accessible code. I fear that casting the net too broadly will discourage many well meaning developers, and may inhibit adoption by people who need it. </p><br />
<p><b>Possible Danger:</b> Administrators who are ignorant of the divisions of labor in a web development project may assign this document to all developers, and accidentally cause push back from developers who do not need and cannot tolerate this level of detail. </p>{Wayne}</li><br />
<br />
<li>''[further comment] Agree with the difficulty of reading. Very much like the table.<span style="color: #808080;">{Sharron, 28/March }</span>''</li><br />
<br />
<li>''The "who" refers back to a process, not a person, in the bullet item "Web accessibility monitoring activities who want to benchmark or compare the accessibility conformance of websites" under "Purpose of Document." One possible solution: change "monitoring activities" to "monitors."<span style="color: #808080;">{Howard, 21/March }</span>''</li><br />
<li>''Observation: The list indicates use cases that "want" to perform an activity, how about "need" to perform an activity? Possibly, by shortening the items for easier reading, and including some "need" to perform activities, the list might not seem repetitive (i.e. 4x starting with "Web accessibility...") and may be easier to read. (I would even remove the repeated instances in the bullet points "of websites" since it it's clear in the context of the document that the reference is to accessibility conformance "of websites"). Suggested rewording with shorter sentences:<br /><br />
<br />
• Accessibility evaluation service providers who need to evaluate websites for accessibility conformance <br /><br />
• Experts performing accessibility monitoring activities who need to benchmark or compare the accessibility conformance of websites<br /><br />
• Consultants who need to analyze and report on accessibility conformance of websites<br /><br />
• Developers who want to evaluate accessibility conformance of their websites to monitor or improve them<br /><br />
• Website owners, procurers, and suppliers who want to learn about the accessibility conformance of their websites<br /><br />
• Researchers and disability advocates who want to explore accessibility conformance practices<br /><br />
• Accessibility trainers and educators who want to teach methods and approaches for web accessibility evaluation<br /><br />
• Web masters, content authors, designers, and others who want to learn more about web accessibility and evaluation<br /><br />
<span style="color: #808080;">{Vicki - 1 April }</span>''</li><br />
</ul><br /></li><br />
<br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#scope Scope of this Document], first sentence: '''Format it as a list.<br />
<ul><li>''initial comment: the first para under 'Scope' would be easier to read as a list rather than a ';' separating parts of a long para <span style="color: #808080;">{Andrew, 15/March}</span>''</li><br />
<li>''[further comment: Scope: Yes, agree, presentation using a list style would make the scope more readable <span style="color: #808080;">{Vicki - 31 March}</span>''</li><br />
</ul></li><br />
<br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#audience Purpose of this document], last sentence:''' Delete the sentence starting with "Complementary resources on ..." and add those resources to the next section "Background Reading".<br />
<ul><li><br />
''initial comment: I agree with the readability difficulties. It could also be improved in the paragraph beginning with "Complementary resources on" <br />Suggestion: Begin with: For further information, see complementary resources below." Then list those resources in a bulleted list. <span style="color: #808080;">{Sylvie 22/March}</span>''<br />
</li></ul></li><br />
</ul><br />
<br />
</div><br />
<br />
==Using this Methodology section==<br />
<ul><br />
<br />
<li style="padding-bottom:1em">'''Location/Summary:''' Change.<br/>''Rationale: '' <span style="color: #808080;">{Name}</span></li><br />
<br />
<li style="padding-bottom:1em">[http://www.w3.org/TR/WCAG-EM/#usage Using this methodology], first paragraph: Reword to be more positive and be in-line with [http://www.w3.org/WAI/EO/Drafts/eval/checks Easy Checks] (which will replace the old Preliminary Eval page)</span><br />
<ul><br />
<li>[OPEN] '''Suggested rewording:''' A preliminary review can be quite useful to identify obvious errors although it will not check every accessibility issue and will likely not catch all of the problems on a site. Nevertheless, to develop a rough understanding of the overall performance of the website, reviewers may conduct such an exploration using WAI's [http://www.w3.org/WAI/eval/preliminary.html Easy Checks - A First Review of Web Accessibility]<br/>''Rationale: Emphasizes usefulness rather than "cursory" '' <span style="color: #808080;">{Sharron 28 March}</span></li><br />
<br />
''initial comments:''<br />
<li>''In second sentence: "A more cursory approach for exploring the accessibility of a website", the term "cursory approach" is not clear to me. Is it jargony? Why not using a term that everyone can better understand? <span style="color: #808080;">{Sylvie 22/March}</span>''</li><br />
<li>''For better readability, it may better to split following sentence in two: <br />Actual text: "In many cases it is advisable to carry out such preliminary reviews before applying this methodology, for example to identify obvious errors and to develop a rough understanding of the overall performance of the website."<br />Suggestion: "In many cases it is advisable to carry out such preliminary reviews before applying this methodology. For example, identify obvious errors and develop a rough understanding of the overall performance of the website. <span style="color: #808080;">{Sylvie 22/March}</span>''</li><br />
</ul><br />
</li><br />
</ul><br />
<br />
<br /><hr /><br />
<div style="color:#808080;"><br />
<br />
===EOWG discussed comments (Using this Methodology):===<br />
<ul><br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#applicability Scope of Applicability]'''<br />
<br />
Needs clarification.<br />
<ul><br />
''initial comment:''<br />
<li>''Confused between paragraph above &quot;Example of a website diagram&quot; and one below. Above paragraph seems to indicate that a self-contained subsection of a website would qualify for this evaluation as a &quot;self-enclosed&quot; site. In the paragraph below the diagram, the implication is that &quot;sub-sections&quot; of a university site may not be considered self-enclosed sites: &quot;In the example above, none of the depicted parts may be excluded from the scope of evaluation in the context of this methodology, if it is to be applied to the university website.&quot; Perhaps this is referring to evaluating the entire university site as a whole. Anyway - it's a confusing section. I can't offer a rewording until I know for sure the exact meaning trying to be conveyed. <span style="color: #808080;">(Howard 4 April)</span>''</li><br />
</ul><br />
</li><br />
<li style="padding-bottom:1em"> '''Duplicate sentence: ''' [http://www.w3.org/TR/WCAG-EM/#teams Review Teams] and immediately following section, [http://www.w3.org/TR/WCAG-EM/#users Involving Users] both begin with the same sentence. &quot;The methodology defined by this document can be carried out by an individual evaluator with the skills described in section Required Expertise.&quot; Reconsider if this sentence is really necessay in both places. If so, consider that it will look like an error to some people, so see if there's aother way to cover the information.<br />
<ul><br />
''initial comment:''<br />
<li>''Is this really necessary?''<br/><br />
''Rationale: I don't understand what it adds to the point of either of these sections. <span style="color: #808080;">{Sharron 28 March}</span>''</li><br />
</ul><br />
</li><br />
<br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#specialcases Particular Types of Websites], Web Applications section:''' Rewrite to be more clear.<br />(Below are a couple ideas from individuals. EOWG didn't have time to work through these.)<br />
<ul><br />
<li>''initial comment: In second bullet "Web Applications", the note of this part is very long due to the many links and few sentences. Is it possible to make it clearer? After I read it twice, I still try to understand it. <span style="color: #808080;">{Sylvie 22/March}</span>''</li><br />
<li>''I can understand why the definition may be difficult to understand. Below is a suggested abridged version:''<br/ ><br />
''Websites with a limited number of pages which dynamically generate content are considered as a single website (or part of a larger site). Each state of a web page and content-generated web page for the purpose of this document should be included as a candidate for sampling. <span style="color: #808080;">{Vicki - 1 April}</span>''</li><br />
</ul></li><br />
</ul><br />
<br />
</div><br />
<br />
==Conformance Evaluation Procedure section==<br />
<ul><br />
<br />
<li style="padding-bottom:1em">'''Location/Summary:''' Change.<br />
<br> <br />
The paragraph describing the flow diagram has visual dependencies. Change to:<br />
"The workflow diagram depicts each of the steps defined in this<br />
section. Work flow starts with the first step and proceeds to the last<br />
step in order. In addition, the diagram permits evaluators to return<br />
to any preceding step in the process whenever the evaluation reveals a<br />
need to rework a sequence of steps."<br />
<br/>''Rationale: '' <span style="color: #808080;">{Wayne}</span></li><br />
Describing arrows. The new description is a functional description of the picture.<br />
</ul><br />
===Step 1: Define the Evaluation Scope Section===<br />
<ul><br />
<br />
<li style="padding-bottom:1em">'''Location/Summary:''' Change.<br/>''Rationale: '' <span style="color: #808080;">{Name}</span></li><br />
<br />
<li style="padding-bottom:1em">[EOWG sees the need for the sentence. since some found it confusing, please look to see if can make it more clear.]<br /><br />
'''[http://www.w3.org/TR/WCAG-EM/#step1a Step 1a]''' Sentence: "This scope definition may not contradict the terms established in section Scope of Applicability." Comment: I find this sentence somewhat confusing. Is it really necessary? <span style="color: #808080;">{Vicki - 1 April}</span><br />
<br />Replacing "may" with "should" makes this clearer to me.<span style="color: #808080;">{Anna Belle - 4 April}</span><br />
</li><br />
<br />
<li style="padding-bottom:1em">[EOWG - need to come up with better terms for each and better explanations. the main explanation should be in one place, it's confusing to have as it currently is in two places. see minutes for brainstorms.]<br />'''[http://www.w3.org/TR/WCAG-EM/#step1b Step 1b]:''' Defining the Goal. I am not sure I agree that there is sufficient difference in the two in-depth reports to require three categories. Seems clearer to stick to 2 - basic and detailed and maybe say a bit about the fact that the amount of detail is good to be part of the definition as well.<br/>''Rationale: It may be splitting hairs but it seems that once you have made the decision to go beyond a statement of conformance, there is an entire spectrum of detail and nuance. Why not four categories then? or more?'' <span style="color: #808080;">{Sharron 28 March}</span><br />I thought the problem lay in the label; the 3 definitions seemed distinct but "detailed report" did not seem to accurately reflect the 2nd report according to its description since there's no detail. Perhaps "Statistical Report" or "Itemized Page Report" would be a better fit. "Basic Report" - not sure this fits the description either. Perhaps "Pass / Fail Rating" would be more appropriate.<span style="color: #808080;">{Howard 4 April}</span></li><br />
<br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#step1d Step 1d]''' says "However, it is not necessary to use these particular techniques. In fact, in some situations, such as in a closed network, it may be necessary to use techniques that are specifically developed to the particular needs of the users of that network. Individuals and organizations developing techniques have to employ methods for establishing the technique's ability to meet the WCAG 2.0 Success Criteria." without support .<br/>''Rationale:Wouldn't it be useful to provide one or two examples of this? So it makes more sense to those reading this document? '' <span style="color: #808080;">{Denis 28 March}</span></li><br />
<li style="padding-bottom:1em">In addition to providing examples, this should not be an optional part of the methodology. It seems critical for the reviewer to define what techniques are being used to measure conformance or nonconformance to the SC. The section could make note of the fact that reviewers are not bound by previously established W3C Techniques and Failures, but it should still require that some documentation is needed of just what Techniques are being used. Could also encourage the addition of those new Techniques to the existing library.<br/>''Rationale: '' Without techniques being defined, the review is in danger of becoming undocumented opinion rather than measurement of conformance to a standard. <span style="color: #808080;">{Sharron 3 April}</span></li><br />
</ul><br />
<br />
===Step 2: Explore the Target Website Section===<br />
<br />
<ul><br />
<li style="padding-bottom:1em">'''Location/Summary:''' Change.<br/>''Rationale: '' <span style="color: #808080;">{Name}</span></li><br />
<br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#step2b Step2b]:Identify Common Functionality.'''I keep reading the definition of "common functionality) and I'm just not sure what it is we're talking about here. Are we talking about main navigation, header, footers and so on? Specific features that is used site wide? <br/><br />
''Rationale:'' Wouldn't it be helpful to refer to "common functionalities" as representative testing use cases for the evaluation of the website? <span style="color: #808080;">{Denis 28 March}</span></li><br />
<br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#step2b Step2b]:''' . As noted above, I believe "common" to be the wrong word here. Suggest authors think of a word more likely to convey the sense of ability to complete the task at hand.<br/>''Rationale: '' "Common" is just not the right word for what I think this is trying to mean.<span style="color: #808080;">{Sharron 28 March}</span></li><br />
<br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#step2b Step2b]:''' . Not simple. <br /><br />
Brainstorming: "core functionality", "key functionality", "site functionality" or would "purpose and functionality" work (i.e., looking at what follows in the second paragraph)? <span style="color: #808080;">{Vicki - 2 April}</span></li><br />
<br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#step2d Step2d]:''' .Sentence: "Only the web technologies that are relied upon to provide the website need to be identified for evaluation."<br/ ><br />
Comment: I feel a word is missing, can we add "functionality" after the word website so that it reads :<br/ ><br />
"Only the web technologies that are relied upon to provide the website functionality need to be identified for evaluation." <span style="color: #808080;">{Vicki - 2 April}</span><br /><br />
+1 <span style="color: #808080;">{Sharron - 3 April}</span></li><br />
<br />
<br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#step2d Step2d]:''' . Would change "provide" in "Identify the technologies relied upon to provide the website." to "render" or "produce." ''Rationale:'' You "provide" food or lodging but not a website. <span style="color: #808080;">{Howard - 4 April}</span></li><br />
<br />
</ul><br />
<br />
===Step 3: Select a Representative Sample Section===<br />
<ul><br />
<li style="padding-bottom:1em">'''Location/Summary:''' Change.<br/>''Rationale: '' <span style="color: #808080;">{Name}</span></li><br />
<br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#step3 Section Overview]:''' What is the point of the '''Note'''? Since it is to be covered in a later section, it seems redundant to mention here .<br/>''Rationale: Tersification. It is an entire unnecessary paragraph '' <span style="color: #808080;">{Sharron March 28}</span></li><br />
<br />
</ul><br />
<br />
<div style="color:#808080"><br />
====outside EOWG scope (step 3)====<br />
<ul><br />
<li style="padding-bottom:1em">[outside EOWG scope] '''[http://www.w3.org/TR/2012/WD-WCAG-EM-20120920/#step3 Step 3 Intro]:''' Instead of creating pressure on orgs to consider assessment of ALL pages, why not focus on trying to get them to think about selecting the best possible samples within reasonable scope, rather than have them perceive this selection as a failure because they can't afford to cover all pages? <br />
<br/>''Rationale: ''I know we mention it's usually not possible to evaluate all pages, but if we can recognize that it's rarely possible, then why say ideally it should be all pages? That creates unrealistic expectations and a pressure most people do not need to deal with. I feel this is wishful thinking - we need to be more realistic about this. Most accessibility evaluation do not cover all pages and no organization can ever afford to run a complete evaluation of all their pages, except for very small sites (and even then, if they have a small site, their accessibility budgets will tend to be proportionally small) <span style="color: #808080;">{Denis 28 March}</span></li><br />
<br />
<li style="padding-bottom:1em">[outside EOWG scope]'''[http://www.w3.org/TR/2012/WD-WCAG-EM-20120920/#step3e Step 3e]: Random Sample''' 5% seems a little low to me, even when the sample contains over 30 to 50 pages total (WCAG-EM implies it should always be more than this). I would suggest around 10-15% (where 50 pages would include another 5-7 random pages to complete the sample).<span style="color: #808080;">{Denis 28 March}</span><br />
<ul><br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#step3e Step3e]:''' Random Sample. I actually disagree with Denis' email objection to the 5% sample. I think %5 is an adequate number of random pages to add to the mix.<br/>''Rationale:'' If the reviewer has followed the advice and chosen the samples well, it is unlikely that the random sample will provide much (or any) value. But it is good to do as a process check.<span style="color: #808080;">{Sharron 29 March}</span></li><br />
</ul></li><br />
</ul><br />
</div><br />
<br />
===Step 4: Audit the Selected Sample Section===<br />
<ul><br />
<li style="padding-bottom:1em">'''Location/Summary:''' Change.<br/>''Rationale: '' <span style="color: #808080;">{Name}</span></li><br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#step4 Step 4] Note 1''' We should suggest isolating template findings from the rest of the findings related to main content of a page or pages, so findings/issues related to templates can be referenced globally for all related pages, rather than repeating the findings every time.<br/>''Rationale:By doing this, once the template findings are covered, all subsequent pages could only be covering the main content issues, making the whole process simpler and more organized. '' <span style="color: #808080;">{Denis 28 March}</span></li><br />
<br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#step4 Step 4] Note 2''' Add text to say: "Note: According to WCAG 2.0, Success Criteria to which there is no matching content are deemed to have been satisfied. An outcome such as 'Not Applicable' may be used to denote the particular situation where Success Criteria were satisfied because no relevant content was applicable,<span style="background:yellow;">but WCAG 2.0 does not require this. A Success Criteria that is either validated or not applicable, for whatever reason, is considered satisfied."</span> <br/>''Rationale: To explain more completely ><span style="color: #808080;">{Denis 28 March}</span></li><br />
<br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#step4c Step 4c]:''' Use Techniques and Failures should not be Optional. The section title already says "where possible." Backing away from established techniques and failures reduces confidence in the usefulness of the Techniques. Rewrite to emphasize that the Techniques allow for new ways to meet the SCs but should be followed in general.<br/>''Rationale: '' For consistency, predictability of results, etc. Could also remind evaluators to add to the Techniques if they find previously undocumented ways to meet the SC. <span style="color: #808080;">{Sharron 3 April}</span><br />There are reasons behind this. It's outside EOWG to debate the reasons; however, I think it '''is''' within EOWG scope to discuss how to effectively communicate the issue. <span style="color: #808080;">{Shawn}</li><br />
<br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#step4e Step 4e]''' Again I do not understand the reason for this being optional. Surely a conformance review should be replicable. Recent experience shows significantly different outcomes based on tools and testing environments. Tools documentation should be part of the report - period.<br/>''Rationale: '' I cannot think of an example where the tools and platform are irrelevant to the testing results. If someone can think of such an exception, perhaps provide that as a Note. But in general, the tools etc are an important part of the result. <span style="color: #808080;">{Sharron 3 April}</span></li><br />
<br />
</ul><br />
<br />
===Step 5: Report the Evaluation Findings Section===<br />
<ul><br />
<li style="padding-bottom:1em">'''Location/Summary:''' Change.<br/>''Rationale: '' <span style="color: #808080;">{Name}</span></li><br />
<br />
<li>'''[http://www.w3.org/TR/WCAG-EM/#step5b Step 5.b]: Conformance Evaluation Statement (Optional)''' Change <blockquote> "As per the requirements for WCAG 2.0 conformance claims, also accessibility evaluation statements have to include the following information:"</blockquote> to instead read:<br />
<blockquote>"As per the requirements for WCAG 2.0 conformance claims, accessibility evaluation statements also have to include the following information:".</blockquote>''Rationale: Grammar '' <span style="color: #808080;">{Dennis 28 March}</span></li><br />
<br />
<li>'''Step 5.b Note''' The note states:<br />
<blockquote>"It is not possible to make an accessibility evaluation statement for a website that is still in development."</blockquote><br />
But would be improved by saying: <blockquote> "An accessibility evaluation statement should not be made for a website that is still in development."</blockquote><br />
''Rationale: Again, WCAG-EM is not a dogma or a law. We shouldn't impose anything. Rather than prohibit making an accessibility evaluation statement for a website that is still under development, maybe it would be better to suggest not to.'' <span style="color: #808080;">{Denis 28 March}</span><br />
<li>Sounds better, i.e., less heavy<span style="color: #808080;">{Vicki - 2 April}</span></li> <br />
<br />
</ul><br />
<br />
==Considerations for Particular Situations section==<br />
<br />
<ul><br />
<br />
<li style="padding-bottom:1em">'''Location/Summary:''' Change.<br/>''Rationale: '' <span style="color: #808080;">{Name}</span></li><br />
</ul><br />
<br />
<div style="color:#808080;"><br />
====outside EOWG scope (considerations)====<br />
<ul><br />
<br />
<li style="padding-bottom:1em">[outside EOWG scope] '''[http://www.w3.org/TR/WCAG-EM/#divide Evaluating a Large Website with Separate Parts]:''' Would it be useful here to suggest personas? To think about the different uses that people will have for the large website and to define those pathways? For example, a government agency site may have people coming who are looking for general information, or they may be seeking specific services. There could be a robust series of pages that do not require log-ins as well as those that do. Interest/interaction may be regional and there is likely to be a different series of pages for agency staff. <br/>''Rationale: '' I have found that if the commissioner of the review will define the stakeholder/constiuent groups who most frequently use the site and what they do there, it can help define critical pathways for various tasks. <span style="color: #808080;">{Sharron 3 April}</span></li><br />
<br />
<li>[outside EOWG scope] '''[http://www.w3.org/TR/WCAG-EM/#rerun Re-Running a Website Conformance Evaluation]:''' <br />
I would like to suggest a proportion of 60%/40% between portion of web pages that were in the original sample and additional new web pages that were not in the original sample.<br/>''Rationale:'' to get significant distinction between old pages and new ones and measure how well they compare once remediation has been applied to webpages. <span style="color: #808080;">{Denis 28 March}</span></li><br />
</ul><br />
</div><br />
<br />
==Application of this Methodology section==<br />
<ul><br />
<br />
<li style="padding-bottom:1em">'''Location/Summary:''' Change.<br/>''Rationale: '' <span style="color: #808080;">{Name}</span></li><br />
<br />
</ul><br />
<br />
<hr /><br />
==Copyedits & things that probably don't need discussion==<br />
<br />
<ul><br />
<br />
<li style="padding-bottom:1em">'''Location:''' Problem: @@. Current wording: @@. Revised wording: @@. <span style="color: #808080;">{Name}</span></li><br />
<br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#step4b Step 4b]''' Small typo - including "sufficient technqiues" - s/technqiues/techniques. <span style="color: #808080;">{Denis 28 March}</span></li><br />
<br />
<li style="padding-bottom:1em">In first sentence of second paragraph of Abstract, should be comma after "for example"<span style="color: #808080;">{Howard}</span></li><br />
<li style="padding-bottom:1em">Typo: (may be several times in document): technqiues instead of techniques. <span style="color: #808080;">{Sylvie 22/March}</span></li><br />
<li style="padding-bottom:1em">'''Consistency of section headings:''' The link text of sections (steps) that are referred to are not always the same as the sections titles. For example, at the end of section step 5.A, there is a link to "Step 5.b: Provide and Accessibility Statement)". First there need to be corrected in "an accessibility Statement". Second, the title of the heading is: "Step 5.b: Provide a Conformance Evaluation Statement (Optional)", whereas the Methodology Requirement 5.B is entitled: "Provide an accessibility conformance evaluation statement (Optional).". <span style="color: #808080;">{Sylvie 22/March}</span></li><br />
<li style="padding-bottom:1em">Typo: Sucess criteria instead of Success criteria (several occurences)<span style="color: #808080;">{Sylvie 22/March}</span></li><br />
<br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#step1 Define Scope Overview]:''' Well done in explaining the relationship/role of the reviewer, the commissioner, and the owner.<br/>''Rationale: Important distinction, well made up front.'' <span style="color: #808080;">{Sharron 28 March}</span></li><br />
<br />
</ul><br />
<br />
==other==<br />
<br />
===fyi, Comments that individuals sent directly (not through EOWG)===<br />
<br />
<ul><br />
<li style="padding-bottom:1em">[http://lists.w3.org/Archives/Public/public-wcag-em-comments/2013Mar/0000.html Suzette] Excess use of 'per' especially in section 5. I'm not sure how to do an archive link but have sent the following direct:<br />
"I have read through WCAG EM and congratulate you on its progress. On a small point of language I noticed is an outbreak of the word 'per' - especially in section 5, which I would suggest could inhibit ease of understanding and is also unnecessary. I would propose removing all 'per' and using a plain language alternative, if necessary.<br />
<br />
FYI:<br />
I researched the opinions of others via Google, and here is one of the more<br />
interesting discussions on the use of per and as per:<br />
http://www.businesswritingblog.com/business_writing/2009/05/your-help-please-with-as-per.html<br />
<br />
<br />
Per and 'as per' is a pseudo-latin construction. Opinions appear to divide between clarity, efficiency, and improper use. There are however alternatives which are more natural.<br />
<br />
The only examples that fit well in my head is taking medicine 'per<br />
day', or sharing pencils 'one per child' and 'per your instructions'. The use of 'Per website' and 'per web page' (WCAG EM methodological requirement 5c) seem particularly puzzling and drove me to Google to find out why. <br />
<span style="color: #808080;">{Suzette}</span></li><br />
<br />
<li>[http://lists.w3.org/Archives/Public/public-wcag-em-comments/2013Apr/0001.html Sylvie & friends]</li><br />
</ul><br />
<br />
===Archived Notes (not for Eval TF)===<br />
<ul><br />
<li style="padding-bottom:1em">[closed. updated [[Style]] with rationale for putting periods and commas outside of quoted terms.] This may need discussion, but I'm not sure where else to put it. According the ''Chicago Manual of Style'' Rule 6.8: "Periods and commas precede closing quotation marks, whether double or single." The way I did the previous sentence conforms to that. Things like "not "magnifying glass"." don't. We use this pattern a lot, but that means we're consistent. It just may be consistently wrong. OTOH, it would be an incorrect pattern in code, so coders may cringe if we adopt the Chicago rule. (3/20/13) <span style="color: #808080;">{Anna Belle}</span></li><br />
</ul><br />
<br />
<br />
<br /><hr /><br /><br />
<br />
<div style="color:#808080;"><br />
=<span style="color:#808080;">Comments submitted on 22 October 2012</span>=<br />
<br />
==Readability & Usability==<br />
'''What specific revisions will make the document more readable and usable?'''<br />
<br />
<ul><br />
<li style="padding-bottom:1em" id="reply">'''linked terms distracting'''- Every time a term is mentioned, there's a link to the definition e.g. "web pages",websites, I find this quite distracting and I think it reduces the readability <span style="color: #808080;">{Vicki}</span>.<br />
<br />Strongly agree. Some ideas: just link it the first time in the document, or a new section. OR provide an option for users to turn off these links. <span style="color: #808080;">{shawn}</span></li><br />
<br />
<li style="padding-bottom:1em">'''linked references in sentences''' - the linked reference (e.g. "3.5 Step 5: Report the Evaluation Findings") in the middle of a sentence is also a little distracting and breaks the reading. <span style="color: #808080;">{Vicki}</span></li><br />
<br />
<li style="padding-bottom:1em">'''examples matching use cases''' - readability, section 1.1 scope and 1.2 audience. I think this is a difficult read for the intended audience. To improve usability I would suggest there is a need for better tailored use cases that match 1.2 and are then addressed consistently. There seem to be some examples included about commerce but I think it needs to use a better defined range - that better capture the context of the audience be it large scale government sites, large commercial sites, banks and utilities, and big agencies through to smaller operators eg a local school, a local charity, small organic food retailer. <span style="color: #808080;">{Suzette}</span></li><br />
<br />
<li style="padding-bottom:1em">'''Delete text from Abstract''' - Abstract current wording: "This work is part of complementary W3C/WAI activities on Web Accessibility Evaluation and Testing that address different W3C/WAI guidelines and specifications."<br />Comment: This leads reads off the page to 2 separate places. Suggest not having it in the Abstract. OK in the intro, but in the abstract, I think it takes the focus off this document too much. <span style="color: #808080;">{Shawn}</span></li><br />
<br />
<li style="padding-bottom:1em">'''Section numbering''' - Please consider not numbering every section. "3.4 Step 4:" etc adds complexity. It would be much simpler to just have "Step 4:" <span style="color: #808080;">{shawn}</span></li><br />
<br />
<li style="padding-bottom:1em">[minor] delete "W3C/WAI" where you can</li><br />
<li style="padding-bottom:1em">[minor] add "(WCAG-EM)" to the title, abstract, and introduction</li><br />
<br />
</ul><br />
<br />
==Scope==<br />
'''Is it clear that this set of methodologies is only for websites after they are built and does not address methodologies that might be used prior to and during development? If not, please suggest ways to clarify the scope.'''<br />
<ul><br />
<li style="padding-bottom:1em"> Given that the title is about Compliance evaluation, I have no problem with clarifying that the scope is what educationalists call summative assessment (like the final exam!) rather that formative assessment (feedback you can learn from). I noted a number of mentions in the opening sections about the benefits or effects of iterative testing during the design process. <br />
<br />
My suggestion is to keep the two types of testing separate because they relate to substantially different scenarios. Developers probably should not do their own formal compliance testing. I would suggest that the EM has a short paragraph to discuss the difference so that the reader is aware of this and can chose whether the Compliance EM document is relevant or if they need to go to the less formal 'Design_and_ Evaluation' section. <span style="color: #808080;">{Suzette}</span></li><br />
</ul><br />
<br />
[http://www.w3.org/TR/WCAG-EM/#scope 1.1 Scope of this Document] - second and third paragraphs, cited below:<br />
<br />
"However, this methodology only addresses evaluation of website conformance to WCAG 2.0 after its development. Complementary resources from W3C/WAI on evaluation provide guidance on evaluation in other situations, and complementary W3C/WAI activities on Web Accessibility Evaluation and Testing address different W3C/WAI guidelines and specifications."<br />
<br />
"Also, WCAG 2.0 conformance requirements apply to individual web pages. However, on most websites it is not feasible to evaluate every web page with reasonable effort. To ensure conformance of a website to WCAG 2.0 it is necessary to ensure that this is considered throughout the development process. Following this methodology helps assess the level of conformance with reasonable confidence where it is not feasible to evaluate every web page."<br />
<br />
* I prefer not to restrict the evaluation to "only" sites after development. <br />
* I find the second paragraph starting "Also, WCAG 2.0 conformance....etc." somewhat puzzling. In the first paragraph, there is mention that the evaluation methodology is only for sites after development but, on the other hand, in the second paragraph, there is mention of the importance of conformance during the development process and following "this methodology" (which in the first para is stated as only for after development) helps assess the conformance.<br />
<br />
Suggestion (if the scope is fixed on already developed sies):<br />
<br />
This methodology is best used to address evaluation of website conformance to WCAG 2.0 after development. WCAG 2.0 conformance requirements apply to individual web pages. On most websites, it can be challenging to evaluate every single web page. This methodology helps assess the level of conformance with reasonable confidence where it is not feasible to evaluate every web page. <br />
<br />
Complementary resources from W3C/WAI on evaluation provide guidance on evaluation in other situations, and complementary W3C/WAI activities on Web Accessibility Evaluation and Testing address different W3C/WAI guidelines and specifications.<br />
<br />
It is noted that conformance which is considered during the development process reduces significantly the costs of evaluation after development. <br />
<span style="color: #808080;">{Vicki}</span><br />
<br />
'''[important]''' The only one comment I do feel somewhat concerned about is the "Scope" and restricting the document to "only" sites after development. I look at it from the point of view of someone e.g. a developer coming across the document through a search and, with the patience (rather lack of it) that we have on the web, it might be disregarded by the restrictive focus. It is also a document which could still be useful to someone who might perform iterative evaluation through the development process. Therefore, I would recommend being more receptive to a wider audience by changing the wording somewhat. <span style="color: #808080;">{Vicki via Sharron}</span><br />
<br />
==Evaluate throughout==<br />
'''How should we communicate the importance of evaluating throughout website development, not just at the end?'''<br />
<ul><br />
<li style="padding-bottom:1em">'''Abstract'''<br />''Abstract current wording:'' (in a paragraph) However, ensuring and maintaining accessibility requires that accessibility is considered throughout the development process. Complementary resources from W3C/WAI on evaluation provide guidance for other situations.<br /><br />
''Abstract suggested text:'' '''(separate paragraph)''' When developing or redesigning a website, accessibility should be considered early and throughout the design and development process. This is addressed in [http://www.w3.org/WAI/EO/wiki/Eval_in_process a new resource under development] ''<span style="color: #808080;">{which EOWG expects to have drafted for the next WCAG-EM draft so you can put the actual title of the page here}</span>''.<br /><br />
<span style="color: #808080;">{Shawn}</span></li><br />
<br />
<li style="padding-bottom:1em"><br />
'''Introduction, Scope, middle paragraph:'''<br /><br />
''Current text:'' "However, this methodology only addresses evaluation of website conformance to WCAG 2.0 after its development. Complementary resources from W3C/WAI on evaluation provide guidance on evaluation in other situations, and complementary W3C/WAI activities on Web Accessibility Evaluation and Testing address different W3C/WAI guidelines and specifications."<br /><br />
''Suggested text:'' This methodology only addresses evaluating an existing website's conformance to WCAG 2.0. When developing or redesigning a website, accessibility should be considered early and throughout the design and development process. This is addressed in [http://www.w3.org/WAI/EO/wiki/Eval_in_process a new resource under development] ''<span style="color: #808080;">{which EOWG expects to have drafted for the next WCAG-EM draft so you can put the actual title of the page here}</span>''.<br /><br />
'''(new paragraph)''' Related information outside the scope of this document is provided in [http://www.w3.org/WAI/eval/ Evaluating Websites for Accessibility], [http://www.w3.org/WAI/eval/ W3C WAI Web Accessibility Evaluation and Testing Activities], and [http://www.w3.org/WAI/guid-tech.html WAI Guidelines and Techniques]. <br /><br />
<span style="color: #808080;">{shawn}</span></li><br />
<br />
</ul><br />
<br />
==Missing?==<br />
'''Are there any major considerations that we have overlooked or misrepresented?'''<br />
<ul><br />
<li style="padding-bottom:1em">'''Updates, maintenance, drift:''' An accessibility audit is static - a snapshot in time. By contrast, contemporary websites are organic - constantly evolving and growing. New material and novel features can be added by people who were not part of the original development team and these authors may have very limited editorial skills, and knowledge of development. As part of EM, I would suggest that that we should make a strong case for planned reviews to maintain standards and avoid the effect of drift that has been observed by researchers. <span style="color: #808080;">{Suzette}</span></li><br />
</ul><br />
<br />
==Related material==<br />
'''How much should we refer to and link to existing material as reference and how much should we include directly in the new material? Balance the inconvenience of jumping back and forth between existing documents against our reluctance to unnecessarily duplicate information.'''<br/><br />
'''How should we align the WCAG-EM work with the [http://www.w3.org/WAI/EO/wiki/Web_Accessibility_Preliminary_Evaluation Preliminary Evaluation document] now in process at EOWG?<br />What should the [http://www.w3.org/WAI/eval/conformance.html Conformance Evaluation] page be in relation to WCAG-EM?''' (see also [[Eval Analysis]])<br />
<ul><br />
<li style="padding-bottom:1em">EOWG is currently planning to update the [http://www.w3.org/WAI/eval/preliminary.html old Preliminary Eval page], edit the [http://www.w3.org/WAI/eval/conformance.html old Conformance Eval] page to be something like a "WCAG-EM light", and develop a page on [http://www.w3.org/WAI/EO/wiki/Eval_in_process Evaluating throughout the process]. See more in [[Eval Analysis]]. We look forward to talking with the Eval TF about this approach.</li><br />
</ul><br />
<br />
==Other==<br />
''These comments were entered before we had the structure above, so might apply to above or not.''<br />
<ul><br />
<li style="padding-bottom:1em">'''[Very Important]''' '''[http://www.w3.org/TR/WCAG-EM/#step1d Methodology Requirement 1.d]''' - This requirement appears to claim that the website owner and evaluator are free to choose which users may be excluded. Human rights do not work that way. What reasonable base technologies are required for conformance? This is particularly disturbing within the context of intranets where employers may choose to limit users to assistive technologies the employer can purchase cheaply. The note at the end is not sufficient.<br/><br />
Example, many sites prescribe large print with high contrast to be a universal cure for low vision. This discounts the need for albinos to have lower luminosity. Without high luminosity, high contrast is not possible. <span style="color: #808080;">{Wayne Dick}</span></li><br />
<li style="padding-bottom:1em">'''[important]''' '''[http://www.w3.org/TR/WCAG-EM/#step1e 3.1.5 Step d]''' - appeared to invite employer determined prescription of assistive techonolgy and accessibility support. The result will be employer defined necessary employment discrimination. <span style="color: #808080;">{Wayne Dick}</span></li><br />
<li style="padding-bottom:1em">[minor] '''Relied Upon''' - Just hangs there without inclusion in the context of accessibility supported. <span style="color: #808080;">{Wayne Dick}</span></li><br />
<li style="padding-bottom:1em">[Med] The note to (Web Applications): It may not be feasible to exhaustively examine all possible settings, but sampling should apply just as any website. <span style="color: #808080;">{Wayne Dick}</span></li><br />
<li style="padding-bottom:1em">3.1.5 Step 3. The evaluation commissioner, must be informed that if the self defined sufficient techniques are used then a future accessibility audit may ask for a proof of sufficiency. <span style="color: #808080;">{Wayne Dick}</span></li><br />
<li style="padding-bottom:1em">Throughout 3.1.5 PDF and Silver light are basic web technologies. They are no more technologie than docx or raw text. They as basic web technologies. The accessibility open question.<br/><br />
This issue is particularly important if this document is going to be normative. I do specific reference to Adobe or Microsoft products as basic web technologies is serious vendor preference. <span style="color: #808080;">{Wayne Dick}</span></li><br />
<li style="padding-bottom:1em">[http://www.w3.org/TR/WCAG-EM/#step3 3.3 Step 3]: Select a Representative Sample, (First sentence) &#34;While ideally every web page of a web site is evaluated, usually this is not possible on most web sites.&#34;<br/><br />
I feel that stating "usually this is not possible on most web sites" sounds somewhat contradictory (to our objective).<br/><br />
Suggested text: &#34;While ideally every web page of a website should be evaluated, this may not be possible for very large websites.&#34; <span style="color: #808080;">{Vicki}</span></li><br />
<li style="padding-bottom:1em">[http://www.w3.org/TR/WCAG-EM/#step3 3.3 Step 3]: Select a Representative Sample - website with many heterogeneous sub-university example, the sample selection include users. Focus groups are an effective probably necessary.<br/><br />
Large heterogenous sites behave more like a set of independent sites placed under one URL. As such it is important to organize focus groups within the different autonomous site owners to determine usage patterns and prioritize pages for evaluation. When organizing the CSU System, 23 Campuses, each having more than 50 academic departments, and more administrative departments, we found that the IT unit could not get a handle on usage patterns on its own. Individual site owners had to give direct input on priority and usage. Example: At CSU Long Beach the Computer Science lab invokes the Computer Science Department Website every time a student logs into a lab machine. That makes the Computer Science Department the most referenced site on the Campus. But it is not the most important. <span style="color: #808080;">{Wayne Dick}</span></li><br />
<li style="padding-bottom:1em">Responding to the term &#34;with reasonable confidence&#34;: I have no problem with the term. Alternatively, if the above term is a point of discussion, you could simply modify the sentence to &#34;that is representative of the entire target website&#34;. <span style="color: #808080;">{Vicki}</span></li><br />
<li style="padding-bottom:1em">[http://www.w3.org/TR/WCAG-EM/#users 2.5 Involving Users (Optional)]- Second last sentence. &#34;While not required, it is strongly recommended to involve real people covering a wide range of abilities....&#34;<br/><br />
Suggest removing &#34;real&#34;. <span style="color: #808080;">{Vicki}</span></li><br />
<li style="padding-bottom:1em">[http://www.w3.org/TR/WCAG-EM/#step3 3.1.4 Methodology Requirement 1.d:] Third paragraph: second last sentence. &#34;For example, ….., then the website is effectively not accessible for some users.&#34;<br/><br />
Suggest adding something about conformance for emphasis e.g., &#34;and therefore does not conform to the specified conformance level of WCAG 2.0. ([http://www.w3.org/TR/WCAG-EM/#step1c 3.1.3 Step 1.c.])&#34; <span style="color: #808080;">{Vicki}</span></li><br />
<li style="padding-bottom:1em">[http://www.w3.org/TR/WCAG-EM/#functionality Term "Common Functionality"]<br />
Feedback was requested on the definition on &#34;Common Functionality&#34;. <br />
Having read through the document, I don’t have a problem with the term &#34;common functionality. However, it might pose a question mark to some. Therefore, I’ve put forth a few options below depending on what you mean and if you wish to be more specific:<br/><br />
If it is the general functionality of the site, you could simply leave out the word &#34;common&#34; or use &#34;basic functionality&#34;<br/><br />
If &#34;common functionality&#34; has a more technical connotation (referring to the style sheets, javascript, classes, i.e., the technical mandatory requirements for multiple device support and functionality), leave it as &#34;common&#34;<br/><br />
Another suggestion in the line of &#34;common&#34; and &#34;key&#34; is “core”.<br/><br />
Suggestion to modify the description (in line with the &#34;Note&#34;):<br/><br />
Functionality of a website includes tasks that users of a website perform in order to achieve a goal. <span style="color: #808080;">{Vicki}</span> </li><br />
<br />
<li style="padding-bottom:1em">'''3.5.3 Step 5.c''': Provide a Performance Score (optional) I think there are good reasons for offering a score in addition to or as an alternative to the absolute measure of pass/fail. I have read this section several times, and tried really hard to construct a formula to help me comprehend the differences but I am currently confused. Maybe my basic scenario is wrong, so perhaps a worked example would help? Eg what would the score show where some form elements are consistently incorrectly marked and are affecting 5 out of 10 pages tested. <span style="color: #808080;">{Suzette}</span></li><br />
<br />
<li style="padding-bottom:1em">Term "sub-site" : do you want to add the definition to the terms and definitions? <span style="color: #808080;">{Vicki}</span></li><br />
<li style="padding-bottom:1em">Section step 1.A, last paragraphis not clear to me. What is necessary there? May be it could be easier to understand with concrete examples. <quote>"The outcome of this step is an unambiguous definition for the target website, so that for each web page it can be determined whether it is within the scope of evaluation or not. Where possible, it is recommended to use formalizations such as regular expressions or listings of Universal Resource Identifiers that define the web pages<br />
that are within the scope of evaluation (part of the target website)."</quote> <span style="color: #808080;">{Sylvie}</span></li><br />
<br />
<li style="padding-bottom:1em"> <br />
'''1.3 Background Reading, Accessible Web Design''' <br /><br />
This section doesn't feel right. For example, my first reaction was that some relevant documents are missing, such as [http://www.w3.org/WAI/impl/improving.html Improving the Accessibility of Your Website] – and that some included here are maybe not more important than others that weren't included, e.g., [http://www.w3.org/WAI/older-users/developing Developing Websites for Older People] & [http://www.w3.org/WAI/mobile/overlap.html Web Content Accessibility and Mobile Web] seem less important in this context.<br/><br/><br />
Please reconsider the purpose of this list in the context of WCAG-EM. (Remember this section starts with "It is assumed that the reader of this document is familiar with the following related resources from W3C/WAI:") I can see that Essential Components of Web Accessibility and How People with Disabilities Use the Web are particularly important for evaluation &mdash; perhaps only list those 2 &mdash; and not under the heading "Accessible Web Design" but something more directly related to understanding evaluation in the bigger context. <br /><br />
(minor point: This section is not parallel with the others above it &mdash; although I don't think that's a big deal. minor edit:link change: [http://www.w3.org/WAI/mobile/overlap.html Web Content Accessibility and Mobile Web])<br />
<br /><span style="color: #808080;">{Shawn}</span></li><br />
<br />
<li style="padding-bottom:1em">'''Background Reading'''. <br /><br />
''current wording:'' "It is assumed that the reader of this document is familiar with the following related resources from W3C/WAI:" <br /><br />
''Ideas for edited wording:'' "To effectively use this methodology, you should be familiar with the following related information." <br /><br />
''or'' "The information below related to WCAG 2.0 and evaluation is important background for using this methodology. "<br />
<span style="color: #808080;">{Shawn}</span></li><br />
<br />
</ul><br />
<br />
<br />
<br />
<ul><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#scope paragraph 1 ] I think Howard may have made this suggestion already, but instead of using semicolons, use an unordered list instead.<br /><br /><br />
<br />
The methodology described in this document, WCAG-EM, provides guidance on:<br />
<ul><br />
<li>defining parameters for the evaluation scope</li><br />
<li>exploring and understanding websites including their key features and functionality</li><br />
<li>sampling representative web pages from websites where it is not feasible to evaluate all web pages of a website</li><br />
<li>evaluating the conformance of these selected web pages to the target level of WCAG 2.0 conformance</li><br />
<li>documenting and reporting the findings from such evaluation</li><br />
</ul><br />
<span style="color: #808080;">{Paul}</span></li><br />
</ul><br />
<br />
<ul><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#procedure ] I know this was discussed on the last call - description of diagram should be an ordered list. <span style="color: #808080;">{Paul}</span></li><br />
</ul><br />
<br />
<ul><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#reports Appendix C, "For In-Depth…" last paragraph ] There are a lot of unordered lists in this section already, so it may be overkill.<br />
<br /><br /><br />
Change:<br />
<br /><br /><br />
Reports could also indicate the impact of issues found and specifically identify any high impact issues that are easy to fix. This could include: Any accessibility issues that interfere with the user completing tasks, issues that affect navigation and orientation, issues that occur very frequently and issues that can cause any loss or harm to a user. A lot of the important but technical information could be put in an appendix (such as documentation of each outcome of the steps as per Step 5.a: Provide Documentation for Each Step).<br />
<br /><br /><br />
to:<br />
<br /><br /><br />
Reports could also indicate the impact of issues found and specifically identify any high impact issues that are easy to fix. This could include:<br />
<ul><br />
<li>Any accessibility issues that interfere with the user completing tasks</li><br />
<li>issues that affect navigation and orientation</li><br />
<li>issues that occur very frequently</li><br />
<li>issues that can cause any loss or harm to a user.</li><br />
</ul><br />
A lot of the important but technical information could be put in an appendix (such as documentation of each outcome of the steps as per Step 5.a: Provide Documentation for Each Step).<br />
<span style="color: #808080;">{Paul}</span></li><br />
</ul><br />
<br />
==Copyedits & things that probably don't need discussion==<br />
<br />
<ul><br />
<li style="padding-bottom:0.5em">[http://www.w3.org/TR/WCAG-EM/#step1b 3.1.2 Step 1.b.] In-Depth Analysis. End of last sentence is missing a fullstop. <span style="color: #808080;">{Vicki}</span></li><br />
<li style="padding-bottom:0.5em">3.2.3 "Note: This step is intended to identify groups of web page instances, including in web applications."<br/>Suggest drop the "in" as in "including web applications" or add "including those in web applications". <span style="color: #808080;">{Vicki}</span></li><br />
<br />
<li>[ http://www.w3.org/TR/WCAG-EM/#introduction paragraph 2 ] "This methodology can also be useful for other purposes," (add comma) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#introduction paragraph 3 ] "…and complements existing WCAG 2.0 resources," (add comma) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#audience bullet 5 ] Change "…monitoring activities who want to benchmark…" to "…monitoring activities that benchmark…" <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#usage last sentence ] Change "…of the overall performance of the website…" to "…of the overall conformance of the website…" <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#specialcases Small Websites ] "For websites with few web pages," (add comma) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#specialcases Web Applications Note ] Change "These individual states of web page" to "These individual states of web pages" <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#specialcases Web Applications Note ] Change "…to generate these states of web page and generated web page" to "…to generate these states of web pages and generated web pages" <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#specialcases Website with Separable Areas ] Consider adding example of "site administration" to (extranet) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step2 Methodology Requirement 2 Note ] Change "…other aspects of the implementation that makes" to "…other aspects of the implementation that make" <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step3 third paragraph ] Change "…and in many cases these web pages may have different design to others" to "…and in many cases these web pages may have different design than others" <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step3 third paragraph ] Change "…can significantly reduce the required sample size while..." to "…can significantly reduce the required sample size, while..." (add comma) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step4a Note ] Change "…used to create many web pages, sometimes entire parts..." to "…used to create many web pages, sometimes entire sections..." <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step4c Reminder paragraph 1 ] Change "And you can use..." to "Evaluators can use..." <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step4c Reminder bullet 1 ] Change "…by the WCAG 2.0 Success Criterion at least..." to "…by the WCAG 2.0 Success Criterion, at least..." (add comma) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step5 bullet 7 ] Change "web pages" to "Web pages" (capitalization) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step5a Note after In-Depth Analysis Report ] Change "(see Step 5.b: Provide and Accessibility Statement)" to "(see Step 5.b: Provide an Accessibility Statement)" (misspelling) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step5b ] Change "As per the requirements for WCAG 2.0 conformance claims, also accessibility evaluation statements have to include the following information:" to "As per the requirements for WCAG 2.0 conformance claims, accessibility evaluation statements also have to include the following information:" (change word order for clarity)<span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step5c paragraph 2 ] Change "The type of scoring system used has to be indicated along with..." to "The type of scoring system used has to be indicated, along with..." (added comma) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step5c ] "Currently the following scoring approaches are provided by this methodology:" The word "Currently" suggests other scoring approaches will be added to this document in the future. Does it make sense to remove it?<span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step5c Per Website bullet point 2 ] Change "During the evaluation mark the..." to "During the evaluation, mark the…" (added comma) <span style="color: #808080;">{Paul}</span></li><br />
<li> http://www.w3.org/TR/WCAG-EM/#step5c Per Website bullet point 3 ] Change "After the evaluation calculate..." to "After the evaluation, calculate…" (added comma) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step5c Per Web Page paragraph 1 ] occasional (misspelling) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step5c Per Web Page paragraph 1 ] Change "…such as occasional oversight but does not..." to "…such as occasional oversight, but does not..." (added comma) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step5c Per Web Page paragraph 1 ] consistently (misspelling) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step5c Per Web Page paragraph 1 ] Change "…may still have a high score even though..." to "…may still have a high score, even though..." (added comma) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step5c Per Web Page bullet 2 ] Change "During the evaluation mark..." to "During the evaluation, mark..." (added comma) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step5c Per Web Page bullet 3 ] Change "After the evaluation calculate..." to "After the evaluation, calculate..." <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step5c Per Instance paragraph 1 ] occasional (misspelling) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step5c Per Instance bullet 1 ] Change "Select a Representative Sample) calculate..." to "Select a Representative Sample), calculate..." <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step5c Per Instance bullet 3 ] Change "After the evaluation calculate..." to "After the evaluation, calculate..." (added comma) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#divide paragraph 2 ] Change "…web pages of the main website plus two..." to "…web pages of the main website, plus two…" (added comma) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#reports Appendix C introduction ] Change "…three different levels of reporting following..." to "…three different levels of reporting, following…" (added comma) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#reports Appendix C, "For In-Depth…" bullet 1 ] Change "...the report identifies if it is met or not met and provide minimally one example..." to "the report identifies if it is met or not met and at a minimum provides..." <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#reports Appendix C, "For In-Depth…" bullet 3 ] Change "Provide suggestions for improving the overall accessibility of the website and if possible suggesting guidance for the future;" to "Provide suggestions for improving the overall accessibility of the website, and if possible, suggest guidance for the future;" <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#terms Terms and Definition ] Headings that have anchors leading to them end up underlined, or behave differently in some browsers (they turn red when clicked in Safari, underlined in others), because they are coded like so: &lt;h3&gt;&lt;a id="terms" name="terms"&gt;Terms and Definitions&lt;/a&gt;&lt;/h3&gt;. Either modify how it's coded to &lt;h3&gt;&lt;a id="terms" name="terms"&gt;&lt;!-- anchor --&gt;&lt;/a&gt;Terms and Definitions&lt;/h3&gt;, or change the stylesheet to make sure they remain styled like headings only. <span style="color: #808080;">{Denis}</span> </li><br />
</ul><br />
<br />
==Comments sent directly (not through EOWG)== <br />
<ul><br />
<li style="padding-bottom:0.5em">Jennifer (2012_09_29): Submitted this [http://lists.w3.org/Archives/Public/public-wai-evaltf/2012Sep/0088.html comment on WACG-EM 1.0 -- use of internal links] independently -- meaning that I did not post on behalf of EOWG.</li><br />
</ul><br />
<br />
</div><br />
<br />
__NOINDEX__</div>Wdickhttps://www.w3.org/WAI/EO/wiki/index.php?title=WCAG-EM_review&diff=4672WCAG-EM review2013-04-11T00:47:53Z<p>Wdick: /* EOWG discussed comments (Introduction): */</p>
<hr />
<div>Nav: [[Main Page|EOWG wiki main page]]<br />
<br />
__TOC__<br />
Links:<br />
* [http://www.w3.org/TR/WCAG-EM/ WCAG-EM document] - latest published Working Draft<br />
* [http://www.w3.org/WAI/ER/2011/eval/track/issues/open Open Issues] - Eval Task Force issue tracking<br />
<br />
Reminder: EOWG will focus on the types of questions below under [[#Comments submitted on 22 October 2012]]. If you have comments on specific technical points in the document, you can submit them directly yourself -- that is, e-mail them to public-wai-evaltf@w3.org 22 <br />If you're not sure, feel free to put your comments here and the Group will decide if they are ones you should send yourself.<br />
<br />
=March 2013 Comments on 26 February 2013 Working Draft=<br />
<br />
==General==<br />
<br />
<ul><br />
<br />
<li style="padding-bottom:1em">'''Location/Summary:''' Change.<br/>''Rationale: ''<span style="color: #808080;">{Name}</span></li><br />
<br />
</ul><br />
<br />
<br /><hr /><br />
<br />
<div style="color:#808080;"><br />
===EOWG discussed comments (General):===<br />
<ul><br />
<li style="padding-bottom:1em">'''Table of Contents:''' Change headings to something like: "Contents Summary" and "Detailed Contents". Include the Appendices in the Detailed Contents list, rather than under a separate heading.<br />
<ul><li>''initial comment: I wonder if it is necessary to list the main section in an "overview" heading, then to list all sections in a "sections heading" and have a list of appendices at last. Why not displaying a classical "table of contents" as in WCAG or other W3C documents? May be give the ability to expand/collapse the different sections (in the table of contents)? <span style="color: #808080;">{Sylvie 22/March}</span>''</li><br />
<li>''additional exchange: I think an expand/collapse menu could work <span style="color: #808080;">{Vicki - March 31}</span><br />This is to follow the W3C TR format, and I don't think it's worth pushing for adding the expand collapse here. OK? <span style="color: #808080;">{Shawn}</span> <br />Ok - cool with that <span style="color: #808080;">{Vicki - 3 April}</span>''</li></ul><br />
</li><br />
<li style="padding-bottom:1em">'''Step headings and "Methodology Requirement":'''<br />
<ol><br />
<li>Differentiate the Step headings from the statement that follows. Maybe make the headings even more terse, e.g.,<br />"Define the Scope of the Website"->"Define the Scope", <br />"Define the Goal of the Evaluation"->"Define the Goal", <br />"Define the Conformance Target"->"Define the Conformance", <br />"Define the Techniques and Failures to be Used (Optional)"->"Define the Techniques and Failures (optional)"</li><br />
<li>Delete "Methodology Requirement" and the colon so it's like:<br /><br />
&lt;h4&gt;Step 1.a. Define the Scope<br /><br />
&lt;p class="req"&gt;1.a. Define the scope of the website.<br />
</li><br />
</ol><br />
<ul><br />
<li>''initial comment: I don't understand the difference between h4: "Step 1.a: Define the Scope of the Website" and the following sentence: "Methodology Requirement 1.a: Define the scope of the website." When you listen to it, it sounds redundant but there may be a reason for this redundancy. I think this question is repeated over all the section. <span style="color: #808080;">{Sylvie 22/March}</span>''</li><br />
</ul></li><br />
<br />
<li style="padding-bottom:1em">'''Statement under Steps''' ''(e.g., "Methodology Requirement 1: Define the evaluation scope according to Methodology Requirement 1.a, Methodology Requirement 1.b, Methodology Requirement 1.c, and optionally Methodology Requirement 1.d.")'': remove the links to the sub-steps so it's:<br />&lt;p class="req"&gt;1. Define the evaluation scope<br />&lt;p class="req"&gt;2. Explore the website to be evaluated<br />&lt;p class="req"&gt;3. Select a representative sample of web pages from the website<br />&lt;p class="req"&gt;4. Audit the selected sample of web pages<br />&lt;p class="req"&gt;5. Document the evaluation findings<br />
<ul><br />
<li>''rationale:'' They are long, redundant, and the links are distracting.</li><br />
</ul><br />
</li><br />
<br />
<li style="padding-bottom:1em">'''Definition lists:''' Change the definition lists in some places where it would be better to use different markup. For specific places and rationale, see [http://lists.w3.org/Archives/Public/w3c-wai-eo/2013JanMar/0068.html e-mail] <span style="color: #808080;">{Bim}</span></li><br />
<br />
<li style="padding-bottom:1em">'''Summary sheet:''' Provide a one-page summary in multiple formats, e.g., HTML, RTF, spreadsheet, pretty PDF for printing. (EOWG can help with this.)</li><br />
<br />
</ul><br />
<br />
</div><br />
<br />
==[http://www.w3.org/TR/WCAG-EM/#abstract Abstract]==<br />
<ul><br />
<li style="padding-bottom:1em">'''Location/Summary:''' Change.<br/>''Rationale: ''<span style="color: #808080;">{Name}</span></li><br />
</ul><br />
<br /><hr /><br />
<br />
<div style="color:#808080;"><br />
===EOWG discussed comments (Abstract):===<br />
Eval TF note: Comments on the abstract also apply to the similar sentence in the main document.<br />
<ul><br />
<li style="padding-bottom:1em">Replace &quot;one possible approach&quot; with something that gives it more credibility and more strongly recommends it, e.g., &quot;one established approach&quot;. see brainstorms in [approach - EOWG minutes 5 April]<br /><br />
<ul>''initial comments:''<br />
<li>''Rationale: It sounds too tenuous and it seems we could be more encouraging. Something like “one proven method” or something. <span style="color: #808080;">{Sharron 28 March}</span>''</li><br />
</ul><br />
</li><br />
<li>Replace &quot;However, this methodology does not replace the need for quality assurance measures that are implemented throughout the design, development, and maintenance of websites to ensure their accessibility conformance.&quot; <br />with: &quot;This methodology does not replace the need for quality assurance measures implemented throughout design, development, and maintenance.&quot;<br />''<span style="color: #808080;">{initial comment: Sharron}</span>''</li><br />
</ul><br />
<br />
</div><br />
<br />
==Introduction section==<br />
<ul><br />
<li style="padding-bottom:1em">'''Location/Summary:''' Change.<br/>''Rationale: '' <span style="color: #808080;">{Name}</span></li><br />
<br />
<li style="padding-bottom:1em">[<span style="color: #808080;"><span style="background:yellow;">Wayne</span> - here's a placeholder for your comment]</span><br />'''[http://www.w3.org/TR/WCAG-EM/#audience Purpose of the Document] (and maybe elsewhere):''' @@Clarify that this is not required methodology for most developers.<br/>''Rationale: ''@@ <span style="color: #808080;">{Wayne}</span></li><br />
<br />
</ul><br />
<br />
<br /><hr /><br />
===EOWG discussed comments (Introduction):===<br />
<br />
<div style="color:#808080;"><br />
<ul><br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#terms Terms and Definitions], Common Functionality.''' Change the term &quot;Common Functionality&quot;.<br />
See brainstorms in [common terms shortlist - EOWG minutes 5 April] and [common discussion - EOWG minutes 5 April]<br />
<ul>''initial comments''<br />
<li>''Not clear about the term &quot;common functionality&quot;. Common to what? Could another term be used that denotes the completion of a task - &quot;Task achievement&quot; perhaps? <br/><br />
''Rationale: &quot;Common&quot; is not the right word for this and authors do not want to use &quot;essential&quot;'' <span style="color: #808080;">{Sharron 28 March}</span>''</li><br />
</ul><br />
</li><br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#reading Background Reading], linked headings:''' (minor issue) Unlink the headings and add those links in the lists.<br/> ''Rationale: It's inconsistent and a bit cludgy for the some headings to be links and not others. Also, it would be best to properly indicate the link to the WCAG Oveview. Also, people with some link indicators turned off (e.g., underlining) will miss that the headings are links. <span style="color: #808080;">{initial comment: Shawn}</span>''</li><br />
<li style="padding-bottom:1em"><br />
'''[http://www.w3.org/TR/WCAG-EM/#introduction Introduction] "need"'''. Replace the words &quot;need&quot; and &quot;needs&quot;. Probably replacing with &quot;should&quot; would be simpliest; however, we understand there issues with that word. <br />
See brainstorms in [needs - EOWG minutes 5 April]<br />
<ul>''initial comments''<br />
<li>''Don't like the repetition of &quot;need,&quot; &quot;needs to&quot;<br />Rationale: It doesn't actually make sense, seem true. Better to use &quot;should&quot;<span style="color: #808080;"> {Sharron, 28/March}</span>''</li><br />
</ul><br />
</li><br />
<li style="padding-bottom:1em"> '''[http://www.w3.org/TR/WCAG-EM/#introduction Introduction] Later on.''' From the second sentence, remove the words &quot;Later on&quot;<br />
<ul>''initial comments''<br />
<li> ''Rationale: content could well be in the process of being written or content could already be available. In other words, content creation may not necessarily take place later on. <span style="color: #808080;">{Vicki -31 March}</span>''</li><br />
</ul><br />
</li><br />
<li style="padding-bottom:1em">'''Abstract/Intro/Scope:''' - Tighten it up. It should be a short summary. Best if the whole this is not exactly the same wording as later in doc.<br />
<ul>''initial comments'' <li>''A large part of the Abstract is repeated in the Introduction and Scope section. Is this really intentional?<br/>Rationale: I think documents like these are already long enough, without some content being repeated. <span style="color:#808080;">{Denis 29 March}</span>''<br /><br />
''I think it's common practice for the Abstract to be a summary of material from the main document, and therefore should repeat info.<span style="color: #808080;">{Shawn}</span>''</li><br />
</ul><br />
</li> <br />
</ul><br />
<br />
<ul><br />
<br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#audience Purpose of the Document]:''' Re-write the list to be more clear, and to focus on the most common uses first. fyi, see [http://www.w3.org/WAI/eval/conformance#for Who WCAG-EM is for] in Overview page.<br/>''Rationale:'' As written, the repetition of words makes it quite difficult to parse. Also, we are concerned about having "website developers" as the first item. See: Shadi (for discussion in [http://www.w3.org/2013/02/26-eo-minutes#item01 EOWG f2f before CSUN]).<br />(Below are a couple ideas from individuals. EOWG didn't have time to work through these.)</li><br />
<br />
<ul>''initial comments:''<br />
<br />
<li style="padding-bottom:1em">''The readability of the "Purpose of this Document" section seems difficult. Because the bullet items are long, they seem too bunched together at their current spacing and too wide for easy reading of a list. Also, many of the lines begin with very similar wording: "web accessibility" begins 4 of the 8 lines; web or website begins every line. Lists with similar wording, especially at the beginning reduce readability since it's difficult to distinguish one line from another. Perhaps some lines could start with a distinct function instead of the type of user. Or set up the list as a table with the type of user on the left column and the function or purpose in the right column.<br />
<br />
For example:''<br />
<br />
<table width="80%" border="1" cellspacing="1" cellpadding="1" style="color:#808080;"><br />
<tr><br />
<th scope="column">Function</th><br />
<th scope="column">Example</th><br />
</tr><br />
<tr><br />
<td><strong>An evaluation tool</strong></td><br />
<td><strong>Web developers</strong> who want to evaluate the accessibility conformance of their websites<br />
[Suggested Change] Web Developers who's primary duties include evaluation for web accessibility conformance</td><br />
</tr><br />
<tr><br />
<td><strong>Analysis &amp; reporting</strong></td><br />
<td><strong>Consultants</strong> who want to report the accessibility conformance of websites to their owners</td><br />
</tr><br />
<tr><br />
<td><strong>A learning tool</strong></td><br />
<td><strong>Accessibility researchers</strong> and disability advocates who want to learn accessibility conformance practices</td><br />
</tr><br />
<tr><br />
<td><strong>A teaching tool</strong></td><br />
<td> <strong>Trainers and educators</strong> who want to teach methods and approaches for web accessibility evaluation</td><br />
</tr><br />
<tr><br />
<td><strong>Accessibility Benchmarking</strong></td><br />
<td><strong>Individuals</strong> who want to benchmark or compare the accessibility conformance of websites</td><br />
</tr><br />
</table><br />
<br />
''I'm not sure I know the best solution, only that the readability of this section is problematic. <span style="color: #808080;">{Howard, 21/March }''</span></li><br />
<li><p>The claim that WCAG-EM is for web developers who are interested in accessibility, will probably discourage more developers than it will encourage. WCAG-EM is for developers who specialize in accessibility or who want to specialize in accessibility. It is way to exhaustive for a general web developer who wants to write accessible code. I fear that casting the net too broadly will discourage many well meaning developers, and may inhibit adoption by people who need it. </p><br />
<p><b>Possible Danger</b>Administrators who are ignorant of the divisions of labor in a web development may assign this document to all developers, and accidentally cause push back from developers who don't need and can't tolerate this level of detail. </p>{Wayne}</li><br />
<br />
<li>''[further comment] Agree with the difficulty of reading. Very much like the table.<span style="color: #808080;">{Sharron, 28/March }</span>''</li><br />
<br />
<li>''The "who" refers back to a process, not a person, in the bullet item "Web accessibility monitoring activities who want to benchmark or compare the accessibility conformance of websites" under "Purpose of Document." One possible solution: change "monitoring activities" to "monitors."<span style="color: #808080;">{Howard, 21/March }</span>''</li><br />
<li>''Observation: The list indicates use cases that "want" to perform an activity, how about "need" to perform an activity? Possibly, by shortening the items for easier reading, and including some "need" to perform activities, the list might not seem repetitive (i.e. 4x starting with "Web accessibility...") and may be easier to read. (I would even remove the repeated instances in the bullet points "of websites" since it it's clear in the context of the document that the reference is to accessibility conformance "of websites"). Suggested rewording with shorter sentences:<br /><br />
<br />
• Accessibility evaluation service providers who need to evaluate websites for accessibility conformance <br /><br />
• Experts performing accessibility monitoring activities who need to benchmark or compare the accessibility conformance of websites<br /><br />
• Consultants who need to analyze and report on accessibility conformance of websites<br /><br />
• Developers who want to evaluate accessibility conformance of their websites to monitor or improve them<br /><br />
• Website owners, procurers, and suppliers who want to learn about the accessibility conformance of their websites<br /><br />
• Researchers and disability advocates who want to explore accessibility conformance practices<br /><br />
• Accessibility trainers and educators who want to teach methods and approaches for web accessibility evaluation<br /><br />
• Web masters, content authors, designers, and others who want to learn more about web accessibility and evaluation<br /><br />
<span style="color: #808080;">{Vicki - 1 April }</span>''</li><br />
</ul><br /></li><br />
<br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#scope Scope of this Document], first sentence: '''Format it as a list.<br />
<ul><li>''initial comment: the first para under 'Scope' would be easier to read as a list rather than a ';' separating parts of a long para <span style="color: #808080;">{Andrew, 15/March}</span>''</li><br />
<li>''[further comment: Scope: Yes, agree, presentation using a list style would make the scope more readable <span style="color: #808080;">{Vicki - 31 March}</span>''</li><br />
</ul></li><br />
<br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#audience Purpose of this document], last sentence:''' Delete the sentence starting with "Complementary resources on ..." and add those resources to the next section "Background Reading".<br />
<ul><li><br />
''initial comment: I agree with the readability difficulties. It could also be improved in the paragraph beginning with "Complementary resources on" <br />Suggestion: Begin with: For further information, see complementary resources below." Then list those resources in a bulleted list. <span style="color: #808080;">{Sylvie 22/March}</span>''<br />
</li></ul></li><br />
</ul><br />
<br />
</div><br />
<br />
==Using this Methodology section==<br />
<ul><br />
<br />
<li style="padding-bottom:1em">'''Location/Summary:''' Change.<br/>''Rationale: '' <span style="color: #808080;">{Name}</span></li><br />
<br />
<li style="padding-bottom:1em">[http://www.w3.org/TR/WCAG-EM/#usage Using this methodology], first paragraph: Reword to be more positive and be in-line with [http://www.w3.org/WAI/EO/Drafts/eval/checks Easy Checks] (which will replace the old Preliminary Eval page)</span><br />
<ul><br />
<li>[OPEN] '''Suggested rewording:''' A preliminary review can be quite useful to identify obvious errors although it will not check every accessibility issue and will likely not catch all of the problems on a site. Nevertheless, to develop a rough understanding of the overall performance of the website, reviewers may conduct such an exploration using WAI's [http://www.w3.org/WAI/eval/preliminary.html Easy Checks - A First Review of Web Accessibility]<br/>''Rationale: Emphasizes usefulness rather than "cursory" '' <span style="color: #808080;">{Sharron 28 March}</span></li><br />
<br />
''initial comments:''<br />
<li>''In second sentence: "A more cursory approach for exploring the accessibility of a website", the term "cursory approach" is not clear to me. Is it jargony? Why not using a term that everyone can better understand? <span style="color: #808080;">{Sylvie 22/March}</span>''</li><br />
<li>''For better readability, it may better to split following sentence in two: <br />Actual text: "In many cases it is advisable to carry out such preliminary reviews before applying this methodology, for example to identify obvious errors and to develop a rough understanding of the overall performance of the website."<br />Suggestion: "In many cases it is advisable to carry out such preliminary reviews before applying this methodology. For example, identify obvious errors and develop a rough understanding of the overall performance of the website. <span style="color: #808080;">{Sylvie 22/March}</span>''</li><br />
</ul><br />
</li><br />
</ul><br />
<br />
<br /><hr /><br />
<div style="color:#808080;"><br />
<br />
===EOWG discussed comments (Using this Methodology):===<br />
<ul><br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#applicability Scope of Applicability]'''<br />
<br />
Needs clarification.<br />
<ul><br />
''initial comment:''<br />
<li>''Confused between paragraph above &quot;Example of a website diagram&quot; and one below. Above paragraph seems to indicate that a self-contained subsection of a website would qualify for this evaluation as a &quot;self-enclosed&quot; site. In the paragraph below the diagram, the implication is that &quot;sub-sections&quot; of a university site may not be considered self-enclosed sites: &quot;In the example above, none of the depicted parts may be excluded from the scope of evaluation in the context of this methodology, if it is to be applied to the university website.&quot; Perhaps this is referring to evaluating the entire university site as a whole. Anyway - it's a confusing section. I can't offer a rewording until I know for sure the exact meaning trying to be conveyed. <span style="color: #808080;">(Howard 4 April)</span>''</li><br />
</ul><br />
</li><br />
<li style="padding-bottom:1em"> '''Duplicate sentence: ''' [http://www.w3.org/TR/WCAG-EM/#teams Review Teams] and immediately following section, [http://www.w3.org/TR/WCAG-EM/#users Involving Users] both begin with the same sentence. &quot;The methodology defined by this document can be carried out by an individual evaluator with the skills described in section Required Expertise.&quot; Reconsider if this sentence is really necessay in both places. If so, consider that it will look like an error to some people, so see if there's aother way to cover the information.<br />
<ul><br />
''initial comment:''<br />
<li>''Is this really necessary?''<br/><br />
''Rationale: I don't understand what it adds to the point of either of these sections. <span style="color: #808080;">{Sharron 28 March}</span>''</li><br />
</ul><br />
</li><br />
<br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#specialcases Particular Types of Websites], Web Applications section:''' Rewrite to be more clear.<br />(Below are a couple ideas from individuals. EOWG didn't have time to work through these.)<br />
<ul><br />
<li>''initial comment: In second bullet "Web Applications", the note of this part is very long due to the many links and few sentences. Is it possible to make it clearer? After I read it twice, I still try to understand it. <span style="color: #808080;">{Sylvie 22/March}</span>''</li><br />
<li>''I can understand why the definition may be difficult to understand. Below is a suggested abridged version:''<br/ ><br />
''Websites with a limited number of pages which dynamically generate content are considered as a single website (or part of a larger site). Each state of a web page and content-generated web page for the purpose of this document should be included as a candidate for sampling. <span style="color: #808080;">{Vicki - 1 April}</span>''</li><br />
</ul></li><br />
</ul><br />
<br />
</div><br />
<br />
==Conformance Evaluation Procedure section==<br />
<ul><br />
<br />
<li style="padding-bottom:1em">'''Location/Summary:''' Change.<br />
<br> <br />
The paragraph describing the flow diagram has visual dependencies. Change to:<br />
"The workflow diagram depicts each of the steps defined in this<br />
section. Work flow starts with the first step and proceeds to the last<br />
step in order. In addition, the diagram permits evaluators to return<br />
to any preceding step in the process whenever the evaluation reveals a<br />
need to rework a sequence of steps."<br />
<br/>''Rationale: '' <span style="color: #808080;">{Wayne}</span></li><br />
Describing arrows. The new description is a functional description of the picture.<br />
</ul><br />
===Step 1: Define the Evaluation Scope Section===<br />
<ul><br />
<br />
<li style="padding-bottom:1em">'''Location/Summary:''' Change.<br/>''Rationale: '' <span style="color: #808080;">{Name}</span></li><br />
<br />
<li style="padding-bottom:1em">[EOWG sees the need for the sentence. since some found it confusing, please look to see if can make it more clear.]<br /><br />
'''[http://www.w3.org/TR/WCAG-EM/#step1a Step 1a]''' Sentence: "This scope definition may not contradict the terms established in section Scope of Applicability." Comment: I find this sentence somewhat confusing. Is it really necessary? <span style="color: #808080;">{Vicki - 1 April}</span><br />
<br />Replacing "may" with "should" makes this clearer to me.<span style="color: #808080;">{Anna Belle - 4 April}</span><br />
</li><br />
<br />
<li style="padding-bottom:1em">[EOWG - need to come up with better terms for each and better explanations. the main explanation should be in one place, it's confusing to have as it currently is in two places. see minutes for brainstorms.]<br />'''[http://www.w3.org/TR/WCAG-EM/#step1b Step 1b]:''' Defining the Goal. I am not sure I agree that there is sufficient difference in the two in-depth reports to require three categories. Seems clearer to stick to 2 - basic and detailed and maybe say a bit about the fact that the amount of detail is good to be part of the definition as well.<br/>''Rationale: It may be splitting hairs but it seems that once you have made the decision to go beyond a statement of conformance, there is an entire spectrum of detail and nuance. Why not four categories then? or more?'' <span style="color: #808080;">{Sharron 28 March}</span><br />I thought the problem lay in the label; the 3 definitions seemed distinct but "detailed report" did not seem to accurately reflect the 2nd report according to its description since there's no detail. Perhaps "Statistical Report" or "Itemized Page Report" would be a better fit. "Basic Report" - not sure this fits the description either. Perhaps "Pass / Fail Rating" would be more appropriate.<span style="color: #808080;">{Howard 4 April}</span></li><br />
<br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#step1d Step 1d]''' says "However, it is not necessary to use these particular techniques. In fact, in some situations, such as in a closed network, it may be necessary to use techniques that are specifically developed to the particular needs of the users of that network. Individuals and organizations developing techniques have to employ methods for establishing the technique's ability to meet the WCAG 2.0 Success Criteria." without support .<br/>''Rationale:Wouldn't it be useful to provide one or two examples of this? So it makes more sense to those reading this document? '' <span style="color: #808080;">{Denis 28 March}</span></li><br />
<li style="padding-bottom:1em">In addition to providing examples, this should not be an optional part of the methodology. It seems critical for the reviewer to define what techniques are being used to measure conformance or nonconformance to the SC. The section could make note of the fact that reviewers are not bound by previously established W3C Techniques and Failures, but it should still require that some documentation is needed of just what Techniques are being used. Could also encourage the addition of those new Techniques to the existing library.<br/>''Rationale: '' Without techniques being defined, the review is in danger of becoming undocumented opinion rather than measurement of conformance to a standard. <span style="color: #808080;">{Sharron 3 April}</span></li><br />
</ul><br />
<br />
===Step 2: Explore the Target Website Section===<br />
<br />
<ul><br />
<li style="padding-bottom:1em">'''Location/Summary:''' Change.<br/>''Rationale: '' <span style="color: #808080;">{Name}</span></li><br />
<br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#step2b Step2b]:Identify Common Functionality.'''I keep reading the definition of "common functionality) and I'm just not sure what it is we're talking about here. Are we talking about main navigation, header, footers and so on? Specific features that is used site wide? <br/><br />
''Rationale:'' Wouldn't it be helpful to refer to "common functionalities" as representative testing use cases for the evaluation of the website? <span style="color: #808080;">{Denis 28 March}</span></li><br />
<br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#step2b Step2b]:''' . As noted above, I believe "common" to be the wrong word here. Suggest authors think of a word more likely to convey the sense of ability to complete the task at hand.<br/>''Rationale: '' "Common" is just not the right word for what I think this is trying to mean.<span style="color: #808080;">{Sharron 28 March}</span></li><br />
<br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#step2b Step2b]:''' . Not simple. <br /><br />
Brainstorming: "core functionality", "key functionality", "site functionality" or would "purpose and functionality" work (i.e., looking at what follows in the second paragraph)? <span style="color: #808080;">{Vicki - 2 April}</span></li><br />
<br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#step2d Step2d]:''' .Sentence: "Only the web technologies that are relied upon to provide the website need to be identified for evaluation."<br/ ><br />
Comment: I feel a word is missing, can we add "functionality" after the word website so that it reads :<br/ ><br />
"Only the web technologies that are relied upon to provide the website functionality need to be identified for evaluation." <span style="color: #808080;">{Vicki - 2 April}</span><br /><br />
+1 <span style="color: #808080;">{Sharron - 3 April}</span></li><br />
<br />
<br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#step2d Step2d]:''' . Would change "provide" in "Identify the technologies relied upon to provide the website." to "render" or "produce." ''Rationale:'' You "provide" food or lodging but not a website. <span style="color: #808080;">{Howard - 4 April}</span></li><br />
<br />
</ul><br />
<br />
===Step 3: Select a Representative Sample Section===<br />
<ul><br />
<li style="padding-bottom:1em">'''Location/Summary:''' Change.<br/>''Rationale: '' <span style="color: #808080;">{Name}</span></li><br />
<br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#step3 Section Overview]:''' What is the point of the '''Note'''? Since it is to be covered in a later section, it seems redundant to mention here .<br/>''Rationale: Tersification. It is an entire unnecessary paragraph '' <span style="color: #808080;">{Sharron March 28}</span></li><br />
<br />
</ul><br />
<br />
<div style="color:#808080"><br />
====outside EOWG scope (step 3)====<br />
<ul><br />
<li style="padding-bottom:1em">[outside EOWG scope] '''[http://www.w3.org/TR/2012/WD-WCAG-EM-20120920/#step3 Step 3 Intro]:''' Instead of creating pressure on orgs to consider assessment of ALL pages, why not focus on trying to get them to think about selecting the best possible samples within reasonable scope, rather than have them perceive this selection as a failure because they can't afford to cover all pages? <br />
<br/>''Rationale: ''I know we mention it's usually not possible to evaluate all pages, but if we can recognize that it's rarely possible, then why say ideally it should be all pages? That creates unrealistic expectations and a pressure most people do not need to deal with. I feel this is wishful thinking - we need to be more realistic about this. Most accessibility evaluation do not cover all pages and no organization can ever afford to run a complete evaluation of all their pages, except for very small sites (and even then, if they have a small site, their accessibility budgets will tend to be proportionally small) <span style="color: #808080;">{Denis 28 March}</span></li><br />
<br />
<li style="padding-bottom:1em">[outside EOWG scope]'''[http://www.w3.org/TR/2012/WD-WCAG-EM-20120920/#step3e Step 3e]: Random Sample''' 5% seems a little low to me, even when the sample contains over 30 to 50 pages total (WCAG-EM implies it should always be more than this). I would suggest around 10-15% (where 50 pages would include another 5-7 random pages to complete the sample).<span style="color: #808080;">{Denis 28 March}</span><br />
<ul><br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#step3e Step3e]:''' Random Sample. I actually disagree with Denis' email objection to the 5% sample. I think %5 is an adequate number of random pages to add to the mix.<br/>''Rationale:'' If the reviewer has followed the advice and chosen the samples well, it is unlikely that the random sample will provide much (or any) value. But it is good to do as a process check.<span style="color: #808080;">{Sharron 29 March}</span></li><br />
</ul></li><br />
</ul><br />
</div><br />
<br />
===Step 4: Audit the Selected Sample Section===<br />
<ul><br />
<li style="padding-bottom:1em">'''Location/Summary:''' Change.<br/>''Rationale: '' <span style="color: #808080;">{Name}</span></li><br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#step4 Step 4] Note 1''' We should suggest isolating template findings from the rest of the findings related to main content of a page or pages, so findings/issues related to templates can be referenced globally for all related pages, rather than repeating the findings every time.<br/>''Rationale:By doing this, once the template findings are covered, all subsequent pages could only be covering the main content issues, making the whole process simpler and more organized. '' <span style="color: #808080;">{Denis 28 March}</span></li><br />
<br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#step4 Step 4] Note 2''' Add text to say: "Note: According to WCAG 2.0, Success Criteria to which there is no matching content are deemed to have been satisfied. An outcome such as 'Not Applicable' may be used to denote the particular situation where Success Criteria were satisfied because no relevant content was applicable,<span style="background:yellow;">but WCAG 2.0 does not require this. A Success Criteria that is either validated or not applicable, for whatever reason, is considered satisfied."</span> <br/>''Rationale: To explain more completely ><span style="color: #808080;">{Denis 28 March}</span></li><br />
<br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#step4c Step 4c]:''' Use Techniques and Failures should not be Optional. The section title already says "where possible." Backing away from established techniques and failures reduces confidence in the usefulness of the Techniques. Rewrite to emphasize that the Techniques allow for new ways to meet the SCs but should be followed in general.<br/>''Rationale: '' For consistency, predictability of results, etc. Could also remind evaluators to add to the Techniques if they find previously undocumented ways to meet the SC. <span style="color: #808080;">{Sharron 3 April}</span><br />There are reasons behind this. It's outside EOWG to debate the reasons; however, I think it '''is''' within EOWG scope to discuss how to effectively communicate the issue. <span style="color: #808080;">{Shawn}</li><br />
<br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#step4e Step 4e]''' Again I do not understand the reason for this being optional. Surely a conformance review should be replicable. Recent experience shows significantly different outcomes based on tools and testing environments. Tools documentation should be part of the report - period.<br/>''Rationale: '' I cannot think of an example where the tools and platform are irrelevant to the testing results. If someone can think of such an exception, perhaps provide that as a Note. But in general, the tools etc are an important part of the result. <span style="color: #808080;">{Sharron 3 April}</span></li><br />
<br />
</ul><br />
<br />
===Step 5: Report the Evaluation Findings Section===<br />
<ul><br />
<li style="padding-bottom:1em">'''Location/Summary:''' Change.<br/>''Rationale: '' <span style="color: #808080;">{Name}</span></li><br />
<br />
<li>'''[http://www.w3.org/TR/WCAG-EM/#step5b Step 5.b]: Conformance Evaluation Statement (Optional)''' Change <blockquote> "As per the requirements for WCAG 2.0 conformance claims, also accessibility evaluation statements have to include the following information:"</blockquote> to instead read:<br />
<blockquote>"As per the requirements for WCAG 2.0 conformance claims, accessibility evaluation statements also have to include the following information:".</blockquote>''Rationale: Grammar '' <span style="color: #808080;">{Dennis 28 March}</span></li><br />
<br />
<li>'''Step 5.b Note''' The note states:<br />
<blockquote>"It is not possible to make an accessibility evaluation statement for a website that is still in development."</blockquote><br />
But would be improved by saying: <blockquote> "An accessibility evaluation statement should not be made for a website that is still in development."</blockquote><br />
''Rationale: Again, WCAG-EM is not a dogma or a law. We shouldn't impose anything. Rather than prohibit making an accessibility evaluation statement for a website that is still under development, maybe it would be better to suggest not to.'' <span style="color: #808080;">{Denis 28 March}</span><br />
<li>Sounds better, i.e., less heavy<span style="color: #808080;">{Vicki - 2 April}</span></li> <br />
<br />
</ul><br />
<br />
==Considerations for Particular Situations section==<br />
<br />
<ul><br />
<br />
<li style="padding-bottom:1em">'''Location/Summary:''' Change.<br/>''Rationale: '' <span style="color: #808080;">{Name}</span></li><br />
</ul><br />
<br />
<div style="color:#808080;"><br />
====outside EOWG scope (considerations)====<br />
<ul><br />
<br />
<li style="padding-bottom:1em">[outside EOWG scope] '''[http://www.w3.org/TR/WCAG-EM/#divide Evaluating a Large Website with Separate Parts]:''' Would it be useful here to suggest personas? To think about the different uses that people will have for the large website and to define those pathways? For example, a government agency site may have people coming who are looking for general information, or they may be seeking specific services. There could be a robust series of pages that do not require log-ins as well as those that do. Interest/interaction may be regional and there is likely to be a different series of pages for agency staff. <br/>''Rationale: '' I have found that if the commissioner of the review will define the stakeholder/constiuent groups who most frequently use the site and what they do there, it can help define critical pathways for various tasks. <span style="color: #808080;">{Sharron 3 April}</span></li><br />
<br />
<li>[outside EOWG scope] '''[http://www.w3.org/TR/WCAG-EM/#rerun Re-Running a Website Conformance Evaluation]:''' <br />
I would like to suggest a proportion of 60%/40% between portion of web pages that were in the original sample and additional new web pages that were not in the original sample.<br/>''Rationale:'' to get significant distinction between old pages and new ones and measure how well they compare once remediation has been applied to webpages. <span style="color: #808080;">{Denis 28 March}</span></li><br />
</ul><br />
</div><br />
<br />
==Application of this Methodology section==<br />
<ul><br />
<br />
<li style="padding-bottom:1em">'''Location/Summary:''' Change.<br/>''Rationale: '' <span style="color: #808080;">{Name}</span></li><br />
<br />
</ul><br />
<br />
<hr /><br />
==Copyedits & things that probably don't need discussion==<br />
<br />
<ul><br />
<br />
<li style="padding-bottom:1em">'''Location:''' Problem: @@. Current wording: @@. Revised wording: @@. <span style="color: #808080;">{Name}</span></li><br />
<br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#step4b Step 4b]''' Small typo - including "sufficient technqiues" - s/technqiues/techniques. <span style="color: #808080;">{Denis 28 March}</span></li><br />
<br />
<li style="padding-bottom:1em">In first sentence of second paragraph of Abstract, should be comma after "for example"<span style="color: #808080;">{Howard}</span></li><br />
<li style="padding-bottom:1em">Typo: (may be several times in document): technqiues instead of techniques. <span style="color: #808080;">{Sylvie 22/March}</span></li><br />
<li style="padding-bottom:1em">'''Consistency of section headings:''' The link text of sections (steps) that are referred to are not always the same as the sections titles. For example, at the end of section step 5.A, there is a link to "Step 5.b: Provide and Accessibility Statement)". First there need to be corrected in "an accessibility Statement". Second, the title of the heading is: "Step 5.b: Provide a Conformance Evaluation Statement (Optional)", whereas the Methodology Requirement 5.B is entitled: "Provide an accessibility conformance evaluation statement (Optional).". <span style="color: #808080;">{Sylvie 22/March}</span></li><br />
<li style="padding-bottom:1em">Typo: Sucess criteria instead of Success criteria (several occurences)<span style="color: #808080;">{Sylvie 22/March}</span></li><br />
<br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#step1 Define Scope Overview]:''' Well done in explaining the relationship/role of the reviewer, the commissioner, and the owner.<br/>''Rationale: Important distinction, well made up front.'' <span style="color: #808080;">{Sharron 28 March}</span></li><br />
<br />
</ul><br />
<br />
==other==<br />
<br />
===fyi, Comments that individuals sent directly (not through EOWG)===<br />
<br />
<ul><br />
<li style="padding-bottom:1em">[http://lists.w3.org/Archives/Public/public-wcag-em-comments/2013Mar/0000.html Suzette] Excess use of 'per' especially in section 5. I'm not sure how to do an archive link but have sent the following direct:<br />
"I have read through WCAG EM and congratulate you on its progress. On a small point of language I noticed is an outbreak of the word 'per' - especially in section 5, which I would suggest could inhibit ease of understanding and is also unnecessary. I would propose removing all 'per' and using a plain language alternative, if necessary.<br />
<br />
FYI:<br />
I researched the opinions of others via Google, and here is one of the more<br />
interesting discussions on the use of per and as per:<br />
http://www.businesswritingblog.com/business_writing/2009/05/your-help-please-with-as-per.html<br />
<br />
<br />
Per and 'as per' is a pseudo-latin construction. Opinions appear to divide between clarity, efficiency, and improper use. There are however alternatives which are more natural.<br />
<br />
The only examples that fit well in my head is taking medicine 'per<br />
day', or sharing pencils 'one per child' and 'per your instructions'. The use of 'Per website' and 'per web page' (WCAG EM methodological requirement 5c) seem particularly puzzling and drove me to Google to find out why. <br />
<span style="color: #808080;">{Suzette}</span></li><br />
<br />
<li>[http://lists.w3.org/Archives/Public/public-wcag-em-comments/2013Apr/0001.html Sylvie & friends]</li><br />
</ul><br />
<br />
===Archived Notes (not for Eval TF)===<br />
<ul><br />
<li style="padding-bottom:1em">[closed. updated [[Style]] with rationale for putting periods and commas outside of quoted terms.] This may need discussion, but I'm not sure where else to put it. According the ''Chicago Manual of Style'' Rule 6.8: "Periods and commas precede closing quotation marks, whether double or single." The way I did the previous sentence conforms to that. Things like "not "magnifying glass"." don't. We use this pattern a lot, but that means we're consistent. It just may be consistently wrong. OTOH, it would be an incorrect pattern in code, so coders may cringe if we adopt the Chicago rule. (3/20/13) <span style="color: #808080;">{Anna Belle}</span></li><br />
</ul><br />
<br />
<br />
<br /><hr /><br /><br />
<br />
<div style="color:#808080;"><br />
=<span style="color:#808080;">Comments submitted on 22 October 2012</span>=<br />
<br />
==Readability & Usability==<br />
'''What specific revisions will make the document more readable and usable?'''<br />
<br />
<ul><br />
<li style="padding-bottom:1em" id="reply">'''linked terms distracting'''- Every time a term is mentioned, there's a link to the definition e.g. "web pages",websites, I find this quite distracting and I think it reduces the readability <span style="color: #808080;">{Vicki}</span>.<br />
<br />Strongly agree. Some ideas: just link it the first time in the document, or a new section. OR provide an option for users to turn off these links. <span style="color: #808080;">{shawn}</span></li><br />
<br />
<li style="padding-bottom:1em">'''linked references in sentences''' - the linked reference (e.g. "3.5 Step 5: Report the Evaluation Findings") in the middle of a sentence is also a little distracting and breaks the reading. <span style="color: #808080;">{Vicki}</span></li><br />
<br />
<li style="padding-bottom:1em">'''examples matching use cases''' - readability, section 1.1 scope and 1.2 audience. I think this is a difficult read for the intended audience. To improve usability I would suggest there is a need for better tailored use cases that match 1.2 and are then addressed consistently. There seem to be some examples included about commerce but I think it needs to use a better defined range - that better capture the context of the audience be it large scale government sites, large commercial sites, banks and utilities, and big agencies through to smaller operators eg a local school, a local charity, small organic food retailer. <span style="color: #808080;">{Suzette}</span></li><br />
<br />
<li style="padding-bottom:1em">'''Delete text from Abstract''' - Abstract current wording: "This work is part of complementary W3C/WAI activities on Web Accessibility Evaluation and Testing that address different W3C/WAI guidelines and specifications."<br />Comment: This leads reads off the page to 2 separate places. Suggest not having it in the Abstract. OK in the intro, but in the abstract, I think it takes the focus off this document too much. <span style="color: #808080;">{Shawn}</span></li><br />
<br />
<li style="padding-bottom:1em">'''Section numbering''' - Please consider not numbering every section. "3.4 Step 4:" etc adds complexity. It would be much simpler to just have "Step 4:" <span style="color: #808080;">{shawn}</span></li><br />
<br />
<li style="padding-bottom:1em">[minor] delete "W3C/WAI" where you can</li><br />
<li style="padding-bottom:1em">[minor] add "(WCAG-EM)" to the title, abstract, and introduction</li><br />
<br />
</ul><br />
<br />
==Scope==<br />
'''Is it clear that this set of methodologies is only for websites after they are built and does not address methodologies that might be used prior to and during development? If not, please suggest ways to clarify the scope.'''<br />
<ul><br />
<li style="padding-bottom:1em"> Given that the title is about Compliance evaluation, I have no problem with clarifying that the scope is what educationalists call summative assessment (like the final exam!) rather that formative assessment (feedback you can learn from). I noted a number of mentions in the opening sections about the benefits or effects of iterative testing during the design process. <br />
<br />
My suggestion is to keep the two types of testing separate because they relate to substantially different scenarios. Developers probably should not do their own formal compliance testing. I would suggest that the EM has a short paragraph to discuss the difference so that the reader is aware of this and can chose whether the Compliance EM document is relevant or if they need to go to the less formal 'Design_and_ Evaluation' section. <span style="color: #808080;">{Suzette}</span></li><br />
</ul><br />
<br />
[http://www.w3.org/TR/WCAG-EM/#scope 1.1 Scope of this Document] - second and third paragraphs, cited below:<br />
<br />
"However, this methodology only addresses evaluation of website conformance to WCAG 2.0 after its development. Complementary resources from W3C/WAI on evaluation provide guidance on evaluation in other situations, and complementary W3C/WAI activities on Web Accessibility Evaluation and Testing address different W3C/WAI guidelines and specifications."<br />
<br />
"Also, WCAG 2.0 conformance requirements apply to individual web pages. However, on most websites it is not feasible to evaluate every web page with reasonable effort. To ensure conformance of a website to WCAG 2.0 it is necessary to ensure that this is considered throughout the development process. Following this methodology helps assess the level of conformance with reasonable confidence where it is not feasible to evaluate every web page."<br />
<br />
* I prefer not to restrict the evaluation to "only" sites after development. <br />
* I find the second paragraph starting "Also, WCAG 2.0 conformance....etc." somewhat puzzling. In the first paragraph, there is mention that the evaluation methodology is only for sites after development but, on the other hand, in the second paragraph, there is mention of the importance of conformance during the development process and following "this methodology" (which in the first para is stated as only for after development) helps assess the conformance.<br />
<br />
Suggestion (if the scope is fixed on already developed sies):<br />
<br />
This methodology is best used to address evaluation of website conformance to WCAG 2.0 after development. WCAG 2.0 conformance requirements apply to individual web pages. On most websites, it can be challenging to evaluate every single web page. This methodology helps assess the level of conformance with reasonable confidence where it is not feasible to evaluate every web page. <br />
<br />
Complementary resources from W3C/WAI on evaluation provide guidance on evaluation in other situations, and complementary W3C/WAI activities on Web Accessibility Evaluation and Testing address different W3C/WAI guidelines and specifications.<br />
<br />
It is noted that conformance which is considered during the development process reduces significantly the costs of evaluation after development. <br />
<span style="color: #808080;">{Vicki}</span><br />
<br />
'''[important]''' The only one comment I do feel somewhat concerned about is the "Scope" and restricting the document to "only" sites after development. I look at it from the point of view of someone e.g. a developer coming across the document through a search and, with the patience (rather lack of it) that we have on the web, it might be disregarded by the restrictive focus. It is also a document which could still be useful to someone who might perform iterative evaluation through the development process. Therefore, I would recommend being more receptive to a wider audience by changing the wording somewhat. <span style="color: #808080;">{Vicki via Sharron}</span><br />
<br />
==Evaluate throughout==<br />
'''How should we communicate the importance of evaluating throughout website development, not just at the end?'''<br />
<ul><br />
<li style="padding-bottom:1em">'''Abstract'''<br />''Abstract current wording:'' (in a paragraph) However, ensuring and maintaining accessibility requires that accessibility is considered throughout the development process. Complementary resources from W3C/WAI on evaluation provide guidance for other situations.<br /><br />
''Abstract suggested text:'' '''(separate paragraph)''' When developing or redesigning a website, accessibility should be considered early and throughout the design and development process. This is addressed in [http://www.w3.org/WAI/EO/wiki/Eval_in_process a new resource under development] ''<span style="color: #808080;">{which EOWG expects to have drafted for the next WCAG-EM draft so you can put the actual title of the page here}</span>''.<br /><br />
<span style="color: #808080;">{Shawn}</span></li><br />
<br />
<li style="padding-bottom:1em"><br />
'''Introduction, Scope, middle paragraph:'''<br /><br />
''Current text:'' "However, this methodology only addresses evaluation of website conformance to WCAG 2.0 after its development. Complementary resources from W3C/WAI on evaluation provide guidance on evaluation in other situations, and complementary W3C/WAI activities on Web Accessibility Evaluation and Testing address different W3C/WAI guidelines and specifications."<br /><br />
''Suggested text:'' This methodology only addresses evaluating an existing website's conformance to WCAG 2.0. When developing or redesigning a website, accessibility should be considered early and throughout the design and development process. This is addressed in [http://www.w3.org/WAI/EO/wiki/Eval_in_process a new resource under development] ''<span style="color: #808080;">{which EOWG expects to have drafted for the next WCAG-EM draft so you can put the actual title of the page here}</span>''.<br /><br />
'''(new paragraph)''' Related information outside the scope of this document is provided in [http://www.w3.org/WAI/eval/ Evaluating Websites for Accessibility], [http://www.w3.org/WAI/eval/ W3C WAI Web Accessibility Evaluation and Testing Activities], and [http://www.w3.org/WAI/guid-tech.html WAI Guidelines and Techniques]. <br /><br />
<span style="color: #808080;">{shawn}</span></li><br />
<br />
</ul><br />
<br />
==Missing?==<br />
'''Are there any major considerations that we have overlooked or misrepresented?'''<br />
<ul><br />
<li style="padding-bottom:1em">'''Updates, maintenance, drift:''' An accessibility audit is static - a snapshot in time. By contrast, contemporary websites are organic - constantly evolving and growing. New material and novel features can be added by people who were not part of the original development team and these authors may have very limited editorial skills, and knowledge of development. As part of EM, I would suggest that that we should make a strong case for planned reviews to maintain standards and avoid the effect of drift that has been observed by researchers. <span style="color: #808080;">{Suzette}</span></li><br />
</ul><br />
<br />
==Related material==<br />
'''How much should we refer to and link to existing material as reference and how much should we include directly in the new material? Balance the inconvenience of jumping back and forth between existing documents against our reluctance to unnecessarily duplicate information.'''<br/><br />
'''How should we align the WCAG-EM work with the [http://www.w3.org/WAI/EO/wiki/Web_Accessibility_Preliminary_Evaluation Preliminary Evaluation document] now in process at EOWG?<br />What should the [http://www.w3.org/WAI/eval/conformance.html Conformance Evaluation] page be in relation to WCAG-EM?''' (see also [[Eval Analysis]])<br />
<ul><br />
<li style="padding-bottom:1em">EOWG is currently planning to update the [http://www.w3.org/WAI/eval/preliminary.html old Preliminary Eval page], edit the [http://www.w3.org/WAI/eval/conformance.html old Conformance Eval] page to be something like a "WCAG-EM light", and develop a page on [http://www.w3.org/WAI/EO/wiki/Eval_in_process Evaluating throughout the process]. See more in [[Eval Analysis]]. We look forward to talking with the Eval TF about this approach.</li><br />
</ul><br />
<br />
==Other==<br />
''These comments were entered before we had the structure above, so might apply to above or not.''<br />
<ul><br />
<li style="padding-bottom:1em">'''[Very Important]''' '''[http://www.w3.org/TR/WCAG-EM/#step1d Methodology Requirement 1.d]''' - This requirement appears to claim that the website owner and evaluator are free to choose which users may be excluded. Human rights do not work that way. What reasonable base technologies are required for conformance? This is particularly disturbing within the context of intranets where employers may choose to limit users to assistive technologies the employer can purchase cheaply. The note at the end is not sufficient.<br/><br />
Example, many sites prescribe large print with high contrast to be a universal cure for low vision. This discounts the need for albinos to have lower luminosity. Without high luminosity, high contrast is not possible. <span style="color: #808080;">{Wayne Dick}</span></li><br />
<li style="padding-bottom:1em">'''[important]''' '''[http://www.w3.org/TR/WCAG-EM/#step1e 3.1.5 Step d]''' - appeared to invite employer determined prescription of assistive techonolgy and accessibility support. The result will be employer defined necessary employment discrimination. <span style="color: #808080;">{Wayne Dick}</span></li><br />
<li style="padding-bottom:1em">[minor] '''Relied Upon''' - Just hangs there without inclusion in the context of accessibility supported. <span style="color: #808080;">{Wayne Dick}</span></li><br />
<li style="padding-bottom:1em">[Med] The note to (Web Applications): It may not be feasible to exhaustively examine all possible settings, but sampling should apply just as any website. <span style="color: #808080;">{Wayne Dick}</span></li><br />
<li style="padding-bottom:1em">3.1.5 Step 3. The evaluation commissioner, must be informed that if the self defined sufficient techniques are used then a future accessibility audit may ask for a proof of sufficiency. <span style="color: #808080;">{Wayne Dick}</span></li><br />
<li style="padding-bottom:1em">Throughout 3.1.5 PDF and Silver light are basic web technologies. They are no more technologie than docx or raw text. They as basic web technologies. The accessibility open question.<br/><br />
This issue is particularly important if this document is going to be normative. I do specific reference to Adobe or Microsoft products as basic web technologies is serious vendor preference. <span style="color: #808080;">{Wayne Dick}</span></li><br />
<li style="padding-bottom:1em">[http://www.w3.org/TR/WCAG-EM/#step3 3.3 Step 3]: Select a Representative Sample, (First sentence) &#34;While ideally every web page of a web site is evaluated, usually this is not possible on most web sites.&#34;<br/><br />
I feel that stating "usually this is not possible on most web sites" sounds somewhat contradictory (to our objective).<br/><br />
Suggested text: &#34;While ideally every web page of a website should be evaluated, this may not be possible for very large websites.&#34; <span style="color: #808080;">{Vicki}</span></li><br />
<li style="padding-bottom:1em">[http://www.w3.org/TR/WCAG-EM/#step3 3.3 Step 3]: Select a Representative Sample - website with many heterogeneous sub-university example, the sample selection include users. Focus groups are an effective probably necessary.<br/><br />
Large heterogenous sites behave more like a set of independent sites placed under one URL. As such it is important to organize focus groups within the different autonomous site owners to determine usage patterns and prioritize pages for evaluation. When organizing the CSU System, 23 Campuses, each having more than 50 academic departments, and more administrative departments, we found that the IT unit could not get a handle on usage patterns on its own. Individual site owners had to give direct input on priority and usage. Example: At CSU Long Beach the Computer Science lab invokes the Computer Science Department Website every time a student logs into a lab machine. That makes the Computer Science Department the most referenced site on the Campus. But it is not the most important. <span style="color: #808080;">{Wayne Dick}</span></li><br />
<li style="padding-bottom:1em">Responding to the term &#34;with reasonable confidence&#34;: I have no problem with the term. Alternatively, if the above term is a point of discussion, you could simply modify the sentence to &#34;that is representative of the entire target website&#34;. <span style="color: #808080;">{Vicki}</span></li><br />
<li style="padding-bottom:1em">[http://www.w3.org/TR/WCAG-EM/#users 2.5 Involving Users (Optional)]- Second last sentence. &#34;While not required, it is strongly recommended to involve real people covering a wide range of abilities....&#34;<br/><br />
Suggest removing &#34;real&#34;. <span style="color: #808080;">{Vicki}</span></li><br />
<li style="padding-bottom:1em">[http://www.w3.org/TR/WCAG-EM/#step3 3.1.4 Methodology Requirement 1.d:] Third paragraph: second last sentence. &#34;For example, ….., then the website is effectively not accessible for some users.&#34;<br/><br />
Suggest adding something about conformance for emphasis e.g., &#34;and therefore does not conform to the specified conformance level of WCAG 2.0. ([http://www.w3.org/TR/WCAG-EM/#step1c 3.1.3 Step 1.c.])&#34; <span style="color: #808080;">{Vicki}</span></li><br />
<li style="padding-bottom:1em">[http://www.w3.org/TR/WCAG-EM/#functionality Term "Common Functionality"]<br />
Feedback was requested on the definition on &#34;Common Functionality&#34;. <br />
Having read through the document, I don’t have a problem with the term &#34;common functionality. However, it might pose a question mark to some. Therefore, I’ve put forth a few options below depending on what you mean and if you wish to be more specific:<br/><br />
If it is the general functionality of the site, you could simply leave out the word &#34;common&#34; or use &#34;basic functionality&#34;<br/><br />
If &#34;common functionality&#34; has a more technical connotation (referring to the style sheets, javascript, classes, i.e., the technical mandatory requirements for multiple device support and functionality), leave it as &#34;common&#34;<br/><br />
Another suggestion in the line of &#34;common&#34; and &#34;key&#34; is “core”.<br/><br />
Suggestion to modify the description (in line with the &#34;Note&#34;):<br/><br />
Functionality of a website includes tasks that users of a website perform in order to achieve a goal. <span style="color: #808080;">{Vicki}</span> </li><br />
<br />
<li style="padding-bottom:1em">'''3.5.3 Step 5.c''': Provide a Performance Score (optional) I think there are good reasons for offering a score in addition to or as an alternative to the absolute measure of pass/fail. I have read this section several times, and tried really hard to construct a formula to help me comprehend the differences but I am currently confused. Maybe my basic scenario is wrong, so perhaps a worked example would help? Eg what would the score show where some form elements are consistently incorrectly marked and are affecting 5 out of 10 pages tested. <span style="color: #808080;">{Suzette}</span></li><br />
<br />
<li style="padding-bottom:1em">Term "sub-site" : do you want to add the definition to the terms and definitions? <span style="color: #808080;">{Vicki}</span></li><br />
<li style="padding-bottom:1em">Section step 1.A, last paragraphis not clear to me. What is necessary there? May be it could be easier to understand with concrete examples. <quote>"The outcome of this step is an unambiguous definition for the target website, so that for each web page it can be determined whether it is within the scope of evaluation or not. Where possible, it is recommended to use formalizations such as regular expressions or listings of Universal Resource Identifiers that define the web pages<br />
that are within the scope of evaluation (part of the target website)."</quote> <span style="color: #808080;">{Sylvie}</span></li><br />
<br />
<li style="padding-bottom:1em"> <br />
'''1.3 Background Reading, Accessible Web Design''' <br /><br />
This section doesn't feel right. For example, my first reaction was that some relevant documents are missing, such as [http://www.w3.org/WAI/impl/improving.html Improving the Accessibility of Your Website] – and that some included here are maybe not more important than others that weren't included, e.g., [http://www.w3.org/WAI/older-users/developing Developing Websites for Older People] & [http://www.w3.org/WAI/mobile/overlap.html Web Content Accessibility and Mobile Web] seem less important in this context.<br/><br/><br />
Please reconsider the purpose of this list in the context of WCAG-EM. (Remember this section starts with "It is assumed that the reader of this document is familiar with the following related resources from W3C/WAI:") I can see that Essential Components of Web Accessibility and How People with Disabilities Use the Web are particularly important for evaluation &mdash; perhaps only list those 2 &mdash; and not under the heading "Accessible Web Design" but something more directly related to understanding evaluation in the bigger context. <br /><br />
(minor point: This section is not parallel with the others above it &mdash; although I don't think that's a big deal. minor edit:link change: [http://www.w3.org/WAI/mobile/overlap.html Web Content Accessibility and Mobile Web])<br />
<br /><span style="color: #808080;">{Shawn}</span></li><br />
<br />
<li style="padding-bottom:1em">'''Background Reading'''. <br /><br />
''current wording:'' "It is assumed that the reader of this document is familiar with the following related resources from W3C/WAI:" <br /><br />
''Ideas for edited wording:'' "To effectively use this methodology, you should be familiar with the following related information." <br /><br />
''or'' "The information below related to WCAG 2.0 and evaluation is important background for using this methodology. "<br />
<span style="color: #808080;">{Shawn}</span></li><br />
<br />
</ul><br />
<br />
<br />
<br />
<ul><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#scope paragraph 1 ] I think Howard may have made this suggestion already, but instead of using semicolons, use an unordered list instead.<br /><br /><br />
<br />
The methodology described in this document, WCAG-EM, provides guidance on:<br />
<ul><br />
<li>defining parameters for the evaluation scope</li><br />
<li>exploring and understanding websites including their key features and functionality</li><br />
<li>sampling representative web pages from websites where it is not feasible to evaluate all web pages of a website</li><br />
<li>evaluating the conformance of these selected web pages to the target level of WCAG 2.0 conformance</li><br />
<li>documenting and reporting the findings from such evaluation</li><br />
</ul><br />
<span style="color: #808080;">{Paul}</span></li><br />
</ul><br />
<br />
<ul><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#procedure ] I know this was discussed on the last call - description of diagram should be an ordered list. <span style="color: #808080;">{Paul}</span></li><br />
</ul><br />
<br />
<ul><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#reports Appendix C, "For In-Depth…" last paragraph ] There are a lot of unordered lists in this section already, so it may be overkill.<br />
<br /><br /><br />
Change:<br />
<br /><br /><br />
Reports could also indicate the impact of issues found and specifically identify any high impact issues that are easy to fix. This could include: Any accessibility issues that interfere with the user completing tasks, issues that affect navigation and orientation, issues that occur very frequently and issues that can cause any loss or harm to a user. A lot of the important but technical information could be put in an appendix (such as documentation of each outcome of the steps as per Step 5.a: Provide Documentation for Each Step).<br />
<br /><br /><br />
to:<br />
<br /><br /><br />
Reports could also indicate the impact of issues found and specifically identify any high impact issues that are easy to fix. This could include:<br />
<ul><br />
<li>Any accessibility issues that interfere with the user completing tasks</li><br />
<li>issues that affect navigation and orientation</li><br />
<li>issues that occur very frequently</li><br />
<li>issues that can cause any loss or harm to a user.</li><br />
</ul><br />
A lot of the important but technical information could be put in an appendix (such as documentation of each outcome of the steps as per Step 5.a: Provide Documentation for Each Step).<br />
<span style="color: #808080;">{Paul}</span></li><br />
</ul><br />
<br />
==Copyedits & things that probably don't need discussion==<br />
<br />
<ul><br />
<li style="padding-bottom:0.5em">[http://www.w3.org/TR/WCAG-EM/#step1b 3.1.2 Step 1.b.] In-Depth Analysis. End of last sentence is missing a fullstop. <span style="color: #808080;">{Vicki}</span></li><br />
<li style="padding-bottom:0.5em">3.2.3 "Note: This step is intended to identify groups of web page instances, including in web applications."<br/>Suggest drop the "in" as in "including web applications" or add "including those in web applications". <span style="color: #808080;">{Vicki}</span></li><br />
<br />
<li>[ http://www.w3.org/TR/WCAG-EM/#introduction paragraph 2 ] "This methodology can also be useful for other purposes," (add comma) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#introduction paragraph 3 ] "…and complements existing WCAG 2.0 resources," (add comma) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#audience bullet 5 ] Change "…monitoring activities who want to benchmark…" to "…monitoring activities that benchmark…" <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#usage last sentence ] Change "…of the overall performance of the website…" to "…of the overall conformance of the website…" <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#specialcases Small Websites ] "For websites with few web pages," (add comma) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#specialcases Web Applications Note ] Change "These individual states of web page" to "These individual states of web pages" <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#specialcases Web Applications Note ] Change "…to generate these states of web page and generated web page" to "…to generate these states of web pages and generated web pages" <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#specialcases Website with Separable Areas ] Consider adding example of "site administration" to (extranet) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step2 Methodology Requirement 2 Note ] Change "…other aspects of the implementation that makes" to "…other aspects of the implementation that make" <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step3 third paragraph ] Change "…and in many cases these web pages may have different design to others" to "…and in many cases these web pages may have different design than others" <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step3 third paragraph ] Change "…can significantly reduce the required sample size while..." to "…can significantly reduce the required sample size, while..." (add comma) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step4a Note ] Change "…used to create many web pages, sometimes entire parts..." to "…used to create many web pages, sometimes entire sections..." <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step4c Reminder paragraph 1 ] Change "And you can use..." to "Evaluators can use..." <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step4c Reminder bullet 1 ] Change "…by the WCAG 2.0 Success Criterion at least..." to "…by the WCAG 2.0 Success Criterion, at least..." (add comma) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step5 bullet 7 ] Change "web pages" to "Web pages" (capitalization) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step5a Note after In-Depth Analysis Report ] Change "(see Step 5.b: Provide and Accessibility Statement)" to "(see Step 5.b: Provide an Accessibility Statement)" (misspelling) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step5b ] Change "As per the requirements for WCAG 2.0 conformance claims, also accessibility evaluation statements have to include the following information:" to "As per the requirements for WCAG 2.0 conformance claims, accessibility evaluation statements also have to include the following information:" (change word order for clarity)<span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step5c paragraph 2 ] Change "The type of scoring system used has to be indicated along with..." to "The type of scoring system used has to be indicated, along with..." (added comma) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step5c ] "Currently the following scoring approaches are provided by this methodology:" The word "Currently" suggests other scoring approaches will be added to this document in the future. Does it make sense to remove it?<span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step5c Per Website bullet point 2 ] Change "During the evaluation mark the..." to "During the evaluation, mark the…" (added comma) <span style="color: #808080;">{Paul}</span></li><br />
<li> http://www.w3.org/TR/WCAG-EM/#step5c Per Website bullet point 3 ] Change "After the evaluation calculate..." to "After the evaluation, calculate…" (added comma) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step5c Per Web Page paragraph 1 ] occasional (misspelling) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step5c Per Web Page paragraph 1 ] Change "…such as occasional oversight but does not..." to "…such as occasional oversight, but does not..." (added comma) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step5c Per Web Page paragraph 1 ] consistently (misspelling) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step5c Per Web Page paragraph 1 ] Change "…may still have a high score even though..." to "…may still have a high score, even though..." (added comma) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step5c Per Web Page bullet 2 ] Change "During the evaluation mark..." to "During the evaluation, mark..." (added comma) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step5c Per Web Page bullet 3 ] Change "After the evaluation calculate..." to "After the evaluation, calculate..." <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step5c Per Instance paragraph 1 ] occasional (misspelling) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step5c Per Instance bullet 1 ] Change "Select a Representative Sample) calculate..." to "Select a Representative Sample), calculate..." <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step5c Per Instance bullet 3 ] Change "After the evaluation calculate..." to "After the evaluation, calculate..." (added comma) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#divide paragraph 2 ] Change "…web pages of the main website plus two..." to "…web pages of the main website, plus two…" (added comma) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#reports Appendix C introduction ] Change "…three different levels of reporting following..." to "…three different levels of reporting, following…" (added comma) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#reports Appendix C, "For In-Depth…" bullet 1 ] Change "...the report identifies if it is met or not met and provide minimally one example..." to "the report identifies if it is met or not met and at a minimum provides..." <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#reports Appendix C, "For In-Depth…" bullet 3 ] Change "Provide suggestions for improving the overall accessibility of the website and if possible suggesting guidance for the future;" to "Provide suggestions for improving the overall accessibility of the website, and if possible, suggest guidance for the future;" <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#terms Terms and Definition ] Headings that have anchors leading to them end up underlined, or behave differently in some browsers (they turn red when clicked in Safari, underlined in others), because they are coded like so: &lt;h3&gt;&lt;a id="terms" name="terms"&gt;Terms and Definitions&lt;/a&gt;&lt;/h3&gt;. Either modify how it's coded to &lt;h3&gt;&lt;a id="terms" name="terms"&gt;&lt;!-- anchor --&gt;&lt;/a&gt;Terms and Definitions&lt;/h3&gt;, or change the stylesheet to make sure they remain styled like headings only. <span style="color: #808080;">{Denis}</span> </li><br />
</ul><br />
<br />
==Comments sent directly (not through EOWG)== <br />
<ul><br />
<li style="padding-bottom:0.5em">Jennifer (2012_09_29): Submitted this [http://lists.w3.org/Archives/Public/public-wai-evaltf/2012Sep/0088.html comment on WACG-EM 1.0 -- use of internal links] independently -- meaning that I did not post on behalf of EOWG.</li><br />
</ul><br />
<br />
</div><br />
<br />
__NOINDEX__</div>Wdickhttps://www.w3.org/WAI/EO/wiki/index.php?title=WCAG-EM_review&diff=4671WCAG-EM review2013-04-11T00:24:46Z<p>Wdick: /* Conformance Evaluation Procedure section */</p>
<hr />
<div>Nav: [[Main Page|EOWG wiki main page]]<br />
<br />
__TOC__<br />
Links:<br />
* [http://www.w3.org/TR/WCAG-EM/ WCAG-EM document] - latest published Working Draft<br />
* [http://www.w3.org/WAI/ER/2011/eval/track/issues/open Open Issues] - Eval Task Force issue tracking<br />
<br />
Reminder: EOWG will focus on the types of questions below under [[#Comments submitted on 22 October 2012]]. If you have comments on specific technical points in the document, you can submit them directly yourself -- that is, e-mail them to public-wai-evaltf@w3.org 22 <br />If you're not sure, feel free to put your comments here and the Group will decide if they are ones you should send yourself.<br />
<br />
=March 2013 Comments on 26 February 2013 Working Draft=<br />
<br />
==General==<br />
<br />
<ul><br />
<br />
<li style="padding-bottom:1em">'''Location/Summary:''' Change.<br/>''Rationale: ''<span style="color: #808080;">{Name}</span></li><br />
<br />
</ul><br />
<br />
<br /><hr /><br />
<br />
<div style="color:#808080;"><br />
===EOWG discussed comments (General):===<br />
<ul><br />
<li style="padding-bottom:1em">'''Table of Contents:''' Change headings to something like: "Contents Summary" and "Detailed Contents". Include the Appendices in the Detailed Contents list, rather than under a separate heading.<br />
<ul><li>''initial comment: I wonder if it is necessary to list the main section in an "overview" heading, then to list all sections in a "sections heading" and have a list of appendices at last. Why not displaying a classical "table of contents" as in WCAG or other W3C documents? May be give the ability to expand/collapse the different sections (in the table of contents)? <span style="color: #808080;">{Sylvie 22/March}</span>''</li><br />
<li>''additional exchange: I think an expand/collapse menu could work <span style="color: #808080;">{Vicki - March 31}</span><br />This is to follow the W3C TR format, and I don't think it's worth pushing for adding the expand collapse here. OK? <span style="color: #808080;">{Shawn}</span> <br />Ok - cool with that <span style="color: #808080;">{Vicki - 3 April}</span>''</li></ul><br />
</li><br />
<li style="padding-bottom:1em">'''Step headings and "Methodology Requirement":'''<br />
<ol><br />
<li>Differentiate the Step headings from the statement that follows. Maybe make the headings even more terse, e.g.,<br />"Define the Scope of the Website"->"Define the Scope", <br />"Define the Goal of the Evaluation"->"Define the Goal", <br />"Define the Conformance Target"->"Define the Conformance", <br />"Define the Techniques and Failures to be Used (Optional)"->"Define the Techniques and Failures (optional)"</li><br />
<li>Delete "Methodology Requirement" and the colon so it's like:<br /><br />
&lt;h4&gt;Step 1.a. Define the Scope<br /><br />
&lt;p class="req"&gt;1.a. Define the scope of the website.<br />
</li><br />
</ol><br />
<ul><br />
<li>''initial comment: I don't understand the difference between h4: "Step 1.a: Define the Scope of the Website" and the following sentence: "Methodology Requirement 1.a: Define the scope of the website." When you listen to it, it sounds redundant but there may be a reason for this redundancy. I think this question is repeated over all the section. <span style="color: #808080;">{Sylvie 22/March}</span>''</li><br />
</ul></li><br />
<br />
<li style="padding-bottom:1em">'''Statement under Steps''' ''(e.g., "Methodology Requirement 1: Define the evaluation scope according to Methodology Requirement 1.a, Methodology Requirement 1.b, Methodology Requirement 1.c, and optionally Methodology Requirement 1.d.")'': remove the links to the sub-steps so it's:<br />&lt;p class="req"&gt;1. Define the evaluation scope<br />&lt;p class="req"&gt;2. Explore the website to be evaluated<br />&lt;p class="req"&gt;3. Select a representative sample of web pages from the website<br />&lt;p class="req"&gt;4. Audit the selected sample of web pages<br />&lt;p class="req"&gt;5. Document the evaluation findings<br />
<ul><br />
<li>''rationale:'' They are long, redundant, and the links are distracting.</li><br />
</ul><br />
</li><br />
<br />
<li style="padding-bottom:1em">'''Definition lists:''' Change the definition lists in some places where it would be better to use different markup. For specific places and rationale, see [http://lists.w3.org/Archives/Public/w3c-wai-eo/2013JanMar/0068.html e-mail] <span style="color: #808080;">{Bim}</span></li><br />
<br />
<li style="padding-bottom:1em">'''Summary sheet:''' Provide a one-page summary in multiple formats, e.g., HTML, RTF, spreadsheet, pretty PDF for printing. (EOWG can help with this.)</li><br />
<br />
</ul><br />
<br />
</div><br />
<br />
==[http://www.w3.org/TR/WCAG-EM/#abstract Abstract]==<br />
<ul><br />
<li style="padding-bottom:1em">'''Location/Summary:''' Change.<br/>''Rationale: ''<span style="color: #808080;">{Name}</span></li><br />
</ul><br />
<br /><hr /><br />
<br />
<div style="color:#808080;"><br />
===EOWG discussed comments (Abstract):===<br />
Eval TF note: Comments on the abstract also apply to the similar sentence in the main document.<br />
<ul><br />
<li style="padding-bottom:1em">Replace &quot;one possible approach&quot; with something that gives it more credibility and more strongly recommends it, e.g., &quot;one established approach&quot;. see brainstorms in [approach - EOWG minutes 5 April]<br /><br />
<ul>''initial comments:''<br />
<li>''Rationale: It sounds too tenuous and it seems we could be more encouraging. Something like “one proven method” or something. <span style="color: #808080;">{Sharron 28 March}</span>''</li><br />
</ul><br />
</li><br />
<li>Replace &quot;However, this methodology does not replace the need for quality assurance measures that are implemented throughout the design, development, and maintenance of websites to ensure their accessibility conformance.&quot; <br />with: &quot;This methodology does not replace the need for quality assurance measures implemented throughout design, development, and maintenance.&quot;<br />''<span style="color: #808080;">{initial comment: Sharron}</span>''</li><br />
</ul><br />
<br />
</div><br />
<br />
==Introduction section==<br />
<ul><br />
<li style="padding-bottom:1em">'''Location/Summary:''' Change.<br/>''Rationale: '' <span style="color: #808080;">{Name}</span></li><br />
<br />
<li style="padding-bottom:1em">[<span style="color: #808080;"><span style="background:yellow;">Wayne</span> - here's a placeholder for your comment]</span><br />'''[http://www.w3.org/TR/WCAG-EM/#audience Purpose of the Document] (and maybe elsewhere):''' @@Clarify that this is not required methodology for most developers.<br/>''Rationale: ''@@ <span style="color: #808080;">{Wayne}</span></li><br />
<br />
</ul><br />
<br />
<br /><hr /><br />
===EOWG discussed comments (Introduction):===<br />
<br />
<div style="color:#808080;"><br />
<ul><br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#terms Terms and Definitions], Common Functionality.''' Change the term &quot;Common Functionality&quot;.<br />
See brainstorms in [common terms shortlist - EOWG minutes 5 April] and [common discussion - EOWG minutes 5 April]<br />
<ul>''initial comments''<br />
<li>''Not clear about the term &quot;common functionality&quot;. Common to what? Could another term be used that denotes the completion of a task - &quot;Task achievement&quot; perhaps? <br/><br />
''Rationale: &quot;Common&quot; is not the right word for this and authors do not want to use &quot;essential&quot;'' <span style="color: #808080;">{Sharron 28 March}</span>''</li><br />
</ul><br />
</li><br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#reading Background Reading], linked headings:''' (minor issue) Unlink the headings and add those links in the lists.<br/> ''Rationale: It's inconsistent and a bit cludgy for the some headings to be links and not others. Also, it would be best to properly indicate the link to the WCAG Oveview. Also, people with some link indicators turned off (e.g., underlining) will miss that the headings are links. <span style="color: #808080;">{initial comment: Shawn}</span>''</li><br />
<li style="padding-bottom:1em"><br />
'''[http://www.w3.org/TR/WCAG-EM/#introduction Introduction] "need"'''. Replace the words &quot;need&quot; and &quot;needs&quot;. Probably replacing with &quot;should&quot; would be simpliest; however, we understand there issues with that word. <br />
See brainstorms in [needs - EOWG minutes 5 April]<br />
<ul>''initial comments''<br />
<li>''Don't like the repetition of &quot;need,&quot; &quot;needs to&quot;<br />Rationale: It doesn't actually make sense, seem true. Better to use &quot;should&quot;<span style="color: #808080;"> {Sharron, 28/March}</span>''</li><br />
</ul><br />
</li><br />
<li style="padding-bottom:1em"> '''[http://www.w3.org/TR/WCAG-EM/#introduction Introduction] Later on.''' From the second sentence, remove the words &quot;Later on&quot;<br />
<ul>''initial comments''<br />
<li> ''Rationale: content could well be in the process of being written or content could already be available. In other words, content creation may not necessarily take place later on. <span style="color: #808080;">{Vicki -31 March}</span>''</li><br />
</ul><br />
</li><br />
<li style="padding-bottom:1em">'''Abstract/Intro/Scope:''' - Tighten it up. It should be a short summary. Best if the whole this is not exactly the same wording as later in doc.<br />
<ul>''initial comments'' <li>''A large part of the Abstract is repeated in the Introduction and Scope section. Is this really intentional?<br/>Rationale: I think documents like these are already long enough, without some content being repeated. <span style="color:#808080;">{Denis 29 March}</span>''<br /><br />
''I think it's common practice for the Abstract to be a summary of material from the main document, and therefore should repeat info.<span style="color: #808080;">{Shawn}</span>''</li><br />
</ul><br />
</li> <br />
</ul><br />
<br />
<ul><br />
<br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#audience Purpose of the Document]:''' Re-write the list to be more clear, and to focus on the most common uses first. fyi, see [http://www.w3.org/WAI/eval/conformance#for Who WCAG-EM is for] in Overview page.<br/>''Rationale:'' As written, the repetition of words makes it quite difficult to parse. Also, we are concerned about having "website developers" as the first item. See: Shadi (for discussion in [http://www.w3.org/2013/02/26-eo-minutes#item01 EOWG f2f before CSUN]).<br />(Below are a couple ideas from individuals. EOWG didn't have time to work through these.)</li><br />
<br />
<ul>''initial comments:''<br />
<br />
<li style="padding-bottom:1em">''The readability of the "Purpose of this Document" section seems difficult. Because the bullet items are long, they seem too bunched together at their current spacing and too wide for easy reading of a list. Also, many of the lines begin with very similar wording: "web accessibility" begins 4 of the 8 lines; web or website begins every line. Lists with similar wording, especially at the beginning reduce readability since it's difficult to distinguish one line from another. Perhaps some lines could start with a distinct function instead of the type of user. Or set up the list as a table with the type of user on the left column and the function or purpose in the right column.<br />
<br />
For example:''<br />
<br />
<table width="80%" border="1" cellspacing="1" cellpadding="1" style="color:#808080;"><br />
<tr><br />
<th scope="column">Function</th><br />
<th scope="column">Example</th><br />
</tr><br />
<tr><br />
<td><strong>An evaluation tool</strong></td><br />
<td><strong>Web developers</strong> who want to evaluate the accessibility conformance of their websites</td><br />
</tr><br />
<tr><br />
<td><strong>Analysis &amp; reporting</strong></td><br />
<td><strong>Consultants</strong> who want to report the accessibility conformance of websites to their owners</td><br />
</tr><br />
<tr><br />
<td><strong>A learning tool</strong></td><br />
<td><strong>Accessibility researchers</strong> and disability advocates who want to learn accessibility conformance practices</td><br />
</tr><br />
<tr><br />
<td><strong>A teaching tool</strong></td><br />
<td> <strong>Trainers and educators</strong> who want to teach methods and approaches for web accessibility evaluation</td><br />
</tr><br />
<tr><br />
<td><strong>Accessibility Benchmarking</strong></td><br />
<td><strong>Individuals</strong> who want to benchmark or compare the accessibility conformance of websites</td><br />
</tr><br />
</table><br />
<br />
''I'm not sure I know the best solution, only that the readability of this section is problematic. <span style="color: #808080;">{Howard, 21/March }''</span></li><br />
<br />
<li>''[further comment] Agree with the difficulty of reading. Very much like the table.<span style="color: #808080;">{Sharron, 28/March }</span>''</li><br />
<br />
<li>''The "who" refers back to a process, not a person, in the bullet item "Web accessibility monitoring activities who want to benchmark or compare the accessibility conformance of websites" under "Purpose of Document." One possible solution: change "monitoring activities" to "monitors."<span style="color: #808080;">{Howard, 21/March }</span>''</li><br />
<li>''Observation: The list indicates use cases that "want" to perform an activity, how about "need" to perform an activity? Possibly, by shortening the items for easier reading, and including some "need" to perform activities, the list might not seem repetitive (i.e. 4x starting with "Web accessibility...") and may be easier to read. (I would even remove the repeated instances in the bullet points "of websites" since it it's clear in the context of the document that the reference is to accessibility conformance "of websites"). Suggested rewording with shorter sentences:<br /><br />
<br />
• Accessibility evaluation service providers who need to evaluate websites for accessibility conformance <br /><br />
• Experts performing accessibility monitoring activities who need to benchmark or compare the accessibility conformance of websites<br /><br />
• Consultants who need to analyze and report on accessibility conformance of websites<br /><br />
• Developers who want to evaluate accessibility conformance of their websites to monitor or improve them<br /><br />
• Website owners, procurers, and suppliers who want to learn about the accessibility conformance of their websites<br /><br />
• Researchers and disability advocates who want to explore accessibility conformance practices<br /><br />
• Accessibility trainers and educators who want to teach methods and approaches for web accessibility evaluation<br /><br />
• Web masters, content authors, designers, and others who want to learn more about web accessibility and evaluation<br /><br />
<span style="color: #808080;">{Vicki - 1 April }</span>''</li><br />
</ul><br /></li><br />
<br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#scope Scope of this Document], first sentence: '''Format it as a list.<br />
<ul><li>''initial comment: the first para under 'Scope' would be easier to read as a list rather than a ';' separating parts of a long para <span style="color: #808080;">{Andrew, 15/March}</span>''</li><br />
<li>''[further comment: Scope: Yes, agree, presentation using a list style would make the scope more readable <span style="color: #808080;">{Vicki - 31 March}</span>''</li><br />
</ul></li><br />
<br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#audience Purpose of this document], last sentence:''' Delete the sentence starting with "Complementary resources on ..." and add those resources to the next section "Background Reading".<br />
<ul><li><br />
''initial comment: I agree with the readability difficulties. It could also be improved in the paragraph beginning with "Complementary resources on" <br />Suggestion: Begin with: For further information, see complementary resources below." Then list those resources in a bulleted list. <span style="color: #808080;">{Sylvie 22/March}</span>''<br />
</li></ul></li><br />
</ul><br />
<br />
</div><br />
<br />
==Using this Methodology section==<br />
<ul><br />
<br />
<li style="padding-bottom:1em">'''Location/Summary:''' Change.<br/>''Rationale: '' <span style="color: #808080;">{Name}</span></li><br />
<br />
<li style="padding-bottom:1em">[http://www.w3.org/TR/WCAG-EM/#usage Using this methodology], first paragraph: Reword to be more positive and be in-line with [http://www.w3.org/WAI/EO/Drafts/eval/checks Easy Checks] (which will replace the old Preliminary Eval page)</span><br />
<ul><br />
<li>[OPEN] '''Suggested rewording:''' A preliminary review can be quite useful to identify obvious errors although it will not check every accessibility issue and will likely not catch all of the problems on a site. Nevertheless, to develop a rough understanding of the overall performance of the website, reviewers may conduct such an exploration using WAI's [http://www.w3.org/WAI/eval/preliminary.html Easy Checks - A First Review of Web Accessibility]<br/>''Rationale: Emphasizes usefulness rather than "cursory" '' <span style="color: #808080;">{Sharron 28 March}</span></li><br />
<br />
''initial comments:''<br />
<li>''In second sentence: "A more cursory approach for exploring the accessibility of a website", the term "cursory approach" is not clear to me. Is it jargony? Why not using a term that everyone can better understand? <span style="color: #808080;">{Sylvie 22/March}</span>''</li><br />
<li>''For better readability, it may better to split following sentence in two: <br />Actual text: "In many cases it is advisable to carry out such preliminary reviews before applying this methodology, for example to identify obvious errors and to develop a rough understanding of the overall performance of the website."<br />Suggestion: "In many cases it is advisable to carry out such preliminary reviews before applying this methodology. For example, identify obvious errors and develop a rough understanding of the overall performance of the website. <span style="color: #808080;">{Sylvie 22/March}</span>''</li><br />
</ul><br />
</li><br />
</ul><br />
<br />
<br /><hr /><br />
<div style="color:#808080;"><br />
<br />
===EOWG discussed comments (Using this Methodology):===<br />
<ul><br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#applicability Scope of Applicability]'''<br />
<br />
Needs clarification.<br />
<ul><br />
''initial comment:''<br />
<li>''Confused between paragraph above &quot;Example of a website diagram&quot; and one below. Above paragraph seems to indicate that a self-contained subsection of a website would qualify for this evaluation as a &quot;self-enclosed&quot; site. In the paragraph below the diagram, the implication is that &quot;sub-sections&quot; of a university site may not be considered self-enclosed sites: &quot;In the example above, none of the depicted parts may be excluded from the scope of evaluation in the context of this methodology, if it is to be applied to the university website.&quot; Perhaps this is referring to evaluating the entire university site as a whole. Anyway - it's a confusing section. I can't offer a rewording until I know for sure the exact meaning trying to be conveyed. <span style="color: #808080;">(Howard 4 April)</span>''</li><br />
</ul><br />
</li><br />
<li style="padding-bottom:1em"> '''Duplicate sentence: ''' [http://www.w3.org/TR/WCAG-EM/#teams Review Teams] and immediately following section, [http://www.w3.org/TR/WCAG-EM/#users Involving Users] both begin with the same sentence. &quot;The methodology defined by this document can be carried out by an individual evaluator with the skills described in section Required Expertise.&quot; Reconsider if this sentence is really necessay in both places. If so, consider that it will look like an error to some people, so see if there's aother way to cover the information.<br />
<ul><br />
''initial comment:''<br />
<li>''Is this really necessary?''<br/><br />
''Rationale: I don't understand what it adds to the point of either of these sections. <span style="color: #808080;">{Sharron 28 March}</span>''</li><br />
</ul><br />
</li><br />
<br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#specialcases Particular Types of Websites], Web Applications section:''' Rewrite to be more clear.<br />(Below are a couple ideas from individuals. EOWG didn't have time to work through these.)<br />
<ul><br />
<li>''initial comment: In second bullet "Web Applications", the note of this part is very long due to the many links and few sentences. Is it possible to make it clearer? After I read it twice, I still try to understand it. <span style="color: #808080;">{Sylvie 22/March}</span>''</li><br />
<li>''I can understand why the definition may be difficult to understand. Below is a suggested abridged version:''<br/ ><br />
''Websites with a limited number of pages which dynamically generate content are considered as a single website (or part of a larger site). Each state of a web page and content-generated web page for the purpose of this document should be included as a candidate for sampling. <span style="color: #808080;">{Vicki - 1 April}</span>''</li><br />
</ul></li><br />
</ul><br />
<br />
</div><br />
<br />
==Conformance Evaluation Procedure section==<br />
<ul><br />
<br />
<li style="padding-bottom:1em">'''Location/Summary:''' Change.<br />
<br> <br />
The paragraph describing the flow diagram has visual dependencies. Change to:<br />
"The workflow diagram depicts each of the steps defined in this<br />
section. Work flow starts with the first step and proceeds to the last<br />
step in order. In addition, the diagram permits evaluators to return<br />
to any preceding step in the process whenever the evaluation reveals a<br />
need to rework a sequence of steps."<br />
<br/>''Rationale: '' <span style="color: #808080;">{Wayne}</span></li><br />
Describing arrows. The new description is a functional description of the picture.<br />
</ul><br />
===Step 1: Define the Evaluation Scope Section===<br />
<ul><br />
<br />
<li style="padding-bottom:1em">'''Location/Summary:''' Change.<br/>''Rationale: '' <span style="color: #808080;">{Name}</span></li><br />
<br />
<li style="padding-bottom:1em">[EOWG sees the need for the sentence. since some found it confusing, please look to see if can make it more clear.]<br /><br />
'''[http://www.w3.org/TR/WCAG-EM/#step1a Step 1a]''' Sentence: "This scope definition may not contradict the terms established in section Scope of Applicability." Comment: I find this sentence somewhat confusing. Is it really necessary? <span style="color: #808080;">{Vicki - 1 April}</span><br />
<br />Replacing "may" with "should" makes this clearer to me.<span style="color: #808080;">{Anna Belle - 4 April}</span><br />
</li><br />
<br />
<li style="padding-bottom:1em">[EOWG - need to come up with better terms for each and better explanations. the main explanation should be in one place, it's confusing to have as it currently is in two places. see minutes for brainstorms.]<br />'''[http://www.w3.org/TR/WCAG-EM/#step1b Step 1b]:''' Defining the Goal. I am not sure I agree that there is sufficient difference in the two in-depth reports to require three categories. Seems clearer to stick to 2 - basic and detailed and maybe say a bit about the fact that the amount of detail is good to be part of the definition as well.<br/>''Rationale: It may be splitting hairs but it seems that once you have made the decision to go beyond a statement of conformance, there is an entire spectrum of detail and nuance. Why not four categories then? or more?'' <span style="color: #808080;">{Sharron 28 March}</span><br />I thought the problem lay in the label; the 3 definitions seemed distinct but "detailed report" did not seem to accurately reflect the 2nd report according to its description since there's no detail. Perhaps "Statistical Report" or "Itemized Page Report" would be a better fit. "Basic Report" - not sure this fits the description either. Perhaps "Pass / Fail Rating" would be more appropriate.<span style="color: #808080;">{Howard 4 April}</span></li><br />
<br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#step1d Step 1d]''' says "However, it is not necessary to use these particular techniques. In fact, in some situations, such as in a closed network, it may be necessary to use techniques that are specifically developed to the particular needs of the users of that network. Individuals and organizations developing techniques have to employ methods for establishing the technique's ability to meet the WCAG 2.0 Success Criteria." without support .<br/>''Rationale:Wouldn't it be useful to provide one or two examples of this? So it makes more sense to those reading this document? '' <span style="color: #808080;">{Denis 28 March}</span></li><br />
<li style="padding-bottom:1em">In addition to providing examples, this should not be an optional part of the methodology. It seems critical for the reviewer to define what techniques are being used to measure conformance or nonconformance to the SC. The section could make note of the fact that reviewers are not bound by previously established W3C Techniques and Failures, but it should still require that some documentation is needed of just what Techniques are being used. Could also encourage the addition of those new Techniques to the existing library.<br/>''Rationale: '' Without techniques being defined, the review is in danger of becoming undocumented opinion rather than measurement of conformance to a standard. <span style="color: #808080;">{Sharron 3 April}</span></li><br />
</ul><br />
<br />
===Step 2: Explore the Target Website Section===<br />
<br />
<ul><br />
<li style="padding-bottom:1em">'''Location/Summary:''' Change.<br/>''Rationale: '' <span style="color: #808080;">{Name}</span></li><br />
<br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#step2b Step2b]:Identify Common Functionality.'''I keep reading the definition of "common functionality) and I'm just not sure what it is we're talking about here. Are we talking about main navigation, header, footers and so on? Specific features that is used site wide? <br/><br />
''Rationale:'' Wouldn't it be helpful to refer to "common functionalities" as representative testing use cases for the evaluation of the website? <span style="color: #808080;">{Denis 28 March}</span></li><br />
<br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#step2b Step2b]:''' . As noted above, I believe "common" to be the wrong word here. Suggest authors think of a word more likely to convey the sense of ability to complete the task at hand.<br/>''Rationale: '' "Common" is just not the right word for what I think this is trying to mean.<span style="color: #808080;">{Sharron 28 March}</span></li><br />
<br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#step2b Step2b]:''' . Not simple. <br /><br />
Brainstorming: "core functionality", "key functionality", "site functionality" or would "purpose and functionality" work (i.e., looking at what follows in the second paragraph)? <span style="color: #808080;">{Vicki - 2 April}</span></li><br />
<br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#step2d Step2d]:''' .Sentence: "Only the web technologies that are relied upon to provide the website need to be identified for evaluation."<br/ ><br />
Comment: I feel a word is missing, can we add "functionality" after the word website so that it reads :<br/ ><br />
"Only the web technologies that are relied upon to provide the website functionality need to be identified for evaluation." <span style="color: #808080;">{Vicki - 2 April}</span><br /><br />
+1 <span style="color: #808080;">{Sharron - 3 April}</span></li><br />
<br />
<br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#step2d Step2d]:''' . Would change "provide" in "Identify the technologies relied upon to provide the website." to "render" or "produce." ''Rationale:'' You "provide" food or lodging but not a website. <span style="color: #808080;">{Howard - 4 April}</span></li><br />
<br />
</ul><br />
<br />
===Step 3: Select a Representative Sample Section===<br />
<ul><br />
<li style="padding-bottom:1em">'''Location/Summary:''' Change.<br/>''Rationale: '' <span style="color: #808080;">{Name}</span></li><br />
<br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#step3 Section Overview]:''' What is the point of the '''Note'''? Since it is to be covered in a later section, it seems redundant to mention here .<br/>''Rationale: Tersification. It is an entire unnecessary paragraph '' <span style="color: #808080;">{Sharron March 28}</span></li><br />
<br />
</ul><br />
<br />
<div style="color:#808080"><br />
====outside EOWG scope (step 3)====<br />
<ul><br />
<li style="padding-bottom:1em">[outside EOWG scope] '''[http://www.w3.org/TR/2012/WD-WCAG-EM-20120920/#step3 Step 3 Intro]:''' Instead of creating pressure on orgs to consider assessment of ALL pages, why not focus on trying to get them to think about selecting the best possible samples within reasonable scope, rather than have them perceive this selection as a failure because they can't afford to cover all pages? <br />
<br/>''Rationale: ''I know we mention it's usually not possible to evaluate all pages, but if we can recognize that it's rarely possible, then why say ideally it should be all pages? That creates unrealistic expectations and a pressure most people do not need to deal with. I feel this is wishful thinking - we need to be more realistic about this. Most accessibility evaluation do not cover all pages and no organization can ever afford to run a complete evaluation of all their pages, except for very small sites (and even then, if they have a small site, their accessibility budgets will tend to be proportionally small) <span style="color: #808080;">{Denis 28 March}</span></li><br />
<br />
<li style="padding-bottom:1em">[outside EOWG scope]'''[http://www.w3.org/TR/2012/WD-WCAG-EM-20120920/#step3e Step 3e]: Random Sample''' 5% seems a little low to me, even when the sample contains over 30 to 50 pages total (WCAG-EM implies it should always be more than this). I would suggest around 10-15% (where 50 pages would include another 5-7 random pages to complete the sample).<span style="color: #808080;">{Denis 28 March}</span><br />
<ul><br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#step3e Step3e]:''' Random Sample. I actually disagree with Denis' email objection to the 5% sample. I think %5 is an adequate number of random pages to add to the mix.<br/>''Rationale:'' If the reviewer has followed the advice and chosen the samples well, it is unlikely that the random sample will provide much (or any) value. But it is good to do as a process check.<span style="color: #808080;">{Sharron 29 March}</span></li><br />
</ul></li><br />
</ul><br />
</div><br />
<br />
===Step 4: Audit the Selected Sample Section===<br />
<ul><br />
<li style="padding-bottom:1em">'''Location/Summary:''' Change.<br/>''Rationale: '' <span style="color: #808080;">{Name}</span></li><br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#step4 Step 4] Note 1''' We should suggest isolating template findings from the rest of the findings related to main content of a page or pages, so findings/issues related to templates can be referenced globally for all related pages, rather than repeating the findings every time.<br/>''Rationale:By doing this, once the template findings are covered, all subsequent pages could only be covering the main content issues, making the whole process simpler and more organized. '' <span style="color: #808080;">{Denis 28 March}</span></li><br />
<br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#step4 Step 4] Note 2''' Add text to say: "Note: According to WCAG 2.0, Success Criteria to which there is no matching content are deemed to have been satisfied. An outcome such as 'Not Applicable' may be used to denote the particular situation where Success Criteria were satisfied because no relevant content was applicable,<span style="background:yellow;">but WCAG 2.0 does not require this. A Success Criteria that is either validated or not applicable, for whatever reason, is considered satisfied."</span> <br/>''Rationale: To explain more completely ><span style="color: #808080;">{Denis 28 March}</span></li><br />
<br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#step4c Step 4c]:''' Use Techniques and Failures should not be Optional. The section title already says "where possible." Backing away from established techniques and failures reduces confidence in the usefulness of the Techniques. Rewrite to emphasize that the Techniques allow for new ways to meet the SCs but should be followed in general.<br/>''Rationale: '' For consistency, predictability of results, etc. Could also remind evaluators to add to the Techniques if they find previously undocumented ways to meet the SC. <span style="color: #808080;">{Sharron 3 April}</span><br />There are reasons behind this. It's outside EOWG to debate the reasons; however, I think it '''is''' within EOWG scope to discuss how to effectively communicate the issue. <span style="color: #808080;">{Shawn}</li><br />
<br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#step4e Step 4e]''' Again I do not understand the reason for this being optional. Surely a conformance review should be replicable. Recent experience shows significantly different outcomes based on tools and testing environments. Tools documentation should be part of the report - period.<br/>''Rationale: '' I cannot think of an example where the tools and platform are irrelevant to the testing results. If someone can think of such an exception, perhaps provide that as a Note. But in general, the tools etc are an important part of the result. <span style="color: #808080;">{Sharron 3 April}</span></li><br />
<br />
</ul><br />
<br />
===Step 5: Report the Evaluation Findings Section===<br />
<ul><br />
<li style="padding-bottom:1em">'''Location/Summary:''' Change.<br/>''Rationale: '' <span style="color: #808080;">{Name}</span></li><br />
<br />
<li>'''[http://www.w3.org/TR/WCAG-EM/#step5b Step 5.b]: Conformance Evaluation Statement (Optional)''' Change <blockquote> "As per the requirements for WCAG 2.0 conformance claims, also accessibility evaluation statements have to include the following information:"</blockquote> to instead read:<br />
<blockquote>"As per the requirements for WCAG 2.0 conformance claims, accessibility evaluation statements also have to include the following information:".</blockquote>''Rationale: Grammar '' <span style="color: #808080;">{Dennis 28 March}</span></li><br />
<br />
<li>'''Step 5.b Note''' The note states:<br />
<blockquote>"It is not possible to make an accessibility evaluation statement for a website that is still in development."</blockquote><br />
But would be improved by saying: <blockquote> "An accessibility evaluation statement should not be made for a website that is still in development."</blockquote><br />
''Rationale: Again, WCAG-EM is not a dogma or a law. We shouldn't impose anything. Rather than prohibit making an accessibility evaluation statement for a website that is still under development, maybe it would be better to suggest not to.'' <span style="color: #808080;">{Denis 28 March}</span><br />
<li>Sounds better, i.e., less heavy<span style="color: #808080;">{Vicki - 2 April}</span></li> <br />
<br />
</ul><br />
<br />
==Considerations for Particular Situations section==<br />
<br />
<ul><br />
<br />
<li style="padding-bottom:1em">'''Location/Summary:''' Change.<br/>''Rationale: '' <span style="color: #808080;">{Name}</span></li><br />
</ul><br />
<br />
<div style="color:#808080;"><br />
====outside EOWG scope (considerations)====<br />
<ul><br />
<br />
<li style="padding-bottom:1em">[outside EOWG scope] '''[http://www.w3.org/TR/WCAG-EM/#divide Evaluating a Large Website with Separate Parts]:''' Would it be useful here to suggest personas? To think about the different uses that people will have for the large website and to define those pathways? For example, a government agency site may have people coming who are looking for general information, or they may be seeking specific services. There could be a robust series of pages that do not require log-ins as well as those that do. Interest/interaction may be regional and there is likely to be a different series of pages for agency staff. <br/>''Rationale: '' I have found that if the commissioner of the review will define the stakeholder/constiuent groups who most frequently use the site and what they do there, it can help define critical pathways for various tasks. <span style="color: #808080;">{Sharron 3 April}</span></li><br />
<br />
<li>[outside EOWG scope] '''[http://www.w3.org/TR/WCAG-EM/#rerun Re-Running a Website Conformance Evaluation]:''' <br />
I would like to suggest a proportion of 60%/40% between portion of web pages that were in the original sample and additional new web pages that were not in the original sample.<br/>''Rationale:'' to get significant distinction between old pages and new ones and measure how well they compare once remediation has been applied to webpages. <span style="color: #808080;">{Denis 28 March}</span></li><br />
</ul><br />
</div><br />
<br />
==Application of this Methodology section==<br />
<ul><br />
<br />
<li style="padding-bottom:1em">'''Location/Summary:''' Change.<br/>''Rationale: '' <span style="color: #808080;">{Name}</span></li><br />
<br />
</ul><br />
<br />
<hr /><br />
==Copyedits & things that probably don't need discussion==<br />
<br />
<ul><br />
<br />
<li style="padding-bottom:1em">'''Location:''' Problem: @@. Current wording: @@. Revised wording: @@. <span style="color: #808080;">{Name}</span></li><br />
<br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#step4b Step 4b]''' Small typo - including "sufficient technqiues" - s/technqiues/techniques. <span style="color: #808080;">{Denis 28 March}</span></li><br />
<br />
<li style="padding-bottom:1em">In first sentence of second paragraph of Abstract, should be comma after "for example"<span style="color: #808080;">{Howard}</span></li><br />
<li style="padding-bottom:1em">Typo: (may be several times in document): technqiues instead of techniques. <span style="color: #808080;">{Sylvie 22/March}</span></li><br />
<li style="padding-bottom:1em">'''Consistency of section headings:''' The link text of sections (steps) that are referred to are not always the same as the sections titles. For example, at the end of section step 5.A, there is a link to "Step 5.b: Provide and Accessibility Statement)". First there need to be corrected in "an accessibility Statement". Second, the title of the heading is: "Step 5.b: Provide a Conformance Evaluation Statement (Optional)", whereas the Methodology Requirement 5.B is entitled: "Provide an accessibility conformance evaluation statement (Optional).". <span style="color: #808080;">{Sylvie 22/March}</span></li><br />
<li style="padding-bottom:1em">Typo: Sucess criteria instead of Success criteria (several occurences)<span style="color: #808080;">{Sylvie 22/March}</span></li><br />
<br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#step1 Define Scope Overview]:''' Well done in explaining the relationship/role of the reviewer, the commissioner, and the owner.<br/>''Rationale: Important distinction, well made up front.'' <span style="color: #808080;">{Sharron 28 March}</span></li><br />
<br />
</ul><br />
<br />
==other==<br />
<br />
===fyi, Comments that individuals sent directly (not through EOWG)===<br />
<br />
<ul><br />
<li style="padding-bottom:1em">[http://lists.w3.org/Archives/Public/public-wcag-em-comments/2013Mar/0000.html Suzette] Excess use of 'per' especially in section 5. I'm not sure how to do an archive link but have sent the following direct:<br />
"I have read through WCAG EM and congratulate you on its progress. On a small point of language I noticed is an outbreak of the word 'per' - especially in section 5, which I would suggest could inhibit ease of understanding and is also unnecessary. I would propose removing all 'per' and using a plain language alternative, if necessary.<br />
<br />
FYI:<br />
I researched the opinions of others via Google, and here is one of the more<br />
interesting discussions on the use of per and as per:<br />
http://www.businesswritingblog.com/business_writing/2009/05/your-help-please-with-as-per.html<br />
<br />
<br />
Per and 'as per' is a pseudo-latin construction. Opinions appear to divide between clarity, efficiency, and improper use. There are however alternatives which are more natural.<br />
<br />
The only examples that fit well in my head is taking medicine 'per<br />
day', or sharing pencils 'one per child' and 'per your instructions'. The use of 'Per website' and 'per web page' (WCAG EM methodological requirement 5c) seem particularly puzzling and drove me to Google to find out why. <br />
<span style="color: #808080;">{Suzette}</span></li><br />
<br />
<li>[http://lists.w3.org/Archives/Public/public-wcag-em-comments/2013Apr/0001.html Sylvie & friends]</li><br />
</ul><br />
<br />
===Archived Notes (not for Eval TF)===<br />
<ul><br />
<li style="padding-bottom:1em">[closed. updated [[Style]] with rationale for putting periods and commas outside of quoted terms.] This may need discussion, but I'm not sure where else to put it. According the ''Chicago Manual of Style'' Rule 6.8: "Periods and commas precede closing quotation marks, whether double or single." The way I did the previous sentence conforms to that. Things like "not "magnifying glass"." don't. We use this pattern a lot, but that means we're consistent. It just may be consistently wrong. OTOH, it would be an incorrect pattern in code, so coders may cringe if we adopt the Chicago rule. (3/20/13) <span style="color: #808080;">{Anna Belle}</span></li><br />
</ul><br />
<br />
<br />
<br /><hr /><br /><br />
<br />
<div style="color:#808080;"><br />
=<span style="color:#808080;">Comments submitted on 22 October 2012</span>=<br />
<br />
==Readability & Usability==<br />
'''What specific revisions will make the document more readable and usable?'''<br />
<br />
<ul><br />
<li style="padding-bottom:1em" id="reply">'''linked terms distracting'''- Every time a term is mentioned, there's a link to the definition e.g. "web pages",websites, I find this quite distracting and I think it reduces the readability <span style="color: #808080;">{Vicki}</span>.<br />
<br />Strongly agree. Some ideas: just link it the first time in the document, or a new section. OR provide an option for users to turn off these links. <span style="color: #808080;">{shawn}</span></li><br />
<br />
<li style="padding-bottom:1em">'''linked references in sentences''' - the linked reference (e.g. "3.5 Step 5: Report the Evaluation Findings") in the middle of a sentence is also a little distracting and breaks the reading. <span style="color: #808080;">{Vicki}</span></li><br />
<br />
<li style="padding-bottom:1em">'''examples matching use cases''' - readability, section 1.1 scope and 1.2 audience. I think this is a difficult read for the intended audience. To improve usability I would suggest there is a need for better tailored use cases that match 1.2 and are then addressed consistently. There seem to be some examples included about commerce but I think it needs to use a better defined range - that better capture the context of the audience be it large scale government sites, large commercial sites, banks and utilities, and big agencies through to smaller operators eg a local school, a local charity, small organic food retailer. <span style="color: #808080;">{Suzette}</span></li><br />
<br />
<li style="padding-bottom:1em">'''Delete text from Abstract''' - Abstract current wording: "This work is part of complementary W3C/WAI activities on Web Accessibility Evaluation and Testing that address different W3C/WAI guidelines and specifications."<br />Comment: This leads reads off the page to 2 separate places. Suggest not having it in the Abstract. OK in the intro, but in the abstract, I think it takes the focus off this document too much. <span style="color: #808080;">{Shawn}</span></li><br />
<br />
<li style="padding-bottom:1em">'''Section numbering''' - Please consider not numbering every section. "3.4 Step 4:" etc adds complexity. It would be much simpler to just have "Step 4:" <span style="color: #808080;">{shawn}</span></li><br />
<br />
<li style="padding-bottom:1em">[minor] delete "W3C/WAI" where you can</li><br />
<li style="padding-bottom:1em">[minor] add "(WCAG-EM)" to the title, abstract, and introduction</li><br />
<br />
</ul><br />
<br />
==Scope==<br />
'''Is it clear that this set of methodologies is only for websites after they are built and does not address methodologies that might be used prior to and during development? If not, please suggest ways to clarify the scope.'''<br />
<ul><br />
<li style="padding-bottom:1em"> Given that the title is about Compliance evaluation, I have no problem with clarifying that the scope is what educationalists call summative assessment (like the final exam!) rather that formative assessment (feedback you can learn from). I noted a number of mentions in the opening sections about the benefits or effects of iterative testing during the design process. <br />
<br />
My suggestion is to keep the two types of testing separate because they relate to substantially different scenarios. Developers probably should not do their own formal compliance testing. I would suggest that the EM has a short paragraph to discuss the difference so that the reader is aware of this and can chose whether the Compliance EM document is relevant or if they need to go to the less formal 'Design_and_ Evaluation' section. <span style="color: #808080;">{Suzette}</span></li><br />
</ul><br />
<br />
[http://www.w3.org/TR/WCAG-EM/#scope 1.1 Scope of this Document] - second and third paragraphs, cited below:<br />
<br />
"However, this methodology only addresses evaluation of website conformance to WCAG 2.0 after its development. Complementary resources from W3C/WAI on evaluation provide guidance on evaluation in other situations, and complementary W3C/WAI activities on Web Accessibility Evaluation and Testing address different W3C/WAI guidelines and specifications."<br />
<br />
"Also, WCAG 2.0 conformance requirements apply to individual web pages. However, on most websites it is not feasible to evaluate every web page with reasonable effort. To ensure conformance of a website to WCAG 2.0 it is necessary to ensure that this is considered throughout the development process. Following this methodology helps assess the level of conformance with reasonable confidence where it is not feasible to evaluate every web page."<br />
<br />
* I prefer not to restrict the evaluation to "only" sites after development. <br />
* I find the second paragraph starting "Also, WCAG 2.0 conformance....etc." somewhat puzzling. In the first paragraph, there is mention that the evaluation methodology is only for sites after development but, on the other hand, in the second paragraph, there is mention of the importance of conformance during the development process and following "this methodology" (which in the first para is stated as only for after development) helps assess the conformance.<br />
<br />
Suggestion (if the scope is fixed on already developed sies):<br />
<br />
This methodology is best used to address evaluation of website conformance to WCAG 2.0 after development. WCAG 2.0 conformance requirements apply to individual web pages. On most websites, it can be challenging to evaluate every single web page. This methodology helps assess the level of conformance with reasonable confidence where it is not feasible to evaluate every web page. <br />
<br />
Complementary resources from W3C/WAI on evaluation provide guidance on evaluation in other situations, and complementary W3C/WAI activities on Web Accessibility Evaluation and Testing address different W3C/WAI guidelines and specifications.<br />
<br />
It is noted that conformance which is considered during the development process reduces significantly the costs of evaluation after development. <br />
<span style="color: #808080;">{Vicki}</span><br />
<br />
'''[important]''' The only one comment I do feel somewhat concerned about is the "Scope" and restricting the document to "only" sites after development. I look at it from the point of view of someone e.g. a developer coming across the document through a search and, with the patience (rather lack of it) that we have on the web, it might be disregarded by the restrictive focus. It is also a document which could still be useful to someone who might perform iterative evaluation through the development process. Therefore, I would recommend being more receptive to a wider audience by changing the wording somewhat. <span style="color: #808080;">{Vicki via Sharron}</span><br />
<br />
==Evaluate throughout==<br />
'''How should we communicate the importance of evaluating throughout website development, not just at the end?'''<br />
<ul><br />
<li style="padding-bottom:1em">'''Abstract'''<br />''Abstract current wording:'' (in a paragraph) However, ensuring and maintaining accessibility requires that accessibility is considered throughout the development process. Complementary resources from W3C/WAI on evaluation provide guidance for other situations.<br /><br />
''Abstract suggested text:'' '''(separate paragraph)''' When developing or redesigning a website, accessibility should be considered early and throughout the design and development process. This is addressed in [http://www.w3.org/WAI/EO/wiki/Eval_in_process a new resource under development] ''<span style="color: #808080;">{which EOWG expects to have drafted for the next WCAG-EM draft so you can put the actual title of the page here}</span>''.<br /><br />
<span style="color: #808080;">{Shawn}</span></li><br />
<br />
<li style="padding-bottom:1em"><br />
'''Introduction, Scope, middle paragraph:'''<br /><br />
''Current text:'' "However, this methodology only addresses evaluation of website conformance to WCAG 2.0 after its development. Complementary resources from W3C/WAI on evaluation provide guidance on evaluation in other situations, and complementary W3C/WAI activities on Web Accessibility Evaluation and Testing address different W3C/WAI guidelines and specifications."<br /><br />
''Suggested text:'' This methodology only addresses evaluating an existing website's conformance to WCAG 2.0. When developing or redesigning a website, accessibility should be considered early and throughout the design and development process. This is addressed in [http://www.w3.org/WAI/EO/wiki/Eval_in_process a new resource under development] ''<span style="color: #808080;">{which EOWG expects to have drafted for the next WCAG-EM draft so you can put the actual title of the page here}</span>''.<br /><br />
'''(new paragraph)''' Related information outside the scope of this document is provided in [http://www.w3.org/WAI/eval/ Evaluating Websites for Accessibility], [http://www.w3.org/WAI/eval/ W3C WAI Web Accessibility Evaluation and Testing Activities], and [http://www.w3.org/WAI/guid-tech.html WAI Guidelines and Techniques]. <br /><br />
<span style="color: #808080;">{shawn}</span></li><br />
<br />
</ul><br />
<br />
==Missing?==<br />
'''Are there any major considerations that we have overlooked or misrepresented?'''<br />
<ul><br />
<li style="padding-bottom:1em">'''Updates, maintenance, drift:''' An accessibility audit is static - a snapshot in time. By contrast, contemporary websites are organic - constantly evolving and growing. New material and novel features can be added by people who were not part of the original development team and these authors may have very limited editorial skills, and knowledge of development. As part of EM, I would suggest that that we should make a strong case for planned reviews to maintain standards and avoid the effect of drift that has been observed by researchers. <span style="color: #808080;">{Suzette}</span></li><br />
</ul><br />
<br />
==Related material==<br />
'''How much should we refer to and link to existing material as reference and how much should we include directly in the new material? Balance the inconvenience of jumping back and forth between existing documents against our reluctance to unnecessarily duplicate information.'''<br/><br />
'''How should we align the WCAG-EM work with the [http://www.w3.org/WAI/EO/wiki/Web_Accessibility_Preliminary_Evaluation Preliminary Evaluation document] now in process at EOWG?<br />What should the [http://www.w3.org/WAI/eval/conformance.html Conformance Evaluation] page be in relation to WCAG-EM?''' (see also [[Eval Analysis]])<br />
<ul><br />
<li style="padding-bottom:1em">EOWG is currently planning to update the [http://www.w3.org/WAI/eval/preliminary.html old Preliminary Eval page], edit the [http://www.w3.org/WAI/eval/conformance.html old Conformance Eval] page to be something like a "WCAG-EM light", and develop a page on [http://www.w3.org/WAI/EO/wiki/Eval_in_process Evaluating throughout the process]. See more in [[Eval Analysis]]. We look forward to talking with the Eval TF about this approach.</li><br />
</ul><br />
<br />
==Other==<br />
''These comments were entered before we had the structure above, so might apply to above or not.''<br />
<ul><br />
<li style="padding-bottom:1em">'''[Very Important]''' '''[http://www.w3.org/TR/WCAG-EM/#step1d Methodology Requirement 1.d]''' - This requirement appears to claim that the website owner and evaluator are free to choose which users may be excluded. Human rights do not work that way. What reasonable base technologies are required for conformance? This is particularly disturbing within the context of intranets where employers may choose to limit users to assistive technologies the employer can purchase cheaply. The note at the end is not sufficient.<br/><br />
Example, many sites prescribe large print with high contrast to be a universal cure for low vision. This discounts the need for albinos to have lower luminosity. Without high luminosity, high contrast is not possible. <span style="color: #808080;">{Wayne Dick}</span></li><br />
<li style="padding-bottom:1em">'''[important]''' '''[http://www.w3.org/TR/WCAG-EM/#step1e 3.1.5 Step d]''' - appeared to invite employer determined prescription of assistive techonolgy and accessibility support. The result will be employer defined necessary employment discrimination. <span style="color: #808080;">{Wayne Dick}</span></li><br />
<li style="padding-bottom:1em">[minor] '''Relied Upon''' - Just hangs there without inclusion in the context of accessibility supported. <span style="color: #808080;">{Wayne Dick}</span></li><br />
<li style="padding-bottom:1em">[Med] The note to (Web Applications): It may not be feasible to exhaustively examine all possible settings, but sampling should apply just as any website. <span style="color: #808080;">{Wayne Dick}</span></li><br />
<li style="padding-bottom:1em">3.1.5 Step 3. The evaluation commissioner, must be informed that if the self defined sufficient techniques are used then a future accessibility audit may ask for a proof of sufficiency. <span style="color: #808080;">{Wayne Dick}</span></li><br />
<li style="padding-bottom:1em">Throughout 3.1.5 PDF and Silver light are basic web technologies. They are no more technologie than docx or raw text. They as basic web technologies. The accessibility open question.<br/><br />
This issue is particularly important if this document is going to be normative. I do specific reference to Adobe or Microsoft products as basic web technologies is serious vendor preference. <span style="color: #808080;">{Wayne Dick}</span></li><br />
<li style="padding-bottom:1em">[http://www.w3.org/TR/WCAG-EM/#step3 3.3 Step 3]: Select a Representative Sample, (First sentence) &#34;While ideally every web page of a web site is evaluated, usually this is not possible on most web sites.&#34;<br/><br />
I feel that stating "usually this is not possible on most web sites" sounds somewhat contradictory (to our objective).<br/><br />
Suggested text: &#34;While ideally every web page of a website should be evaluated, this may not be possible for very large websites.&#34; <span style="color: #808080;">{Vicki}</span></li><br />
<li style="padding-bottom:1em">[http://www.w3.org/TR/WCAG-EM/#step3 3.3 Step 3]: Select a Representative Sample - website with many heterogeneous sub-university example, the sample selection include users. Focus groups are an effective probably necessary.<br/><br />
Large heterogenous sites behave more like a set of independent sites placed under one URL. As such it is important to organize focus groups within the different autonomous site owners to determine usage patterns and prioritize pages for evaluation. When organizing the CSU System, 23 Campuses, each having more than 50 academic departments, and more administrative departments, we found that the IT unit could not get a handle on usage patterns on its own. Individual site owners had to give direct input on priority and usage. Example: At CSU Long Beach the Computer Science lab invokes the Computer Science Department Website every time a student logs into a lab machine. That makes the Computer Science Department the most referenced site on the Campus. But it is not the most important. <span style="color: #808080;">{Wayne Dick}</span></li><br />
<li style="padding-bottom:1em">Responding to the term &#34;with reasonable confidence&#34;: I have no problem with the term. Alternatively, if the above term is a point of discussion, you could simply modify the sentence to &#34;that is representative of the entire target website&#34;. <span style="color: #808080;">{Vicki}</span></li><br />
<li style="padding-bottom:1em">[http://www.w3.org/TR/WCAG-EM/#users 2.5 Involving Users (Optional)]- Second last sentence. &#34;While not required, it is strongly recommended to involve real people covering a wide range of abilities....&#34;<br/><br />
Suggest removing &#34;real&#34;. <span style="color: #808080;">{Vicki}</span></li><br />
<li style="padding-bottom:1em">[http://www.w3.org/TR/WCAG-EM/#step3 3.1.4 Methodology Requirement 1.d:] Third paragraph: second last sentence. &#34;For example, ….., then the website is effectively not accessible for some users.&#34;<br/><br />
Suggest adding something about conformance for emphasis e.g., &#34;and therefore does not conform to the specified conformance level of WCAG 2.0. ([http://www.w3.org/TR/WCAG-EM/#step1c 3.1.3 Step 1.c.])&#34; <span style="color: #808080;">{Vicki}</span></li><br />
<li style="padding-bottom:1em">[http://www.w3.org/TR/WCAG-EM/#functionality Term "Common Functionality"]<br />
Feedback was requested on the definition on &#34;Common Functionality&#34;. <br />
Having read through the document, I don’t have a problem with the term &#34;common functionality. However, it might pose a question mark to some. Therefore, I’ve put forth a few options below depending on what you mean and if you wish to be more specific:<br/><br />
If it is the general functionality of the site, you could simply leave out the word &#34;common&#34; or use &#34;basic functionality&#34;<br/><br />
If &#34;common functionality&#34; has a more technical connotation (referring to the style sheets, javascript, classes, i.e., the technical mandatory requirements for multiple device support and functionality), leave it as &#34;common&#34;<br/><br />
Another suggestion in the line of &#34;common&#34; and &#34;key&#34; is “core”.<br/><br />
Suggestion to modify the description (in line with the &#34;Note&#34;):<br/><br />
Functionality of a website includes tasks that users of a website perform in order to achieve a goal. <span style="color: #808080;">{Vicki}</span> </li><br />
<br />
<li style="padding-bottom:1em">'''3.5.3 Step 5.c''': Provide a Performance Score (optional) I think there are good reasons for offering a score in addition to or as an alternative to the absolute measure of pass/fail. I have read this section several times, and tried really hard to construct a formula to help me comprehend the differences but I am currently confused. Maybe my basic scenario is wrong, so perhaps a worked example would help? Eg what would the score show where some form elements are consistently incorrectly marked and are affecting 5 out of 10 pages tested. <span style="color: #808080;">{Suzette}</span></li><br />
<br />
<li style="padding-bottom:1em">Term "sub-site" : do you want to add the definition to the terms and definitions? <span style="color: #808080;">{Vicki}</span></li><br />
<li style="padding-bottom:1em">Section step 1.A, last paragraphis not clear to me. What is necessary there? May be it could be easier to understand with concrete examples. <quote>"The outcome of this step is an unambiguous definition for the target website, so that for each web page it can be determined whether it is within the scope of evaluation or not. Where possible, it is recommended to use formalizations such as regular expressions or listings of Universal Resource Identifiers that define the web pages<br />
that are within the scope of evaluation (part of the target website)."</quote> <span style="color: #808080;">{Sylvie}</span></li><br />
<br />
<li style="padding-bottom:1em"> <br />
'''1.3 Background Reading, Accessible Web Design''' <br /><br />
This section doesn't feel right. For example, my first reaction was that some relevant documents are missing, such as [http://www.w3.org/WAI/impl/improving.html Improving the Accessibility of Your Website] – and that some included here are maybe not more important than others that weren't included, e.g., [http://www.w3.org/WAI/older-users/developing Developing Websites for Older People] & [http://www.w3.org/WAI/mobile/overlap.html Web Content Accessibility and Mobile Web] seem less important in this context.<br/><br/><br />
Please reconsider the purpose of this list in the context of WCAG-EM. (Remember this section starts with "It is assumed that the reader of this document is familiar with the following related resources from W3C/WAI:") I can see that Essential Components of Web Accessibility and How People with Disabilities Use the Web are particularly important for evaluation &mdash; perhaps only list those 2 &mdash; and not under the heading "Accessible Web Design" but something more directly related to understanding evaluation in the bigger context. <br /><br />
(minor point: This section is not parallel with the others above it &mdash; although I don't think that's a big deal. minor edit:link change: [http://www.w3.org/WAI/mobile/overlap.html Web Content Accessibility and Mobile Web])<br />
<br /><span style="color: #808080;">{Shawn}</span></li><br />
<br />
<li style="padding-bottom:1em">'''Background Reading'''. <br /><br />
''current wording:'' "It is assumed that the reader of this document is familiar with the following related resources from W3C/WAI:" <br /><br />
''Ideas for edited wording:'' "To effectively use this methodology, you should be familiar with the following related information." <br /><br />
''or'' "The information below related to WCAG 2.0 and evaluation is important background for using this methodology. "<br />
<span style="color: #808080;">{Shawn}</span></li><br />
<br />
</ul><br />
<br />
<br />
<br />
<ul><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#scope paragraph 1 ] I think Howard may have made this suggestion already, but instead of using semicolons, use an unordered list instead.<br /><br /><br />
<br />
The methodology described in this document, WCAG-EM, provides guidance on:<br />
<ul><br />
<li>defining parameters for the evaluation scope</li><br />
<li>exploring and understanding websites including their key features and functionality</li><br />
<li>sampling representative web pages from websites where it is not feasible to evaluate all web pages of a website</li><br />
<li>evaluating the conformance of these selected web pages to the target level of WCAG 2.0 conformance</li><br />
<li>documenting and reporting the findings from such evaluation</li><br />
</ul><br />
<span style="color: #808080;">{Paul}</span></li><br />
</ul><br />
<br />
<ul><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#procedure ] I know this was discussed on the last call - description of diagram should be an ordered list. <span style="color: #808080;">{Paul}</span></li><br />
</ul><br />
<br />
<ul><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#reports Appendix C, "For In-Depth…" last paragraph ] There are a lot of unordered lists in this section already, so it may be overkill.<br />
<br /><br /><br />
Change:<br />
<br /><br /><br />
Reports could also indicate the impact of issues found and specifically identify any high impact issues that are easy to fix. This could include: Any accessibility issues that interfere with the user completing tasks, issues that affect navigation and orientation, issues that occur very frequently and issues that can cause any loss or harm to a user. A lot of the important but technical information could be put in an appendix (such as documentation of each outcome of the steps as per Step 5.a: Provide Documentation for Each Step).<br />
<br /><br /><br />
to:<br />
<br /><br /><br />
Reports could also indicate the impact of issues found and specifically identify any high impact issues that are easy to fix. This could include:<br />
<ul><br />
<li>Any accessibility issues that interfere with the user completing tasks</li><br />
<li>issues that affect navigation and orientation</li><br />
<li>issues that occur very frequently</li><br />
<li>issues that can cause any loss or harm to a user.</li><br />
</ul><br />
A lot of the important but technical information could be put in an appendix (such as documentation of each outcome of the steps as per Step 5.a: Provide Documentation for Each Step).<br />
<span style="color: #808080;">{Paul}</span></li><br />
</ul><br />
<br />
==Copyedits & things that probably don't need discussion==<br />
<br />
<ul><br />
<li style="padding-bottom:0.5em">[http://www.w3.org/TR/WCAG-EM/#step1b 3.1.2 Step 1.b.] In-Depth Analysis. End of last sentence is missing a fullstop. <span style="color: #808080;">{Vicki}</span></li><br />
<li style="padding-bottom:0.5em">3.2.3 "Note: This step is intended to identify groups of web page instances, including in web applications."<br/>Suggest drop the "in" as in "including web applications" or add "including those in web applications". <span style="color: #808080;">{Vicki}</span></li><br />
<br />
<li>[ http://www.w3.org/TR/WCAG-EM/#introduction paragraph 2 ] "This methodology can also be useful for other purposes," (add comma) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#introduction paragraph 3 ] "…and complements existing WCAG 2.0 resources," (add comma) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#audience bullet 5 ] Change "…monitoring activities who want to benchmark…" to "…monitoring activities that benchmark…" <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#usage last sentence ] Change "…of the overall performance of the website…" to "…of the overall conformance of the website…" <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#specialcases Small Websites ] "For websites with few web pages," (add comma) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#specialcases Web Applications Note ] Change "These individual states of web page" to "These individual states of web pages" <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#specialcases Web Applications Note ] Change "…to generate these states of web page and generated web page" to "…to generate these states of web pages and generated web pages" <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#specialcases Website with Separable Areas ] Consider adding example of "site administration" to (extranet) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step2 Methodology Requirement 2 Note ] Change "…other aspects of the implementation that makes" to "…other aspects of the implementation that make" <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step3 third paragraph ] Change "…and in many cases these web pages may have different design to others" to "…and in many cases these web pages may have different design than others" <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step3 third paragraph ] Change "…can significantly reduce the required sample size while..." to "…can significantly reduce the required sample size, while..." (add comma) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step4a Note ] Change "…used to create many web pages, sometimes entire parts..." to "…used to create many web pages, sometimes entire sections..." <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step4c Reminder paragraph 1 ] Change "And you can use..." to "Evaluators can use..." <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step4c Reminder bullet 1 ] Change "…by the WCAG 2.0 Success Criterion at least..." to "…by the WCAG 2.0 Success Criterion, at least..." (add comma) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step5 bullet 7 ] Change "web pages" to "Web pages" (capitalization) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step5a Note after In-Depth Analysis Report ] Change "(see Step 5.b: Provide and Accessibility Statement)" to "(see Step 5.b: Provide an Accessibility Statement)" (misspelling) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step5b ] Change "As per the requirements for WCAG 2.0 conformance claims, also accessibility evaluation statements have to include the following information:" to "As per the requirements for WCAG 2.0 conformance claims, accessibility evaluation statements also have to include the following information:" (change word order for clarity)<span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step5c paragraph 2 ] Change "The type of scoring system used has to be indicated along with..." to "The type of scoring system used has to be indicated, along with..." (added comma) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step5c ] "Currently the following scoring approaches are provided by this methodology:" The word "Currently" suggests other scoring approaches will be added to this document in the future. Does it make sense to remove it?<span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step5c Per Website bullet point 2 ] Change "During the evaluation mark the..." to "During the evaluation, mark the…" (added comma) <span style="color: #808080;">{Paul}</span></li><br />
<li> http://www.w3.org/TR/WCAG-EM/#step5c Per Website bullet point 3 ] Change "After the evaluation calculate..." to "After the evaluation, calculate…" (added comma) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step5c Per Web Page paragraph 1 ] occasional (misspelling) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step5c Per Web Page paragraph 1 ] Change "…such as occasional oversight but does not..." to "…such as occasional oversight, but does not..." (added comma) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step5c Per Web Page paragraph 1 ] consistently (misspelling) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step5c Per Web Page paragraph 1 ] Change "…may still have a high score even though..." to "…may still have a high score, even though..." (added comma) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step5c Per Web Page bullet 2 ] Change "During the evaluation mark..." to "During the evaluation, mark..." (added comma) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step5c Per Web Page bullet 3 ] Change "After the evaluation calculate..." to "After the evaluation, calculate..." <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step5c Per Instance paragraph 1 ] occasional (misspelling) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step5c Per Instance bullet 1 ] Change "Select a Representative Sample) calculate..." to "Select a Representative Sample), calculate..." <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step5c Per Instance bullet 3 ] Change "After the evaluation calculate..." to "After the evaluation, calculate..." (added comma) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#divide paragraph 2 ] Change "…web pages of the main website plus two..." to "…web pages of the main website, plus two…" (added comma) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#reports Appendix C introduction ] Change "…three different levels of reporting following..." to "…three different levels of reporting, following…" (added comma) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#reports Appendix C, "For In-Depth…" bullet 1 ] Change "...the report identifies if it is met or not met and provide minimally one example..." to "the report identifies if it is met or not met and at a minimum provides..." <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#reports Appendix C, "For In-Depth…" bullet 3 ] Change "Provide suggestions for improving the overall accessibility of the website and if possible suggesting guidance for the future;" to "Provide suggestions for improving the overall accessibility of the website, and if possible, suggest guidance for the future;" <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#terms Terms and Definition ] Headings that have anchors leading to them end up underlined, or behave differently in some browsers (they turn red when clicked in Safari, underlined in others), because they are coded like so: &lt;h3&gt;&lt;a id="terms" name="terms"&gt;Terms and Definitions&lt;/a&gt;&lt;/h3&gt;. Either modify how it's coded to &lt;h3&gt;&lt;a id="terms" name="terms"&gt;&lt;!-- anchor --&gt;&lt;/a&gt;Terms and Definitions&lt;/h3&gt;, or change the stylesheet to make sure they remain styled like headings only. <span style="color: #808080;">{Denis}</span> </li><br />
</ul><br />
<br />
==Comments sent directly (not through EOWG)== <br />
<ul><br />
<li style="padding-bottom:0.5em">Jennifer (2012_09_29): Submitted this [http://lists.w3.org/Archives/Public/public-wai-evaltf/2012Sep/0088.html comment on WACG-EM 1.0 -- use of internal links] independently -- meaning that I did not post on behalf of EOWG.</li><br />
</ul><br />
<br />
</div><br />
<br />
__NOINDEX__</div>Wdickhttps://www.w3.org/WAI/EO/wiki/index.php?title=WCAG-EM_review&diff=4670WCAG-EM review2013-04-11T00:23:48Z<p>Wdick: /* Conformance Evaluation Procedure section */</p>
<hr />
<div>Nav: [[Main Page|EOWG wiki main page]]<br />
<br />
__TOC__<br />
Links:<br />
* [http://www.w3.org/TR/WCAG-EM/ WCAG-EM document] - latest published Working Draft<br />
* [http://www.w3.org/WAI/ER/2011/eval/track/issues/open Open Issues] - Eval Task Force issue tracking<br />
<br />
Reminder: EOWG will focus on the types of questions below under [[#Comments submitted on 22 October 2012]]. If you have comments on specific technical points in the document, you can submit them directly yourself -- that is, e-mail them to public-wai-evaltf@w3.org 22 <br />If you're not sure, feel free to put your comments here and the Group will decide if they are ones you should send yourself.<br />
<br />
=March 2013 Comments on 26 February 2013 Working Draft=<br />
<br />
==General==<br />
<br />
<ul><br />
<br />
<li style="padding-bottom:1em">'''Location/Summary:''' Change.<br/>''Rationale: ''<span style="color: #808080;">{Name}</span></li><br />
<br />
</ul><br />
<br />
<br /><hr /><br />
<br />
<div style="color:#808080;"><br />
===EOWG discussed comments (General):===<br />
<ul><br />
<li style="padding-bottom:1em">'''Table of Contents:''' Change headings to something like: "Contents Summary" and "Detailed Contents". Include the Appendices in the Detailed Contents list, rather than under a separate heading.<br />
<ul><li>''initial comment: I wonder if it is necessary to list the main section in an "overview" heading, then to list all sections in a "sections heading" and have a list of appendices at last. Why not displaying a classical "table of contents" as in WCAG or other W3C documents? May be give the ability to expand/collapse the different sections (in the table of contents)? <span style="color: #808080;">{Sylvie 22/March}</span>''</li><br />
<li>''additional exchange: I think an expand/collapse menu could work <span style="color: #808080;">{Vicki - March 31}</span><br />This is to follow the W3C TR format, and I don't think it's worth pushing for adding the expand collapse here. OK? <span style="color: #808080;">{Shawn}</span> <br />Ok - cool with that <span style="color: #808080;">{Vicki - 3 April}</span>''</li></ul><br />
</li><br />
<li style="padding-bottom:1em">'''Step headings and "Methodology Requirement":'''<br />
<ol><br />
<li>Differentiate the Step headings from the statement that follows. Maybe make the headings even more terse, e.g.,<br />"Define the Scope of the Website"->"Define the Scope", <br />"Define the Goal of the Evaluation"->"Define the Goal", <br />"Define the Conformance Target"->"Define the Conformance", <br />"Define the Techniques and Failures to be Used (Optional)"->"Define the Techniques and Failures (optional)"</li><br />
<li>Delete "Methodology Requirement" and the colon so it's like:<br /><br />
&lt;h4&gt;Step 1.a. Define the Scope<br /><br />
&lt;p class="req"&gt;1.a. Define the scope of the website.<br />
</li><br />
</ol><br />
<ul><br />
<li>''initial comment: I don't understand the difference between h4: "Step 1.a: Define the Scope of the Website" and the following sentence: "Methodology Requirement 1.a: Define the scope of the website." When you listen to it, it sounds redundant but there may be a reason for this redundancy. I think this question is repeated over all the section. <span style="color: #808080;">{Sylvie 22/March}</span>''</li><br />
</ul></li><br />
<br />
<li style="padding-bottom:1em">'''Statement under Steps''' ''(e.g., "Methodology Requirement 1: Define the evaluation scope according to Methodology Requirement 1.a, Methodology Requirement 1.b, Methodology Requirement 1.c, and optionally Methodology Requirement 1.d.")'': remove the links to the sub-steps so it's:<br />&lt;p class="req"&gt;1. Define the evaluation scope<br />&lt;p class="req"&gt;2. Explore the website to be evaluated<br />&lt;p class="req"&gt;3. Select a representative sample of web pages from the website<br />&lt;p class="req"&gt;4. Audit the selected sample of web pages<br />&lt;p class="req"&gt;5. Document the evaluation findings<br />
<ul><br />
<li>''rationale:'' They are long, redundant, and the links are distracting.</li><br />
</ul><br />
</li><br />
<br />
<li style="padding-bottom:1em">'''Definition lists:''' Change the definition lists in some places where it would be better to use different markup. For specific places and rationale, see [http://lists.w3.org/Archives/Public/w3c-wai-eo/2013JanMar/0068.html e-mail] <span style="color: #808080;">{Bim}</span></li><br />
<br />
<li style="padding-bottom:1em">'''Summary sheet:''' Provide a one-page summary in multiple formats, e.g., HTML, RTF, spreadsheet, pretty PDF for printing. (EOWG can help with this.)</li><br />
<br />
</ul><br />
<br />
</div><br />
<br />
==[http://www.w3.org/TR/WCAG-EM/#abstract Abstract]==<br />
<ul><br />
<li style="padding-bottom:1em">'''Location/Summary:''' Change.<br/>''Rationale: ''<span style="color: #808080;">{Name}</span></li><br />
</ul><br />
<br /><hr /><br />
<br />
<div style="color:#808080;"><br />
===EOWG discussed comments (Abstract):===<br />
Eval TF note: Comments on the abstract also apply to the similar sentence in the main document.<br />
<ul><br />
<li style="padding-bottom:1em">Replace &quot;one possible approach&quot; with something that gives it more credibility and more strongly recommends it, e.g., &quot;one established approach&quot;. see brainstorms in [approach - EOWG minutes 5 April]<br /><br />
<ul>''initial comments:''<br />
<li>''Rationale: It sounds too tenuous and it seems we could be more encouraging. Something like “one proven method” or something. <span style="color: #808080;">{Sharron 28 March}</span>''</li><br />
</ul><br />
</li><br />
<li>Replace &quot;However, this methodology does not replace the need for quality assurance measures that are implemented throughout the design, development, and maintenance of websites to ensure their accessibility conformance.&quot; <br />with: &quot;This methodology does not replace the need for quality assurance measures implemented throughout design, development, and maintenance.&quot;<br />''<span style="color: #808080;">{initial comment: Sharron}</span>''</li><br />
</ul><br />
<br />
</div><br />
<br />
==Introduction section==<br />
<ul><br />
<li style="padding-bottom:1em">'''Location/Summary:''' Change.<br/>''Rationale: '' <span style="color: #808080;">{Name}</span></li><br />
<br />
<li style="padding-bottom:1em">[<span style="color: #808080;"><span style="background:yellow;">Wayne</span> - here's a placeholder for your comment]</span><br />'''[http://www.w3.org/TR/WCAG-EM/#audience Purpose of the Document] (and maybe elsewhere):''' @@Clarify that this is not required methodology for most developers.<br/>''Rationale: ''@@ <span style="color: #808080;">{Wayne}</span></li><br />
<br />
</ul><br />
<br />
<br /><hr /><br />
===EOWG discussed comments (Introduction):===<br />
<br />
<div style="color:#808080;"><br />
<ul><br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#terms Terms and Definitions], Common Functionality.''' Change the term &quot;Common Functionality&quot;.<br />
See brainstorms in [common terms shortlist - EOWG minutes 5 April] and [common discussion - EOWG minutes 5 April]<br />
<ul>''initial comments''<br />
<li>''Not clear about the term &quot;common functionality&quot;. Common to what? Could another term be used that denotes the completion of a task - &quot;Task achievement&quot; perhaps? <br/><br />
''Rationale: &quot;Common&quot; is not the right word for this and authors do not want to use &quot;essential&quot;'' <span style="color: #808080;">{Sharron 28 March}</span>''</li><br />
</ul><br />
</li><br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#reading Background Reading], linked headings:''' (minor issue) Unlink the headings and add those links in the lists.<br/> ''Rationale: It's inconsistent and a bit cludgy for the some headings to be links and not others. Also, it would be best to properly indicate the link to the WCAG Oveview. Also, people with some link indicators turned off (e.g., underlining) will miss that the headings are links. <span style="color: #808080;">{initial comment: Shawn}</span>''</li><br />
<li style="padding-bottom:1em"><br />
'''[http://www.w3.org/TR/WCAG-EM/#introduction Introduction] "need"'''. Replace the words &quot;need&quot; and &quot;needs&quot;. Probably replacing with &quot;should&quot; would be simpliest; however, we understand there issues with that word. <br />
See brainstorms in [needs - EOWG minutes 5 April]<br />
<ul>''initial comments''<br />
<li>''Don't like the repetition of &quot;need,&quot; &quot;needs to&quot;<br />Rationale: It doesn't actually make sense, seem true. Better to use &quot;should&quot;<span style="color: #808080;"> {Sharron, 28/March}</span>''</li><br />
</ul><br />
</li><br />
<li style="padding-bottom:1em"> '''[http://www.w3.org/TR/WCAG-EM/#introduction Introduction] Later on.''' From the second sentence, remove the words &quot;Later on&quot;<br />
<ul>''initial comments''<br />
<li> ''Rationale: content could well be in the process of being written or content could already be available. In other words, content creation may not necessarily take place later on. <span style="color: #808080;">{Vicki -31 March}</span>''</li><br />
</ul><br />
</li><br />
<li style="padding-bottom:1em">'''Abstract/Intro/Scope:''' - Tighten it up. It should be a short summary. Best if the whole this is not exactly the same wording as later in doc.<br />
<ul>''initial comments'' <li>''A large part of the Abstract is repeated in the Introduction and Scope section. Is this really intentional?<br/>Rationale: I think documents like these are already long enough, without some content being repeated. <span style="color:#808080;">{Denis 29 March}</span>''<br /><br />
''I think it's common practice for the Abstract to be a summary of material from the main document, and therefore should repeat info.<span style="color: #808080;">{Shawn}</span>''</li><br />
</ul><br />
</li> <br />
</ul><br />
<br />
<ul><br />
<br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#audience Purpose of the Document]:''' Re-write the list to be more clear, and to focus on the most common uses first. fyi, see [http://www.w3.org/WAI/eval/conformance#for Who WCAG-EM is for] in Overview page.<br/>''Rationale:'' As written, the repetition of words makes it quite difficult to parse. Also, we are concerned about having "website developers" as the first item. See: Shadi (for discussion in [http://www.w3.org/2013/02/26-eo-minutes#item01 EOWG f2f before CSUN]).<br />(Below are a couple ideas from individuals. EOWG didn't have time to work through these.)</li><br />
<br />
<ul>''initial comments:''<br />
<br />
<li style="padding-bottom:1em">''The readability of the "Purpose of this Document" section seems difficult. Because the bullet items are long, they seem too bunched together at their current spacing and too wide for easy reading of a list. Also, many of the lines begin with very similar wording: "web accessibility" begins 4 of the 8 lines; web or website begins every line. Lists with similar wording, especially at the beginning reduce readability since it's difficult to distinguish one line from another. Perhaps some lines could start with a distinct function instead of the type of user. Or set up the list as a table with the type of user on the left column and the function or purpose in the right column.<br />
<br />
For example:''<br />
<br />
<table width="80%" border="1" cellspacing="1" cellpadding="1" style="color:#808080;"><br />
<tr><br />
<th scope="column">Function</th><br />
<th scope="column">Example</th><br />
</tr><br />
<tr><br />
<td><strong>An evaluation tool</strong></td><br />
<td><strong>Web developers</strong> who want to evaluate the accessibility conformance of their websites</td><br />
</tr><br />
<tr><br />
<td><strong>Analysis &amp; reporting</strong></td><br />
<td><strong>Consultants</strong> who want to report the accessibility conformance of websites to their owners</td><br />
</tr><br />
<tr><br />
<td><strong>A learning tool</strong></td><br />
<td><strong>Accessibility researchers</strong> and disability advocates who want to learn accessibility conformance practices</td><br />
</tr><br />
<tr><br />
<td><strong>A teaching tool</strong></td><br />
<td> <strong>Trainers and educators</strong> who want to teach methods and approaches for web accessibility evaluation</td><br />
</tr><br />
<tr><br />
<td><strong>Accessibility Benchmarking</strong></td><br />
<td><strong>Individuals</strong> who want to benchmark or compare the accessibility conformance of websites</td><br />
</tr><br />
</table><br />
<br />
''I'm not sure I know the best solution, only that the readability of this section is problematic. <span style="color: #808080;">{Howard, 21/March }''</span></li><br />
<br />
<li>''[further comment] Agree with the difficulty of reading. Very much like the table.<span style="color: #808080;">{Sharron, 28/March }</span>''</li><br />
<br />
<li>''The "who" refers back to a process, not a person, in the bullet item "Web accessibility monitoring activities who want to benchmark or compare the accessibility conformance of websites" under "Purpose of Document." One possible solution: change "monitoring activities" to "monitors."<span style="color: #808080;">{Howard, 21/March }</span>''</li><br />
<li>''Observation: The list indicates use cases that "want" to perform an activity, how about "need" to perform an activity? Possibly, by shortening the items for easier reading, and including some "need" to perform activities, the list might not seem repetitive (i.e. 4x starting with "Web accessibility...") and may be easier to read. (I would even remove the repeated instances in the bullet points "of websites" since it it's clear in the context of the document that the reference is to accessibility conformance "of websites"). Suggested rewording with shorter sentences:<br /><br />
<br />
• Accessibility evaluation service providers who need to evaluate websites for accessibility conformance <br /><br />
• Experts performing accessibility monitoring activities who need to benchmark or compare the accessibility conformance of websites<br /><br />
• Consultants who need to analyze and report on accessibility conformance of websites<br /><br />
• Developers who want to evaluate accessibility conformance of their websites to monitor or improve them<br /><br />
• Website owners, procurers, and suppliers who want to learn about the accessibility conformance of their websites<br /><br />
• Researchers and disability advocates who want to explore accessibility conformance practices<br /><br />
• Accessibility trainers and educators who want to teach methods and approaches for web accessibility evaluation<br /><br />
• Web masters, content authors, designers, and others who want to learn more about web accessibility and evaluation<br /><br />
<span style="color: #808080;">{Vicki - 1 April }</span>''</li><br />
</ul><br /></li><br />
<br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#scope Scope of this Document], first sentence: '''Format it as a list.<br />
<ul><li>''initial comment: the first para under 'Scope' would be easier to read as a list rather than a ';' separating parts of a long para <span style="color: #808080;">{Andrew, 15/March}</span>''</li><br />
<li>''[further comment: Scope: Yes, agree, presentation using a list style would make the scope more readable <span style="color: #808080;">{Vicki - 31 March}</span>''</li><br />
</ul></li><br />
<br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#audience Purpose of this document], last sentence:''' Delete the sentence starting with "Complementary resources on ..." and add those resources to the next section "Background Reading".<br />
<ul><li><br />
''initial comment: I agree with the readability difficulties. It could also be improved in the paragraph beginning with "Complementary resources on" <br />Suggestion: Begin with: For further information, see complementary resources below." Then list those resources in a bulleted list. <span style="color: #808080;">{Sylvie 22/March}</span>''<br />
</li></ul></li><br />
</ul><br />
<br />
</div><br />
<br />
==Using this Methodology section==<br />
<ul><br />
<br />
<li style="padding-bottom:1em">'''Location/Summary:''' Change.<br/>''Rationale: '' <span style="color: #808080;">{Name}</span></li><br />
<br />
<li style="padding-bottom:1em">[http://www.w3.org/TR/WCAG-EM/#usage Using this methodology], first paragraph: Reword to be more positive and be in-line with [http://www.w3.org/WAI/EO/Drafts/eval/checks Easy Checks] (which will replace the old Preliminary Eval page)</span><br />
<ul><br />
<li>[OPEN] '''Suggested rewording:''' A preliminary review can be quite useful to identify obvious errors although it will not check every accessibility issue and will likely not catch all of the problems on a site. Nevertheless, to develop a rough understanding of the overall performance of the website, reviewers may conduct such an exploration using WAI's [http://www.w3.org/WAI/eval/preliminary.html Easy Checks - A First Review of Web Accessibility]<br/>''Rationale: Emphasizes usefulness rather than "cursory" '' <span style="color: #808080;">{Sharron 28 March}</span></li><br />
<br />
''initial comments:''<br />
<li>''In second sentence: "A more cursory approach for exploring the accessibility of a website", the term "cursory approach" is not clear to me. Is it jargony? Why not using a term that everyone can better understand? <span style="color: #808080;">{Sylvie 22/March}</span>''</li><br />
<li>''For better readability, it may better to split following sentence in two: <br />Actual text: "In many cases it is advisable to carry out such preliminary reviews before applying this methodology, for example to identify obvious errors and to develop a rough understanding of the overall performance of the website."<br />Suggestion: "In many cases it is advisable to carry out such preliminary reviews before applying this methodology. For example, identify obvious errors and develop a rough understanding of the overall performance of the website. <span style="color: #808080;">{Sylvie 22/March}</span>''</li><br />
</ul><br />
</li><br />
</ul><br />
<br />
<br /><hr /><br />
<div style="color:#808080;"><br />
<br />
===EOWG discussed comments (Using this Methodology):===<br />
<ul><br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#applicability Scope of Applicability]'''<br />
<br />
Needs clarification.<br />
<ul><br />
''initial comment:''<br />
<li>''Confused between paragraph above &quot;Example of a website diagram&quot; and one below. Above paragraph seems to indicate that a self-contained subsection of a website would qualify for this evaluation as a &quot;self-enclosed&quot; site. In the paragraph below the diagram, the implication is that &quot;sub-sections&quot; of a university site may not be considered self-enclosed sites: &quot;In the example above, none of the depicted parts may be excluded from the scope of evaluation in the context of this methodology, if it is to be applied to the university website.&quot; Perhaps this is referring to evaluating the entire university site as a whole. Anyway - it's a confusing section. I can't offer a rewording until I know for sure the exact meaning trying to be conveyed. <span style="color: #808080;">(Howard 4 April)</span>''</li><br />
</ul><br />
</li><br />
<li style="padding-bottom:1em"> '''Duplicate sentence: ''' [http://www.w3.org/TR/WCAG-EM/#teams Review Teams] and immediately following section, [http://www.w3.org/TR/WCAG-EM/#users Involving Users] both begin with the same sentence. &quot;The methodology defined by this document can be carried out by an individual evaluator with the skills described in section Required Expertise.&quot; Reconsider if this sentence is really necessay in both places. If so, consider that it will look like an error to some people, so see if there's aother way to cover the information.<br />
<ul><br />
''initial comment:''<br />
<li>''Is this really necessary?''<br/><br />
''Rationale: I don't understand what it adds to the point of either of these sections. <span style="color: #808080;">{Sharron 28 March}</span>''</li><br />
</ul><br />
</li><br />
<br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#specialcases Particular Types of Websites], Web Applications section:''' Rewrite to be more clear.<br />(Below are a couple ideas from individuals. EOWG didn't have time to work through these.)<br />
<ul><br />
<li>''initial comment: In second bullet "Web Applications", the note of this part is very long due to the many links and few sentences. Is it possible to make it clearer? After I read it twice, I still try to understand it. <span style="color: #808080;">{Sylvie 22/March}</span>''</li><br />
<li>''I can understand why the definition may be difficult to understand. Below is a suggested abridged version:''<br/ ><br />
''Websites with a limited number of pages which dynamically generate content are considered as a single website (or part of a larger site). Each state of a web page and content-generated web page for the purpose of this document should be included as a candidate for sampling. <span style="color: #808080;">{Vicki - 1 April}</span>''</li><br />
</ul></li><br />
</ul><br />
<br />
</div><br />
<br />
==Conformance Evaluation Procedure section==<br />
<ul><br />
<br />
<li style="padding-bottom:1em">'''Location/Summary:''' Change.<br />
<br> <br />
The paragraph describing the flow diagram has visual dependencies. Change to:<br />
"The workflow diagram depicts each of the steps defined in this<br />
section. Work flow starts with the first step and proceeds to the last<br />
step in order. In addition, the diagram permits evaluators to return<br />
to preceding step in the process whenever the evaluation reveals a<br />
need to rework a sequence of steps."<br />
<br/>''Rationale: '' <span style="color: #808080;">{Wayne}</span></li><br />
Describing arrows. The new description is a functional description of the picture.<br />
</ul><br />
===Step 1: Define the Evaluation Scope Section===<br />
<ul><br />
<br />
<li style="padding-bottom:1em">'''Location/Summary:''' Change.<br/>''Rationale: '' <span style="color: #808080;">{Name}</span></li><br />
<br />
<li style="padding-bottom:1em">[EOWG sees the need for the sentence. since some found it confusing, please look to see if can make it more clear.]<br /><br />
'''[http://www.w3.org/TR/WCAG-EM/#step1a Step 1a]''' Sentence: "This scope definition may not contradict the terms established in section Scope of Applicability." Comment: I find this sentence somewhat confusing. Is it really necessary? <span style="color: #808080;">{Vicki - 1 April}</span><br />
<br />Replacing "may" with "should" makes this clearer to me.<span style="color: #808080;">{Anna Belle - 4 April}</span><br />
</li><br />
<br />
<li style="padding-bottom:1em">[EOWG - need to come up with better terms for each and better explanations. the main explanation should be in one place, it's confusing to have as it currently is in two places. see minutes for brainstorms.]<br />'''[http://www.w3.org/TR/WCAG-EM/#step1b Step 1b]:''' Defining the Goal. I am not sure I agree that there is sufficient difference in the two in-depth reports to require three categories. Seems clearer to stick to 2 - basic and detailed and maybe say a bit about the fact that the amount of detail is good to be part of the definition as well.<br/>''Rationale: It may be splitting hairs but it seems that once you have made the decision to go beyond a statement of conformance, there is an entire spectrum of detail and nuance. Why not four categories then? or more?'' <span style="color: #808080;">{Sharron 28 March}</span><br />I thought the problem lay in the label; the 3 definitions seemed distinct but "detailed report" did not seem to accurately reflect the 2nd report according to its description since there's no detail. Perhaps "Statistical Report" or "Itemized Page Report" would be a better fit. "Basic Report" - not sure this fits the description either. Perhaps "Pass / Fail Rating" would be more appropriate.<span style="color: #808080;">{Howard 4 April}</span></li><br />
<br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#step1d Step 1d]''' says "However, it is not necessary to use these particular techniques. In fact, in some situations, such as in a closed network, it may be necessary to use techniques that are specifically developed to the particular needs of the users of that network. Individuals and organizations developing techniques have to employ methods for establishing the technique's ability to meet the WCAG 2.0 Success Criteria." without support .<br/>''Rationale:Wouldn't it be useful to provide one or two examples of this? So it makes more sense to those reading this document? '' <span style="color: #808080;">{Denis 28 March}</span></li><br />
<li style="padding-bottom:1em">In addition to providing examples, this should not be an optional part of the methodology. It seems critical for the reviewer to define what techniques are being used to measure conformance or nonconformance to the SC. The section could make note of the fact that reviewers are not bound by previously established W3C Techniques and Failures, but it should still require that some documentation is needed of just what Techniques are being used. Could also encourage the addition of those new Techniques to the existing library.<br/>''Rationale: '' Without techniques being defined, the review is in danger of becoming undocumented opinion rather than measurement of conformance to a standard. <span style="color: #808080;">{Sharron 3 April}</span></li><br />
</ul><br />
<br />
===Step 2: Explore the Target Website Section===<br />
<br />
<ul><br />
<li style="padding-bottom:1em">'''Location/Summary:''' Change.<br/>''Rationale: '' <span style="color: #808080;">{Name}</span></li><br />
<br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#step2b Step2b]:Identify Common Functionality.'''I keep reading the definition of "common functionality) and I'm just not sure what it is we're talking about here. Are we talking about main navigation, header, footers and so on? Specific features that is used site wide? <br/><br />
''Rationale:'' Wouldn't it be helpful to refer to "common functionalities" as representative testing use cases for the evaluation of the website? <span style="color: #808080;">{Denis 28 March}</span></li><br />
<br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#step2b Step2b]:''' . As noted above, I believe "common" to be the wrong word here. Suggest authors think of a word more likely to convey the sense of ability to complete the task at hand.<br/>''Rationale: '' "Common" is just not the right word for what I think this is trying to mean.<span style="color: #808080;">{Sharron 28 March}</span></li><br />
<br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#step2b Step2b]:''' . Not simple. <br /><br />
Brainstorming: "core functionality", "key functionality", "site functionality" or would "purpose and functionality" work (i.e., looking at what follows in the second paragraph)? <span style="color: #808080;">{Vicki - 2 April}</span></li><br />
<br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#step2d Step2d]:''' .Sentence: "Only the web technologies that are relied upon to provide the website need to be identified for evaluation."<br/ ><br />
Comment: I feel a word is missing, can we add "functionality" after the word website so that it reads :<br/ ><br />
"Only the web technologies that are relied upon to provide the website functionality need to be identified for evaluation." <span style="color: #808080;">{Vicki - 2 April}</span><br /><br />
+1 <span style="color: #808080;">{Sharron - 3 April}</span></li><br />
<br />
<br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#step2d Step2d]:''' . Would change "provide" in "Identify the technologies relied upon to provide the website." to "render" or "produce." ''Rationale:'' You "provide" food or lodging but not a website. <span style="color: #808080;">{Howard - 4 April}</span></li><br />
<br />
</ul><br />
<br />
===Step 3: Select a Representative Sample Section===<br />
<ul><br />
<li style="padding-bottom:1em">'''Location/Summary:''' Change.<br/>''Rationale: '' <span style="color: #808080;">{Name}</span></li><br />
<br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#step3 Section Overview]:''' What is the point of the '''Note'''? Since it is to be covered in a later section, it seems redundant to mention here .<br/>''Rationale: Tersification. It is an entire unnecessary paragraph '' <span style="color: #808080;">{Sharron March 28}</span></li><br />
<br />
</ul><br />
<br />
<div style="color:#808080"><br />
====outside EOWG scope (step 3)====<br />
<ul><br />
<li style="padding-bottom:1em">[outside EOWG scope] '''[http://www.w3.org/TR/2012/WD-WCAG-EM-20120920/#step3 Step 3 Intro]:''' Instead of creating pressure on orgs to consider assessment of ALL pages, why not focus on trying to get them to think about selecting the best possible samples within reasonable scope, rather than have them perceive this selection as a failure because they can't afford to cover all pages? <br />
<br/>''Rationale: ''I know we mention it's usually not possible to evaluate all pages, but if we can recognize that it's rarely possible, then why say ideally it should be all pages? That creates unrealistic expectations and a pressure most people do not need to deal with. I feel this is wishful thinking - we need to be more realistic about this. Most accessibility evaluation do not cover all pages and no organization can ever afford to run a complete evaluation of all their pages, except for very small sites (and even then, if they have a small site, their accessibility budgets will tend to be proportionally small) <span style="color: #808080;">{Denis 28 March}</span></li><br />
<br />
<li style="padding-bottom:1em">[outside EOWG scope]'''[http://www.w3.org/TR/2012/WD-WCAG-EM-20120920/#step3e Step 3e]: Random Sample''' 5% seems a little low to me, even when the sample contains over 30 to 50 pages total (WCAG-EM implies it should always be more than this). I would suggest around 10-15% (where 50 pages would include another 5-7 random pages to complete the sample).<span style="color: #808080;">{Denis 28 March}</span><br />
<ul><br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#step3e Step3e]:''' Random Sample. I actually disagree with Denis' email objection to the 5% sample. I think %5 is an adequate number of random pages to add to the mix.<br/>''Rationale:'' If the reviewer has followed the advice and chosen the samples well, it is unlikely that the random sample will provide much (or any) value. But it is good to do as a process check.<span style="color: #808080;">{Sharron 29 March}</span></li><br />
</ul></li><br />
</ul><br />
</div><br />
<br />
===Step 4: Audit the Selected Sample Section===<br />
<ul><br />
<li style="padding-bottom:1em">'''Location/Summary:''' Change.<br/>''Rationale: '' <span style="color: #808080;">{Name}</span></li><br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#step4 Step 4] Note 1''' We should suggest isolating template findings from the rest of the findings related to main content of a page or pages, so findings/issues related to templates can be referenced globally for all related pages, rather than repeating the findings every time.<br/>''Rationale:By doing this, once the template findings are covered, all subsequent pages could only be covering the main content issues, making the whole process simpler and more organized. '' <span style="color: #808080;">{Denis 28 March}</span></li><br />
<br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#step4 Step 4] Note 2''' Add text to say: "Note: According to WCAG 2.0, Success Criteria to which there is no matching content are deemed to have been satisfied. An outcome such as 'Not Applicable' may be used to denote the particular situation where Success Criteria were satisfied because no relevant content was applicable,<span style="background:yellow;">but WCAG 2.0 does not require this. A Success Criteria that is either validated or not applicable, for whatever reason, is considered satisfied."</span> <br/>''Rationale: To explain more completely ><span style="color: #808080;">{Denis 28 March}</span></li><br />
<br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#step4c Step 4c]:''' Use Techniques and Failures should not be Optional. The section title already says "where possible." Backing away from established techniques and failures reduces confidence in the usefulness of the Techniques. Rewrite to emphasize that the Techniques allow for new ways to meet the SCs but should be followed in general.<br/>''Rationale: '' For consistency, predictability of results, etc. Could also remind evaluators to add to the Techniques if they find previously undocumented ways to meet the SC. <span style="color: #808080;">{Sharron 3 April}</span><br />There are reasons behind this. It's outside EOWG to debate the reasons; however, I think it '''is''' within EOWG scope to discuss how to effectively communicate the issue. <span style="color: #808080;">{Shawn}</li><br />
<br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#step4e Step 4e]''' Again I do not understand the reason for this being optional. Surely a conformance review should be replicable. Recent experience shows significantly different outcomes based on tools and testing environments. Tools documentation should be part of the report - period.<br/>''Rationale: '' I cannot think of an example where the tools and platform are irrelevant to the testing results. If someone can think of such an exception, perhaps provide that as a Note. But in general, the tools etc are an important part of the result. <span style="color: #808080;">{Sharron 3 April}</span></li><br />
<br />
</ul><br />
<br />
===Step 5: Report the Evaluation Findings Section===<br />
<ul><br />
<li style="padding-bottom:1em">'''Location/Summary:''' Change.<br/>''Rationale: '' <span style="color: #808080;">{Name}</span></li><br />
<br />
<li>'''[http://www.w3.org/TR/WCAG-EM/#step5b Step 5.b]: Conformance Evaluation Statement (Optional)''' Change <blockquote> "As per the requirements for WCAG 2.0 conformance claims, also accessibility evaluation statements have to include the following information:"</blockquote> to instead read:<br />
<blockquote>"As per the requirements for WCAG 2.0 conformance claims, accessibility evaluation statements also have to include the following information:".</blockquote>''Rationale: Grammar '' <span style="color: #808080;">{Dennis 28 March}</span></li><br />
<br />
<li>'''Step 5.b Note''' The note states:<br />
<blockquote>"It is not possible to make an accessibility evaluation statement for a website that is still in development."</blockquote><br />
But would be improved by saying: <blockquote> "An accessibility evaluation statement should not be made for a website that is still in development."</blockquote><br />
''Rationale: Again, WCAG-EM is not a dogma or a law. We shouldn't impose anything. Rather than prohibit making an accessibility evaluation statement for a website that is still under development, maybe it would be better to suggest not to.'' <span style="color: #808080;">{Denis 28 March}</span><br />
<li>Sounds better, i.e., less heavy<span style="color: #808080;">{Vicki - 2 April}</span></li> <br />
<br />
</ul><br />
<br />
==Considerations for Particular Situations section==<br />
<br />
<ul><br />
<br />
<li style="padding-bottom:1em">'''Location/Summary:''' Change.<br/>''Rationale: '' <span style="color: #808080;">{Name}</span></li><br />
</ul><br />
<br />
<div style="color:#808080;"><br />
====outside EOWG scope (considerations)====<br />
<ul><br />
<br />
<li style="padding-bottom:1em">[outside EOWG scope] '''[http://www.w3.org/TR/WCAG-EM/#divide Evaluating a Large Website with Separate Parts]:''' Would it be useful here to suggest personas? To think about the different uses that people will have for the large website and to define those pathways? For example, a government agency site may have people coming who are looking for general information, or they may be seeking specific services. There could be a robust series of pages that do not require log-ins as well as those that do. Interest/interaction may be regional and there is likely to be a different series of pages for agency staff. <br/>''Rationale: '' I have found that if the commissioner of the review will define the stakeholder/constiuent groups who most frequently use the site and what they do there, it can help define critical pathways for various tasks. <span style="color: #808080;">{Sharron 3 April}</span></li><br />
<br />
<li>[outside EOWG scope] '''[http://www.w3.org/TR/WCAG-EM/#rerun Re-Running a Website Conformance Evaluation]:''' <br />
I would like to suggest a proportion of 60%/40% between portion of web pages that were in the original sample and additional new web pages that were not in the original sample.<br/>''Rationale:'' to get significant distinction between old pages and new ones and measure how well they compare once remediation has been applied to webpages. <span style="color: #808080;">{Denis 28 March}</span></li><br />
</ul><br />
</div><br />
<br />
==Application of this Methodology section==<br />
<ul><br />
<br />
<li style="padding-bottom:1em">'''Location/Summary:''' Change.<br/>''Rationale: '' <span style="color: #808080;">{Name}</span></li><br />
<br />
</ul><br />
<br />
<hr /><br />
==Copyedits & things that probably don't need discussion==<br />
<br />
<ul><br />
<br />
<li style="padding-bottom:1em">'''Location:''' Problem: @@. Current wording: @@. Revised wording: @@. <span style="color: #808080;">{Name}</span></li><br />
<br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#step4b Step 4b]''' Small typo - including "sufficient technqiues" - s/technqiues/techniques. <span style="color: #808080;">{Denis 28 March}</span></li><br />
<br />
<li style="padding-bottom:1em">In first sentence of second paragraph of Abstract, should be comma after "for example"<span style="color: #808080;">{Howard}</span></li><br />
<li style="padding-bottom:1em">Typo: (may be several times in document): technqiues instead of techniques. <span style="color: #808080;">{Sylvie 22/March}</span></li><br />
<li style="padding-bottom:1em">'''Consistency of section headings:''' The link text of sections (steps) that are referred to are not always the same as the sections titles. For example, at the end of section step 5.A, there is a link to "Step 5.b: Provide and Accessibility Statement)". First there need to be corrected in "an accessibility Statement". Second, the title of the heading is: "Step 5.b: Provide a Conformance Evaluation Statement (Optional)", whereas the Methodology Requirement 5.B is entitled: "Provide an accessibility conformance evaluation statement (Optional).". <span style="color: #808080;">{Sylvie 22/March}</span></li><br />
<li style="padding-bottom:1em">Typo: Sucess criteria instead of Success criteria (several occurences)<span style="color: #808080;">{Sylvie 22/March}</span></li><br />
<br />
<li style="padding-bottom:1em">'''[http://www.w3.org/TR/WCAG-EM/#step1 Define Scope Overview]:''' Well done in explaining the relationship/role of the reviewer, the commissioner, and the owner.<br/>''Rationale: Important distinction, well made up front.'' <span style="color: #808080;">{Sharron 28 March}</span></li><br />
<br />
</ul><br />
<br />
==other==<br />
<br />
===fyi, Comments that individuals sent directly (not through EOWG)===<br />
<br />
<ul><br />
<li style="padding-bottom:1em">[http://lists.w3.org/Archives/Public/public-wcag-em-comments/2013Mar/0000.html Suzette] Excess use of 'per' especially in section 5. I'm not sure how to do an archive link but have sent the following direct:<br />
"I have read through WCAG EM and congratulate you on its progress. On a small point of language I noticed is an outbreak of the word 'per' - especially in section 5, which I would suggest could inhibit ease of understanding and is also unnecessary. I would propose removing all 'per' and using a plain language alternative, if necessary.<br />
<br />
FYI:<br />
I researched the opinions of others via Google, and here is one of the more<br />
interesting discussions on the use of per and as per:<br />
http://www.businesswritingblog.com/business_writing/2009/05/your-help-please-with-as-per.html<br />
<br />
<br />
Per and 'as per' is a pseudo-latin construction. Opinions appear to divide between clarity, efficiency, and improper use. There are however alternatives which are more natural.<br />
<br />
The only examples that fit well in my head is taking medicine 'per<br />
day', or sharing pencils 'one per child' and 'per your instructions'. The use of 'Per website' and 'per web page' (WCAG EM methodological requirement 5c) seem particularly puzzling and drove me to Google to find out why. <br />
<span style="color: #808080;">{Suzette}</span></li><br />
<br />
<li>[http://lists.w3.org/Archives/Public/public-wcag-em-comments/2013Apr/0001.html Sylvie & friends]</li><br />
</ul><br />
<br />
===Archived Notes (not for Eval TF)===<br />
<ul><br />
<li style="padding-bottom:1em">[closed. updated [[Style]] with rationale for putting periods and commas outside of quoted terms.] This may need discussion, but I'm not sure where else to put it. According the ''Chicago Manual of Style'' Rule 6.8: "Periods and commas precede closing quotation marks, whether double or single." The way I did the previous sentence conforms to that. Things like "not "magnifying glass"." don't. We use this pattern a lot, but that means we're consistent. It just may be consistently wrong. OTOH, it would be an incorrect pattern in code, so coders may cringe if we adopt the Chicago rule. (3/20/13) <span style="color: #808080;">{Anna Belle}</span></li><br />
</ul><br />
<br />
<br />
<br /><hr /><br /><br />
<br />
<div style="color:#808080;"><br />
=<span style="color:#808080;">Comments submitted on 22 October 2012</span>=<br />
<br />
==Readability & Usability==<br />
'''What specific revisions will make the document more readable and usable?'''<br />
<br />
<ul><br />
<li style="padding-bottom:1em" id="reply">'''linked terms distracting'''- Every time a term is mentioned, there's a link to the definition e.g. "web pages",websites, I find this quite distracting and I think it reduces the readability <span style="color: #808080;">{Vicki}</span>.<br />
<br />Strongly agree. Some ideas: just link it the first time in the document, or a new section. OR provide an option for users to turn off these links. <span style="color: #808080;">{shawn}</span></li><br />
<br />
<li style="padding-bottom:1em">'''linked references in sentences''' - the linked reference (e.g. "3.5 Step 5: Report the Evaluation Findings") in the middle of a sentence is also a little distracting and breaks the reading. <span style="color: #808080;">{Vicki}</span></li><br />
<br />
<li style="padding-bottom:1em">'''examples matching use cases''' - readability, section 1.1 scope and 1.2 audience. I think this is a difficult read for the intended audience. To improve usability I would suggest there is a need for better tailored use cases that match 1.2 and are then addressed consistently. There seem to be some examples included about commerce but I think it needs to use a better defined range - that better capture the context of the audience be it large scale government sites, large commercial sites, banks and utilities, and big agencies through to smaller operators eg a local school, a local charity, small organic food retailer. <span style="color: #808080;">{Suzette}</span></li><br />
<br />
<li style="padding-bottom:1em">'''Delete text from Abstract''' - Abstract current wording: "This work is part of complementary W3C/WAI activities on Web Accessibility Evaluation and Testing that address different W3C/WAI guidelines and specifications."<br />Comment: This leads reads off the page to 2 separate places. Suggest not having it in the Abstract. OK in the intro, but in the abstract, I think it takes the focus off this document too much. <span style="color: #808080;">{Shawn}</span></li><br />
<br />
<li style="padding-bottom:1em">'''Section numbering''' - Please consider not numbering every section. "3.4 Step 4:" etc adds complexity. It would be much simpler to just have "Step 4:" <span style="color: #808080;">{shawn}</span></li><br />
<br />
<li style="padding-bottom:1em">[minor] delete "W3C/WAI" where you can</li><br />
<li style="padding-bottom:1em">[minor] add "(WCAG-EM)" to the title, abstract, and introduction</li><br />
<br />
</ul><br />
<br />
==Scope==<br />
'''Is it clear that this set of methodologies is only for websites after they are built and does not address methodologies that might be used prior to and during development? If not, please suggest ways to clarify the scope.'''<br />
<ul><br />
<li style="padding-bottom:1em"> Given that the title is about Compliance evaluation, I have no problem with clarifying that the scope is what educationalists call summative assessment (like the final exam!) rather that formative assessment (feedback you can learn from). I noted a number of mentions in the opening sections about the benefits or effects of iterative testing during the design process. <br />
<br />
My suggestion is to keep the two types of testing separate because they relate to substantially different scenarios. Developers probably should not do their own formal compliance testing. I would suggest that the EM has a short paragraph to discuss the difference so that the reader is aware of this and can chose whether the Compliance EM document is relevant or if they need to go to the less formal 'Design_and_ Evaluation' section. <span style="color: #808080;">{Suzette}</span></li><br />
</ul><br />
<br />
[http://www.w3.org/TR/WCAG-EM/#scope 1.1 Scope of this Document] - second and third paragraphs, cited below:<br />
<br />
"However, this methodology only addresses evaluation of website conformance to WCAG 2.0 after its development. Complementary resources from W3C/WAI on evaluation provide guidance on evaluation in other situations, and complementary W3C/WAI activities on Web Accessibility Evaluation and Testing address different W3C/WAI guidelines and specifications."<br />
<br />
"Also, WCAG 2.0 conformance requirements apply to individual web pages. However, on most websites it is not feasible to evaluate every web page with reasonable effort. To ensure conformance of a website to WCAG 2.0 it is necessary to ensure that this is considered throughout the development process. Following this methodology helps assess the level of conformance with reasonable confidence where it is not feasible to evaluate every web page."<br />
<br />
* I prefer not to restrict the evaluation to "only" sites after development. <br />
* I find the second paragraph starting "Also, WCAG 2.0 conformance....etc." somewhat puzzling. In the first paragraph, there is mention that the evaluation methodology is only for sites after development but, on the other hand, in the second paragraph, there is mention of the importance of conformance during the development process and following "this methodology" (which in the first para is stated as only for after development) helps assess the conformance.<br />
<br />
Suggestion (if the scope is fixed on already developed sies):<br />
<br />
This methodology is best used to address evaluation of website conformance to WCAG 2.0 after development. WCAG 2.0 conformance requirements apply to individual web pages. On most websites, it can be challenging to evaluate every single web page. This methodology helps assess the level of conformance with reasonable confidence where it is not feasible to evaluate every web page. <br />
<br />
Complementary resources from W3C/WAI on evaluation provide guidance on evaluation in other situations, and complementary W3C/WAI activities on Web Accessibility Evaluation and Testing address different W3C/WAI guidelines and specifications.<br />
<br />
It is noted that conformance which is considered during the development process reduces significantly the costs of evaluation after development. <br />
<span style="color: #808080;">{Vicki}</span><br />
<br />
'''[important]''' The only one comment I do feel somewhat concerned about is the "Scope" and restricting the document to "only" sites after development. I look at it from the point of view of someone e.g. a developer coming across the document through a search and, with the patience (rather lack of it) that we have on the web, it might be disregarded by the restrictive focus. It is also a document which could still be useful to someone who might perform iterative evaluation through the development process. Therefore, I would recommend being more receptive to a wider audience by changing the wording somewhat. <span style="color: #808080;">{Vicki via Sharron}</span><br />
<br />
==Evaluate throughout==<br />
'''How should we communicate the importance of evaluating throughout website development, not just at the end?'''<br />
<ul><br />
<li style="padding-bottom:1em">'''Abstract'''<br />''Abstract current wording:'' (in a paragraph) However, ensuring and maintaining accessibility requires that accessibility is considered throughout the development process. Complementary resources from W3C/WAI on evaluation provide guidance for other situations.<br /><br />
''Abstract suggested text:'' '''(separate paragraph)''' When developing or redesigning a website, accessibility should be considered early and throughout the design and development process. This is addressed in [http://www.w3.org/WAI/EO/wiki/Eval_in_process a new resource under development] ''<span style="color: #808080;">{which EOWG expects to have drafted for the next WCAG-EM draft so you can put the actual title of the page here}</span>''.<br /><br />
<span style="color: #808080;">{Shawn}</span></li><br />
<br />
<li style="padding-bottom:1em"><br />
'''Introduction, Scope, middle paragraph:'''<br /><br />
''Current text:'' "However, this methodology only addresses evaluation of website conformance to WCAG 2.0 after its development. Complementary resources from W3C/WAI on evaluation provide guidance on evaluation in other situations, and complementary W3C/WAI activities on Web Accessibility Evaluation and Testing address different W3C/WAI guidelines and specifications."<br /><br />
''Suggested text:'' This methodology only addresses evaluating an existing website's conformance to WCAG 2.0. When developing or redesigning a website, accessibility should be considered early and throughout the design and development process. This is addressed in [http://www.w3.org/WAI/EO/wiki/Eval_in_process a new resource under development] ''<span style="color: #808080;">{which EOWG expects to have drafted for the next WCAG-EM draft so you can put the actual title of the page here}</span>''.<br /><br />
'''(new paragraph)''' Related information outside the scope of this document is provided in [http://www.w3.org/WAI/eval/ Evaluating Websites for Accessibility], [http://www.w3.org/WAI/eval/ W3C WAI Web Accessibility Evaluation and Testing Activities], and [http://www.w3.org/WAI/guid-tech.html WAI Guidelines and Techniques]. <br /><br />
<span style="color: #808080;">{shawn}</span></li><br />
<br />
</ul><br />
<br />
==Missing?==<br />
'''Are there any major considerations that we have overlooked or misrepresented?'''<br />
<ul><br />
<li style="padding-bottom:1em">'''Updates, maintenance, drift:''' An accessibility audit is static - a snapshot in time. By contrast, contemporary websites are organic - constantly evolving and growing. New material and novel features can be added by people who were not part of the original development team and these authors may have very limited editorial skills, and knowledge of development. As part of EM, I would suggest that that we should make a strong case for planned reviews to maintain standards and avoid the effect of drift that has been observed by researchers. <span style="color: #808080;">{Suzette}</span></li><br />
</ul><br />
<br />
==Related material==<br />
'''How much should we refer to and link to existing material as reference and how much should we include directly in the new material? Balance the inconvenience of jumping back and forth between existing documents against our reluctance to unnecessarily duplicate information.'''<br/><br />
'''How should we align the WCAG-EM work with the [http://www.w3.org/WAI/EO/wiki/Web_Accessibility_Preliminary_Evaluation Preliminary Evaluation document] now in process at EOWG?<br />What should the [http://www.w3.org/WAI/eval/conformance.html Conformance Evaluation] page be in relation to WCAG-EM?''' (see also [[Eval Analysis]])<br />
<ul><br />
<li style="padding-bottom:1em">EOWG is currently planning to update the [http://www.w3.org/WAI/eval/preliminary.html old Preliminary Eval page], edit the [http://www.w3.org/WAI/eval/conformance.html old Conformance Eval] page to be something like a "WCAG-EM light", and develop a page on [http://www.w3.org/WAI/EO/wiki/Eval_in_process Evaluating throughout the process]. See more in [[Eval Analysis]]. We look forward to talking with the Eval TF about this approach.</li><br />
</ul><br />
<br />
==Other==<br />
''These comments were entered before we had the structure above, so might apply to above or not.''<br />
<ul><br />
<li style="padding-bottom:1em">'''[Very Important]''' '''[http://www.w3.org/TR/WCAG-EM/#step1d Methodology Requirement 1.d]''' - This requirement appears to claim that the website owner and evaluator are free to choose which users may be excluded. Human rights do not work that way. What reasonable base technologies are required for conformance? This is particularly disturbing within the context of intranets where employers may choose to limit users to assistive technologies the employer can purchase cheaply. The note at the end is not sufficient.<br/><br />
Example, many sites prescribe large print with high contrast to be a universal cure for low vision. This discounts the need for albinos to have lower luminosity. Without high luminosity, high contrast is not possible. <span style="color: #808080;">{Wayne Dick}</span></li><br />
<li style="padding-bottom:1em">'''[important]''' '''[http://www.w3.org/TR/WCAG-EM/#step1e 3.1.5 Step d]''' - appeared to invite employer determined prescription of assistive techonolgy and accessibility support. The result will be employer defined necessary employment discrimination. <span style="color: #808080;">{Wayne Dick}</span></li><br />
<li style="padding-bottom:1em">[minor] '''Relied Upon''' - Just hangs there without inclusion in the context of accessibility supported. <span style="color: #808080;">{Wayne Dick}</span></li><br />
<li style="padding-bottom:1em">[Med] The note to (Web Applications): It may not be feasible to exhaustively examine all possible settings, but sampling should apply just as any website. <span style="color: #808080;">{Wayne Dick}</span></li><br />
<li style="padding-bottom:1em">3.1.5 Step 3. The evaluation commissioner, must be informed that if the self defined sufficient techniques are used then a future accessibility audit may ask for a proof of sufficiency. <span style="color: #808080;">{Wayne Dick}</span></li><br />
<li style="padding-bottom:1em">Throughout 3.1.5 PDF and Silver light are basic web technologies. They are no more technologie than docx or raw text. They as basic web technologies. The accessibility open question.<br/><br />
This issue is particularly important if this document is going to be normative. I do specific reference to Adobe or Microsoft products as basic web technologies is serious vendor preference. <span style="color: #808080;">{Wayne Dick}</span></li><br />
<li style="padding-bottom:1em">[http://www.w3.org/TR/WCAG-EM/#step3 3.3 Step 3]: Select a Representative Sample, (First sentence) &#34;While ideally every web page of a web site is evaluated, usually this is not possible on most web sites.&#34;<br/><br />
I feel that stating "usually this is not possible on most web sites" sounds somewhat contradictory (to our objective).<br/><br />
Suggested text: &#34;While ideally every web page of a website should be evaluated, this may not be possible for very large websites.&#34; <span style="color: #808080;">{Vicki}</span></li><br />
<li style="padding-bottom:1em">[http://www.w3.org/TR/WCAG-EM/#step3 3.3 Step 3]: Select a Representative Sample - website with many heterogeneous sub-university example, the sample selection include users. Focus groups are an effective probably necessary.<br/><br />
Large heterogenous sites behave more like a set of independent sites placed under one URL. As such it is important to organize focus groups within the different autonomous site owners to determine usage patterns and prioritize pages for evaluation. When organizing the CSU System, 23 Campuses, each having more than 50 academic departments, and more administrative departments, we found that the IT unit could not get a handle on usage patterns on its own. Individual site owners had to give direct input on priority and usage. Example: At CSU Long Beach the Computer Science lab invokes the Computer Science Department Website every time a student logs into a lab machine. That makes the Computer Science Department the most referenced site on the Campus. But it is not the most important. <span style="color: #808080;">{Wayne Dick}</span></li><br />
<li style="padding-bottom:1em">Responding to the term &#34;with reasonable confidence&#34;: I have no problem with the term. Alternatively, if the above term is a point of discussion, you could simply modify the sentence to &#34;that is representative of the entire target website&#34;. <span style="color: #808080;">{Vicki}</span></li><br />
<li style="padding-bottom:1em">[http://www.w3.org/TR/WCAG-EM/#users 2.5 Involving Users (Optional)]- Second last sentence. &#34;While not required, it is strongly recommended to involve real people covering a wide range of abilities....&#34;<br/><br />
Suggest removing &#34;real&#34;. <span style="color: #808080;">{Vicki}</span></li><br />
<li style="padding-bottom:1em">[http://www.w3.org/TR/WCAG-EM/#step3 3.1.4 Methodology Requirement 1.d:] Third paragraph: second last sentence. &#34;For example, ….., then the website is effectively not accessible for some users.&#34;<br/><br />
Suggest adding something about conformance for emphasis e.g., &#34;and therefore does not conform to the specified conformance level of WCAG 2.0. ([http://www.w3.org/TR/WCAG-EM/#step1c 3.1.3 Step 1.c.])&#34; <span style="color: #808080;">{Vicki}</span></li><br />
<li style="padding-bottom:1em">[http://www.w3.org/TR/WCAG-EM/#functionality Term "Common Functionality"]<br />
Feedback was requested on the definition on &#34;Common Functionality&#34;. <br />
Having read through the document, I don’t have a problem with the term &#34;common functionality. However, it might pose a question mark to some. Therefore, I’ve put forth a few options below depending on what you mean and if you wish to be more specific:<br/><br />
If it is the general functionality of the site, you could simply leave out the word &#34;common&#34; or use &#34;basic functionality&#34;<br/><br />
If &#34;common functionality&#34; has a more technical connotation (referring to the style sheets, javascript, classes, i.e., the technical mandatory requirements for multiple device support and functionality), leave it as &#34;common&#34;<br/><br />
Another suggestion in the line of &#34;common&#34; and &#34;key&#34; is “core”.<br/><br />
Suggestion to modify the description (in line with the &#34;Note&#34;):<br/><br />
Functionality of a website includes tasks that users of a website perform in order to achieve a goal. <span style="color: #808080;">{Vicki}</span> </li><br />
<br />
<li style="padding-bottom:1em">'''3.5.3 Step 5.c''': Provide a Performance Score (optional) I think there are good reasons for offering a score in addition to or as an alternative to the absolute measure of pass/fail. I have read this section several times, and tried really hard to construct a formula to help me comprehend the differences but I am currently confused. Maybe my basic scenario is wrong, so perhaps a worked example would help? Eg what would the score show where some form elements are consistently incorrectly marked and are affecting 5 out of 10 pages tested. <span style="color: #808080;">{Suzette}</span></li><br />
<br />
<li style="padding-bottom:1em">Term "sub-site" : do you want to add the definition to the terms and definitions? <span style="color: #808080;">{Vicki}</span></li><br />
<li style="padding-bottom:1em">Section step 1.A, last paragraphis not clear to me. What is necessary there? May be it could be easier to understand with concrete examples. <quote>"The outcome of this step is an unambiguous definition for the target website, so that for each web page it can be determined whether it is within the scope of evaluation or not. Where possible, it is recommended to use formalizations such as regular expressions or listings of Universal Resource Identifiers that define the web pages<br />
that are within the scope of evaluation (part of the target website)."</quote> <span style="color: #808080;">{Sylvie}</span></li><br />
<br />
<li style="padding-bottom:1em"> <br />
'''1.3 Background Reading, Accessible Web Design''' <br /><br />
This section doesn't feel right. For example, my first reaction was that some relevant documents are missing, such as [http://www.w3.org/WAI/impl/improving.html Improving the Accessibility of Your Website] – and that some included here are maybe not more important than others that weren't included, e.g., [http://www.w3.org/WAI/older-users/developing Developing Websites for Older People] & [http://www.w3.org/WAI/mobile/overlap.html Web Content Accessibility and Mobile Web] seem less important in this context.<br/><br/><br />
Please reconsider the purpose of this list in the context of WCAG-EM. (Remember this section starts with "It is assumed that the reader of this document is familiar with the following related resources from W3C/WAI:") I can see that Essential Components of Web Accessibility and How People with Disabilities Use the Web are particularly important for evaluation &mdash; perhaps only list those 2 &mdash; and not under the heading "Accessible Web Design" but something more directly related to understanding evaluation in the bigger context. <br /><br />
(minor point: This section is not parallel with the others above it &mdash; although I don't think that's a big deal. minor edit:link change: [http://www.w3.org/WAI/mobile/overlap.html Web Content Accessibility and Mobile Web])<br />
<br /><span style="color: #808080;">{Shawn}</span></li><br />
<br />
<li style="padding-bottom:1em">'''Background Reading'''. <br /><br />
''current wording:'' "It is assumed that the reader of this document is familiar with the following related resources from W3C/WAI:" <br /><br />
''Ideas for edited wording:'' "To effectively use this methodology, you should be familiar with the following related information." <br /><br />
''or'' "The information below related to WCAG 2.0 and evaluation is important background for using this methodology. "<br />
<span style="color: #808080;">{Shawn}</span></li><br />
<br />
</ul><br />
<br />
<br />
<br />
<ul><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#scope paragraph 1 ] I think Howard may have made this suggestion already, but instead of using semicolons, use an unordered list instead.<br /><br /><br />
<br />
The methodology described in this document, WCAG-EM, provides guidance on:<br />
<ul><br />
<li>defining parameters for the evaluation scope</li><br />
<li>exploring and understanding websites including their key features and functionality</li><br />
<li>sampling representative web pages from websites where it is not feasible to evaluate all web pages of a website</li><br />
<li>evaluating the conformance of these selected web pages to the target level of WCAG 2.0 conformance</li><br />
<li>documenting and reporting the findings from such evaluation</li><br />
</ul><br />
<span style="color: #808080;">{Paul}</span></li><br />
</ul><br />
<br />
<ul><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#procedure ] I know this was discussed on the last call - description of diagram should be an ordered list. <span style="color: #808080;">{Paul}</span></li><br />
</ul><br />
<br />
<ul><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#reports Appendix C, "For In-Depth…" last paragraph ] There are a lot of unordered lists in this section already, so it may be overkill.<br />
<br /><br /><br />
Change:<br />
<br /><br /><br />
Reports could also indicate the impact of issues found and specifically identify any high impact issues that are easy to fix. This could include: Any accessibility issues that interfere with the user completing tasks, issues that affect navigation and orientation, issues that occur very frequently and issues that can cause any loss or harm to a user. A lot of the important but technical information could be put in an appendix (such as documentation of each outcome of the steps as per Step 5.a: Provide Documentation for Each Step).<br />
<br /><br /><br />
to:<br />
<br /><br /><br />
Reports could also indicate the impact of issues found and specifically identify any high impact issues that are easy to fix. This could include:<br />
<ul><br />
<li>Any accessibility issues that interfere with the user completing tasks</li><br />
<li>issues that affect navigation and orientation</li><br />
<li>issues that occur very frequently</li><br />
<li>issues that can cause any loss or harm to a user.</li><br />
</ul><br />
A lot of the important but technical information could be put in an appendix (such as documentation of each outcome of the steps as per Step 5.a: Provide Documentation for Each Step).<br />
<span style="color: #808080;">{Paul}</span></li><br />
</ul><br />
<br />
==Copyedits & things that probably don't need discussion==<br />
<br />
<ul><br />
<li style="padding-bottom:0.5em">[http://www.w3.org/TR/WCAG-EM/#step1b 3.1.2 Step 1.b.] In-Depth Analysis. End of last sentence is missing a fullstop. <span style="color: #808080;">{Vicki}</span></li><br />
<li style="padding-bottom:0.5em">3.2.3 "Note: This step is intended to identify groups of web page instances, including in web applications."<br/>Suggest drop the "in" as in "including web applications" or add "including those in web applications". <span style="color: #808080;">{Vicki}</span></li><br />
<br />
<li>[ http://www.w3.org/TR/WCAG-EM/#introduction paragraph 2 ] "This methodology can also be useful for other purposes," (add comma) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#introduction paragraph 3 ] "…and complements existing WCAG 2.0 resources," (add comma) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#audience bullet 5 ] Change "…monitoring activities who want to benchmark…" to "…monitoring activities that benchmark…" <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#usage last sentence ] Change "…of the overall performance of the website…" to "…of the overall conformance of the website…" <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#specialcases Small Websites ] "For websites with few web pages," (add comma) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#specialcases Web Applications Note ] Change "These individual states of web page" to "These individual states of web pages" <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#specialcases Web Applications Note ] Change "…to generate these states of web page and generated web page" to "…to generate these states of web pages and generated web pages" <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#specialcases Website with Separable Areas ] Consider adding example of "site administration" to (extranet) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step2 Methodology Requirement 2 Note ] Change "…other aspects of the implementation that makes" to "…other aspects of the implementation that make" <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step3 third paragraph ] Change "…and in many cases these web pages may have different design to others" to "…and in many cases these web pages may have different design than others" <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step3 third paragraph ] Change "…can significantly reduce the required sample size while..." to "…can significantly reduce the required sample size, while..." (add comma) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step4a Note ] Change "…used to create many web pages, sometimes entire parts..." to "…used to create many web pages, sometimes entire sections..." <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step4c Reminder paragraph 1 ] Change "And you can use..." to "Evaluators can use..." <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step4c Reminder bullet 1 ] Change "…by the WCAG 2.0 Success Criterion at least..." to "…by the WCAG 2.0 Success Criterion, at least..." (add comma) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step5 bullet 7 ] Change "web pages" to "Web pages" (capitalization) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step5a Note after In-Depth Analysis Report ] Change "(see Step 5.b: Provide and Accessibility Statement)" to "(see Step 5.b: Provide an Accessibility Statement)" (misspelling) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step5b ] Change "As per the requirements for WCAG 2.0 conformance claims, also accessibility evaluation statements have to include the following information:" to "As per the requirements for WCAG 2.0 conformance claims, accessibility evaluation statements also have to include the following information:" (change word order for clarity)<span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step5c paragraph 2 ] Change "The type of scoring system used has to be indicated along with..." to "The type of scoring system used has to be indicated, along with..." (added comma) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step5c ] "Currently the following scoring approaches are provided by this methodology:" The word "Currently" suggests other scoring approaches will be added to this document in the future. Does it make sense to remove it?<span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step5c Per Website bullet point 2 ] Change "During the evaluation mark the..." to "During the evaluation, mark the…" (added comma) <span style="color: #808080;">{Paul}</span></li><br />
<li> http://www.w3.org/TR/WCAG-EM/#step5c Per Website bullet point 3 ] Change "After the evaluation calculate..." to "After the evaluation, calculate…" (added comma) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step5c Per Web Page paragraph 1 ] occasional (misspelling) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step5c Per Web Page paragraph 1 ] Change "…such as occasional oversight but does not..." to "…such as occasional oversight, but does not..." (added comma) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step5c Per Web Page paragraph 1 ] consistently (misspelling) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step5c Per Web Page paragraph 1 ] Change "…may still have a high score even though..." to "…may still have a high score, even though..." (added comma) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step5c Per Web Page bullet 2 ] Change "During the evaluation mark..." to "During the evaluation, mark..." (added comma) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step5c Per Web Page bullet 3 ] Change "After the evaluation calculate..." to "After the evaluation, calculate..." <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step5c Per Instance paragraph 1 ] occasional (misspelling) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step5c Per Instance bullet 1 ] Change "Select a Representative Sample) calculate..." to "Select a Representative Sample), calculate..." <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#step5c Per Instance bullet 3 ] Change "After the evaluation calculate..." to "After the evaluation, calculate..." (added comma) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#divide paragraph 2 ] Change "…web pages of the main website plus two..." to "…web pages of the main website, plus two…" (added comma) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#reports Appendix C introduction ] Change "…three different levels of reporting following..." to "…three different levels of reporting, following…" (added comma) <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#reports Appendix C, "For In-Depth…" bullet 1 ] Change "...the report identifies if it is met or not met and provide minimally one example..." to "the report identifies if it is met or not met and at a minimum provides..." <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#reports Appendix C, "For In-Depth…" bullet 3 ] Change "Provide suggestions for improving the overall accessibility of the website and if possible suggesting guidance for the future;" to "Provide suggestions for improving the overall accessibility of the website, and if possible, suggest guidance for the future;" <span style="color: #808080;">{Paul}</span></li><br />
<li>[ http://www.w3.org/TR/WCAG-EM/#terms Terms and Definition ] Headings that have anchors leading to them end up underlined, or behave differently in some browsers (they turn red when clicked in Safari, underlined in others), because they are coded like so: &lt;h3&gt;&lt;a id="terms" name="terms"&gt;Terms and Definitions&lt;/a&gt;&lt;/h3&gt;. Either modify how it's coded to &lt;h3&gt;&lt;a id="terms" name="terms"&gt;&lt;!-- anchor --&gt;&lt;/a&gt;Terms and Definitions&lt;/h3&gt;, or change the stylesheet to make sure they remain styled like headings only. <span style="color: #808080;">{Denis}</span> </li><br />
</ul><br />
<br />
==Comments sent directly (not through EOWG)== <br />
<ul><br />
<li style="padding-bottom:0.5em">Jennifer (2012_09_29): Submitted this [http://lists.w3.org/Archives/Public/public-wai-evaltf/2012Sep/0088.html comment on WACG-EM 1.0 -- use of internal links] independently -- meaning that I did not post on behalf of EOWG.</li><br />
</ul><br />
<br />
</div><br />
<br />
__NOINDEX__</div>Wdickhttps://www.w3.org/WAI/EO/wiki/index.php?title=Eval_in_process&diff=2696Eval in process2013-01-08T21:09:40Z<p>Wdick: /* Title ideas */</p>
<hr />
<div>Nav: [[Main Page|EOWG wiki main page]]<br />
<br />
__TOC__<br />
<br />
'''This page explores the possibility of providing additional guidance on evaluating early and throughout the design & development process -- or more broadly on including accessibility early.'''<br/><br />
[[#Analysis_&_Notes]] at the end of the page includes open issues.<br/><br />
Archived info from previous drafts is at [[Accessibility Early Archive]].<br />
<br />
=[Draft] Address Accessibility Early=<br />
<br />
==Introduction==<br />
<br />
Consider accessibility early and throughout the design process for seamless and elegant integration into web and application development projects. Incorporating accessibility from the start increases the positive impact of designing for a broad constituency while decreasing development costs associated with accessibility.<br />
<br />
Avoid situations in which accessibility is considered only at the end of the development process. This often results in awkward, "tacked on" accessibility features that are much less effective for people with disabilities and less beneficial overall. Incorporating accessibility from the beginning of a design project is significantly easier, more effective, and less expensive than waiting until later in the project.<br />
<br />
It is almost always better to integrate accessibility considerations throughout your existing processes, rather than addressing accessibility separately. While you may need some additional steps for accessibility, most of it fits nicely within what you're already doing. For example, instead of evaluating accessibility separately, integrate accessibility checks where they fit best within your current testing and quality assurance (QA) processes. That's just one example; integrating accessibility applies all the way through a project.<br />
<br />
This resource addresses how and where accessibility fits through the lifecycle of a web project.<br />
<br />
==Project Initiation Stage==<br />
The [http://www.w3.org/community/wai-engage/wiki/Accessibility_Responsibility_Breakdown#Project_management role of the Project Manager] is vital to the success of an accessible web project. At the very start, the Project Manager needs to ensure that every stakeholder understands their role and the requirements at every stage of the project (definition, planning, development, closure). <br />
<br />
In the initiation phase, there are several accessibility considerations that need to be addressed in the project document and which may require some research as regards legal requirements, the understanding of accessibility within the organization, the tools which are used and so forth.<br />
<br />
===Legal requirements===<br />
There may be legal requirements of the country which should be taken into consideration. Many organizations use WCAG as a target for accessibility. For example, an organization sets its target to meet WCAG 2.0 Level A and Level AA success criteria. Developing an accessibility policy is a good way to clarify and communicate your target.<br />
<br />
The following resources provide information on:<br />
* [http://www.w3.org/WAI/guid-tech.html Accessibility standards and guidelines] <br />
* [http://www.w3.org/WAI/Policy/Overview.html Policies relating to accessibility] <br />
* [http://www.w3.org/WAI/bcase/pol Legal and Policy Factors in Developing a Web Accessibility Business Case for Your Organization] <br />
<br />
At the same time, in order to enable continuity of the accessible site or application, an internal policy and an implementation plan should be developed. The following pages provide guidance on how to:<br />
* [http://www.w3.org/WAI/impl/pol Develop internal policies on accessibility]<br />
* [http://www.w3.org/WAI/impl/Overview.html Develop an Implementation Plan]<br />
<br />
===Discovery & Analysis===<br />
<br />
Some analysis is necessary in order to assess the level of accessibility within the organization. The authoring tools, the software specifications and the technical solutions should all be considered. A frequent cause of accessibility barriers is simply that web developers are not aware that they should make websites accessible. <br />
<br />
The following resources provide some guidance on the essential aspects pertinent to accessibility requirements gathering:<br />
<br />
* Evaluate the [http://www.w3.org/WAI/impl/software accessibility support in design and development tools] for the project<br />
* Assess the level of accessibility knowledge and if there is need to provide training<br />
* Ensure that everyone knows that accessibility is a requirement, in particular, stakeholders, even if an official policy is not yet available<br />
* Estimate resources required to address the needs identified in the initial assessment. Include software replacement, staff training, retrofitting of site, monitoring of site, etc., as needed.<br />
<br />
===Technical specifications===<br />
In drafting the technical specifications, once the standard and level of conformance is agreed upon, this will need to be documented in some or all of the following areas:<br />
<br />
* Software specifications<br />
* Design specifications<br />
* Functional design specifications<br />
* User acceptance criteria<br />
<br />
===Budget===<br />
Incorporating accessibility from the beginning of a website development or redesign process is almost always significantly easier, less expensive, and more effective than making accessibility improvements to an existing site later as a separate project. When accessibility is only addressed late in design, it can be very [http://www.w3.org/WAI/bcase/fin#decreasing costly to make required design changes]. Furthermore, [http://www.w3.org/WAI/impl/improving.html#retro retrofitting sites] can be a long process. Therefore, include accessibility into the budget at the start of the project.<br />
* Plan a budget and schedule to [http://www.w3.org/WAI/users/involving.html include people with disabilities] as collaborators in the project<br />
* Budget for testing accessibility in case resources are not available within the organization<br />
* Budget for training and/or hiring in order to develop accessibility knowledge and skills<br />
<br />
==Design Stage==<br />
<br />
Designers are responsible for the design and user interface of web pages and applications. It is important to recognize that accessibility is not only an issue for developers and programmers. People who are knowledgeable about accessibility must work together with designers throughout the project life cycle to understand relationships that help the team collectively develop an accessible, usable, and quality product. <br />
<br />
Choosing accessible technologies to begin with makes the process much more intrinsically accessible. Evaluating early design prototypes helps to validate design aspects that work well, and to find potential accessibility barriers while it is still relatively easy and inexpensive to fix them. <br />
<br />
In the [http://www.w3.org/community/wai-engage/wiki/Accessibility_By_Roles_-_Graphic_Design role of Web Designer], a number of tasks associated with quality control of the design - e.g. graphical and user interfaces, navigational elements, contextual changes and other general design elements of content pages - are of relevance and should be checked for conformance to accessibility standards and best practices.<br />
<br />
===Evaluate Accessible Design===<br />
Effective evaluation during the design period can include:<br />
<br />
* Establishing clear requirements for the expected accessibility conformance level<br />
* Ensuring common understanding among team members<br />
* Involvement in initial planning meetings for the site<br />
* Agreeing on a review schedule during the development process<br />
* Providing information on evaluation approaches so that the developers can at least do preliminary reviews on their own<br />
<br />
===Initial Mock-ups===<br />
Even before coding begins, wireframes or visual mock-ups can be evaluated through early screening by performing checks on<br />
* information architecture<br />
* color scheme<br />
* contrast of colors<br />
* alerts for planned dynamic interactions<br />
<br />
At this early stage, accessible design elements can be built into the project to allow stakeholders to understand from the start where and why changes are introduced.<br />
<br />
===Content Creation===<br />
Content that is easily understood and available to persons with disabilities is a fundamental aspect of web accessibility. Accessible content requires little effort and increases usability at large. Websites and web tools that are designed for people with a broad range of abilities will benefit everyone, including people without disabilities.<br />
<br />
If content is created with accessibility in mind, all users will be included, for example,<br />
<br />
* if audio content, such as videos with voices and sounds, contain captions or transcripts, this will enable people with auditory disabilities to access the information<br />
* if navigation mechanisms and page layouts are simple, they are much easier to understand and use by persons with cognitive disabilities<br />
* if sufficient time is given to respond or to complete a task, such as to fill out an online form, this will ensure that persons with physical disabilities are not time-barred<br />
* if websites offer alternative means of communication, such as including e-mail and feedback forms, this will ensure that persons with speech disabilities are not confined to contact by phone and can, therefore, interact<br />
* if text, images, and page layouts can be resized, this will ensure that persons with visual impairment can also benefit and access the information<br />
<br />
[http://www.w3.org/WAI/intro/people-use-web/diversity Diversity of web users] describes the types of disabilities, situations, problems and remedies to making content accessible.<br />
<br />
== Development Stage ==<br />
<br />
The implementation is the last part of the process of building a site or application, but that does not mean that developers should not be involved early. They often have a broad knowledge of usability and accessibility issues as everything from the product owner's and content writer's requirements to the user experience designer's vision of the product are filtered through them.<br />
<br />
Make sure to use developers to spot issues that would normally only be caught at the development stage as early as possible.<br />
<br />
=== Pre-Development Checklist ===<br />
<br />
Checklists often work well for the developer mindset, and can be checked at the product requirements and design stage.<br />
<br />
<span style="color: #808080;">{I think this is too specific and we don't want to be this prescriptive &mdash; Shawn.<br />If we do keep a list, then need to separate technical aspects from content aspects as usually different groups &mdash; Andrew}</span><br />
<br />
Ensure requirements specify:<br />
* exact foreground and background colours<br />
* tab order<br />
* focus handling<br />
* focus styles<br />
* alt text for images<br />
* additional hidden content for AT where required<br />
* placeholder / summary / title text where required<br />
* error message text and placement where required<br />
* simple /clear text in buttons, titles and content<br />
[Create list from the various sources we have gathered]<br />
<br />
=== The Development Cycle ===<br />
<br />
<span style="color: #808080;">{This section needs editing to be less specific and prescriptive. Could present the steps as an example.}</span><br />
<br />
<span style="color: #808080;">{This section doesn't seem to address the typical information site where the templates are developed for use within a CMS along with most scripting and the CSS, and then the content is added &mdash; Andrew}</span><br />
<br />
The development stage can make or break the accessibility of a project. A good development workflow with a focus on accessibility can find problems before the QA phase, or worse, before the users find them.<br />
<br />
Not all of these steps need to followed on every iteration or for every feature, but all of the testing points should be hit at least once for each release.<br />
<br />
* Markup content<br />
* Test simple keyboard (tab and return keys) interaction without CSS<br />
* Add CSS<br />
* Test with text increase 200%<br />
* Test with screen reader / keyboard<br />
* Add JavaScript enhancement<br />
* Test with screen reader / keyboard<br />
* Re-factor and repeat<br />
<br />
===Quality Plan===<br />
Iteratively test for accessibility throughout the development process.<br />
* Include accessibility testing stages in the quality assurance plan<br />
** Web Accessibility Preliminary Evaluation provides detailed guidance on how to check accessibility<br />
** Consider developing a Compliance Matrix<br />
Whilst accessibility evaluation is performed with a combination of tools, services and experts, there are many benefits to evaluating with real people to learn how your website or web tool really works and to better understand accessibility issues. <br />
* [http://www.w3.org/WAI/eval/users.html Evaluating with users with disabilities] and with older users identifies usability issues that are not discovered by conformance evaluation alone. <br />
* [http://www.w3.org/WAI/users/involving#why Involving users early in web projects ensures better and easier accessibility]<br />
* [http://www.w3.org/WAI/users/involving Involving users with disabilities and having accessibility specialists evaluate] in planned repairs can catch any problems before they are propagated throughout your site.<br />
<br />
Including users throughout the development process to complete sample tasks on prototypes can assist in understanding how the different aspects of the design and coding can be improved.<br />
<br />
==Content Creation==<br />
<span style="color: #808080;">{Andrew to add some notes here - see also earlier draft for ideas}</span><br />
<br />
==Project Closure==<br />
In the project sign-off, include the sign-off for accessibility conformance and celebrate this as an achievement in the project launch.<br />
<br />
Document the lessons learned in implementing accessibility. This can be a very useful source of information in the post project phase and for other projects within the Organization.<br />
<br />
==Post Project==<br />
In order to maintain a level of conformance, a post project plan should be in place to ensure that<br />
<br />
* regular checks are performed for continued accessibility<br />
* all aspects of implementation plan for effectiveness are periodically reviewed<br />
* new barriers are not introduced when redesigns or updates are planned<br />
* accessibility knowledge of staff is a continued requirement (offer repeated training opportunities as staff and responsibilities change)<br />
<br />
==More Information==<br />
{@@link to some of the resources listed under [[#Current_related_WAI_information]] ?}<br />
<br />
<br /><hr /><hr /><br />
<br />
=Analysis & Notes=<br />
<br />
'''''Comment template:''''' @@ comment <span style="color: #808080;">{name}</span><br />
<br />
==<span style="background:yellow;">To Do</span>==<br />
<br />
* <span style="background:yellow;">Ian</span> to edit Development Stage sections <http://www.w3.org/WAI/EO/wiki/Eval_in_process#Development_Stage><br />
* <span style="background:yellow;">Sharron</span> to add to Design Stage section <http://www.w3.org/WAI/EO/wiki/Eval_in_process#Design_Stage> ''(Sharron were you done with this, or do you have more ideas to add?)''<br />
* <span style="background:yellow;">Vicki</span> to consider Suzette's input in "Just some thoughts for consideration {Suzette}" ''(Vicki, did you already complete this? if so, would you add breif notes on how you addressed it and move it to the "Comments - Closed" section of this wiki page?)''<br />
* <span style="background:yellow;">EOWG</span> to comment on titles ideas <http://www.w3.org/WAI/EO/wiki/Eval_in_process#Title_ideas><br />
<br />
==Open issues & Comments==<br />
<br />
...comment <span style="color: #808080;">{name}</span><br />
<br />
===What to do with the related material in other documents?===<br />
<span style="background:yellow;">OPEN: Need to look more closely at the content of this new page and the content that we currently have elsewhere to decide what to do with it. (Vicki has incorporated some of it already.)</span><br />
<br />
[[#Current_related_WAI_information|current related material in other documents listed below]]<br /><br />
Would some of the information in other documents move to this page, and we would delete it on those pages and point to it here? Or would it be handle differently?<br />
<ul><br />
<li>My tendency is to integrate and reduce the number of documents, but related documents will have to be reviewed and decided as this one develops.<span style="color: #808080;">{Sharron}</span></li><br />
<li>Where information in other documents is particularly relevant, introduce passages (with some minor modifications) into this document and point to the other relevant documents through links within the text. I wouldn't do away with the other documents unless something is totally out of date.<span style="color: #808080;">{Vicki}</span></li><br />
</ul><br />
<br />
===Just some thoughts for consideration <span style="color: #808080;">{Suzette}</span>===<br />
<br />
Vicky and Ian have made a good start on an important topic. It is good to have clearly defined roles and stages and references out to appropriate documents that will support getting accessibility in at the earlier planning stages.<br />
Design process: My comments mainly relate to how we conceptualise the design processes being applied to web design and development. <br />
<br />
I think it would help if we could establish an agreed process strategy. Some people may still mash a website overnight but it is hard to help people improve quality when they are not being systematic – unless they are really, really good!<br />
<br />
I think we should broadly assume and establish that designing today’s sophisticated websites demands a relatively formal multi-stage design process. This will allow accessibility issues to be addressed early and at each stage, and is why we are writing this document. <br />
<br />
====Introduction====<br />
<br />
Essential to set the tone – the two key points to sell the benefits of early intervention AND that this document establishes a strategy for early and continuing engagement.<br />
<br />
This is a good place to establish something about having a systematic process eg: “Best practice in web design shows that it is important to follow a systematic design process, and for accessibility issues to be addressed at each stage”<br />
<br />
====Project initiation stage:====<br />
<br />
This seems to be linked to the Project Manager and picks up on the legal case – although it could equally well pick up on the pages on the Business Case. The output of this stage appears to be a policy document on accessibility.<br />
Stage naming: We’ve named this stage Project Initiation but then in the 1st paragraph the stages are defined as definition, planning, development and closure. It would be neat to correlate these stages in the text description with our chosen headings. My suggestion for discussion is: Project planning, Design, Development.<br />
See comments later about Quality plan, Project closure and post project which are also planning issues<br />
<br />
====Design Stage:====<br />
<br />
Linked to role of Designer. Good to bring in aesthetic design and content creation, and essential to talk about mock-ups and prototype testing, and opportunities to talk to representative disabled people and accessibility experts. <br />
<br />
Maybe also consider ‘how’ the content is delivered - especially in relation to multi-media and interactive elements. Where else can you consider needs of low literacy, print impairments as well as visual impairment, and keyboard only use?<br />
<br />
====Development stage:====<br />
<br />
Linked to role of Developer – some confusion here about scope and timing of this role. <br />
<br />
Alternatives to the waterfall model of design process: Some design processes like Agile are much more comfortable with the expectation of parallel development. Maybe we can establish that design and development stages are fully interlinked. Maybe also need to establish the relationship with the content creators, I’m sure the PR and marketing people start to get involved especially in medium to large government sites or media heavy commercial sites. <br />
<br />
Check and test lists: Pre-development checklist and the development cycle list both seem too detailed. Maybe just have one and go higher level eg Content, style, design, features, navigation. Can then point to our other stuff on evaluation such as the Preliminary Evaluation.<br />
<br />
Preliminary Evaluation – I’m not sure that we have this group fully in mind. They are going to have to deal with some quite complex decisions which we have currently excluded as too difficult to describe simply.<br />
Good also to repeat about testing the later stage mock-ups and prototypes, and simulations as part of development not Quality testing.<br />
<br />
====Final stages:====<br />
<br />
Quality plan, Project Closure and Post project. Quality is iterative but otherwise these are not about ‘early’ as such, but belong with the project manager and could be dealt with in the planning/initiation stage.<br />
<br />
====Review and Comments <span style="color: #808080;">{Wayne 14 Dec}</span>====<br />
This is excellent for the need: a high level overview of fully integrated accessibility at initial stages.<br />
<br />
I was confused by the sentence: "Some analysis is necessary in order to assess the level of accessibility within the organization." To what organizational entity does accessibility refer?<br />
<br />
I do think the check lists are essential, but I'm not sure how to address Shawn's issue with prescription. Perhaps these check lists need be introduced as a getting contrite phase of design. When you are at phase X you should consider issues like ... [check list]. It might be made clear that this list is neither exhaustive nor mandatory. However, omission of lists makes the document to abstract and vague.<br />
<br />
I don't understand refactor in this context.<br />
<br />
==Comments - Closed==<br />
===[Closed] In the "Introduction", second paragraph, I would like to suggest removing the following sentences:===<br />
<br />
"As an example, consider a building that is architecturally planned for accessibility from the beginning and has a wheelchair-accessible entrance that fits with the building design aesthetically and practically. Compare that to a building with a ramp added on after the building was already designed and the ramp looks awkward and is less useful to all."<br />
<br />
I think a shorter introduction with focus on guidance in the framework of a web project is more likely to grasp attention.<br />
<span style="color: #808080;">{Vicki}</span><br />
<br />
===[closed] Do we want to develop a new document, or do existing documents cover it sufficiently?===<br />
Decision: Develop new document.<br />
<br />
[[#Current_related_WAI_information|Existing documents listed below]] <br />
<ul><br />
<li>A new document that integrates key points from all of the others would be useful. However, it will only be so if we can keep it focused and quite clear. <span style="color: #808080;">{Sharron}</span></li><br />
<li>Agree with the above approach of Sharron<span style="color: #808080;">{Vicki}</span></li><br />
<li>...comment <span style="color: #808080;">{name}</span></li><br />
</ul><br />
<br />
===[closed] If new document, what should be the scope?===<br />
Decision: Broad scope - accessibility early & throughout.<br />
<br />
Should it focus only on evaluation throughout design & development process, or more broadly addressing including accessibility from early and throughout in all projects?<br />
<ul><br />
<li>A comprehensive approach seems best to me, but we should be conscious (and vigilant) about length and scope creep. <span style="color: #808080;">{Sharron}</span></li><br />
<li>A broad approach addressing where accessibility fits through the project, i.e., at the start, during, after but careful about length and style. It should act as guidance to the valuable other information already available.<span style="color: #808080;">{Vicki}</span></li><br />
<li>...comment <span style="color: #808080;">{name}</span></li><br />
</ul><br />
<br />
===[closed] If new document, how long and how detailed?===<br />
Decision: Keep as short. Not detailed. Link to existing material elsewhere, or that might developed elsewhere.<br />
<br />
Would we just give general guidance, or would we include specific steps and tasks that apply broadly?<br />
<ul><br />
<li>I like the tendency that I am seeing in relating the content here to the roles that were developed earlier this year. I would caution against too much specificity unless we also commit to a schedule of updates and revisions to keep the information current and accurate<span style="color: #808080;">{Sharron}</span></li><br />
<li>Not a lengthy document, if possible. Keep it to the point and reference to the other valuable information already available under WAI. Later, once webplatform docs has some tips and trick, especially under "Development Stage", we could link there<span style="color: #808080;">{Vicki}</span></li><br />
<li>...comment <span style="color: #808080;">{name}</span></li><br />
</ul><br />
<br />
==Purpose==<br />
* Convince readers of the benefits of addressing accessibility early and throughout the design & development process -- and provide them guidance<br />
* Have a place to point to from WCAG-EM (and other docs that talk about evaluating existing sites) that says do it early & do it often<br />
See also [[Eval Analysis]] for use cases for this and related documents<br />
<br />
==Current related WAI information==<br />
<br />
* [http://www.w3.org/WAI/users/involving Involving Users in Web Projects for Better, Easier Accessibility]<br />
** includes section on How Involving Users Early Helps<br />
<br />
* [http://www.w3.org/WAI/eval/users.html Involving Users in Evaluating Web Accessibility]<br />
** says things like "including them throughout the development process to complete sample tasks on prototypes so you can see how the different aspects of the design and coding could be improved"<br />
** [done] There's a pointer under "Quality Plan" to the above link. I could expand on the wording as suggested.<span style="color: #808080;">{Vicki}</span><br />
<br />
* [http://www.w3.org/WAI/impl/improving.html Improving the Accessibility of Your Website]<br />
** includes sections on Evaluating to Identify the Issues, Optimizing Your Retrofitting, Prioritizing the Repairs<br />
** [done] Yes - some points especially from "Clarifying requirements" (could be used 'Discovery & Analysis', /DONE/ "Validating solutions" (second paragraph could be inserted under 'Quality Plan', /DONE/ "Next: Strategic Planning" (parts could be used under "Legal requirements") (<span style="color: #808080;">{Vicki}</span><br />
** [done] Under "Setting the target", the first paragraph could be used under "Legal requirements" and the first sentence of the last paragraph of this section (<span style="color: #808080;">{Vicki}</span><br />
<br />
* [http://www.w3.org/WAI/impl/Overview.html Implementation Plan for Web Accessibility]<br />
** Has sections on [http://www.w3.org/WAI/impl/Overview.html#assess Conduct Initial Assessment] and [http://www.w3.org/WAI/impl/Overview.html#develop Develop Accessible Website]<br />
** Is from 2002 - is it still point-to-able, or too old? how much work to update it?<br />
** [OPEN] Also interesting points under "Develop Accessible Website" which could possibly go under "Development stage" with some minor modifications (<span style="color: #808080;">{Vicki}</span> <br />
** [done] A paragraph to close with the points from "Monitor Website Accessibility" could be added at the end of this document(<span style="color: #808080;">{Vicki}</span> <br />
** There's good stuff there. I could try to integrate /DONE/some points briefly into this document. Wouldn't move anything out of the original since I think it is all still quite relevant. Perhaps, some minor updating but the document is a very good source of information for anyone starting out.<span style="color: #808080;">{Vicki}</span><br />
<br />
* [http://www.w3.org/WAI/bcase/fin#decreasing B-Case, Financial Factors, Decreasing Costs]<br />
** has section on "Incorporating accessibility from the beginning"<br />
** [done] Yes, this sentence can be slightly modified and added under Budget <span style="color: #808080;">{Vicki}</span><br />
** Interesting paragraph to add under "Design" on "Addressing accessibility and mobile together" <span style="color: #808080;">{Vicki}</span><br />
<br />
* [http://www.w3.org/WAI/users/ Designing for Inclusion]<br />
** doesn't have info on design process, but some people might come looking here for it; therefore, we might want to add pointers to related information in the "See also" sections<br />
<br />
''([http://www.w3.org/WAI/EO/changelogs/outreach.html Outreach Planning page] has info on dated-ness of some docs.)''<br />
<br />
===other inputs===<br />
* Text EOWG is welcome to use:<br />
** [http://uiaccess.com/accessucd/early.html Incorporating Accessibility Early and Throughout]<br />
** [http://uiaccess.com/accessucd/design.html#eval Evaluate Throughout Design]<br />
** [http://uiaccess.com/accessucd/evaluate.html Evaluating for Accessibility], e.g., [http://uiaccess.com/accessucd/evaluate.html#walkthroughs Design Walkthroughs]<br />
* [http://lists.w3.org/Archives/Public/public-wai-evaltf/2012Oct/0052.html email from Phill Jenkins includes some considerations early]<br />
** more: Yes, please add in some specifics about doing a design review and for accessibility prior to development of running or prototype code.<br/>Seems you have a step already listed:<br/>Design specification: We want an independent assessment of high level objects during early stage design planning. We can provide sample use cases, early page mock-ups, wireframes and simple prototypes.<br/>The other step is a "review of the technology choices" for accessibility support for the new/redesigned site. Such as user interface components (UI widgits) from jQuery, DoJo, and other JavaScript libraries and embedded video playersfor example that do (or don't) a good job of supporting accessibility. <br />
* [http://www-03.ibm.com/able/education/downloads/CostSavingsofEarlyAccessibility-CSUN-2012_accessible_IBM.pdf Cost Savings of Early Accessibility]<br />
* [http://www.standards-schmandards.com/2007/rapid-accessibility-feedback/ Bringing Accessibility into the Development Process]<br />
* [http://www.w3.org/community/wai-engage/wiki/Accessibility_Responsibility_Breakdown Accessibility_Responsibility_Breakdown] draft<br />
<br />
==Misc Notes==<br />
<br />
<ul><br />
<li style="padding-bottom:1em">@@ comment template <span style="color: #808080;">{name}</span></li><br />
</ul><br />
<br />
===Title ideas===<br />
<span style="color: #808080;">'''''summary''''' - Comment {name}</span><br />
<br />
* Start with Accessibility<br />
** <span style="color: #808080;">'''''like''''' - "Start" is good - supports the idea that accessibility is fundamental and leads to innovation! might also get SEO for searches like "getting started with accessibility" {Shawn}</span><br />
* {Wayne} I think this is perfect: simple and complete<br />
** A sub-title like "How to and What to Address" might help<br />
<br />
* Build Accessibility Early into Web Projects<br />
** <span style="color: #808080;">'''''like'''''- kinda like "build into" {Shawn}</span><br />
** <span style="color: #808080;">'''''like'''''- because it sounds "solid" and "serious" and contains the words "web projects"{Vicki}</span><br />
** <span style="color: #808080;">'''''like'''''- because it sounds clear and good. {Sylvie}</span><br />
<br />
* Integrating Accessibility in Your Web Project<br />
** <span style="color: #808080;">'''''like'''''- "integrating" is nice, saying it's not a separate thing {Shawn}</span><br />
** <span style="color: #808080;">'''''best'''''- like for the same previous reasons "solid", "serious", and also since the document (now) encompasses a project framework, I like the idea of having the words "web project" in the title. This would be my favorite {Vicki}</span><br />
** <span style="color: #808080;">'''''like''''' - this too, because it sounds positive. I like both above better than the following proposals. {Sylvie}</span><br />
<br />
* Accessibility Early in the Process<br />
** <span style="color: #808080;">@@'''''summary''''' - Comment {name}</span><br />
<br />
* Address Accessibility Early<br />
** <span style="color: #808080;">@@'''''summary''''' - Comment {name}</span><br />
<br />
* Early Accessibility<br />
** <span style="color: #808080;">'''''no''''' - this one doesn't do anything for me. {Shawn}</span><br />
<br />
* Accessibility Now<br />
** <span style="color: #808080;">@@'''''summary''''' - Comment {name}</span><br />
<br />
* Accessibility First<br />
** <span style="color: #808080;">@@'''''summary''''' - Comment {name}</span><br />
<br />
* Plan for Accessibility Early<br />
** <span style="color: #808080;">'''''caution''''' - Wonder if developers and designers would realize this applies to them, or think it's targeted to managers {Shawn}</span><br />
<br />
* Accessibility Early<br />
** <span style="color: #808080;">@@'''''summary''''' - Comment {name}</span><br />
<br />
* Accessibility in Development Early<br />
** <span style="color: #808080;">'''''caution''''' - maybe designers & content creators wouldn't think this applies to them? {Shawn}</span><br />
<br />
* Accessibility in Web Projects <br />
** <span style="color: #808080;">'''''caution''''' - maybe too broad {Shawn}</span><br />
** <span style="color: #808080;">'''''okay''''' - similar to previously mentioned, the focus being accessibility on projects {Shawn}</span><br />
<br />
* Accessibility Early, Accessibility Often (play off [http://en.wikipedia.org/wiki/Release_early,_release_often RERO])<br />
** <span style="color: #808080;">'''''caution''''' - probably most people won't get the RERO play. without that, I think "often" makes it sound like a lot of work {Shawn}</span><br />
<br />
* How Accessibility Planning Works<br />
** <span style="color: #808080;">@@'''''summary''''' - Comment {name}</span><br />
<br />
==Acknowledgements==<br />
<br />
Thanks to:<br />
* Vicki Menezes Miller for significant drafting and editing of several sections<br />
* Ian Pouncey for editing and drafting some sections<br />
* Shawn Henry for working on the framework and commenting on drafts<br />
* Sharron Rush for commenting on open issues<br />
* Suzette Keith for some initial ideas and detailed review and comment on December draft<br />
<br />
__NOINDEX__</div>Wdickhttps://www.w3.org/WAI/EO/wiki/index.php?title=Eval_in_process&diff=2644Eval in process2012-12-14T04:49:06Z<p>Wdick: /* Title ideas */</p>
<hr />
<div>Nav: [[Main Page|EOWG wiki main page]]<br />
<br />
__TOC__<br />
<br />
'''This page explores the possibility of providing additional guidance on evaluating early and throughout the design & development process -- or more broadly on including accessibility early.'''<br/><br />
[[#Analysis_&_Notes]] at the end of the page includes open issues.<br/><br />
Archived info from previous drafts is at [[Accessibility Early Archive]].<br />
<br />
=[Draft] Address Accessibility Early=<br />
<br />
==Introduction==<br />
<br />
Consider accessibility early and throughout the design process for seamless and elegant integration into web and application development projects. Incorporating accessibility from the start increases the positive impact of designing for a broad constituency while decreasing development costs associated with accessibility.<br />
<br />
Avoid situations in which accessibility is considered only at the end of the development process. This often results in awkward, "tacked on" accessibility features that are much less effective for people with disabilities and less beneficial overall. As an example, consider a building that is architecturally planned for accessibility from the beginning and has a wheelchair-accessible entrance that fits with the building design aesthetically and practically. Compare that to a building with a ramp added on after the building was already designed and the ramp looks awkward and is less useful to all. Incorporating accessibility from the beginning of a design project is significantly easier, more effective, and less expensive than waiting until later in the project.<br />
<br />
It is almost always better to integrate accessibility considerations throughout your existing processes, rather than addressing accessibility separately. While you may need some additional steps for accessibility, most of it fits nicely within what you're already doing. For example, instead of evaluating accessibility separately, integrate accessibility checks where they fit best within your current testing and quality assurance (QA) processes. That's just one example; integrating accessibility applies all the way through a project.<br />
<br />
This resource addresses how and where accessibility fits through the lifecycle of a web project.<br />
<br />
==Project Initiation Stage==<br />
The [http://www.w3.org/community/wai-engage/wiki/Accessibility_Responsibility_Breakdown#Project_management role of the Project Manager] is vital to the success of an accessible web project. At the very start, the Project Manager needs to ensure that every stakeholder understands their role and the requirements at every stage of the project (definition, planning, development, closure). <br />
<br />
In the initiation phase, there are several accessibility considerations that need to be addressed in the project document and which may require some research as regards legal requirements, the understanding of accessibility within the organization, the tools which are used and so forth.<br />
<br />
===Legal requirements===<br />
There may be legal requirements of the country which should be taken into consideration. Many organizations use WCAG as a target for accessibility. For example, an organization sets its target to meet WCAG 2.0 Level A and Level AA success criteria. Developing an accessibility policy is a good way to clarify and communicate your target.<br />
<br />
The following resources provide information on:<br />
* [http://www.w3.org/WAI/guid-tech.html Accessibility standards and guidelines] <br />
* [http://www.w3.org/WAI/Policy/Overview.html Policies relating to accessibility] <br />
* [http://www.w3.org/WAI/bcase/pol Legal and Policy Factors in Developing a Web Accessibility Business Case for Your Organization] <br />
<br />
At the same time, in order to enable continuity of the accessible site or application, an internal policy and an implementation plan should be developed. The following pages provide guidance on how to:<br />
* [http://www.w3.org/WAI/impl/pol Develop internal policies on accessibility]<br />
* [http://www.w3.org/WAI/impl/Overview.html Develop an Implementation Plan]<br />
<br />
===Discovery & Analysis===<br />
<br />
Some analysis is necessary in order to assess the level of accessibility within the organization. The authoring tools, the software specifications and the technical solutions should all be considered. A frequent cause of accessibility barriers is simply that web developers are not aware that they should make websites accessible. <br />
<br />
The following resources provide some guidance on the essential aspects pertinent to accessibility requirements gathering:<br />
<br />
* Evaluate the [http://www.w3.org/WAI/impl/software accessibility support in design and development tools] for the project<br />
* Assess the level of accessibility knowledge and if there is need to provide training<br />
* Ensure that everyone knows that accessibility is a requirement, in particular, stakeholders, even if an official policy is not yet available<br />
* Estimate resources required to address the needs identified in the initial assessment. Include software replacement, staff training, retrofitting of site, monitoring of site, etc., as needed.<br />
<br />
===Technical specifications===<br />
In drafting the technical specifications, once the standard and level of conformance is agreed upon, this will need to be documented in some or all of the following areas:<br />
<br />
* Software specifications<br />
* Design specifications<br />
* Functional design specifications<br />
* User acceptance criteria<br />
<br />
===Budget===<br />
Incorporating accessibility from the beginning of a website development or redesign process is almost always significantly easier, less expensive, and more effective than making accessibility improvements to an existing site later as a separate project. When accessibility is only addressed late in design, it can be very [http://www.w3.org/WAI/bcase/fin#decreasing costly to make required design changes]. Furthermore, [http://www.w3.org/WAI/impl/improving.html#retro retrofitting sites] can be a long process. Therefore, include accessibility into the budget at the start of the project.<br />
* Plan a budget and schedule to [http://www.w3.org/WAI/users/involving.html include people with disabilities] as collaborators in the project<br />
* Budget for testing accessibility in case resources are not available within the organization<br />
* Budget for training and/or hiring in order to develop accessibility knowledge and skills<br />
<br />
==Design Stage==<br />
<br />
Designers are responsible for the design and user interface of web pages. Specifications need to be identified early in the project to include conformance to accessibility. <br />
<br />
Evaluating early design prototypes helps to validate design aspects that work well, and find potential accessibility barriers while it is still relatively easy and inexpensive to fix them. <br />
<br />
In the [http://www.w3.org/community/wai-engage/wiki/Accessibility_By_Roles_-_Graphic_Design role of Web Designer], a number of tasks associated with quality control of the design, e.g. graphical and user interfaces, navigational elements, contextual changes and other general design elements of content pages are of relevance and should be checked for conformance.<br />
<br />
===Evaluate Accessible Design===<br />
Effective evaluation during the design period can include:<br />
<br />
* Establishing clear requirements for the expected accessibility conformance level<br />
* Involvement in initial planning meetings for the site<br />
* Agreeing on a review schedule during the development process<br />
* Providing information on evaluation approaches so that the developers can at least do preliminary reviews on their own<br />
<br />
===Initial Mock-ups===<br />
Even before coding begins, wireframes or visual mock-ups can be evaluated through early screening by performing checks on<br />
* information architecture<br />
* color scheme<br />
* contrast of colors<br />
<br />
At this early stage, accessible design elements can be built into the project and stakeholders will understand from the start where and why changes are introduced.<br />
<br />
===Content Creation===<br />
Content which is easily understood and available to persons with disabilities is a fundamental aspect of web accessibility. Accessible content requires little effort and increases usability at large. Websites and web tools that are designed for people with a broad range of abilities will benefit everyone, including people without disabilities.<br />
<br />
If content is created with accessibility in mind, all users will be included, for example,<br />
<br />
* if audio content, such as videos with voices and sounds, contain captions or transcripts, this will enable people with auditory disabilities to access the information<br />
* if navigation mechanisms and page layouts are simple, they are much easier to understand and use by persons with cognitive disabilities<br />
* if sufficient time is given to respond or to complete a task, such as to fill out an online form, this will ensure that persons with physical disabilities are not time-barred<br />
* if websites offer alternative means of communication, such as including e-mail and feedback forms, this will ensure that persons with speech disabilities are not confined to contact by phone and can, therefore, interact<br />
* if text, images, and page layouts can be resized, this will ensure that persons with visual impairment can also benefit and access the information<br />
<br />
[http://www.w3.org/WAI/intro/people-use-web/diversity Diversity of web users] describes the types of disabilities, situations, problems and remedies to making content accessible.<br />
<br />
== Development Stage ==<br />
<br />
The implementation is the last part of the process of building a site or application, but that does not mean that developers should not be involved early. They often have a broad knowledge of usability and accessibility issues as everything from the product owner's and content writer's requirements to the user experience designer's vision of the product are filtered through them.<br />
<br />
Make sure to use developers to spot issues that would normally only be caught at the development stage as early as possible.<br />
<br />
=== Pre-Development Checklist ===<br />
<br />
Checklists often work well for the developer mindset, and can be checked at the product requirements and design stage.<br />
<br />
<span style="color: #808080;">{I think this is too specific and we don't want to be this prescriptive &mdash;Shawn}</span><br />
Ensure requirements specify:<br />
* exact foreground and background colours<br />
* tab order<br />
* focus handling<br />
* focus styles<br />
* alt text for images<br />
* additional hidden content for AT where required<br />
* placeholder / summary / title text where required<br />
* error message text and placement where required<br />
* simple /clear text in buttons, titles and content<br />
[Create list from the various sources we have gathered]<br />
<br />
=== The Development Cycle ===<br />
<br />
<span style="color: #808080;">{This section needs editing to be less specific and prescriptive. Could present the steps as an example.}</span><br />
<br />
The development stage can make or break the accessibility of a project. A good development workflow with a focus on accessibility can find problems before the QA phase, or worse, before the users find them.<br />
<br />
Not all of these steps need to followed on every iteration or for every feature, but all of the testing points should be hit at least once for each release.<br />
<br />
* Markup content<br />
* Test simple keyboard (tab and return keys) interaction without CSS<br />
* Add CSS<br />
* Test with text increase 200%<br />
* Test with screen reader / keyboard<br />
* Add JavaScript enhancement<br />
* Test with screen reader / keyboard<br />
* Re-factor and repeat<br />
<br />
===Quality Plan===<br />
Iteratively test for accessibility throughout the development process.<br />
* Include accessibility testing stages in the quality assurance plan<br />
** Web Accessibility Preliminary Evaluation provides detailed guidance on how to check accessibility<br />
** Consider developing a Compliance Matrix<br />
Whilst accessibility evaluation is peformed with a combination of tools, services and experts, there are many benefits to evaluating with real people to learn how your website or web tool really works and to better understand accessibility issues. <br />
* [http://www.w3.org/WAI/eval/users.html Evaluating with users with disabilities] and with older users identifies usability issues that are not discovered by conformance evaluation alone. <br />
* [http://www.w3.org/WAI/users/involving#why Involving users early in web projects ensures better and easier accessibility]<br />
* [http://www.w3.org/WAI/users/involving Involving users with disabilities and having accessibility specialists evaluate] in planned repairs can catch any problems before they are propagated throughout your site.<br />
<br />
Including users throughout the development process to complete sample tasks on prototypes can assist in understanding how the different aspects of the design and coding can be improved.<br />
<br />
==Project Closure==<br />
In the project sign-off, include the sign-off for accessibility conformance and celebrate this as an achievement in the project launch.<br />
<br />
Document the lessons learned in implementing accessibility. This can be a very useful source of information in the post project phase and for other projects within the Organization.<br />
<br />
==Post Project==<br />
In order to maintain a level of conformance, a post project plan should be in place to ensure that<br />
<br />
* regular checks are performed for continued accessibility<br />
* all aspects of implementation plan for effectiveness are periodically reviewed<br />
* new barriers are not introduced when redesigns or updates are planned<br />
* accessibility knowledge of staff is a continued requirement (offer repeated training opportunities as staff and responsibilities change)<br />
<br />
==More Information==<br />
{@@link to some of the resources listed under [[#Current_related_WAI_information]] ?}<br />
<br />
<br /><hr /><hr /><br />
<br />
=Analysis & Notes=<br />
<br />
'''''Comment template:''''' @@ comment <span style="color: #808080;">{name}</span><br />
<br />
==Open issues==<br />
<br />
...comment <span style="color: #808080;">{name}</span><br />
<br />
Open question: In the "Introduction", second paragraph, I would like to suggest removing the following sentences:<br />
<br />
"As an example, consider a building that is architecturally planned for accessibility from the beginning and has a wheelchair-accessible entrance that fits with the building design aesthetically and practically. Compare that to a building with a ramp added on after the building was already designed and the ramp looks awkward and is less useful to all."<br />
<br />
I think a shorter introduction with focus on guidance in the framework of a web project is more likely to grasp attention.<br />
<span style="color: #808080;">{Vicki}</span><br />
<br />
<br />
===[closed] Do we want to develop a new document, or do existing documents cover it sufficiently?===<br />
Decision: Develop new document.<br />
<br />
[[#Current_related_WAI_information|Existing documents listed below]] <br />
<ul><br />
<li>A new document that integrates key points from all of the others would be useful. However, it will only be so if we can keep it focused and quite clear. <span style="color: #808080;">{Sharron}</span></li><br />
<li>Agree with the above approach of Sharron<span style="color: #808080;">{Vicki}</span></li><br />
<li>...comment <span style="color: #808080;">{name}</span></li><br />
</ul><br />
<br />
===[closed] If new document, what should be the scope?===<br />
Decision: Broad scope - accessibility early & throughout.<br />
<br />
Should it focus only on evaluation throughout design & development process, or more broadly addressing including accessibility from early and throughout in all projects?<br />
<ul><br />
<li>A comprehensive approach seems best to me, but we should be conscious (and vigilant) about length and scope creep. <span style="color: #808080;">{Sharron}</span></li><br />
<li>A broad approach addressing where accessibility fits through the project, i.e., at the start, during, after but careful about length and style. It should act as guidance to the valuable other information already available.<span style="color: #808080;">{Vicki}</span></li><br />
<li>...comment <span style="color: #808080;">{name}</span></li><br />
</ul><br />
<br />
===[closed] If new document, how long and how detailed?===<br />
Decision: Keep as short. Not detailed. Link to existing material elsewhere, or that might developed elsewhere.<br />
<br />
Would we just give general guidance, or would we include specific steps and tasks that apply broadly?<br />
<ul><br />
<li>I like the tendency that I am seeing in relating the content here to the roles that were developed earlier this year. I would caution against too much specificity unless we also commit to a schedule of updates and revisions to keep the information current and accurate<span style="color: #808080;">{Sharron}</span></li><br />
<li>Not a lengthy document, if possible. Keep it to the point and reference to the other valuable information already available under WAI. Later, once webplatform docs has some tips and trick, especially under "Development Stage", we could link there<span style="color: #808080;">{Vicki}</span></li><br />
<li>...comment <span style="color: #808080;">{name}</span></li><br />
</ul><br />
<br />
===If new document, what would we do with the current related material in other documents?===<br />
<span style="background:yellow;">OPEN: Need to look more closely at the content of this new page and the content that we currently have elsewhere to decide what to do with it.</span><br />
<br />
[[#Current_related_WAI_information|current related material in other documents listed below]]<br /><br />
Would some of the information in other documents move to this page, and we would delete it on those pages and point to it here? Or would it be handle differently?<br />
<ul><br />
<li>My tendency is to integrate and reduce the number of documents, but related documents will have to be reviewed and decided as this one develops.<span style="color: #808080;">{Sharron}</span></li><br />
<li>Where information in other documents is particularly relevant, introduce passages (with some minor modifications) into this document and point to the other relevant documents through links within the text. I wouldn't do away with the other documents unless something is totally out of date.<span style="color: #808080;">{Vicki}</span></li><br />
</ul><br />
<br />
==Purpose==<br />
* Convince readers of the benefits of addressing accessibility early and throughout the design & development process -- and provide them guidance<br />
* Have a place to point to from WCAG-EM (and other docs that talk about evaluating existing sites) that says do it early & do it often<br />
See also [[Eval Analysis]] for use cases for this and related documents<br />
<br />
==Current related WAI information==<br />
<br />
* [http://www.w3.org/WAI/users/involving Involving Users in Web Projects for Better, Easier Accessibility]<br />
** includes section on How Involving Users Early Helps<br />
<br />
* [http://www.w3.org/WAI/eval/users.html Involving Users in Evaluating Web Accessibility]<br />
** says things like "including them throughout the development process to complete sample tasks on prototypes so you can see how the different aspects of the design and coding could be improved"<br />
** @@/DONE/There's a pointer under "Quality Plan" to the above link. I could expand on the wording as suggested.<span style="color: #808080;">{Vicki}</span><br />
<br />
* [http://www.w3.org/WAI/impl/improving.html Improving the Accessibility of Your Website]<br />
** includes sections on Evaluating to Identify the Issues, Optimizing Your Retrofitting, Prioritizing the Repairs<br />
** @@DONE/Yes - some points especially from "Clarifying requirements" (could be used 'Discovery & Analysis', /DONE/ "Validating solutions" (second paragraph could be inserted under 'Quality Plan', /DONE/ "Next: Strategic Planning" (parts could be used under "Legal requirements") (<span style="color: #808080;">{Vicki}</span><br />
**@@DONE/Under "Setting the target", the first paragraph could be used under "Legal requirements" and the first sentence of the last paragraph of this section (<span style="color: #808080;">{Vicki}</span><br />
<br />
* [http://www.w3.org/WAI/impl/Overview.html Implementation Plan for Web Accessibility]<br />
** Has sections on [http://www.w3.org/WAI/impl/Overview.html#assess Conduct Initial Assessment] and [http://www.w3.org/WAI/impl/Overview.html#develop Develop Accessible Website]<br />
** Is from 2002 - iss it still point-to-able, or too old? how much work to update it?<br />
** @@Also interesting points under "Develop Accessible Website" which could possibly go under "Development stage" with some minor modifications (<span style="color: #808080;">{Vicki}</span> <br />
** @@DONE/A paragraph to close with the points from "Monitor Website Accessibility" could be added at the end of this document(<span style="color: #808080;">{Vicki}</span> <br />
** @@There's good stuff there. I could try to integrate /DONE/some points briefly into this document. Wouldn't move anything out of the original since I think it is all still quite relevant. Perhaps, some minor updating but the document is a very good source of information for anyone starting out.<span style="color: #808080;">{Vicki}</span><br />
<br />
* [http://www.w3.org/WAI/bcase/fin#decreasing B-Case, Financial Factors, Decreasing Costs]<br />
** has section on "Incorporating accessibility from the beginning"<br />
** @@DONE/Yes, this sentence can be slightly modified and added under Budget <span style="color: #808080;">{Vicki}</span><br />
** @@Interesting paragraph to add under "Design" on "Addressing accessibility and mobile together" <span style="color: #808080;">{Vicki}</span><br />
<br />
* [http://www.w3.org/WAI/users/ Designing for Inclusion]<br />
** doesn't have info on design process, but some people might come looking here for it; therefore, we might want to add pointers to related information in the "See also" sections<br />
<br />
''([http://www.w3.org/WAI/EO/changelogs/outreach.html Outreach Planning page] has info on dated-ness of some docs.)''<br />
<br />
===other inputs===<br />
* Text EOWG is welcome to use:<br />
** [http://uiaccess.com/accessucd/early.html Incorporating Accessibility Early and Throughout]<br />
** [http://uiaccess.com/accessucd/design.html#eval Evaluate Throughout Design]<br />
** [http://uiaccess.com/accessucd/evaluate.html Evaluating for Accessibility], e.g., [http://uiaccess.com/accessucd/evaluate.html#walkthroughs Design Walkthroughs]<br />
* [http://lists.w3.org/Archives/Public/public-wai-evaltf/2012Oct/0052.html email from Phill Jenkins includes some considerations early]<br />
** more: Yes, please add in some specifics about doing a design review and for accessibility prior to development of running or prototype code.<br/>Seems you have a step already listed:<br/>Design specification: We want an independent assessment of high level objects during early stage design planning. We can provide sample use cases, early page mock-ups, wireframes and simple prototypes.<br/>The other step is a "review of the technology choices" for accessibility support for the new/redesigned site. Such as user interface components (UI widgits) from jQuery, DoJo, and other JavaScript libraries and embedded video playersfor example that do (or don't) a good job of supporting accessibility. <br />
* [http://www-03.ibm.com/able/education/downloads/CostSavingsofEarlyAccessibility-CSUN-2012_accessible_IBM.pdf Cost Savings of Early Accessibility]<br />
* [http://www.standards-schmandards.com/2007/rapid-accessibility-feedback/ Bringing Accessibility into the Development Process]<br />
* [http://www.w3.org/community/wai-engage/wiki/Accessibility_Responsibility_Breakdown Accessibility_Responsibility_Breakdown] draft<br />
<br />
==Misc Notes==<br />
<br />
<ul><br />
<li style="padding-bottom:1em">@@ comment template <span style="color: #808080;">{name}</span></li><br />
</ul><br />
<br />
===Title ideas===<br />
<span style="color: #808080;">'''''summary''''' - Comment {name}</span><br />
<br />
* Review and Comments* {Wayne}<br />
This is excellent for the need: a high level overview of fully integrated accessibility at initial stages.<br />
<br />
I was confused by the sentence: "Some analysis is necessary in order to assess the level of accessibility within the organization." To what organizational entity does accessibility refer?<br />
<br />
I do think the check lists are essential, but I'm not sure how to address Shawn's issue with prescription. Perhaps these check lists need be introduced as a getting contrite phase of design. When you are at phase X you should consider issues like ... [check list]. It might be made clear that this list is neither exhaustive nor mandatory. However, omission of lists makes the document to abstract and vague.<br />
<br />
I don't understand refactor in this context. <br />
<br />
As far as a title goes I suggest: How Accessibility Planning Works.<br />
<br />
<br />
<br />
<br />
* Start with Accessibility<br />
** <span style="color: #808080;">'''''like''''' - "Start" is good - supports the idea that accessibility is fundamental and leads to innovation! might also get SEO for searches like "getting started with accessibility" {Shawn}</span><br />
<br />
* Build Accessibility Early into Web Projects<br />
** <span style="color: #808080;">'''''like'''''- kinda like "build into" {Shawn}</span><br />
** <span style="color: #808080;">'''''like'''''- because it sounds "solid" and "serious" and contains the words "web projects"{Vicki}</span><br />
<br />
* Integrating Accessibility in Your Web Project<br />
** <span style="color: #808080;">'''''like'''''- "integrating" is nice, saying it's not a separate thing {Shawn}</span><br />
** <span style="color: #808080;">'''''like'''''- like for the same previous reasons "solid", "serious", and also since the document (now) encompasses a project framework, I like the idea of having the words "web project" in the title. This would be my favorite {Vicki}</span><br />
<br />
* Accessibility Early in the Process<br />
** <span style="color: #808080;">@@'''''summary''''' - Comment {name}</span><br />
<br />
* Address Accessibility Early<br />
** <span style="color: #808080;">@@'''''summary''''' - Comment {name}</span><br />
<br />
* Early Accessibility<br />
** <span style="color: #808080;">'''''no''''' - this one doesn't do anything for me. {Shawn}</span><br />
<br />
* Accessibility Now<br />
** <span style="color: #808080;">@@'''''summary''''' - Comment {name}</span><br />
<br />
* Accessibility First<br />
** <span style="color: #808080;">@@'''''summary''''' - Comment {name}</span><br />
<br />
* Plan for Accessibility Early<br />
** <span style="color: #808080;">'''''caution''''' - Wonder if developers and designers would realize this applies to them, or think it's targeted to managers {Shawn}</span><br />
<br />
* Accessibility Early<br />
** <span style="color: #808080;">@@'''''summary''''' - Comment {name}</span><br />
<br />
* Accessibility in Development Early<br />
** <span style="color: #808080;">'''''caution''''' - maybe designers & content creators wouldn't think this applies to them? {Shawn}</span><br />
<br />
* Accessibility in Web Projects <br />
** <span style="color: #808080;">'''''caution''''' - maybe too broad {Shawn}</span><br />
** <span style="color: #808080;">'''''okay''''' - similar to previously mentioned, the focus being accessibility on projects {Shawn}</span><br />
<br />
* Accessibility Early, Accessibility Often (play off [http://en.wikipedia.org/wiki/Release_early,_release_often RERO])<br />
** <span style="color: #808080;">'''''caution''''' - probably most people won't get the RERO play. without that, I think "often" makes it sound like a lot of work {Shawn}</span><br />
<br />
==Acknowledgements==<br />
<br />
Thanks to:<br />
* Vicki Menezes Miller for significant drafting and editing of several sections<br />
* Ian Pouncey for editing and drafting some sections<br />
* Shawn Henry for working on the framework and commenting on drafts<br />
* Sharron Rush for commenting on open issues<br />
* Suzette Keith for some initial ideas<br />
<br />
__NOINDEX__</div>Wdickhttps://www.w3.org/WAI/EO/wiki/index.php?title=Eval_in_process&diff=2643Eval in process2012-12-14T04:48:29Z<p>Wdick: /* Misc Notes */</p>
<hr />
<div>Nav: [[Main Page|EOWG wiki main page]]<br />
<br />
__TOC__<br />
<br />
'''This page explores the possibility of providing additional guidance on evaluating early and throughout the design & development process -- or more broadly on including accessibility early.'''<br/><br />
[[#Analysis_&_Notes]] at the end of the page includes open issues.<br/><br />
Archived info from previous drafts is at [[Accessibility Early Archive]].<br />
<br />
=[Draft] Address Accessibility Early=<br />
<br />
==Introduction==<br />
<br />
Consider accessibility early and throughout the design process for seamless and elegant integration into web and application development projects. Incorporating accessibility from the start increases the positive impact of designing for a broad constituency while decreasing development costs associated with accessibility.<br />
<br />
Avoid situations in which accessibility is considered only at the end of the development process. This often results in awkward, "tacked on" accessibility features that are much less effective for people with disabilities and less beneficial overall. As an example, consider a building that is architecturally planned for accessibility from the beginning and has a wheelchair-accessible entrance that fits with the building design aesthetically and practically. Compare that to a building with a ramp added on after the building was already designed and the ramp looks awkward and is less useful to all. Incorporating accessibility from the beginning of a design project is significantly easier, more effective, and less expensive than waiting until later in the project.<br />
<br />
It is almost always better to integrate accessibility considerations throughout your existing processes, rather than addressing accessibility separately. While you may need some additional steps for accessibility, most of it fits nicely within what you're already doing. For example, instead of evaluating accessibility separately, integrate accessibility checks where they fit best within your current testing and quality assurance (QA) processes. That's just one example; integrating accessibility applies all the way through a project.<br />
<br />
This resource addresses how and where accessibility fits through the lifecycle of a web project.<br />
<br />
==Project Initiation Stage==<br />
The [http://www.w3.org/community/wai-engage/wiki/Accessibility_Responsibility_Breakdown#Project_management role of the Project Manager] is vital to the success of an accessible web project. At the very start, the Project Manager needs to ensure that every stakeholder understands their role and the requirements at every stage of the project (definition, planning, development, closure). <br />
<br />
In the initiation phase, there are several accessibility considerations that need to be addressed in the project document and which may require some research as regards legal requirements, the understanding of accessibility within the organization, the tools which are used and so forth.<br />
<br />
===Legal requirements===<br />
There may be legal requirements of the country which should be taken into consideration. Many organizations use WCAG as a target for accessibility. For example, an organization sets its target to meet WCAG 2.0 Level A and Level AA success criteria. Developing an accessibility policy is a good way to clarify and communicate your target.<br />
<br />
The following resources provide information on:<br />
* [http://www.w3.org/WAI/guid-tech.html Accessibility standards and guidelines] <br />
* [http://www.w3.org/WAI/Policy/Overview.html Policies relating to accessibility] <br />
* [http://www.w3.org/WAI/bcase/pol Legal and Policy Factors in Developing a Web Accessibility Business Case for Your Organization] <br />
<br />
At the same time, in order to enable continuity of the accessible site or application, an internal policy and an implementation plan should be developed. The following pages provide guidance on how to:<br />
* [http://www.w3.org/WAI/impl/pol Develop internal policies on accessibility]<br />
* [http://www.w3.org/WAI/impl/Overview.html Develop an Implementation Plan]<br />
<br />
===Discovery & Analysis===<br />
<br />
Some analysis is necessary in order to assess the level of accessibility within the organization. The authoring tools, the software specifications and the technical solutions should all be considered. A frequent cause of accessibility barriers is simply that web developers are not aware that they should make websites accessible. <br />
<br />
The following resources provide some guidance on the essential aspects pertinent to accessibility requirements gathering:<br />
<br />
* Evaluate the [http://www.w3.org/WAI/impl/software accessibility support in design and development tools] for the project<br />
* Assess the level of accessibility knowledge and if there is need to provide training<br />
* Ensure that everyone knows that accessibility is a requirement, in particular, stakeholders, even if an official policy is not yet available<br />
* Estimate resources required to address the needs identified in the initial assessment. Include software replacement, staff training, retrofitting of site, monitoring of site, etc., as needed.<br />
<br />
===Technical specifications===<br />
In drafting the technical specifications, once the standard and level of conformance is agreed upon, this will need to be documented in some or all of the following areas:<br />
<br />
* Software specifications<br />
* Design specifications<br />
* Functional design specifications<br />
* User acceptance criteria<br />
<br />
===Budget===<br />
Incorporating accessibility from the beginning of a website development or redesign process is almost always significantly easier, less expensive, and more effective than making accessibility improvements to an existing site later as a separate project. When accessibility is only addressed late in design, it can be very [http://www.w3.org/WAI/bcase/fin#decreasing costly to make required design changes]. Furthermore, [http://www.w3.org/WAI/impl/improving.html#retro retrofitting sites] can be a long process. Therefore, include accessibility into the budget at the start of the project.<br />
* Plan a budget and schedule to [http://www.w3.org/WAI/users/involving.html include people with disabilities] as collaborators in the project<br />
* Budget for testing accessibility in case resources are not available within the organization<br />
* Budget for training and/or hiring in order to develop accessibility knowledge and skills<br />
<br />
==Design Stage==<br />
<br />
Designers are responsible for the design and user interface of web pages. Specifications need to be identified early in the project to include conformance to accessibility. <br />
<br />
Evaluating early design prototypes helps to validate design aspects that work well, and find potential accessibility barriers while it is still relatively easy and inexpensive to fix them. <br />
<br />
In the [http://www.w3.org/community/wai-engage/wiki/Accessibility_By_Roles_-_Graphic_Design role of Web Designer], a number of tasks associated with quality control of the design, e.g. graphical and user interfaces, navigational elements, contextual changes and other general design elements of content pages are of relevance and should be checked for conformance.<br />
<br />
===Evaluate Accessible Design===<br />
Effective evaluation during the design period can include:<br />
<br />
* Establishing clear requirements for the expected accessibility conformance level<br />
* Involvement in initial planning meetings for the site<br />
* Agreeing on a review schedule during the development process<br />
* Providing information on evaluation approaches so that the developers can at least do preliminary reviews on their own<br />
<br />
===Initial Mock-ups===<br />
Even before coding begins, wireframes or visual mock-ups can be evaluated through early screening by performing checks on<br />
* information architecture<br />
* color scheme<br />
* contrast of colors<br />
<br />
At this early stage, accessible design elements can be built into the project and stakeholders will understand from the start where and why changes are introduced.<br />
<br />
===Content Creation===<br />
Content which is easily understood and available to persons with disabilities is a fundamental aspect of web accessibility. Accessible content requires little effort and increases usability at large. Websites and web tools that are designed for people with a broad range of abilities will benefit everyone, including people without disabilities.<br />
<br />
If content is created with accessibility in mind, all users will be included, for example,<br />
<br />
* if audio content, such as videos with voices and sounds, contain captions or transcripts, this will enable people with auditory disabilities to access the information<br />
* if navigation mechanisms and page layouts are simple, they are much easier to understand and use by persons with cognitive disabilities<br />
* if sufficient time is given to respond or to complete a task, such as to fill out an online form, this will ensure that persons with physical disabilities are not time-barred<br />
* if websites offer alternative means of communication, such as including e-mail and feedback forms, this will ensure that persons with speech disabilities are not confined to contact by phone and can, therefore, interact<br />
* if text, images, and page layouts can be resized, this will ensure that persons with visual impairment can also benefit and access the information<br />
<br />
[http://www.w3.org/WAI/intro/people-use-web/diversity Diversity of web users] describes the types of disabilities, situations, problems and remedies to making content accessible.<br />
<br />
== Development Stage ==<br />
<br />
The implementation is the last part of the process of building a site or application, but that does not mean that developers should not be involved early. They often have a broad knowledge of usability and accessibility issues as everything from the product owner's and content writer's requirements to the user experience designer's vision of the product are filtered through them.<br />
<br />
Make sure to use developers to spot issues that would normally only be caught at the development stage as early as possible.<br />
<br />
=== Pre-Development Checklist ===<br />
<br />
Checklists often work well for the developer mindset, and can be checked at the product requirements and design stage.<br />
<br />
<span style="color: #808080;">{I think this is too specific and we don't want to be this prescriptive &mdash;Shawn}</span><br />
Ensure requirements specify:<br />
* exact foreground and background colours<br />
* tab order<br />
* focus handling<br />
* focus styles<br />
* alt text for images<br />
* additional hidden content for AT where required<br />
* placeholder / summary / title text where required<br />
* error message text and placement where required<br />
* simple /clear text in buttons, titles and content<br />
[Create list from the various sources we have gathered]<br />
<br />
=== The Development Cycle ===<br />
<br />
<span style="color: #808080;">{This section needs editing to be less specific and prescriptive. Could present the steps as an example.}</span><br />
<br />
The development stage can make or break the accessibility of a project. A good development workflow with a focus on accessibility can find problems before the QA phase, or worse, before the users find them.<br />
<br />
Not all of these steps need to followed on every iteration or for every feature, but all of the testing points should be hit at least once for each release.<br />
<br />
* Markup content<br />
* Test simple keyboard (tab and return keys) interaction without CSS<br />
* Add CSS<br />
* Test with text increase 200%<br />
* Test with screen reader / keyboard<br />
* Add JavaScript enhancement<br />
* Test with screen reader / keyboard<br />
* Re-factor and repeat<br />
<br />
===Quality Plan===<br />
Iteratively test for accessibility throughout the development process.<br />
* Include accessibility testing stages in the quality assurance plan<br />
** Web Accessibility Preliminary Evaluation provides detailed guidance on how to check accessibility<br />
** Consider developing a Compliance Matrix<br />
Whilst accessibility evaluation is peformed with a combination of tools, services and experts, there are many benefits to evaluating with real people to learn how your website or web tool really works and to better understand accessibility issues. <br />
* [http://www.w3.org/WAI/eval/users.html Evaluating with users with disabilities] and with older users identifies usability issues that are not discovered by conformance evaluation alone. <br />
* [http://www.w3.org/WAI/users/involving#why Involving users early in web projects ensures better and easier accessibility]<br />
* [http://www.w3.org/WAI/users/involving Involving users with disabilities and having accessibility specialists evaluate] in planned repairs can catch any problems before they are propagated throughout your site.<br />
<br />
Including users throughout the development process to complete sample tasks on prototypes can assist in understanding how the different aspects of the design and coding can be improved.<br />
<br />
==Project Closure==<br />
In the project sign-off, include the sign-off for accessibility conformance and celebrate this as an achievement in the project launch.<br />
<br />
Document the lessons learned in implementing accessibility. This can be a very useful source of information in the post project phase and for other projects within the Organization.<br />
<br />
==Post Project==<br />
In order to maintain a level of conformance, a post project plan should be in place to ensure that<br />
<br />
* regular checks are performed for continued accessibility<br />
* all aspects of implementation plan for effectiveness are periodically reviewed<br />
* new barriers are not introduced when redesigns or updates are planned<br />
* accessibility knowledge of staff is a continued requirement (offer repeated training opportunities as staff and responsibilities change)<br />
<br />
==More Information==<br />
{@@link to some of the resources listed under [[#Current_related_WAI_information]] ?}<br />
<br />
<br /><hr /><hr /><br />
<br />
=Analysis & Notes=<br />
<br />
'''''Comment template:''''' @@ comment <span style="color: #808080;">{name}</span><br />
<br />
==Open issues==<br />
<br />
...comment <span style="color: #808080;">{name}</span><br />
<br />
Open question: In the "Introduction", second paragraph, I would like to suggest removing the following sentences:<br />
<br />
"As an example, consider a building that is architecturally planned for accessibility from the beginning and has a wheelchair-accessible entrance that fits with the building design aesthetically and practically. Compare that to a building with a ramp added on after the building was already designed and the ramp looks awkward and is less useful to all."<br />
<br />
I think a shorter introduction with focus on guidance in the framework of a web project is more likely to grasp attention.<br />
<span style="color: #808080;">{Vicki}</span><br />
<br />
<br />
===[closed] Do we want to develop a new document, or do existing documents cover it sufficiently?===<br />
Decision: Develop new document.<br />
<br />
[[#Current_related_WAI_information|Existing documents listed below]] <br />
<ul><br />
<li>A new document that integrates key points from all of the others would be useful. However, it will only be so if we can keep it focused and quite clear. <span style="color: #808080;">{Sharron}</span></li><br />
<li>Agree with the above approach of Sharron<span style="color: #808080;">{Vicki}</span></li><br />
<li>...comment <span style="color: #808080;">{name}</span></li><br />
</ul><br />
<br />
===[closed] If new document, what should be the scope?===<br />
Decision: Broad scope - accessibility early & throughout.<br />
<br />
Should it focus only on evaluation throughout design & development process, or more broadly addressing including accessibility from early and throughout in all projects?<br />
<ul><br />
<li>A comprehensive approach seems best to me, but we should be conscious (and vigilant) about length and scope creep. <span style="color: #808080;">{Sharron}</span></li><br />
<li>A broad approach addressing where accessibility fits through the project, i.e., at the start, during, after but careful about length and style. It should act as guidance to the valuable other information already available.<span style="color: #808080;">{Vicki}</span></li><br />
<li>...comment <span style="color: #808080;">{name}</span></li><br />
</ul><br />
<br />
===[closed] If new document, how long and how detailed?===<br />
Decision: Keep as short. Not detailed. Link to existing material elsewhere, or that might developed elsewhere.<br />
<br />
Would we just give general guidance, or would we include specific steps and tasks that apply broadly?<br />
<ul><br />
<li>I like the tendency that I am seeing in relating the content here to the roles that were developed earlier this year. I would caution against too much specificity unless we also commit to a schedule of updates and revisions to keep the information current and accurate<span style="color: #808080;">{Sharron}</span></li><br />
<li>Not a lengthy document, if possible. Keep it to the point and reference to the other valuable information already available under WAI. Later, once webplatform docs has some tips and trick, especially under "Development Stage", we could link there<span style="color: #808080;">{Vicki}</span></li><br />
<li>...comment <span style="color: #808080;">{name}</span></li><br />
</ul><br />
<br />
===If new document, what would we do with the current related material in other documents?===<br />
<span style="background:yellow;">OPEN: Need to look more closely at the content of this new page and the content that we currently have elsewhere to decide what to do with it.</span><br />
<br />
[[#Current_related_WAI_information|current related material in other documents listed below]]<br /><br />
Would some of the information in other documents move to this page, and we would delete it on those pages and point to it here? Or would it be handle differently?<br />
<ul><br />
<li>My tendency is to integrate and reduce the number of documents, but related documents will have to be reviewed and decided as this one develops.<span style="color: #808080;">{Sharron}</span></li><br />
<li>Where information in other documents is particularly relevant, introduce passages (with some minor modifications) into this document and point to the other relevant documents through links within the text. I wouldn't do away with the other documents unless something is totally out of date.<span style="color: #808080;">{Vicki}</span></li><br />
</ul><br />
<br />
==Purpose==<br />
* Convince readers of the benefits of addressing accessibility early and throughout the design & development process -- and provide them guidance<br />
* Have a place to point to from WCAG-EM (and other docs that talk about evaluating existing sites) that says do it early & do it often<br />
See also [[Eval Analysis]] for use cases for this and related documents<br />
<br />
==Current related WAI information==<br />
<br />
* [http://www.w3.org/WAI/users/involving Involving Users in Web Projects for Better, Easier Accessibility]<br />
** includes section on How Involving Users Early Helps<br />
<br />
* [http://www.w3.org/WAI/eval/users.html Involving Users in Evaluating Web Accessibility]<br />
** says things like "including them throughout the development process to complete sample tasks on prototypes so you can see how the different aspects of the design and coding could be improved"<br />
** @@/DONE/There's a pointer under "Quality Plan" to the above link. I could expand on the wording as suggested.<span style="color: #808080;">{Vicki}</span><br />
<br />
* [http://www.w3.org/WAI/impl/improving.html Improving the Accessibility of Your Website]<br />
** includes sections on Evaluating to Identify the Issues, Optimizing Your Retrofitting, Prioritizing the Repairs<br />
** @@DONE/Yes - some points especially from "Clarifying requirements" (could be used 'Discovery & Analysis', /DONE/ "Validating solutions" (second paragraph could be inserted under 'Quality Plan', /DONE/ "Next: Strategic Planning" (parts could be used under "Legal requirements") (<span style="color: #808080;">{Vicki}</span><br />
**@@DONE/Under "Setting the target", the first paragraph could be used under "Legal requirements" and the first sentence of the last paragraph of this section (<span style="color: #808080;">{Vicki}</span><br />
<br />
* [http://www.w3.org/WAI/impl/Overview.html Implementation Plan for Web Accessibility]<br />
** Has sections on [http://www.w3.org/WAI/impl/Overview.html#assess Conduct Initial Assessment] and [http://www.w3.org/WAI/impl/Overview.html#develop Develop Accessible Website]<br />
** Is from 2002 - iss it still point-to-able, or too old? how much work to update it?<br />
** @@Also interesting points under "Develop Accessible Website" which could possibly go under "Development stage" with some minor modifications (<span style="color: #808080;">{Vicki}</span> <br />
** @@DONE/A paragraph to close with the points from "Monitor Website Accessibility" could be added at the end of this document(<span style="color: #808080;">{Vicki}</span> <br />
** @@There's good stuff there. I could try to integrate /DONE/some points briefly into this document. Wouldn't move anything out of the original since I think it is all still quite relevant. Perhaps, some minor updating but the document is a very good source of information for anyone starting out.<span style="color: #808080;">{Vicki}</span><br />
<br />
* [http://www.w3.org/WAI/bcase/fin#decreasing B-Case, Financial Factors, Decreasing Costs]<br />
** has section on "Incorporating accessibility from the beginning"<br />
** @@DONE/Yes, this sentence can be slightly modified and added under Budget <span style="color: #808080;">{Vicki}</span><br />
** @@Interesting paragraph to add under "Design" on "Addressing accessibility and mobile together" <span style="color: #808080;">{Vicki}</span><br />
<br />
* [http://www.w3.org/WAI/users/ Designing for Inclusion]<br />
** doesn't have info on design process, but some people might come looking here for it; therefore, we might want to add pointers to related information in the "See also" sections<br />
<br />
''([http://www.w3.org/WAI/EO/changelogs/outreach.html Outreach Planning page] has info on dated-ness of some docs.)''<br />
<br />
===other inputs===<br />
* Text EOWG is welcome to use:<br />
** [http://uiaccess.com/accessucd/early.html Incorporating Accessibility Early and Throughout]<br />
** [http://uiaccess.com/accessucd/design.html#eval Evaluate Throughout Design]<br />
** [http://uiaccess.com/accessucd/evaluate.html Evaluating for Accessibility], e.g., [http://uiaccess.com/accessucd/evaluate.html#walkthroughs Design Walkthroughs]<br />
* [http://lists.w3.org/Archives/Public/public-wai-evaltf/2012Oct/0052.html email from Phill Jenkins includes some considerations early]<br />
** more: Yes, please add in some specifics about doing a design review and for accessibility prior to development of running or prototype code.<br/>Seems you have a step already listed:<br/>Design specification: We want an independent assessment of high level objects during early stage design planning. We can provide sample use cases, early page mock-ups, wireframes and simple prototypes.<br/>The other step is a "review of the technology choices" for accessibility support for the new/redesigned site. Such as user interface components (UI widgits) from jQuery, DoJo, and other JavaScript libraries and embedded video playersfor example that do (or don't) a good job of supporting accessibility. <br />
* [http://www-03.ibm.com/able/education/downloads/CostSavingsofEarlyAccessibility-CSUN-2012_accessible_IBM.pdf Cost Savings of Early Accessibility]<br />
* [http://www.standards-schmandards.com/2007/rapid-accessibility-feedback/ Bringing Accessibility into the Development Process]<br />
* [http://www.w3.org/community/wai-engage/wiki/Accessibility_Responsibility_Breakdown Accessibility_Responsibility_Breakdown] draft<br />
<br />
==Misc Notes==<br />
<br />
<ul><br />
<li style="padding-bottom:1em">@@ comment template <span style="color: #808080;">{name}</span></li><br />
</ul><br />
<br />
===Title ideas===<br />
<span style="color: #808080;">'''''summary''''' - Comment {name}</span><br />
<br />
* Review and Comments*<br />
This is excellent for the need: a high level overview of fully integrated accessibility at initial stages.<br />
<br />
I was confused by the sentence: "Some analysis is necessary in order to assess the level of accessibility within the organization." To what organizational entity does accessibility refer?<br />
<br />
I do think the check lists are essential, but I'm not sure how to address Shawn's issue with prescription. Perhaps these check lists need be introduced as a getting contrite phase of design. When you are at phase X you should consider issues like ... [check list]. It might be made clear that this list is neither exhaustive nor mandatory. However, omission of lists makes the document to abstract and vague.<br />
<br />
I don't understand refactor in this context. <br />
<br />
As far as a title goes I suggest: How Accessibility Planning Works.<br />
<br />
<br />
<br />
<br />
* Start with Accessibility<br />
** <span style="color: #808080;">'''''like''''' - "Start" is good - supports the idea that accessibility is fundamental and leads to innovation! might also get SEO for searches like "getting started with accessibility" {Shawn}</span><br />
<br />
* Build Accessibility Early into Web Projects<br />
** <span style="color: #808080;">'''''like'''''- kinda like "build into" {Shawn}</span><br />
** <span style="color: #808080;">'''''like'''''- because it sounds "solid" and "serious" and contains the words "web projects"{Vicki}</span><br />
<br />
* Integrating Accessibility in Your Web Project<br />
** <span style="color: #808080;">'''''like'''''- "integrating" is nice, saying it's not a separate thing {Shawn}</span><br />
** <span style="color: #808080;">'''''like'''''- like for the same previous reasons "solid", "serious", and also since the document (now) encompasses a project framework, I like the idea of having the words "web project" in the title. This would be my favorite {Vicki}</span><br />
<br />
* Accessibility Early in the Process<br />
** <span style="color: #808080;">@@'''''summary''''' - Comment {name}</span><br />
<br />
* Address Accessibility Early<br />
** <span style="color: #808080;">@@'''''summary''''' - Comment {name}</span><br />
<br />
* Early Accessibility<br />
** <span style="color: #808080;">'''''no''''' - this one doesn't do anything for me. {Shawn}</span><br />
<br />
* Accessibility Now<br />
** <span style="color: #808080;">@@'''''summary''''' - Comment {name}</span><br />
<br />
* Accessibility First<br />
** <span style="color: #808080;">@@'''''summary''''' - Comment {name}</span><br />
<br />
* Plan for Accessibility Early<br />
** <span style="color: #808080;">'''''caution''''' - Wonder if developers and designers would realize this applies to them, or think it's targeted to managers {Shawn}</span><br />
<br />
* Accessibility Early<br />
** <span style="color: #808080;">@@'''''summary''''' - Comment {name}</span><br />
<br />
* Accessibility in Development Early<br />
** <span style="color: #808080;">'''''caution''''' - maybe designers & content creators wouldn't think this applies to them? {Shawn}</span><br />
<br />
* Accessibility in Web Projects <br />
** <span style="color: #808080;">'''''caution''''' - maybe too broad {Shawn}</span><br />
** <span style="color: #808080;">'''''okay''''' - similar to previously mentioned, the focus being accessibility on projects {Shawn}</span><br />
<br />
* Accessibility Early, Accessibility Often (play off [http://en.wikipedia.org/wiki/Release_early,_release_often RERO])<br />
** <span style="color: #808080;">'''''caution''''' - probably most people won't get the RERO play. without that, I think "often" makes it sound like a lot of work {Shawn}</span><br />
<br />
==Acknowledgements==<br />
<br />
Thanks to:<br />
* Vicki Menezes Miller for significant drafting and editing of several sections<br />
* Ian Pouncey for editing and drafting some sections<br />
* Shawn Henry for working on the framework and commenting on drafts<br />
* Sharron Rush for commenting on open issues<br />
* Suzette Keith for some initial ideas<br />
<br />
__NOINDEX__</div>Wdickhttps://www.w3.org/WAI/EO/wiki/index.php?title=Web_Accessibility_Preliminary_Evaluation&diff=2350Web Accessibility Preliminary Evaluation2012-11-30T06:26:31Z<p>Wdick: /* Check usable without CSS, javascript [Wayne is drafting (though maybe not including this one)] */</p>
<hr />
<div>Nav: [[Main Page|EOWG wiki main page]] > [[Main_Page#Evaluation_pages | Evaluation Pages ]]<br/><br />
Old page on WAI website: [http://www.w3.org/WAI/eval/preliminary.html Prelim Eval]<br/><br />
<br />
Note:<br />
* '''A template for the check items is at the top of the [http://www.w3.org/WAI/EO/wiki/Talk:Web_Accessibility_Preliminary_Evaluation discussion tab].'''<br />
* For tasks, example user cases with audience, and focus for this and related documents, see the [[Eval Analysis]] page<br />
* For previous drafts and contributed material, see:<br />
** Old page with Denis' edits and Ian's input in [[Preliminary Eval - old notes]]<br />
** Extensive revisions and suggestions at [[Archived_Work_on_PreLimEval]]<br />
** From Wayne & Tom [[Prelim Eval input: Smart analysis simplified]]<br />
<br />
<span style="background:yellow;">'''''Important Note''''': For this draft we have some tool-specific guidance. However, there are potential issues with vendor-neutraility and we might need to address this a different way &mdash; for example, moving tool-specific guidance to WebPlatform Docs or the WAI-Engage wiki where people can easily add other tools.</span><br />
<br />
<br />
__TOC__<br />
<br />
<span style="background:yellow;">'''''Important Note''''': For this draft we have some tool-specific guidance. However, there are potential issues with vendor-neutraility and we might need to address this a different way &mdash; for example, moving tool-specific guidance to WebPlatform Docs or the WAI-Engage wiki where people can easily add other tools.</span><br />
<br />
=Preliminary Review|Evaluation: Checking the Accessibility of a Web Page=<br />
<br />
==Introduction==<br />
<p>Testing and evaluating a web site for accessibility may seem intimidating but it need not be. There are simple ways to check on some basic features that do not require special skills or tools beyond your browser controls. Here you will find two approaches to doing Preliminary Evaluation of your pages. The first is a Quick Check - a list of 5 things you can do in 5 minutes. The second, while not a full conformance validation of WCAG2 Guidelines, will help ensure basic accessibility across a broader range of issues. While the second can quickly determine if the most important elements of a web page can be used by most persons with disabilities, it also requires more knowledge of accessibility principles and a few testing tools.</p><br />
<br />
<p>... @@ first run on good BAD page to see what it should look like, then on the bad page ... </p><br />
<br />
==Quick Checks==<br />
<br />
<p>Here are 5 things you can do to quickly check for accessibility barriers on a web page:<br /><br />
<span style="color:#808080;">{EOWG note: Let's work on the longer section first, then decide what we can move up to the quick checks section later.</span></p><br />
#First thing.<br />
#Second thing.<br />
#Third thing. <br />
#Fourth thing. <br />
#Fifth thing.<br />
<br />
Once you have taken this quick dip you may be ready to dive a bit deeper. The next section provides more context and additional things you can do to check for accessibility barriers.<br />
<br />
==A Deeper Look==<br />
<p>If you are interested in a more comprehensive look at the page(s), here more tests that require a little more time, skills, and/or tools.</p><br />
<br />
<span style="color:#808080;">''{reminder: A template for the check draft items is at the top of the [http://www.w3.org/WAI/EO/wiki/Talk:Web_Accessibility_Preliminary_Evaluation discussion tab].}''</span><br />
<br />
===Check text descriptions for images [mostly drafted]===<br />
<span style="color:#808080;">EOWG notes - importance: HIGH.<br />
<br/> 5min: yes, at least the easy part.<br />
<br /> 15min: yes. might want additional checks here.</span><br />
<br />
<p>Text alternatives convey the purpose of an image or function to provide an equivalent user experience for a user who may not see the images. For instance, a text alternative for a search button is "search".<br />
====What to do====<br />
# Disable images in the browser<br />
# Turn off CSS in the browser<br />
# Use free checking tools to list the text alternatives (or lack of them) for all graphic elements<br />
# If content is multimedia, see also </p> <br />
====What to look for====<br />
<p>If the images are CSS (background images), visually inspect when CSS is disabled to ensure that no meaningful element is removed from the content</p><br />
<p>For content delivered as an HTML img element, examine the result and follow this decision tree. For each element of type img: <br />
* Is there an attribute of type alt?<br />
** No: Item fails, this check is complete.<br />
** Yes: Continue on<br />
* Is the image purely decorative? <br />
** No: Continue on<br />
** Yes: Verify that alt="". Test complete <br />
* Is image the only content of a link or form control? <br />
** No: Continue on<br />
** Yes: Verify that the alt attribute clearly communicates the destination of the link or action taken.<br />
* Is image link also present as link text nearby? <br />
** No: Continue on<br />
** Yes: ensure that image and text are both within one anchor tag and that alt="". Test complete. <br />
* Does image contain text? <br />
** No: Continue on <br />
** Yes: Is image text also available as real text nearby?<br />
*** No: Verify that the alt attribute echoes the onscreen text exactly. Test complete.<br />
*** Yes: Verify that alt="" Test complete.<br />
* Does the image contribute meaning to the current page or context? <br />
* No: Continue on<br />
* Yes: Is image a simple graphic or photo?<br />
** Yes: Verify that alt=“brief description of image meaning”. Also verify that brief description does NOT contain words like photo, image, picture, graphic, etc, unless intrinsic to the meaning. Test complete. <br />
** No: Is image visually complex (for example, a graph, chart, or other image of complex meaning)? <br />
*** Yes: Verify that alt=“brief description” AND that there is also an explanation of the full information as a caption, a data table, a long description, or a paragraph positioned off screen that provides equivalent meaning. Test complete.<br />
</p><br />
<br />
====References====<br />
* [http://www.w3.org/WAI/intro/people-use-web/principles#alternatives Text alternatives for non-text content section in Accessibility Principles]<br />
* [http://www.w3.org/TR/UNDERSTANDING-WCAG20/text-equiv-all.html Understanding Success Criteria 1.1.1] (LevelA)<br />
* [http://www.w3.org/WAI/demos/bad/before/annotated/home.html Examples of incorrect, missing, or inadequate alt text] from WAI's Before and After Demo<br />
<br />
====Notes====<br />
<ul><br />
<li>Text that is actually an image.</li><br />
<li>Important image should have alt text that provides adequate alternative of the image for people who cannot see it...</li><br />
<li>Image that doesn't convey important information...</li><br />
<li>@@ Some guidance on not saying things like "this is an image..." or "this is a link..."</li><br />
</ul><br />
<br />
===Check headings and other semantic structure [some parts drafted]===<br />
<span style="color:#808080;">EOWG notes - importance: HIGH.<br />
<br/> 5min: maybe. fairly easy to check if there are at least some headings.<br />
<br /> 15min: yes.</span><br />
<br />
... @@ brief summary of why & what to check for ...<br />
See also:<br />
* ? [http://www.w3.org/TR/2012/NOTE-WCAG20-TECHS-20120103/G141 G141 technique]<br />
* ? [http://www.w3.org/TR/2012/NOTE-WCAG20-TECHS-20120103/H42 H42 technique]<br />
<br />
What you're looking for: @@<br />
<ul><br />
<li>Does the page have any headings?</li><br />
<li>Are the things that look like headings that aren't marked up as heading?</li><br />
<li>Are there things that are marked up as headings that aren't really headings?</li><br />
</ul><br />
<br />
====Checking with WAVE====<br />
<ol><br />
<li>Open [http://wave.webaim.org/ WAVE]</li><br />
<li>Enter the web page:<br />
<ul><br />
<li>If the website is online: Enter a web site address and click the "WAVE the page!" button.</li><br />
<li>... Upload a file...</li><br />
<li>... Check HTML code...</li><br />
</ul></li><br />
<li>Check headings:<br />
<ul><br />
<li>...</li><br />
</ul></li><br />
<li>Check lists:<br />
<ul><br />
<li>...</li><br />
</ul></li><br />
</ol><br />
<br />
====Checking headings with HTML Validator====<br />
<ol><br />
<li> Open the [http://validator.w3.org/ W3C HTML Validator (The W3C Markup Validation Service)].</li><br />
<li>Select the appropriate tab and input the page:<br />
<ul><br />
<li>If the web page is online, leave the '''Validate by URI''' tab selected. <br />In the Address field, type the URI (e.g., www.w3.org).</li><br />
<li>If the web page is on your local computer, click the '''Validate by File Upload''' tab.<br />In the File field, select &quot;Choose...&quot; and find the file on your computer.</li><br />
<li>If you will paste the HTML code/markup, '''Validate by Direct Input''' tab.<br />Paste your HTML in the Enter the Markup to validate: field.</li><br />
</ul><br />
</li><br />
<li>Click the More Options link.</li><br />
<li>Select the Outline checkbox.</li><br />
<li>Click the Check button.</li><br />
<li>In the results page at the top, click the Outline link.</li><br />
<li>Compare the Document Outline to the visual rendering of the page. <ul><br />
<li>Are the things that look like headings listed in the Document Outline?</li><br />
<li>Are there things in the Document Outline that aren't really headings?<br /><br />
</li><br />
</ul></li><br />
</ol><br />
<br />
===Check keyboard access [mostly drafted]===<br />
<span style="color:#808080;">EOWG notes - importance: HIGH.<br />
<br/> 5min: maybe.<br />
<br /> 15min: yes.</span><br />
<br />
Many people do not use the mouse and rely on the keyboard to interact with the Web. This requires keyboard access to all functionality, including links, form controls, input, and other user interface components. <br />
====What To Do====<br />
* Click in the address bar, then put your mouse aside and don't use it. <br />
* Press the 'tab' key to move around the page.<br />
''(see also Forms)''<br />
<br />
''(see also Visible Focus)''<br />
====What To Look For====<br />
* Can you tab to all the elements, including links, form fields, buttons, and media player controls? Are there any actions you can't get to (e.g., if they are only available on mouse hover)?<br />
* Does the focus get stuck anywhere - that is, you can tab into a control but not out? (called a "keyboard trap")?<br />
* Does the order that items get focus make sense to sighted users? (e.g., you don't jump around the page out of order logically)<br />
* Can you tab right through to the bottom of the page and then resume again from the top? (e.g. you don't get stuck anywhere and can't move on)<br />
* If there is a drop-down box (for example, for navigating to a different page): If you tab into the drop-down box, can you use the down/up arrow keys to move through the options, and @@use 'tab' to the following item@@? (Make sure it doesn't automatically select the first item.)<br />
====References====<br />
* [http://www.w3.org/WAI/intro/people-use-web/principles#keyboard Functionality is available from a keyboard]<br />
* [http://www.w3.org/WAI/users/browsing#keyboard Browsing the Web by Keyboard] section in [http://www.w3.org/WAI/users/browsing Better Web Browsing: Tips for Customizing Your Computer]<br />
* Example: [http://www.w3.org/WAI/demos/bad/before/survey.html web page template that does not enable keyboard access] from the WAI Before and After Demo (BAD)<br />
====Notes====<br />
* Mac browsers by default only tab through forms, will need to turn on...<br />
* not work easily in Opera...<br />
* ...<br />
<br />
===Visible focus [mostly drafted]===<br />
<br />
<span style="color:#808080;">EOWG notes.<br />
<br/> 5min: probably not (unless merged with keyboard access)<br />
<br /> 15min: probably</span><br />
<br />
'''''NOTE: Should this be merged with the keyboard access?'''''<br />
<br />
<p>Use keyboard only navigation to ensure that a user who relies on the keyboard will be able to know which element among multiple elements has the keyboard focus. This is an important element in facilitating success for keyboard users to operate the page, by letting them visually determine the component on which keyboard operations will interact at any point in time. People with attention limitations, short term memory limitations, or limitations in executive processes benefit by being able to discover where the focus is located.</p><br />
<br />
====What to do====<br />
# Use the keyboard to set the focus to all focusable elements on the page.<br />
<br />
====What to look for====<br />
# Visually examine progress through elements and verify that the focus indicator is visible.<br />
# Common failures occur when the default focus indicator is turned off in CSS or when the element is styled with borders that occlude the focus indicator.<br />
# Verify that any visual changes that occur with mouse hover also are triggered with keyboard focus<br />
<br />
====References====<br />
* [http://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-focus-visible.html Focus Visible - Understanding Success Criteria 2.4.7 (Level A)] <br />
* <span style="color:#808080;">[Found no relevant BAD example, Shadi is checking]</span><br />
* <span style="color:#808080;">[nothing specific in Accessibility Requirements page]</span><br />
<br />
===Check the page title [mostly drafted]===<br />
<span style="color:#808080;">EOWG notes - importance: medium.<br />
<br/> 5min: maybe not. it is easy to check, but a little more complicated to explain what makes a good title. Also not the most vital to lots of users.<br />
<br /> 15min: probably.</span><br />
<br />
@@ add image showing only a few words with multiple tabs in browser...<br />
<br />
Page titles are the first information read by a screen reader; useful for when users have multiple web pages opens, e.g., on different tabs and go between different windows. (Also good for adding to bookmarks & also search engine results.) <br />
<br />
====What to do====<br />
# Look at the browser's window title bar.<br />
# Look at titles of other pages within the site.<br />
<br />
====What to look for====<br />
* Verify that the title indicates the specific page and website and distinguishes the current page from others in the set of pages.<br />
* Make sure that every page in the site does not have the same title.<br />
* Check that the specific page title is listed BEFORE the name of the website. (for example, ''About Us - Our Long Web Site Name'')<br />
<br />
====References====<br />
* [http://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-title.html Page Titled- Understanding SC 2.4.2]<br />
* Consider if the page titles of all of the [http://www.w3.org/WAI/demos/bad/Overview.html Before and After Demo] had been the same. Instead, each has a distinctive name that identifies its function within the set of pages.<br />
====Notes====<br />
* Some browsers don't show title in browser title bar (Chrome, IE)<br />
<br />
===Check link text [partly drafted]===<br />
<span style="color:#808080;">EOWG notes.<br />
<br/> 5min: maybe not.<br />
<br /> 15min: maybe. fairly easy to check. not the most vital for lots of users.</span><br />
<br />
Wording the text that is linked to indicate clearly where the link goes or what the link does. Some people use a list of links where they don't see the text around it. See also:<br />
* [http://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-refs.html Link Purpose (In Context): Understanding SC 2.4.4] (Level A)<br />
* [http://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-link.html Link Purpose (Link Only): Understanding SC 2.4.9] (Level AAA)<br />
* [BAD]<br />
<br />
Check this<br />
* @@<br />
** @@<br />
<br />
Common failures:<br />
* Link text is something like "Click here" or "More" without any additional clarifying text.<br />
<br />
Notes:<br />
* List links (Can't find this in regular Firefox but easy in Opera where you can get a list of links from the standard tools menu, showing both title and url)<br />
* Issue - titles... ([http://ianpouncey.com/weblog/2010/01/title-attributes/ Ian P says never use titles on links], Sylvie agrees.)<br />
<br />
===Check usable with page zoomed and text enlarged [Suzette drafted for discussion]===<br />
<span style="color:#808080;">EOWG notes.<br />
<br/> 5min: no<br />
<br /> 15min: maybe not.</span><br />
* Zoom to 200%<br />
* Text-only enlargement... (e.g., text actually changes in IE)<br />
<br />
People with mild to moderate visual impairments may need to enlarge text in order to read it, or read it without straining. This simple requirement is mostly achieved by the functionality of the browser and ensuring that the page design supports that functionality. <br />
<br />
The text should be resizable up to 200% without losing information, using a standard browse. Additionally any images of text should also be resizable or replaced with actual text. <br />
<br />
Most modern browsers now offer a zoom function which enlarges both text and other content together. Some older browsers do not resize text if it was set using fixed units – such as points or pixels. <br />
<br />
====What to do====<br />
* Open your preferred browsers. Internet Explorer, Firefox, Chrome and Opera all offer zoom as a function of View or Function menus, or as a keyboard shortcut (usually, Control +, or for Mac Command +). <br />
* Set the screen window to full width<br />
* Use the zoom function or keyboard shortcut repeatedly to step up to a 200% increase. <br />
* Look at the main content, buttons, tabs and text entry fields and field labels.<br />
* Repeat with a different browser.<br />
====Common failures====<br />
* Is the default body text unusually small?<br />
* Does the main heading and body text increase in size? <br />
* Has any text that is part of a control, button, menu item or label increased in size? <br />
* Does any text overflow its space – for example, the text is too big for the button or menu tab, or width or depth of the column?<br />
* Can you read to the end of the line, or does some text disappear off the screen so that you have to scroll right to the end of the line?<br />
=====Note=====<br />
Some browsers can expand the text beyond 200% - this is not covered by the resize requirement as it is recognised that this will cause some of the failures described. It is also accepted that some horizontal scrolling may be necessary but see also 1.4.8 which is a AAA requirement. <br />
Users with more severe visual impairments who need larger text are likely to use screen magnifiers to increase text size above 200%. <br />
====References====<br />
*link to {appropriate section in Accessibility Requirements page http://www.w3.org/WAI/intro/people-use-web/principles#distinguishable} (doesn’t have a lot to say)<br />
*Guideline 1.4 Distinguishable: Make it easier for users to see and hear content including separating foreground from background. <br />
*Resize text: Understanding Success Criteria 1.4.4 (Level AA) {http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-scale.html}<br />
*Images of Text: Understanding Success Criteria 1.4.5 (Level AA) http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-text-presentation.html<br />
*Visual Presentation: Understanding Success Criteria 1.4.8 (Level AAA)http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-visual-presentation.html<br />
*link to {BAD example} No specific BAD examples – some reference to Text as image in relation to the phone number, and column width.<br />
<br />
====Notes for discussion====<br />
*Scrolling: see Visual Presentation: Understanding Success Criteria 1.4.8 (Level AAA) includes:<br />
** Text can be resized without assistive technology up to 200 percent in a way that does not require the user to scroll horizontally to read a line of text on a full-screen window.<br />
*Do we need to spell out the difference between zooming and resizing? Is resizing still important for people who use style sheets?<br />
*Do we still need to worry about IE6 which didn’t resize fixed font sizes?<br />
*Browsers are now hiding their menus – eg under the cogwheel icon, which is making it harder to know where to find the zoom option, however they seem to be reasonably consistent on keyboard shortcuts. Other options include pinch and zoom on trackpad or intellimouse<br />
<br />
===Check color contrast [Suzette is drafting]===<br />
<span style="color:#808080;">EOWG notes.<br />
<br/> 5min: maybe.<br />
<br /> 15min: yes.</span><br />
<br />
First pass - I'm working on this:<br />
<br />
Good colour contrast between the text and background is very important to people with visual impairements. Some users may chose to vary your colour choice by using their own preferred style sheet. <br />
<br />
Screen reader users will hear the text even if the contrast is poor, or deliberately hidden as white on white or black on black!<br />
<br />
* First stage - look out for instances of pale text that might blend into the background eg grey on the default off-white background. Other common combinations are pale green, yellow or blue text on a background of a slightly darker shade of the same colour. Check the text in the main content, menu tabs, links and selected links and in buttons, labels and captions. Any suspect instances need to be investigated. <br />
<br />
Remember that not all users will have high resolution screens and subtle colour combinations may not be rendered properly if the user is using a reduced colour set.<br />
<br />
* Second stage - a number of on-line tools can be used to compare the exact ratio of text and background. Use zoom to increase the font size and follow the tool instructions to pick up a sample of the text colour and a sample of the background colour. If the background is patterned take a sample at different points. The minimum contrast (level AA) is 4.5:1<br />
<insert from Wayne Dick><br />
<p> There are two types of color contrast testers: The first type, a<br />
lexical evaluator, looks at styles in web page code and<br />
computes color contrasts based on coded values. The second type,<br />
run time tester, simply allows the user to sample what is on the<br />
screen and computes contrast based on samples. </p><br />
<p> The lexical evaluator examines what the author declares. It<br />
gives a full page report based color contrasts declared by the<br />
programmer. These tests are quick and efficient. They break down<br />
when run time values change due to actions taken by active<br />
content.</p><br />
<p> The run time tester requires more hands on work. The evaluator<br />
can take samples as the web site runs and determine actual<br />
contrasts. The problem here is that as contrasts change over time<br />
the tester must sample many states of the page. </p><br />
<p> Both types of test are important. If any active content changes<br />
color during run time then WAI advises run time testing. Lexical<br />
testing can be very useful and save time with items with static <br />
color. </p><br />
<br />
<end Wayne's insert><br />
Ref: Contrast (minimum) 1.4.3 http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-contrast.html <br />
<br />
also Contrast (enhanced) 1.4.6 <br />
Note: There are some exceptions and special requirements to achieve full conformance.<br />
<br />
===Check color coding and shape coding [Suzette draft]===<br />
<span style="color:#808080;">EOWG notes.<br />
<br/> 5min: no<br />
<br /> 15min: maybe not. not easy to check thoroughly. not vital for many users.</span><br />
<br />
[Notes: refers specifically to: '''1.4.1 Use of Color''': Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.<br />
<br />
NB. consider if other sensory characteristics [such as shape, size, visual location, orientation, or sound] sould be combined here. See '''1.3.3 Sensory Characteristics''': Instructions provided for understanding and operating content do not rely solely on sensory characteristics of components such as shape, size, visual location, orientation, or sound.]<br />
<br />
Colour, shape and location are often used as a code or visual cue to help people to identify important information or actions on a busy web page. <br />
<br />
These visual cues are not always available – someone who is colour blind may find it difficult to distinguish some or all colour combinations. And in addition, people using some types of assistive technology such as a screen reader, Braille or other alternative display systems will not ‘see’ the cue.<br />
<br />
It helps to use both colour and a symbol together – for example a red asterisk, provides both a colour and shape code. Alt text on any symbols or icons should make the functional meaning obvious. Any text instructions should allow for someone who cannot see the visual cue. <br />
<br />
====What to do====<br />
Inspect the page carefully to identify any instances of visual cues:<br />
* Colour - either coloured text or tinted backgrounds and including in-text links.<br />
* Shape - including icons and symbols, and glyphs such as a smiley face or no entry symbol, or a graphic X to draw attention to removing an item in a shopping list.<br />
* Location - positioning a symbol or instruction at the top, bottom or side of the main text<br />
* Text descriptions or instructions - inspect the text for instructions that refer to colour, shape or location such as the button on the left, or the red square.<br />
<br />
====Common failures====<br />
* In a form, colour used to indicate a required field, or as part of an error messages when a required field is not completed and there is no additional cue such as a colour coded symbol?<br />
* Text links - colour used alone to indicate links in a paragraph of text, and, there is no additional cue such as underlining?<br />
* Text instructions, the instruction does not make sense if you can't see the colour, shape or the location of a control button described.<br />
* Providing alternative text for symbols and icons - in general these need to refer to the function and not the visual appearance. For example if ‘red square’ is the button for the function ‘stop’, then the alt text should say ‘stop’ and not 'red square'. <br />
<br />
====References====<br />
Use of colour: Understanding success criteria 1.4.1 (Level A) {http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-without-color.html}<br />
<br />
Sensory Characteristics: Understanding success criteria 1.3.3 (Level A) { http://www.w3.org/TR/UNDERSTANDING-WCAG20/content-structure-separation-understanding.html}<br />
<br />
See also: Non-text equivalent 1.1.1 (A) for appropriate text equivalents for any symbols, icons or glyphs and Contrast 1.4.3 (AA) for colour contrast.<br />
<br />
====Notes for discussion====<br />
I put colour, shape and location together because functionally they are about visual coding – is this too big a step?<br />
<br />
Also - should the common failures be descriptive, suggest a solution or ask a question? I got a bit confused here :(<br />
<br />
===Content order [open for drafting]===<br />
<span style="color:#808080;">EOWG notes.<br />
<br/> 5min: no.<br />
<br /> 15min: maybe. </span><br />
<br />
'''''NOTE: Should this be merged with the keyboard access check?'''''<br />
<br />
===Video, Sound, (multimedia) [partly drafted]===<br />
<span style="color:#808080;">EOWG notes.<br />
<br/> 5min: maybe. vital for some uses, through maybe not really easy to check thoroughly<br />
<br /> 15min: yes.</span><br />
<br />
====What to do====<br />
# Play the audio content<br />
# Play the video content<br />
# Toggle closed captions on (if available) <br />
# Toggle audio description on (if available) <br />
====What to look for====<br />
* Captions:<br />
** Verify that they synchronized to the spoken content<br />
** Ensure they are accurate and complete (not missing any content)?<br />
** Verify that they are properly formed? (correct spelling, sentence structure, punctuation)<br />
** Make sure that audio content other than dialogue is inlcuded (music, relevant ambient sounds, etc)<br />
* Audio Description<br />
** '''(Judgement call)''' Watch the video content to verify that audio description is needed for complete understanding.<br />
** If needed, verify that they are provided in a separate track that can be toggled on and that they provide context for those who do not see the video.<br />
* Transcript: As a fall-back when captions and audio descriptions are not provided, check to see if there is text-based content that contains dialogue, any other audio content, and any necessary description of video content. Check for spelling and accuracy. <br />
''(see also keyboard access for player controls)''<br />
<br />
''(see also text alternatives for graphic content)''<br />
<br />
====References====<br />
* [http://www.w3.org/2008/06/video-notes Multi Media FAQs] from the W3C<br />
* [http://www.w3.org/TR/UNDERSTANDING-WCAG20/media-equiv-captions.html Understanding WCAG SC 1.2.2 Captions](Level A)<br />
* [http://www.w3.org/TR/UNDERSTANDING-WCAG20/media-equiv-audio-desc.html Understanding 1.2.5 Audio Description](Level A) <br />
====Notes====<br />
<span style="color:#808080;">[can be internal notes for now or maybe will be included in final doc]</span><br />
*...<br />
<br />
===Forms (mostly drafted, need review)===<br />
<span style="color:#808080;">EOWG notes.<br />
<br/> 5min: no, too complicated.<br />
<br /> 15min: not sure (need to see it drafted first :-)</span><br />
<br />
<p>Forms are everywhere on the web and successful user interaction relies on clear, understandable, and accessible form controls. Several principles of accessibility should be kept in mind when testing forms. Labels for form controls, input, and other user interface components must be provided. Many people do not use the mouse and rely on the keyboard to interact with the Web. This requires visible keyboard access to all functionality, including form controls. Forms may be confusing or difficult to use for many people, and, as a result, they may be more likely to make mistakes. Clear recovery mechanisms must be provided.</p> <br />
<br />
====What to do====<br />
<p>Evaluating the accessibility of form controls is one area in which a testing tool comes in very handy. Free web developer tools and accessibility checkers can be downloaded and installed in various browsers and having one installed will make this process much easier. <span style="color:#808080;">SR Note: Do we recommend a tool? Link to the testing tools section of the WAI pages?</span></p> <br />
# Visually examine the forms<br />
# Put the mouse aside and tab through form controls<br />
# Turn images off in the browser and examine submit buttons and other controls<br />
# Turn off CSS in the browser<br />
# Enter data in form input fields <br />
# Deliberately enter an error and then submit form<br />
# Use browser based testing tools to examine form detail<br />
<br />
====What to look for====<br />
<p>Each form control must have an associated label that describes its purpose. Tab order between form controls must match the order in which a user would normally complete them. Complex forms benefit from grouping controls with the FIELDSET element. The form title is optional if the purpose of the form can be determined from context. "Placeholder" text inside text boxes is no longer needed for screen readers; it is redundant in a properly-labeled form. Many forms will also have to be evaluated separately for dynamic behavior such as error response. Listed below are some things that you will look for.</p> <br />
<p>When visually reviewing the form, note the following:<br />
* if required fields are indicated by use of color cues, ensure that additional, redundant methods are also used.<br />
* ensure that related form controls are logically grouped together (perhaps using fieldset and legend, see the section below with testing tools)</p> <br />
<p>When tabbing through form inputs:<br />
* ensure that focus moves logically between the fields.<br />
* ensure that focus is visible on all form controls, including inputs, submit mechanisms, and check boxes and radio buttons.<br />
* if form control is check box or radio button, ensure that focus indication includes form label as well as the actual control<br />
* if form control is select box, ensure that arrow keys can move focus between select options and that selection is made by user action and not by default focus.</p><br />
<p>With images and/or background images turned off in the browser:<br />
* ensure that form controls remain evident and operable<br />
* ensure that any "required" status indicators remain evident</p><br />
<p>When entering data: <br />
* ensure that focus does not automatically advance to the next field, but requires user input to advance </p><br />
* if a certain response triggers presentation of new content,that content is exposed to the keyboard as well.</p><br />
<p>When erroneous data is entered and form submitted:<br />
* ensure that error message is clear and specific about the nature of the error and the field in which it was made<br />
* ensure that focus moves to the error message<br />
* ensure that guidance is provided to help user understand and fix the error. </p><br />
<p>If browser-based testing tool is in use:<br />
* check for form labels<br />
* ensure mutual association and matching of the "for" attribute of the "label" element to the "id" attribute of the "form" element<br />
* if feildset and legend are used, ensure they are properly formed</p><br />
<br />
====References====<br />
<p>Several Accessibility Principles are relevant to the accessibility of forms, including these:<br />
* [http://www.w3.org/WAI/intro/people-use-web/principles#alternatives Text alternatives to non-text content]<br />
* [http://www.w3.org/WAI/intro/people-use-web/principles#keyboard Functionality is available from a keyboard]<br />
* [http://www.w3.org/WAI/intro/people-use-web/principles#navigable Users can easily navigate, find content, and determine where they are]<br />
* [http://www.w3.org/WAI/intro/people-use-web/principles#predictable Content appears and operates in predictable ways]<br />
* [http://www.w3.org/WAI/intro/people-use-web/principles#tolerant Users are helped to avoid and correct mistakes]</p><br />
<p>WCAG2 Guidelines and Success Criteria that may be applied to determining the accessibility of forms include these:<br />
* [http://www.w3.org/TR/UNDERSTANDING-WCAG20/text-equiv-all.html Non-text Content]: Understanding Success Criteria 1.1.1 (Level A)<br />
* [http://www.w3.org/TR/UNDERSTANDING-WCAG20/keyboard-operation-keyboard-operable.html Keyboard]: Understanding Success Criteria 2.1.1 (Level A)<br />
* [http://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-focus-order.html Focus Order]: Understanding Success Criteria 2.4.3 (Level A)<br />
* [http://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-descriptive.html Headings and Labels]: Understanding Success Criteria 2.4.6 (Level AA)<br />
* [http://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-focus-visible.html Visible Focus]: Understanding Success Criteria 2.4.7 (Level AA)<br />
* [http://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-focus-visible.html Predictable]: Understanding Guideline 3.2 (Level A and AA)<br />
* [http://www.w3.org/TR/UNDERSTANDING-WCAG20/minimize-error.html Input Assistance]: Understanding Guideline 3.3 (Level A and AA)<br />
* [http://www.w3.org/TR/UNDERSTANDING-WCAG20/ensure-compat-rsv.html Name, Role, Value]: Understanding Success Criteria 4.1.2 (level A)</p><br />
<br />
<p>WAI's Before and After Demo (BAD)includes examples of forms that have been made accessible:<br />
* [http://www.w3.org/WAI/demos/bad/before/survey.html Inaccessible forms page]<br />
* [http://www.w3.org/WAI/demos/bad/after/survey.html Accessible forms page]<br />
<br />
====Notes====<br />
<span style="color:#808080;">[can be internal notes for now or maybe will be included in final doc]</span><br />
*...<br />
<br />
===Tables [Ian drafting, eta 2012-12-07]===<br />
<span style="color:#808080;">EOWG notes.<br />
<br/> 5min: no, too complex.<br />
<br /> 15min: not sure (need to see it drafted first :-) </span><br />
...<br />
<br />
===Check flickering, flashing, blinking [open for drafting]===<br />
<span style="color:#808080;">EOWG notes.<br />
<br/> 5min: no.<br />
<br /> 15min: maybe not. </span><br />
...<br />
<br />
===WAI-ARIA [Wayne is drafting (although probably not including this one)]===<br />
<span style="color:#808080;">EOWG notes.<br />
<br/> 5min: no.<br />
<br /> 15min: no. </span><br />
<p>Checking ARIA interactively is not part of a preliminary or<br />
ongoing test. It should be left for an formal audit. </p><br />
<p>There is lexical testing available through plugins in some<br />
browsers. These programs show elements using ARIA parameters and<br />
delineate the values. For a preliminary or interim accessibility<br />
test, this is enough. Without a plugin one can search code<br />
for ARIA parameters manually, but this is tedious and can miss<br />
problems. </p><br />
<p>SC. 4.1.2 (Name, Role, Value) applies here. It is Level A. ARIA testing is required whenever AJAX or other rich internet applications are used.<br />
</p><br />
<br />
Note: not a requirement for accessibility and WAI-ARIA is not finalized yet, so probably won't include WAI-ARIA in the 15 minute check.<br />
<br />
===Time-dependent responses [probably not including this one]===<br />
<span style="color:#808080;">EOWG notes.<br />
<br/> 5min: no.<br />
<br /> 15min: no. too hard to check and not vital to many users.</span><br />
...<br />
<br />
===Window resize [probably not including this one]===<br />
<span style="color:#808080;">EOWG notes.<br />
<br/> 5min: no.<br />
<br /> 15min: no. probably too complex an issue from preliminary eval</span><br />
...<br />
<br />
===Validate HTML & CSS [probably not including this one]===<br />
<span style="color:#808080;">EOWG notes.<br />
<br/> 5min: no<br />
<br /> 15min: WCAG requirement issue too complex. </span><br />
...<br />
<br />
Note: Validation not WCAG requirement...<br />
* ...<br />
* Check that the document language is declared<br />
<br />
===Check usable without CSS, javascript [Wayne is drafting (though maybe not including this one)]===<br />
<span style="color:#808080;">EOWG notes.<br />
<br/> 5min: no.<br />
<br /> 15min: not as a separate item. maybe integrated as a technique to check other points.</span><br />
<br />
NOTE: Shadi notes this is not a WCAG requirement<br />
<br />
<p>The ability to remove the author's style is not a WCAG<br />
requirement, but it is a good tool to help diagnose many<br />
accessibility errors. When the page without style can enlarge<br />
text-only with grace, and the page with style cannot then the page<br />
structure probably inhibits conformance with SC 1.4.4 (Resize<br />
text). When items like button disappear without author style, then<br />
there may be a text alternative issue (SC 1.1.1). Often, generated<br />
content from CSS includes pictures to indicate the position active<br />
regions. These images have no alternative text. One can detect<br />
when the page logical order does not match visual reading order by<br />
turning off author style. This is a test for SC 1.3.1 (Information<br />
and relationships) and and SC 2.4.3 (Focus Order). In general a<br />
page that does not make sense without style violates some success<br />
criterion.</p><br />
<p>There are some false issues. Often meaningless or context<br />
sensitive content is given a display value of "none". All of this<br />
data shows up without author style, and can make the page appear<br />
to be filed confusing garbage. This type of data is usually so<br />
clearly inappropriate that one can safely ignore it. </p><br />
<br />
===Use an evaluation tool [probably won't include this generically]===<br />
<span style="color:#808080;">EOWG notes.<br />
<br/> 5min: no.<br />
<br /> 15min: not as a separate item. use of tools will be integrated in specific checks. generally running a tool gives too complicated results for a quick check.</span><br />
<br />
*Use one-page auto checker<br />
EOWG discussion:<br />
* There are a number of simple tools where you just put in the URL of the page of interest and the results are returned automatically eg WAVE and TAW. The results aren't necessarily so easy to interpret if you are a newbie to accessibility. Perhaps we should put this after the top 5 easy checks - and add a paragraph to confirm the benefits and limitations, or discuss some of the common types of problem found {Suzette}<br />
<br />
==More Thorough Evaluation==<br />
@@ point to Conformance Evaluation page and WCAG-EM.<br />
<br />
==Contributors==<br />
Thanks to:<br />
* Those who drafted checks 16-28 November:<br />
** Sharron for drafting {list sections!}<br />
** <span style="background:yellow;">{name} for drafting {section}</span><br />
* Andrew & Shawn for editing the [http://www.w3.org/WAI/EO/wiki/Web_Accessibility_Preliminary_Evaluation#Check_keyboard_access_and_visual_focus_.5Bmostly_drafted.5D keyboard access & visual focus section] in early Nov.<br />
* Ian, Suzette, Vicki, Sylvie, Helle, Shawn for working on an early draft at the [http://www.w3.org/2012/11/02-eo-minutes f2f in Nov].<br />
* Sharron for help making all the drafts and versions less confusing.<br />
* Wayne and Ian for sharing colleagues' related work.<br />
* Denis for edits to the old page content.</div>Wdickhttps://www.w3.org/WAI/EO/wiki/index.php?title=Web_Accessibility_Preliminary_Evaluation&diff=2311Web Accessibility Preliminary Evaluation2012-11-29T21:04:45Z<p>Wdick: /* WAI-ARIA [Wayne is drafting (although probably not including this one)] */</p>
<hr />
<div>Nav: [[Main Page|EOWG wiki main page]] > [[Main_Page#Evaluation_pages | Evaluation Pages ]]<br/><br />
Old page on WAI website: [http://www.w3.org/WAI/eval/preliminary.html Prelim Eval]<br/><br />
<br />
Note:<br />
* '''A template for the check items is at the top of the [http://www.w3.org/WAI/EO/wiki/Talk:Web_Accessibility_Preliminary_Evaluation discussion tab].'''<br />
* For tasks, example user cases with audience, and focus for this and related documents, see the [[Eval Analysis]] page<br />
* For previous drafts and contributed material, see:<br />
** Old page with Denis' edits and Ian's input in [[Preliminary Eval - old notes]]<br />
** Extensive revisions and suggestions at [[Archived_Work_on_PreLimEval]]<br />
** From Wayne & Tom [[Prelim Eval input: Smart analysis simplified]]<br />
<br />
<span style="background:yellow;">'''''Important Note''''': For this draft we have some tool-specific guidance. However, there are potential issues with vendor-neutraility and we might need to address this a different way &mdash; for example, moving tool-specific guidance to WebPlatform Docs or the WAI-Engage wiki where people can easily add other tools.</span><br />
<br />
<br />
__TOC__<br />
<br />
<span style="background:yellow;">'''''Important Note''''': For this draft we have some tool-specific guidance. However, there are potential issues with vendor-neutraility and we might need to address this a different way &mdash; for example, moving tool-specific guidance to WebPlatform Docs or the WAI-Engage wiki where people can easily add other tools.</span><br />
<br />
=Preliminary Review|Evaluation: Checking the Accessibility of a Web Page=<br />
<br />
==Introduction==<br />
<p>Testing and evaluating a web site for accessibility may seem intimidating but it need not be. There are simple ways to check on some basic features that do not require special skills or tools beyond your browser controls. Here you will find two approaches to doing Preliminary Evaluation of your pages. The first is a Quick Check - a list of 5 things you can do in 5 minutes. The second, while not a full conformance validation of WCAG2 Guidelines, will help ensure basic accessibility across a broader range of issues. While the second can quickly determine if the most important elements of a web page can be used by most persons with disabilities, it also requires more knowledge of accessibility principles and a few testing tools.</p><br />
<br />
<p>... @@ first run on good BAD page to see what it should look like, then on the bad page ... </p><br />
<br />
==Quick Checks==<br />
<br />
<p>Here are 5 things you can do to quickly check for accessibility barriers on a web page:<br /><br />
<span style="color:#808080;">{EOWG note: Let's work on the longer section first, then decide what we can move up to the quick checks section later.</span></p><br />
#First thing.<br />
#Second thing.<br />
#Third thing. <br />
#Fourth thing. <br />
#Fifth thing.<br />
<br />
Once you have taken this quick dip you may be ready to dive a bit deeper. The next section provides more context and additional things you can do to check for accessibility barriers.<br />
<br />
==A Deeper Look==<br />
<p>If you are interested in a more comprehensive look at the page(s), here more tests that require a little more time, skills, and/or tools.</p><br />
<br />
<span style="color:#808080;">''{reminder: A template for the check draft items is at the top of the [http://www.w3.org/WAI/EO/wiki/Talk:Web_Accessibility_Preliminary_Evaluation discussion tab].}''</span><br />
<br />
===Check text descriptions for images [mostly drafted]===<br />
<span style="color:#808080;">EOWG notes - importance: HIGH.<br />
<br/> 5min: yes, at least the easy part.<br />
<br /> 15min: yes. might want additional checks here.</span><br />
<br />
<p>Text alternatives convey the purpose of an image or function to provide an equivalent user experience for a user who may not see the images. For instance, a text alternative for a search button is "search".<br />
====What to do====<br />
# Disable images in the browser<br />
# Turn off CSS in the browser<br />
# Use free checking tools to list the text alternatives (or lack of them) for all graphic elements<br />
# If content is multimedia, see also </p> <br />
====What to look for====<br />
<p>If the images are CSS (background images), visually inspect when CSS is disabled to ensure that no meaningful element is removed from the content</p><br />
<p>For content delivered as an HTML img element, examine the result and follow this decision tree. For each element of type img: <br />
* Is there an attribute of type alt?<br />
** No: Item fails, this check is complete.<br />
** Yes: Continue on<br />
* Is the image purely decorative? <br />
** No: Continue on<br />
** Yes: Verify that alt="". Test complete <br />
* Is image the only content of a link or form control? <br />
** No: Continue on<br />
** Yes: Verify that the alt attribute clearly communicates the destination of the link or action taken.<br />
* Is image link also present as link text nearby? <br />
** No: Continue on<br />
** Yes: ensure that image and text are both within one anchor tag and that alt="". Test complete. <br />
* Does image contain text? <br />
** No: Continue on <br />
** Yes: Is image text also available as real text nearby?<br />
*** No: Verify that the alt attribute echoes the onscreen text exactly. Test complete.<br />
*** Yes: Verify that alt="" Test complete.<br />
* Does the image contribute meaning to the current page or context? <br />
* No: Continue on<br />
* Yes: Is image a simple graphic or photo?<br />
** Yes: Verify that alt=“brief description of image meaning”. Also verify that brief description does NOT contain words like photo, image, picture, graphic, etc, unless intrinsic to the meaning. Test complete. <br />
** No: Is image visually complex (for example, a graph, chart, or other image of complex meaning)? <br />
*** Yes: Verify that alt=“brief description” AND that there is also an explanation of the full information as a caption, a data table, a long description, or a paragraph positioned off screen that provides equivalent meaning. Test complete.<br />
</p><br />
<br />
====References====<br />
* [http://www.w3.org/WAI/intro/people-use-web/principles#alternatives Text alternatives for non-text content section in Accessibility Principles]<br />
* [http://www.w3.org/TR/UNDERSTANDING-WCAG20/text-equiv-all.html Understanding Success Criteria 1.1.1] (LevelA)<br />
* [http://www.w3.org/WAI/demos/bad/before/annotated/home.html Examples of incorrect, missing, or inadequate alt text] from WAI's Before and After Demo<br />
<br />
====Notes====<br />
<ul><br />
<li>Text that is actually an image.</li><br />
<li>Important image should have alt text that provides adequate alternative of the image for people who cannot see it...</li><br />
<li>Image that doesn't convey important information...</li><br />
<li>@@ Some guidance on not saying things like "this is an image..." or "this is a link..."</li><br />
</ul><br />
<br />
===Check headings and other semantic structure [some parts drafted]===<br />
<span style="color:#808080;">EOWG notes - importance: HIGH.<br />
<br/> 5min: maybe. fairly easy to check if there are at least some headings.<br />
<br /> 15min: yes.</span><br />
<br />
... @@ brief summary of why & what to check for ...<br />
See also:<br />
* ? [http://www.w3.org/TR/2012/NOTE-WCAG20-TECHS-20120103/G141 G141 technique]<br />
* ? [http://www.w3.org/TR/2012/NOTE-WCAG20-TECHS-20120103/H42 H42 technique]<br />
<br />
What you're looking for: @@<br />
<ul><br />
<li>Does the page have any headings?</li><br />
<li>Are the things that look like headings that aren't marked up as heading?</li><br />
<li>Are there things that are marked up as headings that aren't really headings?</li><br />
</ul><br />
<br />
====Checking with WAVE====<br />
<ol><br />
<li>Open [http://wave.webaim.org/ WAVE]</li><br />
<li>Enter the web page:<br />
<ul><br />
<li>If the website is online: Enter a web site address and click the "WAVE the page!" button.</li><br />
<li>... Upload a file...</li><br />
<li>... Check HTML code...</li><br />
</ul></li><br />
<li>Check headings:<br />
<ul><br />
<li>...</li><br />
</ul></li><br />
<li>Check lists:<br />
<ul><br />
<li>...</li><br />
</ul></li><br />
</ol><br />
<br />
====Checking headings with HTML Validator====<br />
<ol><br />
<li> Open the [http://validator.w3.org/ W3C HTML Validator (The W3C Markup Validation Service)].</li><br />
<li>Select the appropriate tab and input the page:<br />
<ul><br />
<li>If the web page is online, leave the '''Validate by URI''' tab selected. <br />In the Address field, type the URI (e.g., www.w3.org).</li><br />
<li>If the web page is on your local computer, click the '''Validate by File Upload''' tab.<br />In the File field, select &quot;Choose...&quot; and find the file on your computer.</li><br />
<li>If you will paste the HTML code/markup, '''Validate by Direct Input''' tab.<br />Paste your HTML in the Enter the Markup to validate: field.</li><br />
</ul><br />
</li><br />
<li>Click the More Options link.</li><br />
<li>Select the Outline checkbox.</li><br />
<li>Click the Check button.</li><br />
<li>In the results page at the top, click the Outline link.</li><br />
<li>Compare the Document Outline to the visual rendering of the page. <ul><br />
<li>Are the things that look like headings listed in the Document Outline?</li><br />
<li>Are there things in the Document Outline that aren't really headings?<br /><br />
</li><br />
</ul></li><br />
</ol><br />
<br />
===Check keyboard access [mostly drafted]===<br />
<span style="color:#808080;">EOWG notes - importance: HIGH.<br />
<br/> 5min: maybe.<br />
<br /> 15min: yes.</span><br />
<br />
Many people do not use the mouse and rely on the keyboard to interact with the Web. This requires keyboard access to all functionality, including links, form controls, input, and other user interface components. <br />
====What To Do====<br />
* Click in the address bar, then put your mouse aside and don't use it. <br />
* Press the 'tab' key to move around the page.<br />
''(see also Forms)''<br />
<br />
''(see also Visible Focus)''<br />
====What To Look For====<br />
* Can you tab to all the elements, including links, form fields, buttons, and media player controls? Are there any actions you can't get to (e.g., if they are only available on mouse hover)?<br />
* Does the focus get stuck anywhere - that is, you can tab into a control but not out? (called a "keyboard trap")?<br />
* Does the order that items get focus make sense to sighted users? (e.g., you don't jump around the page out of order logically)<br />
* Can you tab right through to the bottom of the page and then resume again from the top? (e.g. you don't get stuck anywhere and can't move on)<br />
* If there is a drop-down box (for example, for navigating to a different page): If you tab into the drop-down box, can you use the down/up arrow keys to move through the options, and @@use 'tab' to the following item@@? (Make sure it doesn't automatically select the first item.)<br />
====References====<br />
* [http://www.w3.org/WAI/intro/people-use-web/principles#keyboard Functionality is available from a keyboard]<br />
* [http://www.w3.org/WAI/users/browsing#keyboard Browsing the Web by Keyboard] section in [http://www.w3.org/WAI/users/browsing Better Web Browsing: Tips for Customizing Your Computer]<br />
* Example: [http://www.w3.org/WAI/demos/bad/before/survey.html web page template that does not enable keyboard access] from the WAI Before and After Demo (BAD)<br />
====Notes====<br />
* Mac browsers by default only tab through forms, will need to turn on...<br />
* not work easily in Opera...<br />
* ...<br />
<br />
===Visible focus [mostly drafted]===<br />
<br />
<span style="color:#808080;">EOWG notes.<br />
<br/> 5min: probably not (unless merged with keyboard access)<br />
<br /> 15min: probably</span><br />
<br />
'''''NOTE: Should this be merged with the keyboard access?'''''<br />
<br />
<p>Use keyboard only navigation to ensure that a user who relies on the keyboard will be able to know which element among multiple elements has the keyboard focus. This is an important element in facilitating success for keyboard users to operate the page, by letting them visually determine the component on which keyboard operations will interact at any point in time. People with attention limitations, short term memory limitations, or limitations in executive processes benefit by being able to discover where the focus is located.</p><br />
<br />
====What to do====<br />
# Use the keyboard to set the focus to all focusable elements on the page.<br />
<br />
====What to look for====<br />
# Visually examine progress through elements and verify that the focus indicator is visible.<br />
# Common failures occur when the default focus indicator is turned off in CSS or when the element is styled with borders that occlude the focus indicator.<br />
# Verify that any visual changes that occur with mouse hover also are triggered with keyboard focus<br />
<br />
====References====<br />
* [http://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-focus-visible.html Focus Visible - Understanding Success Criteria 2.4.7 (Level A)] <br />
* <span style="color:#808080;">[Found no relevant BAD example, Shadi is checking]</span><br />
* <span style="color:#808080;">[nothing specific in Accessibility Requirements page]</span><br />
<br />
===Check the page title [mostly drafted]===<br />
<span style="color:#808080;">EOWG notes - importance: medium.<br />
<br/> 5min: maybe not. it is easy to check, but a little more complicated to explain what makes a good title. Also not the most vital to lots of users.<br />
<br /> 15min: probably.</span><br />
<br />
@@ add image showing only a few words with multiple tabs in browser...<br />
<br />
Page titles are the first information read by a screen reader; useful for when users have multiple web pages opens, e.g., on different tabs and go between different windows. (Also good for adding to bookmarks & also search engine results.) <br />
<br />
====What to do====<br />
# Look at the browser's window title bar.<br />
# Look at titles of other pages within the site.<br />
<br />
====What to look for====<br />
* Verify that the title indicates the specific page and website and distinguishes the current page from others in the set of pages.<br />
* Make sure that every page in the site does not have the same title.<br />
* Check that the specific page title is listed BEFORE the name of the website. (for example, ''About Us - Our Long Web Site Name'')<br />
<br />
====References====<br />
* [http://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-title.html Page Titled- Understanding SC 2.4.2]<br />
* Consider if the page titles of all of the [http://www.w3.org/WAI/demos/bad/Overview.html Before and After Demo] had been the same. Instead, each has a distinctive name that identifies its function within the set of pages.<br />
====Notes====<br />
* Some browsers don't show title in browser title bar (Chrome, IE)<br />
<br />
===Check link text [partly drafted]===<br />
<span style="color:#808080;">EOWG notes.<br />
<br/> 5min: maybe not.<br />
<br /> 15min: maybe. fairly easy to check. not the most vital for lots of users.</span><br />
<br />
Wording the text that is linked to indicate clearly where the link goes or what the link does. Some people use a list of links where they don't see the text around it. See also:<br />
* [http://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-refs.html Link Purpose (In Context): Understanding SC 2.4.4] (Level A)<br />
* [http://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-link.html Link Purpose (Link Only): Understanding SC 2.4.9] (Level AAA)<br />
* [BAD]<br />
<br />
Check this<br />
* @@<br />
** @@<br />
<br />
Common failures:<br />
* Link text is something like "Click here" or "More" without any additional clarifying text.<br />
<br />
Notes:<br />
* List links (Can't find this in regular Firefox but easy in Opera where you can get a list of links from the standard tools menu, showing both title and url)<br />
* Issue - titles... ([http://ianpouncey.com/weblog/2010/01/title-attributes/ Ian P says never use titles on links], Sylvie agrees.)<br />
<br />
===Check usable with page zoomed and text enlarged [Suzette drafted for discussion]===<br />
<span style="color:#808080;">EOWG notes.<br />
<br/> 5min: no<br />
<br /> 15min: maybe not.</span><br />
* Zoom to 200%<br />
* Text-only enlargement... (e.g., text actually changes in IE)<br />
<br />
People with mild to moderate visual impairments may need to enlarge text in order to read it, or read it without straining. This simple requirement is mostly achieved by the functionality of the browser and ensuring that the page design supports that functionality. <br />
<br />
The text should be resizable up to 200% without losing information, using a standard browse. Additionally any images of text should also be resizable or replaced with actual text. <br />
<br />
Most modern browsers now offer a zoom function which enlarges both text and other content together. Some older browsers do not resize text if it was set using fixed units – such as points or pixels. <br />
<br />
====What to do====<br />
* Open your preferred browsers. Internet Explorer, Firefox, Chrome and Opera all offer zoom as a function of View or Function menus, or as a keyboard shortcut (usually, Control +, or for Mac Command +). <br />
* Set the screen window to full width<br />
* Use the zoom function or keyboard shortcut repeatedly to step up to a 200% increase. <br />
* Look at the main content, buttons, tabs and text entry fields and field labels.<br />
* Repeat with a different browser.<br />
====Common failures====<br />
* Is the default body text unusually small?<br />
* Does the main heading and body text increase in size? <br />
* Has any text that is part of a control, button, menu item or label increased in size? <br />
* Does any text overflow its space – for example, the text is too big for the button or menu tab, or width or depth of the column?<br />
* Can you read to the end of the line, or does some text disappear off the screen so that you have to scroll right to the end of the line?<br />
=====Note=====<br />
Some browsers can expand the text beyond 200% - this is not covered by the resize requirement as it is recognised that this will cause some of the failures described. It is also accepted that some horizontal scrolling may be necessary but see also 1.4.8 which is a AAA requirement. <br />
Users with more severe visual impairments who need larger text are likely to use screen magnifiers to increase text size above 200%. <br />
====References====<br />
*link to {appropriate section in Accessibility Requirements page http://www.w3.org/WAI/intro/people-use-web/principles#distinguishable} (doesn’t have a lot to say)<br />
*Guideline 1.4 Distinguishable: Make it easier for users to see and hear content including separating foreground from background. <br />
*Resize text: Understanding Success Criteria 1.4.4 (Level AA) {http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-scale.html}<br />
*Images of Text: Understanding Success Criteria 1.4.5 (Level AA) http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-text-presentation.html<br />
*Visual Presentation: Understanding Success Criteria 1.4.8 (Level AAA)http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-visual-presentation.html<br />
*link to {BAD example} No specific BAD examples – some reference to Text as image in relation to the phone number, and column width.<br />
<br />
====Notes for discussion====<br />
*Scrolling: see Visual Presentation: Understanding Success Criteria 1.4.8 (Level AAA) includes:<br />
** Text can be resized without assistive technology up to 200 percent in a way that does not require the user to scroll horizontally to read a line of text on a full-screen window.<br />
*Do we need to spell out the difference between zooming and resizing? Is resizing still important for people who use style sheets?<br />
*Do we still need to worry about IE6 which didn’t resize fixed font sizes?<br />
*Browsers are now hiding their menus – eg under the cogwheel icon, which is making it harder to know where to find the zoom option, however they seem to be reasonably consistent on keyboard shortcuts. Other options include pinch and zoom on trackpad or intellimouse<br />
<br />
===Check color contrast [Suzette is drafting]===<br />
<span style="color:#808080;">EOWG notes.<br />
<br/> 5min: maybe.<br />
<br /> 15min: yes.</span><br />
<br />
First pass - I'm working on this:<br />
<br />
Good colour contrast between the text and background is very important to people with visual impairements. Some users may chose to vary your colour choice by using their own preferred style sheet. <br />
<br />
Screen reader users will hear the text even if the contrast is poor, or deliberately hidden as white on white or black on black!<br />
<br />
* First stage - look out for instances of pale text that might blend into the background eg grey on the default off-white background. Other common combinations are pale green, yellow or blue text on a background of a slightly darker shade of the same colour. Check the text in the main content, menu tabs, links and selected links and in buttons, labels and captions. Any suspect instances need to be investigated. <br />
<br />
Remember that not all users will have high resolution screens and subtle colour combinations may not be rendered properly if the user is using a reduced colour set.<br />
<br />
* Second stage - a number of on-line tools can be used to compare the exact ratio of text and background. Use zoom to increase the font size and follow the tool instructions to pick up a sample of the text colour and a sample of the background colour. If the background is patterned take a sample at different points. The minimum contrast (level AA) is 4.5:1<br />
<insert from Wayne Dick><br />
<p> There are two types of color contrast testers: The first type, a<br />
lexical evaluator, looks at styles in web page code and<br />
computes color contrasts based on coded values. The second type,<br />
run time tester, simply allows the user to sample what is on the<br />
screen and computes contrast based on samples. </p><br />
<p> The lexical evaluator examines what the author declares. It<br />
gives a full page report based color contrasts declared by the<br />
programmer. These tests are quick and efficient. They break down<br />
when run time values change due to actions taken by active<br />
content.</p><br />
<p> The run time tester requires more hands on work. The evaluator<br />
can take samples as the web site runs and determine actual<br />
contrasts. The problem here is that as contrasts change over time<br />
the tester must sample many states of the page. </p><br />
<p> Both types of test are important. If any active content changes<br />
color during run time then WAI advises run time testing. Lexical<br />
testing can be very useful and save time with items with static <br />
color. </p><br />
<br />
<end Wayne's insert><br />
Ref: Contrast (minimum) 1.4.3 http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-contrast.html <br />
<br />
also Contrast (enhanced) 1.4.6 <br />
Note: There are some exceptions and special requirements to achieve full conformance.<br />
<br />
===Check color coding and shape coding [Suzette draft]===<br />
<span style="color:#808080;">EOWG notes.<br />
<br/> 5min: no<br />
<br /> 15min: maybe not. not easy to check thoroughly. not vital for many users.</span><br />
<br />
[Notes: refers specifically to: '''1.4.1 Use of Color''': Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.<br />
<br />
NB. consider if other sensory characteristics [such as shape, size, visual location, orientation, or sound] sould be combined here. See '''1.3.3 Sensory Characteristics''': Instructions provided for understanding and operating content do not rely solely on sensory characteristics of components such as shape, size, visual location, orientation, or sound.]<br />
<br />
Colour, shape and location are often used as a code or visual cue to help people to identify important information or actions on a busy web page. <br />
<br />
These visual cues are not always available – someone who is colour blind may find it difficult to distinguish some or all colour combinations. And in addition, people using some types of assistive technology such as a screen reader, Braille or other alternative display systems will not ‘see’ the cue.<br />
<br />
It helps to use both colour and a symbol together – for example a red asterisk, provides both a colour and shape code. Alt text on any symbols or icons should make the functional meaning obvious. Any text instructions should allow for someone who cannot see the visual cue. <br />
<br />
====What to do====<br />
Inspect the page carefully to identify any instances of visual cues:<br />
* Colour - either coloured text or tinted backgrounds and including in-text links.<br />
* Shape - including icons and symbols, and glyphs such as a smiley face or no entry symbol, or a graphic X to draw attention to removing an item in a shopping list.<br />
* Location - positioning a symbol or instruction at the top, bottom or side of the main text<br />
* Text descriptions or instructions - inspect the text for instructions that refer to colour, shape or location such as the button on the left, or the red square.<br />
<br />
====Common failures====<br />
* In a form, colour used to indicate a required field, or as part of an error messages when a required field is not completed and there is no additional cue such as a colour coded symbol?<br />
* Text links - colour used alone to indicate links in a paragraph of text, and, there is no additional cue such as underlining?<br />
* Text instructions, the instruction does not make sense if you can't see the colour, shape or the location of a control button described.<br />
* Providing alternative text for symbols and icons - in general these need to refer to the function and not the visual appearance. For example if ‘red square’ is the button for the function ‘stop’, then the alt text should say ‘stop’ and not 'red square'. <br />
<br />
====References====<br />
Use of colour: Understanding success criteria 1.4.1 (Level A) {http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-without-color.html}<br />
<br />
Sensory Characteristics: Understanding success criteria 1.3.3 (Level A) { http://www.w3.org/TR/UNDERSTANDING-WCAG20/content-structure-separation-understanding.html}<br />
<br />
See also: Non-text equivalent 1.1.1 (A) for appropriate text equivalents for any symbols, icons or glyphs and Contrast 1.4.3 (AA) for colour contrast.<br />
<br />
====Notes for discussion====<br />
I put colour, shape and location together because functionally they are about visual coding – is this too big a step?<br />
<br />
Also - should the common failures be descriptive, suggest a solution or ask a question? I got a bit confused here :(<br />
<br />
===Content order [open for drafting]===<br />
<span style="color:#808080;">EOWG notes.<br />
<br/> 5min: no.<br />
<br /> 15min: maybe. </span><br />
<br />
'''''NOTE: Should this be merged with the keyboard access check?'''''<br />
<br />
===Video, Sound, (multimedia) [partly drafted]===<br />
<span style="color:#808080;">EOWG notes.<br />
<br/> 5min: maybe. vital for some uses, through maybe not really easy to check thoroughly<br />
<br /> 15min: yes.</span><br />
<br />
====What to do====<br />
# Play the audio content<br />
# Play the video content<br />
# Toggle closed captions on (if available) <br />
# Toggle audio description on (if available) <br />
====What to look for====<br />
* Captions:<br />
** Verify that they synchronized to the spoken content<br />
** Ensure they are accurate and complete (not missing any content)?<br />
** Verify that they are properly formed? (correct spelling, sentence structure, punctuation)<br />
** Make sure that audio content other than dialogue is inlcuded (music, relevant ambient sounds, etc)<br />
* Audio Description<br />
** '''(Judgement call)''' Watch the video content to verify that audio description is needed for complete understanding.<br />
** If needed, verify that they are provided in a separate track that can be toggled on and that they provide context for those who do not see the video.<br />
* Transcript: As a fall-back when captions and audio descriptions are not provided, check to see if there is text-based content that contains dialogue, any other audio content, and any necessary description of video content. Check for spelling and accuracy. <br />
''(see also keyboard access for player controls)''<br />
<br />
''(see also text alternatives for graphic content)''<br />
<br />
====References====<br />
* [http://www.w3.org/2008/06/video-notes Multi Media FAQs] from the W3C<br />
* [http://www.w3.org/TR/UNDERSTANDING-WCAG20/media-equiv-captions.html Understanding WCAG SC 1.2.2 Captions](Level A)<br />
* [http://www.w3.org/TR/UNDERSTANDING-WCAG20/media-equiv-audio-desc.html Understanding 1.2.5 Audio Description](Level A) <br />
====Notes====<br />
<span style="color:#808080;">[can be internal notes for now or maybe will be included in final doc]</span><br />
*...<br />
<br />
===Forms===<br />
<span style="color:#808080;">EOWG notes.<br />
<br/> 5min: no, too complicated.<br />
<br /> 15min: not sure (need to see it drafted first :-)</span><br />
<br />
<p>Forms are everywhere on the web and successful user interaction relies on clear, understandable, and accessible form controls. Several principles of accessibility should be kept in mind when testing forms. Labels for form controls, input, and other user interface components must be provided. Many people do not use the mouse and rely on the keyboard to interact with the Web. This requires visible keyboard access to all functionality, including form controls. Forms may be confusing or difficult to use for many people, and, as a result, they may be more likely to make mistakes. Clear recovery mechanisms must be provided.</p> <br />
<br />
====What to do====<br />
<p>Evaluating the accessibility of form controls is one area in which a testing tool comes in very handy. Free web developer tools and accessibility checkers can be downloaded and installed in various browsers and having one installed will make this process much easier. <span style="color:#808080;">SR Note: Do we recommend a tool? Link to the testing tools section of the WAI pages?</span></p> <br />
# Visually examine the forms<br />
# Put the mouse aside and tab through form controls<br />
# Turn images off in the browser and examine submit buttons and other controls<br />
# Turn off CSS in the browser<br />
# Enter data in form input fields <br />
# Deliberately enter an error and then submit form<br />
# Use browser based testing tools to examine form detail<br />
<br />
====What to look for====<br />
<p>Each form control must have an associated label that describes its purpose. Tab order between form controls must match the order in which a user would normally complete them. Complex forms benefit from grouping controls with the FIELDSET element. The form title is optional if the purpose of the form can be determined from context. "Placeholder" text inside text boxes is no longer needed for screen readers; it is redundant in a properly-labeled form. Many forms will also have to be evaluated separately for dynamic behavior such as error response. Listed below are some things that you will look for.</p> <br />
<p>When visually reviewing the form, note the following:<br />
* if required fields are indicated by use of color cues, ensure that additional, redundant methods are also used.<br />
* ensure that related form controls are logically grouped together (perhaps using fieldset and legend, see the section below with testing tools)</p> <br />
<p>When tabbing through form inputs:<br />
* ensure that focus moves logically between the fields.<br />
* ensure that focus is visible on all form controls, including inputs, submit mechanisms, and check boxes and radio buttons.<br />
* if form control is check box or radio button, ensure that focus indication includes form label as well as the actual control<br />
* if form control is select box, ensure that arrow keys can move focus between select options and that selection is made by user action and not by default focus.</p><br />
<p>With images and/or background images turned off in the browser:<br />
* ensure that form controls remain evident and operable<br />
* ensure that any "required" status indicators remain evident</p><br />
<p>When entering data: <br />
* ensure that focus does not automatically advance to the next field, but requires user input to advance </p><br />
* if a certain response triggers presentation of new content,that content is exposed to the keyboard as well.</p><br />
<p>When erroneous data is entered and form submitted:<br />
* ensure that error message is clear and specific about the nature of the error and the field in which it was made<br />
* ensure that focus moves to the error message<br />
* ensure that guidance is provided to help user understand and fix the error. </p><br />
<p>If browser-based testing tool is in use:<br />
* check for form labels<br />
* ensure mutual association and matching of the "for" attribute of the "label" element to the "id" attribute of the "form" element<br />
* if feildset and legend are used, ensure they are properly formed</p><br />
<br />
====References====<br />
* <span style="color:#808080;">link to </span> {appropriate section in [http://www.w3.org/WAI/intro/people-use-web/principles Accessibility Requirements page]}<br />
* <span style="color:#808080;">link to </span>Handle - Understanding Success Criteria x.x.x (Level xx)<br />
* <span style="color:#808080;">link to </span>{BAD example}<br />
<br />
====Notes====<br />
<span style="color:#808080;">[can be internal notes for now or maybe will be included in final doc]</span><br />
*...<br />
<br />
===Tables [Ian drafting, eta 2012-12-07]===<br />
<span style="color:#808080;">EOWG notes.<br />
<br/> 5min: no, too complex.<br />
<br /> 15min: not sure (need to see it drafted first :-) </span><br />
...<br />
<br />
===Check flickering, flashing, blinking [open for drafting]===<br />
<span style="color:#808080;">EOWG notes.<br />
<br/> 5min: no.<br />
<br /> 15min: maybe not. </span><br />
...<br />
<br />
===WAI-ARIA [Wayne is drafting (although probably not including this one)]===<br />
<span style="color:#808080;">EOWG notes.<br />
<br/> 5min: no.<br />
<br /> 15min: no. </span><br />
<p>Checking ARIA interactively is not part of a preliminary or<br />
ongoing test. It should be left for an formal audit. </p><br />
<p>There is lexical testing available through plugins in some<br />
browsers. These programs show elements using ARIA parameters and<br />
delineate the values. For a preliminary or interim accessibility<br />
test, this is enough. Without a plugin one can search code<br />
for ARIA parameters manually, but this is tedious and can miss<br />
problems. </p><br />
<p>SC. 4.1.2 (Name, Role, Value) applies here. It is Level A. ARIA testing is required whenever AJAX or other rich internet applications are used.<br />
</p><br />
<br />
Note: not a requirement for accessibility and WAI-ARIA is not finalized yet, so probably won't include WAI-ARIA in the 15 minute check.<br />
<br />
===Time-dependent responses [probably not including this one]===<br />
<span style="color:#808080;">EOWG notes.<br />
<br/> 5min: no.<br />
<br /> 15min: no. too hard to check and not vital to many users.</span><br />
...<br />
<br />
===Window resize [probably not including this one]===<br />
<span style="color:#808080;">EOWG notes.<br />
<br/> 5min: no.<br />
<br /> 15min: no. probably too complex an issue from preliminary eval</span><br />
...<br />
<br />
===Validate HTML & CSS [probably not including this one]===<br />
<span style="color:#808080;">EOWG notes.<br />
<br/> 5min: no<br />
<br /> 15min: WCAG requirement issue too complex. </span><br />
...<br />
<br />
Note: Validation not WCAG requirement...<br />
* ...<br />
* Check that the document language is declared<br />
<br />
===Check usable without CSS, javascript [Wayne is drafting (though maybe not including this one)]===<br />
<span style="color:#808080;">EOWG notes.<br />
<br/> 5min: no.<br />
<br /> 15min: not as a separate item. maybe integrated as a technique to check other points.</span><br />
<br />
NOTE: Shadi notes this is not a WCAG requirement<br />
<br />
NOTE: Wayne notes this is a ''technique'' for finding WCAG compliance problems (not that it is a requirement itself)<br />
<br />
* Disable CSS<br />
* core content available<br />
* check images, check content displayed or not displayed (e.g., display:none), sequence<br />
* links<br />
* ...<br />
Reasonable display without style is a US Section 508 requirement, and is a significant weakening of accessibility in WCAG 2.0. I think this needs to be discussed. Most pages than cannot pass this, cannot pass SC 1.4.4 (Resize Text). Also, pages that pass this pass SC 1.4.4 . The user applies no style, then enlarges at will. I will cover this. Wayne<br />
<br />
===Use an evaluation tool [probably won't include this generically]===<br />
<span style="color:#808080;">EOWG notes.<br />
<br/> 5min: no.<br />
<br /> 15min: not as a separate item. use of tools will be integrated in specific checks. generally running a tool gives too complicated results for a quick check.</span><br />
<br />
*Use one-page auto checker<br />
EOWG discussion:<br />
* There are a number of simple tools where you just put in the URL of the page of interest and the results are returned automatically eg WAVE and TAW. The results aren't necessarily so easy to interpret if you are a newbie to accessibility. Perhaps we should put this after the top 5 easy checks - and add a paragraph to confirm the benefits and limitations, or discuss some of the common types of problem found {Suzette}<br />
<br />
==More Thorough Evaluation==<br />
@@ point to Conformance Evaluation page and WCAG-EM.<br />
<br />
==Contributors==<br />
Thanks to:<br />
* Those who drafted checks 16-28 November:<br />
** Sharron for drafting {list sections!}<br />
** <span style="background:yellow;">{name} for drafting {section}</span><br />
* Andrew & Shawn for editing the [http://www.w3.org/WAI/EO/wiki/Web_Accessibility_Preliminary_Evaluation#Check_keyboard_access_and_visual_focus_.5Bmostly_drafted.5D keyboard access & visual focus section] in early Nov.<br />
* Ian, Suzette, Vicki, Sylvie, Helle, Shawn for working on an early draft at the [http://www.w3.org/2012/11/02-eo-minutes f2f in Nov].<br />
* Sharron for help making all the drafts and versions less confusing.<br />
* Wayne and Ian for sharing colleagues' related work.<br />
* Denis for edits to the old page content.</div>Wdickhttps://www.w3.org/WAI/EO/wiki/index.php?title=Web_Accessibility_Preliminary_Evaluation&diff=2310Web Accessibility Preliminary Evaluation2012-11-29T20:49:46Z<p>Wdick: /* Check color contrast [Suzette is drafting] */</p>
<hr />
<div>Nav: [[Main Page|EOWG wiki main page]] > [[Main_Page#Evaluation_pages | Evaluation Pages ]]<br/><br />
Old page on WAI website: [http://www.w3.org/WAI/eval/preliminary.html Prelim Eval]<br/><br />
<br />
Note:<br />
* '''A template for the check items is at the top of the [http://www.w3.org/WAI/EO/wiki/Talk:Web_Accessibility_Preliminary_Evaluation discussion tab].'''<br />
* For tasks, example user cases with audience, and focus for this and related documents, see the [[Eval Analysis]] page<br />
* For previous drafts and contributed material, see:<br />
** Old page with Denis' edits and Ian's input in [[Preliminary Eval - old notes]]<br />
** Extensive revisions and suggestions at [[Archived_Work_on_PreLimEval]]<br />
** From Wayne & Tom [[Prelim Eval input: Smart analysis simplified]]<br />
<br />
<span style="background:yellow;">'''''Important Note''''': For this draft we have some tool-specific guidance. However, there are potential issues with vendor-neutraility and we might need to address this a different way &mdash; for example, moving tool-specific guidance to WebPlatform Docs or the WAI-Engage wiki where people can easily add other tools.</span><br />
<br />
<br />
__TOC__<br />
<br />
<span style="background:yellow;">'''''Important Note''''': For this draft we have some tool-specific guidance. However, there are potential issues with vendor-neutraility and we might need to address this a different way &mdash; for example, moving tool-specific guidance to WebPlatform Docs or the WAI-Engage wiki where people can easily add other tools.</span><br />
<br />
=Preliminary Review|Evaluation: Checking the Accessibility of a Web Page=<br />
<br />
==Introduction==<br />
<p>Testing and evaluating a web site for accessibility may seem intimidating but it need not be. There are simple ways to check on some basic features that do not require special skills or tools beyond your browser controls. Here you will find two approaches to doing Preliminary Evaluation of your pages. The first is a Quick Check - a list of 5 things you can do in 5 minutes. The second, while not a full conformance validation of WCAG2 Guidelines, will help ensure basic accessibility across a broader range of issues. While the second can quickly determine if the most important elements of a web page can be used by most persons with disabilities, it also requires more knowledge of accessibility principles and a few testing tools.</p><br />
<br />
<p>... @@ first run on good BAD page to see what it should look like, then on the bad page ... </p><br />
<br />
==Quick Checks==<br />
<br />
<p>Here are 5 things you can do to quickly check for accessibility barriers on a web page:<br /><br />
<span style="color:#808080;">{EOWG note: Let's work on the longer section first, then decide what we can move up to the quick checks section later.</span></p><br />
#First thing.<br />
#Second thing.<br />
#Third thing. <br />
#Fourth thing. <br />
#Fifth thing.<br />
<br />
Once you have taken this quick dip you may be ready to dive a bit deeper. The next section provides more context and additional things you can do to check for accessibility barriers.<br />
<br />
==A Deeper Look==<br />
<p>If you are interested in a more comprehensive look at the page(s), here more tests that require a little more time, skills, and/or tools.</p><br />
<br />
<span style="color:#808080;">''{reminder: A template for the check draft items is at the top of the [http://www.w3.org/WAI/EO/wiki/Talk:Web_Accessibility_Preliminary_Evaluation discussion tab].}''</span><br />
<br />
===Check text descriptions for images [mostly drafted]===<br />
<span style="color:#808080;">EOWG notes - importance: HIGH.<br />
<br/> 5min: yes, at least the easy part.<br />
<br /> 15min: yes. might want additional checks here.</span><br />
<br />
<p>Text alternatives convey the purpose of an image or function to provide an equivalent user experience for a user who may not see the images. For instance, a text alternative for a search button is "search".<br />
====What to do====<br />
# Disable images in the browser<br />
# Turn off CSS in the browser<br />
# Use free checking tools to list the text alternatives (or lack of them) for all graphic elements<br />
# If content is multimedia, see also </p> <br />
====What to look for====<br />
<p>If the images are CSS (background images), visually inspect when CSS is disabled to ensure that no meaningful element is removed from the content</p><br />
<p>For content delivered as an HTML img element, examine the result and follow this decision tree. For each element of type img: <br />
* Is there an attribute of type alt?<br />
** No: Item fails, this check is complete.<br />
** Yes: Continue on<br />
* Is the image purely decorative? <br />
** No: Continue on<br />
** Yes: Verify that alt="". Test complete <br />
* Is image the only content of a link or form control? <br />
** No: Continue on<br />
** Yes: Verify that the alt attribute clearly communicates the destination of the link or action taken.<br />
* Is image link also present as link text nearby? <br />
** No: Continue on<br />
** Yes: ensure that image and text are both within one anchor tag and that alt="". Test complete. <br />
* Does image contain text? <br />
** No: Continue on <br />
** Yes: Is image text also available as real text nearby?<br />
*** No: Verify that the alt attribute echoes the onscreen text exactly. Test complete.<br />
*** Yes: Verify that alt="" Test complete.<br />
* Does the image contribute meaning to the current page or context? <br />
* No: Continue on<br />
* Yes: Is image a simple graphic or photo?<br />
** Yes: Verify that alt=“brief description of image meaning”. Also verify that brief description does NOT contain words like photo, image, picture, graphic, etc, unless intrinsic to the meaning. Test complete. <br />
** No: Is image visually complex (for example, a graph, chart, or other image of complex meaning)? <br />
*** Yes: Verify that alt=“brief description” AND that there is also an explanation of the full information as a caption, a data table, a long description, or a paragraph positioned off screen that provides equivalent meaning. Test complete.<br />
</p><br />
<br />
====References====<br />
* [http://www.w3.org/WAI/intro/people-use-web/principles#alternatives Text alternatives for non-text content section in Accessibility Principles]<br />
* [http://www.w3.org/TR/UNDERSTANDING-WCAG20/text-equiv-all.html Understanding Success Criteria 1.1.1] (LevelA)<br />
* [http://www.w3.org/WAI/demos/bad/before/annotated/home.html Examples of incorrect, missing, or inadequate alt text] from WAI's Before and After Demo<br />
<br />
====Notes====<br />
<ul><br />
<li>Text that is actually an image.</li><br />
<li>Important image should have alt text that provides adequate alternative of the image for people who cannot see it...</li><br />
<li>Image that doesn't convey important information...</li><br />
<li>@@ Some guidance on not saying things like "this is an image..." or "this is a link..."</li><br />
</ul><br />
<br />
===Check headings and other semantic structure [some parts drafted]===<br />
<span style="color:#808080;">EOWG notes - importance: HIGH.<br />
<br/> 5min: maybe. fairly easy to check if there are at least some headings.<br />
<br /> 15min: yes.</span><br />
<br />
... @@ brief summary of why & what to check for ...<br />
See also:<br />
* ? [http://www.w3.org/TR/2012/NOTE-WCAG20-TECHS-20120103/G141 G141 technique]<br />
* ? [http://www.w3.org/TR/2012/NOTE-WCAG20-TECHS-20120103/H42 H42 technique]<br />
<br />
What you're looking for: @@<br />
<ul><br />
<li>Does the page have any headings?</li><br />
<li>Are the things that look like headings that aren't marked up as heading?</li><br />
<li>Are there things that are marked up as headings that aren't really headings?</li><br />
</ul><br />
<br />
====Checking with WAVE====<br />
<ol><br />
<li>Open [http://wave.webaim.org/ WAVE]</li><br />
<li>Enter the web page:<br />
<ul><br />
<li>If the website is online: Enter a web site address and click the "WAVE the page!" button.</li><br />
<li>... Upload a file...</li><br />
<li>... Check HTML code...</li><br />
</ul></li><br />
<li>Check headings:<br />
<ul><br />
<li>...</li><br />
</ul></li><br />
<li>Check lists:<br />
<ul><br />
<li>...</li><br />
</ul></li><br />
</ol><br />
<br />
====Checking headings with HTML Validator====<br />
<ol><br />
<li> Open the [http://validator.w3.org/ W3C HTML Validator (The W3C Markup Validation Service)].</li><br />
<li>Select the appropriate tab and input the page:<br />
<ul><br />
<li>If the web page is online, leave the '''Validate by URI''' tab selected. <br />In the Address field, type the URI (e.g., www.w3.org).</li><br />
<li>If the web page is on your local computer, click the '''Validate by File Upload''' tab.<br />In the File field, select &quot;Choose...&quot; and find the file on your computer.</li><br />
<li>If you will paste the HTML code/markup, '''Validate by Direct Input''' tab.<br />Paste your HTML in the Enter the Markup to validate: field.</li><br />
</ul><br />
</li><br />
<li>Click the More Options link.</li><br />
<li>Select the Outline checkbox.</li><br />
<li>Click the Check button.</li><br />
<li>In the results page at the top, click the Outline link.</li><br />
<li>Compare the Document Outline to the visual rendering of the page. <ul><br />
<li>Are the things that look like headings listed in the Document Outline?</li><br />
<li>Are there things in the Document Outline that aren't really headings?<br /><br />
</li><br />
</ul></li><br />
</ol><br />
<br />
===Check keyboard access [mostly drafted]===<br />
<span style="color:#808080;">EOWG notes - importance: HIGH.<br />
<br/> 5min: maybe.<br />
<br /> 15min: yes.</span><br />
<br />
Many people do not use the mouse and rely on the keyboard to interact with the Web. This requires keyboard access to all functionality, including links, form controls, input, and other user interface components. <br />
====What To Do====<br />
* Click in the address bar, then put your mouse aside and don't use it. <br />
* Press the 'tab' key to move around the page.<br />
''(see also Forms)''<br />
<br />
''(see also Visible Focus)''<br />
====What To Look For====<br />
* Can you tab to all the elements, including links, form fields, buttons, and media player controls? Are there any actions you can't get to (e.g., if they are only available on mouse hover)?<br />
* Does the focus get stuck anywhere - that is, you can tab into a control but not out? (called a "keyboard trap")?<br />
* Does the order that items get focus make sense to sighted users? (e.g., you don't jump around the page out of order logically)<br />
* Can you tab right through to the bottom of the page and then resume again from the top? (e.g. you don't get stuck anywhere and can't move on)<br />
* If there is a drop-down box (for example, for navigating to a different page): If you tab into the drop-down box, can you use the down/up arrow keys to move through the options, and @@use 'tab' to the following item@@? (Make sure it doesn't automatically select the first item.)<br />
====References====<br />
* [http://www.w3.org/WAI/intro/people-use-web/principles#keyboard Functionality is available from a keyboard]<br />
* [http://www.w3.org/WAI/users/browsing#keyboard Browsing the Web by Keyboard] section in [http://www.w3.org/WAI/users/browsing Better Web Browsing: Tips for Customizing Your Computer]<br />
* Example: [http://www.w3.org/WAI/demos/bad/before/survey.html web page template that does not enable keyboard access] from the WAI Before and After Demo (BAD)<br />
====Notes====<br />
* Mac browsers by default only tab through forms, will need to turn on...<br />
* not work easily in Opera...<br />
* ...<br />
<br />
===Visible focus [mostly drafted]===<br />
<br />
<span style="color:#808080;">EOWG notes.<br />
<br/> 5min: probably not (unless merged with keyboard access)<br />
<br /> 15min: probably</span><br />
<br />
'''''NOTE: Should this be merged with the keyboard access?'''''<br />
<br />
<p>Use keyboard only navigation to ensure that a user who relies on the keyboard will be able to know which element among multiple elements has the keyboard focus. This is an important element in facilitating success for keyboard users to operate the page, by letting them visually determine the component on which keyboard operations will interact at any point in time. People with attention limitations, short term memory limitations, or limitations in executive processes benefit by being able to discover where the focus is located.</p><br />
<br />
====What to do====<br />
# Use the keyboard to set the focus to all focusable elements on the page.<br />
<br />
====What to look for====<br />
# Visually examine progress through elements and verify that the focus indicator is visible.<br />
# Common failures occur when the default focus indicator is turned off in CSS or when the element is styled with borders that occlude the focus indicator.<br />
# Verify that any visual changes that occur with mouse hover also are triggered with keyboard focus<br />
<br />
====References====<br />
* [http://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-focus-visible.html Focus Visible - Understanding Success Criteria 2.4.7 (Level A)] <br />
* <span style="color:#808080;">[Found no relevant BAD example, Shadi is checking]</span><br />
* <span style="color:#808080;">[nothing specific in Accessibility Requirements page]</span><br />
<br />
===Check the page title [mostly drafted]===<br />
<span style="color:#808080;">EOWG notes - importance: medium.<br />
<br/> 5min: maybe not. it is easy to check, but a little more complicated to explain what makes a good title. Also not the most vital to lots of users.<br />
<br /> 15min: probably.</span><br />
<br />
@@ add image showing only a few words with multiple tabs in browser...<br />
<br />
Page titles are the first information read by a screen reader; useful for when users have multiple web pages opens, e.g., on different tabs and go between different windows. (Also good for adding to bookmarks & also search engine results.) <br />
<br />
====What to do====<br />
# Look at the browser's window title bar.<br />
# Look at titles of other pages within the site.<br />
<br />
====What to look for====<br />
* Verify that the title indicates the specific page and website and distinguishes the current page from others in the set of pages.<br />
* Make sure that every page in the site does not have the same title.<br />
* Check that the specific page title is listed BEFORE the name of the website. (for example, ''About Us - Our Long Web Site Name'')<br />
<br />
====References====<br />
* [http://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-title.html Page Titled- Understanding SC 2.4.2]<br />
* Consider if the page titles of all of the [http://www.w3.org/WAI/demos/bad/Overview.html Before and After Demo] had been the same. Instead, each has a distinctive name that identifies its function within the set of pages.<br />
====Notes====<br />
* Some browsers don't show title in browser title bar (Chrome, IE)<br />
<br />
===Check link text [partly drafted]===<br />
<span style="color:#808080;">EOWG notes.<br />
<br/> 5min: maybe not.<br />
<br /> 15min: maybe. fairly easy to check. not the most vital for lots of users.</span><br />
<br />
Wording the text that is linked to indicate clearly where the link goes or what the link does. Some people use a list of links where they don't see the text around it. See also:<br />
* [http://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-refs.html Link Purpose (In Context): Understanding SC 2.4.4] (Level A)<br />
* [http://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-link.html Link Purpose (Link Only): Understanding SC 2.4.9] (Level AAA)<br />
* [BAD]<br />
<br />
Check this<br />
* @@<br />
** @@<br />
<br />
Common failures:<br />
* Link text is something like "Click here" or "More" without any additional clarifying text.<br />
<br />
Notes:<br />
* List links (Can't find this in regular Firefox but easy in Opera where you can get a list of links from the standard tools menu, showing both title and url)<br />
* Issue - titles... ([http://ianpouncey.com/weblog/2010/01/title-attributes/ Ian P says never use titles on links], Sylvie agrees.)<br />
<br />
===Check usable with page zoomed and text enlarged [Suzette drafted for discussion]===<br />
<span style="color:#808080;">EOWG notes.<br />
<br/> 5min: no<br />
<br /> 15min: maybe not.</span><br />
* Zoom to 200%<br />
* Text-only enlargement... (e.g., text actually changes in IE)<br />
<br />
People with mild to moderate visual impairments may need to enlarge text in order to read it, or read it without straining. This simple requirement is mostly achieved by the functionality of the browser and ensuring that the page design supports that functionality. <br />
<br />
The text should be resizable up to 200% without losing information, using a standard browse. Additionally any images of text should also be resizable or replaced with actual text. <br />
<br />
Most modern browsers now offer a zoom function which enlarges both text and other content together. Some older browsers do not resize text if it was set using fixed units – such as points or pixels. <br />
<br />
====What to do====<br />
* Open your preferred browsers. Internet Explorer, Firefox, Chrome and Opera all offer zoom as a function of View or Function menus, or as a keyboard shortcut (usually, Control +, or for Mac Command +). <br />
* Set the screen window to full width<br />
* Use the zoom function or keyboard shortcut repeatedly to step up to a 200% increase. <br />
* Look at the main content, buttons, tabs and text entry fields and field labels.<br />
* Repeat with a different browser.<br />
====Common failures====<br />
* Is the default body text unusually small?<br />
* Does the main heading and body text increase in size? <br />
* Has any text that is part of a control, button, menu item or label increased in size? <br />
* Does any text overflow its space – for example, the text is too big for the button or menu tab, or width or depth of the column?<br />
* Can you read to the end of the line, or does some text disappear off the screen so that you have to scroll right to the end of the line?<br />
=====Note=====<br />
Some browsers can expand the text beyond 200% - this is not covered by the resize requirement as it is recognised that this will cause some of the failures described. It is also accepted that some horizontal scrolling may be necessary but see also 1.4.8 which is a AAA requirement. <br />
Users with more severe visual impairments who need larger text are likely to use screen magnifiers to increase text size above 200%. <br />
====References====<br />
*link to {appropriate section in Accessibility Requirements page http://www.w3.org/WAI/intro/people-use-web/principles#distinguishable} (doesn’t have a lot to say)<br />
*Guideline 1.4 Distinguishable: Make it easier for users to see and hear content including separating foreground from background. <br />
*Resize text: Understanding Success Criteria 1.4.4 (Level AA) {http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-scale.html}<br />
*Images of Text: Understanding Success Criteria 1.4.5 (Level AA) http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-text-presentation.html<br />
*Visual Presentation: Understanding Success Criteria 1.4.8 (Level AAA)http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-visual-presentation.html<br />
*link to {BAD example} No specific BAD examples – some reference to Text as image in relation to the phone number, and column width.<br />
<br />
====Notes for discussion====<br />
*Scrolling: see Visual Presentation: Understanding Success Criteria 1.4.8 (Level AAA) includes:<br />
** Text can be resized without assistive technology up to 200 percent in a way that does not require the user to scroll horizontally to read a line of text on a full-screen window.<br />
*Do we need to spell out the difference between zooming and resizing? Is resizing still important for people who use style sheets?<br />
*Do we still need to worry about IE6 which didn’t resize fixed font sizes?<br />
*Browsers are now hiding their menus – eg under the cogwheel icon, which is making it harder to know where to find the zoom option, however they seem to be reasonably consistent on keyboard shortcuts. Other options include pinch and zoom on trackpad or intellimouse<br />
<br />
===Check color contrast [Suzette is drafting]===<br />
<span style="color:#808080;">EOWG notes.<br />
<br/> 5min: maybe.<br />
<br /> 15min: yes.</span><br />
<br />
First pass - I'm working on this:<br />
<br />
Good colour contrast between the text and background is very important to people with visual impairements. Some users may chose to vary your colour choice by using their own preferred style sheet. <br />
<br />
Screen reader users will hear the text even if the contrast is poor, or deliberately hidden as white on white or black on black!<br />
<br />
* First stage - look out for instances of pale text that might blend into the background eg grey on the default off-white background. Other common combinations are pale green, yellow or blue text on a background of a slightly darker shade of the same colour. Check the text in the main content, menu tabs, links and selected links and in buttons, labels and captions. Any suspect instances need to be investigated. <br />
<br />
Remember that not all users will have high resolution screens and subtle colour combinations may not be rendered properly if the user is using a reduced colour set.<br />
<br />
* Second stage - a number of on-line tools can be used to compare the exact ratio of text and background. Use zoom to increase the font size and follow the tool instructions to pick up a sample of the text colour and a sample of the background colour. If the background is patterned take a sample at different points. The minimum contrast (level AA) is 4.5:1<br />
<insert from Wayne Dick><br />
<p> There are two types of color contrast testers: The first type, a<br />
lexical evaluator, looks at styles in web page code and<br />
computes color contrasts based on coded values. The second type,<br />
run time tester, simply allows the user to sample what is on the<br />
screen and computes contrast based on samples. </p><br />
<p> The lexical evaluator examines what the author declares. It<br />
gives a full page report based color contrasts declared by the<br />
programmer. These tests are quick and efficient. They break down<br />
when run time values change due to actions taken by active<br />
content.</p><br />
<p> The run time tester requires more hands on work. The evaluator<br />
can take samples as the web site runs and determine actual<br />
contrasts. The problem here is that as contrasts change over time<br />
the tester must sample many states of the page. </p><br />
<p> Both types of test are important. If any active content changes<br />
color during run time then WAI advises run time testing. Lexical<br />
testing can be very useful and save time with items with static <br />
color. </p><br />
<br />
<end Wayne's insert><br />
Ref: Contrast (minimum) 1.4.3 http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-contrast.html <br />
<br />
also Contrast (enhanced) 1.4.6 <br />
Note: There are some exceptions and special requirements to achieve full conformance.<br />
<br />
===Check color coding and shape coding [Suzette draft]===<br />
<span style="color:#808080;">EOWG notes.<br />
<br/> 5min: no<br />
<br /> 15min: maybe not. not easy to check thoroughly. not vital for many users.</span><br />
<br />
[Notes: refers specifically to: '''1.4.1 Use of Color''': Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.<br />
<br />
NB. consider if other sensory characteristics [such as shape, size, visual location, orientation, or sound] sould be combined here. See '''1.3.3 Sensory Characteristics''': Instructions provided for understanding and operating content do not rely solely on sensory characteristics of components such as shape, size, visual location, orientation, or sound.]<br />
<br />
Colour, shape and location are often used as a code or visual cue to help people to identify important information or actions on a busy web page. <br />
<br />
These visual cues are not always available – someone who is colour blind may find it difficult to distinguish some or all colour combinations. And in addition, people using some types of assistive technology such as a screen reader, Braille or other alternative display systems will not ‘see’ the cue.<br />
<br />
It helps to use both colour and a symbol together – for example a red asterisk, provides both a colour and shape code. Alt text on any symbols or icons should make the functional meaning obvious. Any text instructions should allow for someone who cannot see the visual cue. <br />
<br />
====What to do====<br />
Inspect the page carefully to identify any instances of visual cues:<br />
* Colour - either coloured text or tinted backgrounds and including in-text links.<br />
* Shape - including icons and symbols, and glyphs such as a smiley face or no entry symbol, or a graphic X to draw attention to removing an item in a shopping list.<br />
* Location - positioning a symbol or instruction at the top, bottom or side of the main text<br />
* Text descriptions or instructions - inspect the text for instructions that refer to colour, shape or location such as the button on the left, or the red square.<br />
<br />
====Common failures====<br />
* In a form, colour used to indicate a required field, or as part of an error messages when a required field is not completed and there is no additional cue such as a colour coded symbol?<br />
* Text links - colour used alone to indicate links in a paragraph of text, and, there is no additional cue such as underlining?<br />
* Text instructions, the instruction does not make sense if you can't see the colour, shape or the location of a control button described.<br />
* Providing alternative text for symbols and icons - in general these need to refer to the function and not the visual appearance. For example if ‘red square’ is the button for the function ‘stop’, then the alt text should say ‘stop’ and not 'red square'. <br />
<br />
====References====<br />
Use of colour: Understanding success criteria 1.4.1 (Level A) {http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-without-color.html}<br />
<br />
Sensory Characteristics: Understanding success criteria 1.3.3 (Level A) { http://www.w3.org/TR/UNDERSTANDING-WCAG20/content-structure-separation-understanding.html}<br />
<br />
See also: Non-text equivalent 1.1.1 (A) for appropriate text equivalents for any symbols, icons or glyphs and Contrast 1.4.3 (AA) for colour contrast.<br />
<br />
====Notes for discussion====<br />
I put colour, shape and location together because functionally they are about visual coding – is this too big a step?<br />
<br />
Also - should the common failures be descriptive, suggest a solution or ask a question? I got a bit confused here :(<br />
<br />
===Content order [open for drafting]===<br />
<span style="color:#808080;">EOWG notes.<br />
<br/> 5min: no.<br />
<br /> 15min: maybe. </span><br />
<br />
'''''NOTE: Should this be merged with the keyboard access check?'''''<br />
<br />
===Video, Sound, (multimedia) [partly drafted]===<br />
<span style="color:#808080;">EOWG notes.<br />
<br/> 5min: maybe. vital for some uses, through maybe not really easy to check thoroughly<br />
<br /> 15min: yes.</span><br />
<br />
====What to do====<br />
# Play the audio content<br />
# Play the video content<br />
# Toggle closed captions on (if available) <br />
# Toggle audio description on (if available) <br />
====What to look for====<br />
* Captions:<br />
** Verify that they synchronized to the spoken content<br />
** Ensure they are accurate and complete (not missing any content)?<br />
** Verify that they are properly formed? (correct spelling, sentence structure, punctuation)<br />
** Make sure that audio content other than dialogue is inlcuded (music, relevant ambient sounds, etc)<br />
* Audio Description<br />
** '''(Judgement call)''' Watch the video content to verify that audio description is needed for complete understanding.<br />
** If needed, verify that they are provided in a separate track that can be toggled on and that they provide context for those who do not see the video.<br />
* Transcript: As a fall-back when captions and audio descriptions are not provided, check to see if there is text-based content that contains dialogue, any other audio content, and any necessary description of video content. Check for spelling and accuracy. <br />
''(see also keyboard access for player controls)''<br />
<br />
''(see also text alternatives for graphic content)''<br />
<br />
====References====<br />
* [http://www.w3.org/2008/06/video-notes Multi Media FAQs] from the W3C<br />
* [http://www.w3.org/TR/UNDERSTANDING-WCAG20/media-equiv-captions.html Understanding WCAG SC 1.2.2 Captions](Level A)<br />
* [http://www.w3.org/TR/UNDERSTANDING-WCAG20/media-equiv-audio-desc.html Understanding 1.2.5 Audio Description](Level A) <br />
====Notes====<br />
<span style="color:#808080;">[can be internal notes for now or maybe will be included in final doc]</span><br />
*...<br />
<br />
===Forms===<br />
<span style="color:#808080;">EOWG notes.<br />
<br/> 5min: no, too complicated.<br />
<br /> 15min: not sure (need to see it drafted first :-)</span><br />
<br />
<p>Forms are everywhere on the web and successful user interaction relies on clear, understandable, and accessible form controls. Several principles of accessibility should be kept in mind when testing forms. Labels for form controls, input, and other user interface components must be provided. Many people do not use the mouse and rely on the keyboard to interact with the Web. This requires visible keyboard access to all functionality, including form controls. Forms may be confusing or difficult to use for many people, and, as a result, they may be more likely to make mistakes. Clear recovery mechanisms must be provided.</p> <br />
<br />
====What to do====<br />
<p>Evaluating the accessibility of form controls is one area in which a testing tool comes in very handy. Free web developer tools and accessibility checkers can be downloaded and installed in various browsers and having one installed will make this process much easier. <span style="color:#808080;">SR Note: Do we recommend a tool? Link to the testing tools section of the WAI pages?</span></p> <br />
# Visually examine the forms<br />
# Put the mouse aside and tab through form controls<br />
# Turn images off in the browser and examine submit buttons and other controls<br />
# Turn off CSS in the browser<br />
# Enter data in form input fields <br />
# Deliberately enter an error and then submit form<br />
# Use browser based testing tools to examine form detail<br />
<br />
====What to look for====<br />
<p>Each form control must have an associated label that describes its purpose. Tab order between form controls must match the order in which a user would normally complete them. Complex forms benefit from grouping controls with the FIELDSET element. The form title is optional if the purpose of the form can be determined from context. "Placeholder" text inside text boxes is no longer needed for screen readers; it is redundant in a properly-labeled form. Many forms will also have to be evaluated separately for dynamic behavior such as error response. Listed below are some things that you will look for.</p> <br />
<p>When visually reviewing the form, note the following:<br />
* if required fields are indicated by use of color cues, ensure that additional, redundant methods are also used.<br />
* ensure that related form controls are logically grouped together (perhaps using fieldset and legend, see the section below with testing tools)</p> <br />
<p>When tabbing through form inputs:<br />
* ensure that focus moves logically between the fields.<br />
* ensure that focus is visible on all form controls, including inputs, submit mechanisms, and check boxes and radio buttons.<br />
* if form control is check box or radio button, ensure that focus indication includes form label as well as the actual control<br />
* if form control is select box, ensure that arrow keys can move focus between select options and that selection is made by user action and not by default focus.</p><br />
<p>With images and/or background images turned off in the browser:<br />
* ensure that form controls remain evident and operable<br />
* ensure that any "required" status indicators remain evident</p><br />
<p>When entering data: <br />
* ensure that focus does not automatically advance to the next field, but requires user input to advance </p><br />
* if a certain response triggers presentation of new content,that content is exposed to the keyboard as well.</p><br />
<p>When erroneous data is entered and form submitted:<br />
* ensure that error message is clear and specific about the nature of the error and the field in which it was made<br />
* ensure that focus moves to the error message<br />
* ensure that guidance is provided to help user understand and fix the error. </p><br />
<p>If browser-based testing tool is in use:<br />
* check for form labels<br />
* ensure mutual association and matching of the "for" attribute of the "label" element to the "id" attribute of the "form" element<br />
* if feildset and legend are used, ensure they are properly formed</p><br />
<br />
====References====<br />
* <span style="color:#808080;">link to </span> {appropriate section in [http://www.w3.org/WAI/intro/people-use-web/principles Accessibility Requirements page]}<br />
* <span style="color:#808080;">link to </span>Handle - Understanding Success Criteria x.x.x (Level xx)<br />
* <span style="color:#808080;">link to </span>{BAD example}<br />
<br />
====Notes====<br />
<span style="color:#808080;">[can be internal notes for now or maybe will be included in final doc]</span><br />
*...<br />
<br />
===Tables [Ian drafting, eta 2012-12-07]===<br />
<span style="color:#808080;">EOWG notes.<br />
<br/> 5min: no, too complex.<br />
<br /> 15min: not sure (need to see it drafted first :-) </span><br />
...<br />
<br />
===Check flickering, flashing, blinking [open for drafting]===<br />
<span style="color:#808080;">EOWG notes.<br />
<br/> 5min: no.<br />
<br /> 15min: maybe not. </span><br />
...<br />
<br />
===WAI-ARIA [Wayne is drafting (although probably not including this one)]===<br />
<span style="color:#808080;">EOWG notes.<br />
<br/> 5min: no.<br />
<br /> 15min: no. </span><br />
<br />
<br />
Note: not a requirement for accessibility and WAI-ARIA is not finalized yet, so probably won't include WAI-ARIA in the 15 minute check.<br />
<br />
===Time-dependent responses [probably not including this one]===<br />
<span style="color:#808080;">EOWG notes.<br />
<br/> 5min: no.<br />
<br /> 15min: no. too hard to check and not vital to many users.</span><br />
...<br />
<br />
===Window resize [probably not including this one]===<br />
<span style="color:#808080;">EOWG notes.<br />
<br/> 5min: no.<br />
<br /> 15min: no. probably too complex an issue from preliminary eval</span><br />
...<br />
<br />
===Validate HTML & CSS [probably not including this one]===<br />
<span style="color:#808080;">EOWG notes.<br />
<br/> 5min: no<br />
<br /> 15min: WCAG requirement issue too complex. </span><br />
...<br />
<br />
Note: Validation not WCAG requirement...<br />
* ...<br />
* Check that the document language is declared<br />
<br />
===Check usable without CSS, javascript [Wayne is drafting (though maybe not including this one)]===<br />
<span style="color:#808080;">EOWG notes.<br />
<br/> 5min: no.<br />
<br /> 15min: not as a separate item. maybe integrated as a technique to check other points.</span><br />
<br />
NOTE: Shadi notes this is not a WCAG requirement<br />
<br />
NOTE: Wayne notes this is a ''technique'' for finding WCAG compliance problems (not that it is a requirement itself)<br />
<br />
* Disable CSS<br />
* core content available<br />
* check images, check content displayed or not displayed (e.g., display:none), sequence<br />
* links<br />
* ...<br />
Reasonable display without style is a US Section 508 requirement, and is a significant weakening of accessibility in WCAG 2.0. I think this needs to be discussed. Most pages than cannot pass this, cannot pass SC 1.4.4 (Resize Text). Also, pages that pass this pass SC 1.4.4 . The user applies no style, then enlarges at will. I will cover this. Wayne<br />
<br />
===Use an evaluation tool [probably won't include this generically]===<br />
<span style="color:#808080;">EOWG notes.<br />
<br/> 5min: no.<br />
<br /> 15min: not as a separate item. use of tools will be integrated in specific checks. generally running a tool gives too complicated results for a quick check.</span><br />
<br />
*Use one-page auto checker<br />
EOWG discussion:<br />
* There are a number of simple tools where you just put in the URL of the page of interest and the results are returned automatically eg WAVE and TAW. The results aren't necessarily so easy to interpret if you are a newbie to accessibility. Perhaps we should put this after the top 5 easy checks - and add a paragraph to confirm the benefits and limitations, or discuss some of the common types of problem found {Suzette}<br />
<br />
==More Thorough Evaluation==<br />
@@ point to Conformance Evaluation page and WCAG-EM.<br />
<br />
==Contributors==<br />
Thanks to:<br />
* Those who drafted checks 16-28 November:<br />
** Sharron for drafting {list sections!}<br />
** <span style="background:yellow;">{name} for drafting {section}</span><br />
* Andrew & Shawn for editing the [http://www.w3.org/WAI/EO/wiki/Web_Accessibility_Preliminary_Evaluation#Check_keyboard_access_and_visual_focus_.5Bmostly_drafted.5D keyboard access & visual focus section] in early Nov.<br />
* Ian, Suzette, Vicki, Sylvie, Helle, Shawn for working on an early draft at the [http://www.w3.org/2012/11/02-eo-minutes f2f in Nov].<br />
* Sharron for help making all the drafts and versions less confusing.<br />
* Wayne and Ian for sharing colleagues' related work.<br />
* Denis for edits to the old page content.</div>Wdickhttps://www.w3.org/WAI/EO/wiki/index.php?title=Web_Accessibility_Preliminary_Evaluation&diff=2308Web Accessibility Preliminary Evaluation2012-11-29T20:35:11Z<p>Wdick: /* Check color contrast [Suzette is drafting] */</p>
<hr />
<div>Nav: [[Main Page|EOWG wiki main page]] > [[Main_Page#Evaluation_pages | Evaluation Pages ]]<br/><br />
Old page on WAI website: [http://www.w3.org/WAI/eval/preliminary.html Prelim Eval]<br/><br />
<br />
Note:<br />
* '''A template for the check items is at the top of the [http://www.w3.org/WAI/EO/wiki/Talk:Web_Accessibility_Preliminary_Evaluation discussion tab].'''<br />
* For tasks, example user cases with audience, and focus for this and related documents, see the [[Eval Analysis]] page<br />
* For previous drafts and contributed material, see:<br />
** Old page with Denis' edits and Ian's input in [[Preliminary Eval - old notes]]<br />
** Extensive revisions and suggestions at [[Archived_Work_on_PreLimEval]]<br />
** From Wayne & Tom [[Prelim Eval input: Smart analysis simplified]]<br />
<br />
<span style="background:yellow;">'''''Important Note''''': For this draft we have some tool-specific guidance. However, there are potential issues with vendor-neutraility and we might need to address this a different way &mdash; for example, moving tool-specific guidance to WebPlatform Docs or the WAI-Engage wiki where people can easily add other tools.</span><br />
<br />
<br />
__TOC__<br />
<br />
<span style="background:yellow;">'''''Important Note''''': For this draft we have some tool-specific guidance. However, there are potential issues with vendor-neutraility and we might need to address this a different way &mdash; for example, moving tool-specific guidance to WebPlatform Docs or the WAI-Engage wiki where people can easily add other tools.</span><br />
<br />
=Preliminary Review|Evaluation: Checking the Accessibility of a Web Page=<br />
<br />
==Introduction==<br />
<p>Testing and evaluating a web site for accessibility may seem intimidating but it need not be. There are simple ways to check on some basic features that do not require special skills or tools beyond your browser controls. Here you will find two approaches to doing Preliminary Evaluation of your pages. The first is a Quick Check - a list of 5 things you can do in 5 minutes. The second, while not a full conformance validation of WCAG2 Guidelines, will help ensure basic accessibility across a broader range of issues. While the second can quickly determine if the most important elements of a web page can be used by most persons with disabilities, it also requires more knowledge of accessibility principles and a few testing tools.</p><br />
<br />
<p>... @@ first run on good BAD page to see what it should look like, then on the bad page ... </p><br />
<br />
==Quick Checks==<br />
<br />
<p>Here are 5 things you can do to quickly check for accessibility barriers on a web page:<br /><br />
<span style="color:#808080;">{EOWG note: Let's work on the longer section first, then decide what we can move up to the quick checks section later.</span></p><br />
#First thing.<br />
#Second thing.<br />
#Third thing. <br />
#Fourth thing. <br />
#Fifth thing.<br />
<br />
Once you have taken this quick dip you may be ready to dive a bit deeper. The next section provides more context and additional things you can do to check for accessibility barriers.<br />
<br />
==A Deeper Look==<br />
<p>If you are interested in a more comprehensive look at the page(s), here more tests that require a little more time, skills, and/or tools.</p><br />
<br />
<span style="color:#808080;">''{reminder: A template for the check draft items is at the top of the [http://www.w3.org/WAI/EO/wiki/Talk:Web_Accessibility_Preliminary_Evaluation discussion tab].}''</span><br />
<br />
===Check text descriptions for images [mostly drafted]===<br />
<span style="color:#808080;">EOWG notes - importance: HIGH.<br />
<br/> 5min: yes, at least the easy part.<br />
<br /> 15min: yes. might want additional checks here.</span><br />
<br />
<p>Text alternatives convey the purpose of an image or function to provide an equivalent user experience for a user who may not see the images. For instance, a text alternative for a search button is "search".<br />
====What to do====<br />
# Disable images in the browser<br />
# Turn off CSS in the browser<br />
# Use free checking tools to list the text alternatives (or lack of them) for all graphic elements<br />
# If content is multimedia, see also </p> <br />
====What to look for====<br />
<p>If the images are CSS (background images), visually inspect when CSS is disabled to ensure that no meaningful element is removed from the content</p><br />
<p>For content delivered as an HTML img element, examine the result and follow this decision tree. For each element of type img: <br />
* Is there an attribute of type alt?<br />
** No: Item fails, this check is complete.<br />
** Yes: Continue on<br />
* Is the image purely decorative? <br />
** No: Continue on<br />
** Yes: Verify that alt="". Test complete <br />
* Is image the only content of a link or form control? <br />
** No: Continue on<br />
** Yes: Verify that the alt attribute clearly communicates the destination of the link or action taken.<br />
* Is image link also present as link text nearby? <br />
** No: Continue on<br />
** Yes: ensure that image and text are both within one anchor tag and that alt="". Test complete. <br />
* Does image contain text? <br />
** No: Continue on <br />
** Yes: Is image text also available as real text nearby?<br />
*** No: Verify that the alt attribute echoes the onscreen text exactly. Test complete.<br />
*** Yes: Verify that alt="" Test complete.<br />
* Does the image contribute meaning to the current page or context? <br />
* No: Continue on<br />
* Yes: Is image a simple graphic or photo?<br />
** Yes: Verify that alt=“brief description of image meaning”. Also verify that brief description does NOT contain words like photo, image, picture, graphic, etc, unless intrinsic to the meaning. Test complete. <br />
** No: Is image visually complex (for example, a graph, chart, or other image of complex meaning)? <br />
*** Yes: Verify that alt=“brief description” AND that there is also an explanation of the full information as a caption, a data table, a long description, or a paragraph positioned off screen that provides equivalent meaning. Test complete.<br />
</p><br />
<br />
====References====<br />
* [http://www.w3.org/WAI/intro/people-use-web/principles#alternatives Text alternatives for non-text content section in Accessibility Principles]<br />
* [http://www.w3.org/TR/UNDERSTANDING-WCAG20/text-equiv-all.html Understanding Success Criteria 1.1.1] (LevelA)<br />
* [http://www.w3.org/WAI/demos/bad/before/annotated/home.html Examples of incorrect, missing, or inadequate alt text] from WAI's Before and After Demo<br />
<br />
====Notes====<br />
<ul><br />
<li>Text that is actually an image.</li><br />
<li>Important image should have alt text that provides adequate alternative of the image for people who cannot see it...</li><br />
<li>Image that doesn't convey important information...</li><br />
<li>@@ Some guidance on not saying things like "this is an image..." or "this is a link..."</li><br />
</ul><br />
<br />
===Check headings and other semantic structure [some parts drafted]===<br />
<span style="color:#808080;">EOWG notes - importance: HIGH.<br />
<br/> 5min: maybe. fairly easy to check if there are at least some headings.<br />
<br /> 15min: yes.</span><br />
<br />
... @@ brief summary of why & what to check for ...<br />
See also:<br />
* ? [http://www.w3.org/TR/2012/NOTE-WCAG20-TECHS-20120103/G141 G141 technique]<br />
* ? [http://www.w3.org/TR/2012/NOTE-WCAG20-TECHS-20120103/H42 H42 technique]<br />
<br />
What you're looking for: @@<br />
<ul><br />
<li>Does the page have any headings?</li><br />
<li>Are the things that look like headings that aren't marked up as heading?</li><br />
<li>Are there things that are marked up as headings that aren't really headings?</li><br />
</ul><br />
<br />
====Checking with WAVE====<br />
<ol><br />
<li>Open [http://wave.webaim.org/ WAVE]</li><br />
<li>Enter the web page:<br />
<ul><br />
<li>If the website is online: Enter a web site address and click the "WAVE the page!" button.</li><br />
<li>... Upload a file...</li><br />
<li>... Check HTML code...</li><br />
</ul></li><br />
<li>Check headings:<br />
<ul><br />
<li>...</li><br />
</ul></li><br />
<li>Check lists:<br />
<ul><br />
<li>...</li><br />
</ul></li><br />
</ol><br />
<br />
====Checking headings with HTML Validator====<br />
<ol><br />
<li> Open the [http://validator.w3.org/ W3C HTML Validator (The W3C Markup Validation Service)].</li><br />
<li>Select the appropriate tab and input the page:<br />
<ul><br />
<li>If the web page is online, leave the '''Validate by URI''' tab selected. <br />In the Address field, type the URI (e.g., www.w3.org).</li><br />
<li>If the web page is on your local computer, click the '''Validate by File Upload''' tab.<br />In the File field, select &quot;Choose...&quot; and find the file on your computer.</li><br />
<li>If you will paste the HTML code/markup, '''Validate by Direct Input''' tab.<br />Paste your HTML in the Enter the Markup to validate: field.</li><br />
</ul><br />
</li><br />
<li>Click the More Options link.</li><br />
<li>Select the Outline checkbox.</li><br />
<li>Click the Check button.</li><br />
<li>In the results page at the top, click the Outline link.</li><br />
<li>Compare the Document Outline to the visual rendering of the page. <ul><br />
<li>Are the things that look like headings listed in the Document Outline?</li><br />
<li>Are there things in the Document Outline that aren't really headings?<br /><br />
</li><br />
</ul></li><br />
</ol><br />
<br />
===Check keyboard access [mostly drafted]===<br />
<span style="color:#808080;">EOWG notes - importance: HIGH.<br />
<br/> 5min: maybe.<br />
<br /> 15min: yes.</span><br />
<br />
Many people do not use the mouse and rely on the keyboard to interact with the Web. This requires keyboard access to all functionality, including links, form controls, input, and other user interface components. <br />
====What To Do====<br />
* Click in the address bar, then put your mouse aside and don't use it. <br />
* Press the 'tab' key to move around the page.<br />
''(see also Forms)''<br />
<br />
''(see also Visible Focus)''<br />
====What To Look For====<br />
* Can you tab to all the elements, including links, form fields, buttons, and media player controls? Are there any actions you can't get to (e.g., if they are only available on mouse hover)?<br />
* Does the focus get stuck anywhere - that is, you can tab into a control but not out? (called a "keyboard trap")?<br />
* Does the order that items get focus make sense to sighted users? (e.g., you don't jump around the page out of order logically)<br />
* Can you tab right through to the bottom of the page and then resume again from the top? (e.g. you don't get stuck anywhere and can't move on)<br />
* If there is a drop-down box (for example, for navigating to a different page): If you tab into the drop-down box, can you use the down/up arrow keys to move through the options, and @@use 'tab' to the following item@@? (Make sure it doesn't automatically select the first item.)<br />
====References====<br />
* [http://www.w3.org/WAI/intro/people-use-web/principles#keyboard Functionality is available from a keyboard]<br />
* [http://www.w3.org/WAI/users/browsing#keyboard Browsing the Web by Keyboard] section in [http://www.w3.org/WAI/users/browsing Better Web Browsing: Tips for Customizing Your Computer]<br />
* Example: [http://www.w3.org/WAI/demos/bad/before/survey.html web page template that does not enable keyboard access] from the WAI Before and After Demo (BAD)<br />
====Notes====<br />
* Mac browsers by default only tab through forms, will need to turn on...<br />
* not work easily in Opera...<br />
* ...<br />
<br />
===Visible focus [mostly drafted]===<br />
<br />
<span style="color:#808080;">EOWG notes.<br />
<br/> 5min: probably not (unless merged with keyboard access)<br />
<br /> 15min: probably</span><br />
<br />
'''''NOTE: Should this be merged with the keyboard access?'''''<br />
<br />
<p>Use keyboard only navigation to ensure that a user who relies on the keyboard will be able to know which element among multiple elements has the keyboard focus. This is an important element in facilitating success for keyboard users to operate the page, by letting them visually determine the component on which keyboard operations will interact at any point in time. People with attention limitations, short term memory limitations, or limitations in executive processes benefit by being able to discover where the focus is located.</p><br />
<br />
====What to do====<br />
# Use the keyboard to set the focus to all focusable elements on the page.<br />
<br />
====What to look for====<br />
# Visually examine progress through elements and verify that the focus indicator is visible.<br />
# Common failures occur when the default focus indicator is turned off in CSS or when the element is styled with borders that occlude the focus indicator.<br />
# Verify that any visual changes that occur with mouse hover also are triggered with keyboard focus<br />
<br />
====References====<br />
* [http://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-focus-visible.html Focus Visible - Understanding Success Criteria 2.4.7 (Level A)] <br />
* <span style="color:#808080;">[Found no relevant BAD example, Shadi is checking]</span><br />
* <span style="color:#808080;">[nothing specific in Accessibility Requirements page]</span><br />
<br />
===Check the page title [mostly drafted]===<br />
<span style="color:#808080;">EOWG notes - importance: medium.<br />
<br/> 5min: maybe not. it is easy to check, but a little more complicated to explain what makes a good title. Also not the most vital to lots of users.<br />
<br /> 15min: probably.</span><br />
<br />
@@ add image showing only a few words with multiple tabs in browser...<br />
<br />
Page titles are the first information read by a screen reader; useful for when users have multiple web pages opens, e.g., on different tabs and go between different windows. (Also good for adding to bookmarks & also search engine results.) <br />
<br />
====What to do====<br />
# Look at the browser's window title bar.<br />
# Look at titles of other pages within the site.<br />
<br />
====What to look for====<br />
* Verify that the title indicates the specific page and website and distinguishes the current page from others in the set of pages.<br />
* Make sure that every page in the site does not have the same title.<br />
* Check that the specific page title is listed BEFORE the name of the website. (for example, ''About Us - Our Long Web Site Name'')<br />
<br />
====References====<br />
* [http://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-title.html Page Titled- Understanding SC 2.4.2]<br />
* Consider if the page titles of all of the [http://www.w3.org/WAI/demos/bad/Overview.html Before and After Demo] had been the same. Instead, each has a distinctive name that identifies its function within the set of pages.<br />
====Notes====<br />
* Some browsers don't show title in browser title bar (Chrome, IE)<br />
<br />
===Check link text [partly drafted]===<br />
<span style="color:#808080;">EOWG notes.<br />
<br/> 5min: maybe not.<br />
<br /> 15min: maybe. fairly easy to check. not the most vital for lots of users.</span><br />
<br />
Wording the text that is linked to indicate clearly where the link goes or what the link does. Some people use a list of links where they don't see the text around it. See also:<br />
* [http://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-refs.html Link Purpose (In Context): Understanding SC 2.4.4] (Level A)<br />
* [http://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-link.html Link Purpose (Link Only): Understanding SC 2.4.9] (Level AAA)<br />
* [BAD]<br />
<br />
Check this<br />
* @@<br />
** @@<br />
<br />
Common failures:<br />
* Link text is something like "Click here" or "More" without any additional clarifying text.<br />
<br />
Notes:<br />
* List links (Can't find this in regular Firefox but easy in Opera where you can get a list of links from the standard tools menu, showing both title and url)<br />
* Issue - titles... ([http://ianpouncey.com/weblog/2010/01/title-attributes/ Ian P says never use titles on links], Sylvie agrees.)<br />
<br />
===Check usable with page zoomed and text enlarged [Suzette drafted for discussion]===<br />
<span style="color:#808080;">EOWG notes.<br />
<br/> 5min: no<br />
<br /> 15min: maybe not.</span><br />
* Zoom to 200%<br />
* Text-only enlargement... (e.g., text actually changes in IE)<br />
<br />
People with mild to moderate visual impairments may need to enlarge text in order to read it, or read it without straining. This simple requirement is mostly achieved by the functionality of the browser and ensuring that the page design supports that functionality. <br />
<br />
The text should be resizable up to 200% without losing information, using a standard browse. Additionally any images of text should also be resizable or replaced with actual text. <br />
<br />
Most modern browsers now offer a zoom function which enlarges both text and other content together. Some older browsers do not resize text if it was set using fixed units – such as points or pixels. <br />
<br />
====What to do====<br />
* Open your preferred browsers. Internet Explorer, Firefox, Chrome and Opera all offer zoom as a function of View or Function menus, or as a keyboard shortcut (usually, Control +, or for Mac Command +). <br />
* Set the screen window to full width<br />
* Use the zoom function or keyboard shortcut repeatedly to step up to a 200% increase. <br />
* Look at the main content, buttons, tabs and text entry fields and field labels.<br />
* Repeat with a different browser.<br />
====Common failures====<br />
* Is the default body text unusually small?<br />
* Does the main heading and body text increase in size? <br />
* Has any text that is part of a control, button, menu item or label increased in size? <br />
* Does any text overflow its space – for example, the text is too big for the button or menu tab, or width or depth of the column?<br />
* Can you read to the end of the line, or does some text disappear off the screen so that you have to scroll right to the end of the line?<br />
=====Note=====<br />
Some browsers can expand the text beyond 200% - this is not covered by the resize requirement as it is recognised that this will cause some of the failures described. It is also accepted that some horizontal scrolling may be necessary but see also 1.4.8 which is a AAA requirement. <br />
Users with more severe visual impairments who need larger text are likely to use screen magnifiers to increase text size above 200%. <br />
====References====<br />
*link to {appropriate section in Accessibility Requirements page http://www.w3.org/WAI/intro/people-use-web/principles#distinguishable} (doesn’t have a lot to say)<br />
*Guideline 1.4 Distinguishable: Make it easier for users to see and hear content including separating foreground from background. <br />
*Resize text: Understanding Success Criteria 1.4.4 (Level AA) {http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-scale.html}<br />
*Images of Text: Understanding Success Criteria 1.4.5 (Level AA) http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-text-presentation.html<br />
*Visual Presentation: Understanding Success Criteria 1.4.8 (Level AAA)http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-visual-presentation.html<br />
*link to {BAD example} No specific BAD examples – some reference to Text as image in relation to the phone number, and column width.<br />
<br />
====Notes for discussion====<br />
*Scrolling: see Visual Presentation: Understanding Success Criteria 1.4.8 (Level AAA) includes:<br />
** Text can be resized without assistive technology up to 200 percent in a way that does not require the user to scroll horizontally to read a line of text on a full-screen window.<br />
*Do we need to spell out the difference between zooming and resizing? Is resizing still important for people who use style sheets?<br />
*Do we still need to worry about IE6 which didn’t resize fixed font sizes?<br />
*Browsers are now hiding their menus – eg under the cogwheel icon, which is making it harder to know where to find the zoom option, however they seem to be reasonably consistent on keyboard shortcuts. Other options include pinch and zoom on trackpad or intellimouse<br />
<br />
===Check color contrast [Suzette is drafting]===<br />
<span style="color:#808080;">EOWG notes.<br />
<br/> 5min: maybe.<br />
<br /> 15min: yes.</span><br />
<br />
First pass - I'm working on this:<br />
<br />
Good colour contrast between the text and background is very important to people with visual impairements. Some users may chose to vary your colour choice by using their own preferred style sheet. <br />
<br />
Screen reader users will hear the text even if the contrast is poor, or deliberately hidden as white on white or black on black!<br />
<br />
* First stage - look out for instances of pale text that might blend into the background eg grey on the default off-white background. Other common combinations are pale green, yellow or blue text on a background of a slightly darker shade of the same colour. Check the text in the main content, menu tabs, links and selected links and in buttons, labels and captions. Any suspect instances need to be investigated. <br />
<br />
Remember that not all users will have high resolution screens and subtle colour combinations may not be rendered properly if the user is using a reduced colour set.<br />
<br />
* Second stage - a number of on-line tools can be used to compare the exact ratio of text and background. Use zoom to increase the font size and follow the tool instructions to pick up a sample of the text colour and a sample of the background colour. If the background is patterned take a sample at different points. The minimum contrast (level AA) is 4.5:1<br />
<insert from Wayne Dick><br />
<p> There are two types of color contrast testers: The first type, a<br />
lexical evaluator, looks at active styles on a web page and<br />
computes color contrasts based on coded values. The second type,<br />
run time tester, simply allows the user to sample what is on the<br />
screen and computes contrast based on samples. </p><br />
<p> The lexical evaluator examines what the author declares. It<br />
gives a full page report based color contrasts declared by the<br />
programmer. These tests are quick and efficient. They break down<br />
when run time values change due to actions taken by active<br />
content.</p><br />
<p> The run time tester requires more hands on work. The evaluator<br />
can take samples as the web site runs and determine actual<br />
contrasts. The problem here is that as contrasts change over time<br />
the tester must sample many states of the page. </p><br />
<p> Both types of test are important. If any active content change<br />
color during run time then WAI advises run time testing. Lexical<br />
testing can be very useful and save time with items that stay<br />
static. </p><br />
<br />
<end Wayne's insert><br />
Ref: Contrast (minimum) 1.4.3 http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-contrast.html <br />
<br />
also Contrast (enhanced) 1.4.6 <br />
Note: There are some exceptions and special requirements to achieve full conformance.<br />
<br />
===Check color coding and shape coding [Suzette draft]===<br />
<span style="color:#808080;">EOWG notes.<br />
<br/> 5min: no<br />
<br /> 15min: maybe not. not easy to check thoroughly. not vital for many users.</span><br />
<br />
[Notes: refers specifically to: '''1.4.1 Use of Color''': Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.<br />
<br />
NB. consider if other sensory characteristics [such as shape, size, visual location, orientation, or sound] sould be combined here. See '''1.3.3 Sensory Characteristics''': Instructions provided for understanding and operating content do not rely solely on sensory characteristics of components such as shape, size, visual location, orientation, or sound.]<br />
<br />
Colour, shape and location are often used as a code or visual cue to help people to identify important information or actions on a busy web page. <br />
<br />
These visual cues are not always available – someone who is colour blind may find it difficult to distinguish some or all colour combinations. And in addition, people using some types of assistive technology such as a screen reader, Braille or other alternative display systems will not ‘see’ the cue.<br />
<br />
It helps to use both colour and a symbol together – for example a red asterisk, provides both a colour and shape code. Alt text on any symbols or icons should make the functional meaning obvious. Any text instructions should allow for someone who cannot see the visual cue. <br />
<br />
====What to do====<br />
Inspect the page carefully to identify any instances of visual cues:<br />
* Colour - either coloured text or tinted backgrounds and including in-text links.<br />
* Shape - including icons and symbols, and glyphs such as a smiley face or no entry symbol, or a graphic X to draw attention to removing an item in a shopping list.<br />
* Location - positioning a symbol or instruction at the top, bottom or side of the main text<br />
* Text descriptions or instructions - inspect the text for instructions that refer to colour, shape or location such as the button on the left, or the red square.<br />
<br />
====Common failures====<br />
* In a form, colour used to indicate a required field, or as part of an error messages when a required field is not completed and there is no additional cue such as a colour coded symbol?<br />
* Text links - colour used alone to indicate links in a paragraph of text, and, there is no additional cue such as underlining?<br />
* Text instructions, the instruction does not make sense if you can't see the colour, shape or the location of a control button described.<br />
* Providing alternative text for symbols and icons - in general these need to refer to the function and not the visual appearance. For example if ‘red square’ is the button for the function ‘stop’, then the alt text should say ‘stop’ and not 'red square'. <br />
<br />
====References====<br />
Use of colour: Understanding success criteria 1.4.1 (Level A) {http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-without-color.html}<br />
<br />
Sensory Characteristics: Understanding success criteria 1.3.3 (Level A) { http://www.w3.org/TR/UNDERSTANDING-WCAG20/content-structure-separation-understanding.html}<br />
<br />
See also: Non-text equivalent 1.1.1 (A) for appropriate text equivalents for any symbols, icons or glyphs and Contrast 1.4.3 (AA) for colour contrast.<br />
<br />
====Notes for discussion====<br />
I put colour, shape and location together because functionally they are about visual coding – is this too big a step?<br />
<br />
Also - should the common failures be descriptive, suggest a solution or ask a question? I got a bit confused here :(<br />
<br />
===Content order [open for drafting]===<br />
<span style="color:#808080;">EOWG notes.<br />
<br/> 5min: no.<br />
<br /> 15min: maybe. </span><br />
<br />
'''''NOTE: Should this be merged with the keyboard access check?'''''<br />
<br />
===Video, Sound, (multimedia) [partly drafted]===<br />
<span style="color:#808080;">EOWG notes.<br />
<br/> 5min: maybe. vital for some uses, through maybe not really easy to check thoroughly<br />
<br /> 15min: yes.</span><br />
<br />
====What to do====<br />
# Play the audio content<br />
# Play the video content<br />
# Toggle closed captions on (if available) <br />
# Toggle audio description on (if available) <br />
====What to look for====<br />
* Captions:<br />
** Verify that they synchronized to the spoken content<br />
** Ensure they are accurate and complete (not missing any content)?<br />
** Verify that they are properly formed? (correct spelling, sentence structure, punctuation)<br />
** Make sure that audio content other than dialogue is inlcuded (music, relevant ambient sounds, etc)<br />
* Audio Description<br />
** '''(Judgement call)''' Watch the video content to verify that audio description is needed for complete understanding.<br />
** If needed, verify that they are provided in a separate track that can be toggled on and that they provide context for those who do not see the video.<br />
* Transcript: As a fall-back when captions and audio descriptions are not provided, check to see if there is text-based content that contains dialogue, any other audio content, and any necessary description of video content. Check for spelling and accuracy. <br />
''(see also keyboard access for player controls)''<br />
<br />
''(see also text alternatives for graphic content)''<br />
<br />
====References====<br />
* [http://www.w3.org/2008/06/video-notes Multi Media FAQs] from the W3C<br />
* [http://www.w3.org/TR/UNDERSTANDING-WCAG20/media-equiv-captions.html Understanding WCAG SC 1.2.2 Captions](Level A)<br />
* [http://www.w3.org/TR/UNDERSTANDING-WCAG20/media-equiv-audio-desc.html Understanding 1.2.5 Audio Description](Level A) <br />
====Notes====<br />
<span style="color:#808080;">[can be internal notes for now or maybe will be included in final doc]</span><br />
*...<br />
<br />
===Forms===<br />
<span style="color:#808080;">EOWG notes.<br />
<br/> 5min: no, too complicated.<br />
<br /> 15min: not sure (need to see it drafted first :-)</span><br />
<br />
<p>Forms are everywhere on the web and successful user interaction relies on clear, understandable, and accessible form controls. Several principles of accessibility should be kept in mind when testing forms. Labels for form controls, input, and other user interface components must be provided. Many people do not use the mouse and rely on the keyboard to interact with the Web. This requires visible keyboard access to all functionality, including form controls. Forms may be confusing or difficult to use for many people, and, as a result, they may be more likely to make mistakes. Clear recovery mechanisms must be provided.</p> <br />
<br />
====What to do====<br />
<p>Evaluating the accessibility of form controls is one area in which a testing tool comes in very handy. Free web developer tools and accessibility checkers can be downloaded and installed in various browsers and having one installed will make this process much easier. <span style="color:#808080;">SR Note: Do we recommend a tool? Link to the testing tools section of the WAI pages?</span></p> <br />
# Visually examine the forms<br />
# Put the mouse aside and tab through form controls<br />
# Turn images off in the browser and examine submit buttons and other controls<br />
# Turn off CSS in the browser<br />
# Enter data in form input fields <br />
# Deliberately enter an error and then submit form<br />
# Use browser based testing tools to examine form detail<br />
<br />
====What to look for====<br />
<p>Each form control must have an associated label that describes its purpose. Tab order between form controls must match the order in which a user would normally complete them. Complex forms benefit from grouping controls with the FIELDSET element. The form title is optional if the purpose of the form can be determined from context. "Placeholder" text inside text boxes is no longer needed for screen readers; it is redundant in a properly-labeled form. Many forms will also have to be evaluated separately for dynamic behavior such as error response. Listed below are some things that you will look for.</p> <br />
<p>When visually reviewing the form, note the following:<br />
* if required fields are indicated by use of color cues, ensure that additional, redundant methods are also used.<br />
* ensure that related form controls are logically grouped together (perhaps using fieldset and legend, see the section below with testing tools)</p> <br />
<p>When tabbing through form inputs:<br />
* ensure that focus moves logically between the fields.<br />
* ensure that focus is visible on all form controls, including inputs, submit mechanisms, and check boxes and radio buttons.<br />
* if form control is a select box, ensure that arrow keys can move focus between select options and that selection is made by user action and not by default focus.</p><br />
<p>With images and/or background images turned off in the browser:<br />
* ensure that form controls are still evident and operable<br />
* ensure that any "required" status indicators are still evident</p><br />
<br />
====References====<br />
* <span style="color:#808080;">link to </span> {appropriate section in [http://www.w3.org/WAI/intro/people-use-web/principles Accessibility Requirements page]}<br />
* <span style="color:#808080;">link to </span>Handle - Understanding Success Criteria x.x.x (Level xx)<br />
* <span style="color:#808080;">link to </span>{BAD example}<br />
<br />
====Notes====<br />
<span style="color:#808080;">[can be internal notes for now or maybe will be included in final doc]</span><br />
*...<br />
<br />
===Tables [Ian drafting, eta 2012-12-07]===<br />
<span style="color:#808080;">EOWG notes.<br />
<br/> 5min: no, too complex.<br />
<br /> 15min: not sure (need to see it drafted first :-) </span><br />
...<br />
<br />
===Check flickering, flashing, blinking [open for drafting]===<br />
<span style="color:#808080;">EOWG notes.<br />
<br/> 5min: no.<br />
<br /> 15min: maybe not. </span><br />
...<br />
<br />
===WAI-ARIA [Wayne is drafting (although probably not including this one)]===<br />
<span style="color:#808080;">EOWG notes.<br />
<br/> 5min: no.<br />
<br /> 15min: no. </span><br />
<br />
<br />
Note: not a requirement for accessibility and WAI-ARIA is not finalized yet, so probably won't include WAI-ARIA in the 15 minute check.<br />
<br />
===Time-dependent responses [probably not including this one]===<br />
<span style="color:#808080;">EOWG notes.<br />
<br/> 5min: no.<br />
<br /> 15min: no. too hard to check and not vital to many users.</span><br />
...<br />
<br />
===Window resize [probably not including this one]===<br />
<span style="color:#808080;">EOWG notes.<br />
<br/> 5min: no.<br />
<br /> 15min: no. probably too complex an issue from preliminary eval</span><br />
...<br />
<br />
===Validate HTML & CSS [probably not including this one]===<br />
<span style="color:#808080;">EOWG notes.<br />
<br/> 5min: no<br />
<br /> 15min: WCAG requirement issue too complex. </span><br />
...<br />
<br />
Note: Validation not WCAG requirement...<br />
* ...<br />
* Check that the document language is declared<br />
<br />
===Check usable without CSS, javascript [Wayne is drafting (though maybe not including this one)]===<br />
<span style="color:#808080;">EOWG notes.<br />
<br/> 5min: no.<br />
<br /> 15min: not as a separate item. maybe integrated as a technique to check other points.</span><br />
<br />
NOTE: Shadi notes this is not a WCAG requirement<br />
<br />
NOTE: Wayne notes this is a ''technique'' for finding WCAG compliance problems (not that it is a requirement itself)<br />
<br />
* Disable CSS<br />
* core content available<br />
* check images, check content displayed or not displayed (e.g., display:none), sequence<br />
* links<br />
* ...<br />
Reasonable display without style is a US Section 508 requirement, and is a significant weakening of accessibility in WCAG 2.0. I think this needs to be discussed. Most pages than cannot pass this, cannot pass SC 1.4.4 (Resize Text). Also, pages that pass this pass SC 1.4.4 . The user applies no style, then enlarges at will. I will cover this. Wayne<br />
<br />
===Use an evaluation tool [probably won't include this generically]===<br />
<span style="color:#808080;">EOWG notes.<br />
<br/> 5min: no.<br />
<br /> 15min: not as a separate item. use of tools will be integrated in specific checks. generally running a tool gives too complicated results for a quick check.</span><br />
<br />
*Use one-page auto checker<br />
EOWG discussion:<br />
* There are a number of simple tools where you just put in the URL of the page of interest and the results are returned automatically eg WAVE and TAW. The results aren't necessarily so easy to interpret if you are a newbie to accessibility. Perhaps we should put this after the top 5 easy checks - and add a paragraph to confirm the benefits and limitations, or discuss some of the common types of problem found {Suzette}<br />
<br />
==More Thorough Evaluation==<br />
@@ point to Conformance Evaluation page and WCAG-EM.<br />
<br />
==Contributors==<br />
Thanks to:<br />
* Those who drafted checks 16-28 November:<br />
** Sharron for drafting {list sections!}<br />
** <span style="background:yellow;">{name} for drafting {section}</span><br />
* Andrew & Shawn for editing the [http://www.w3.org/WAI/EO/wiki/Web_Accessibility_Preliminary_Evaluation#Check_keyboard_access_and_visual_focus_.5Bmostly_drafted.5D keyboard access & visual focus section] in early Nov.<br />
* Ian, Suzette, Vicki, Sylvie, Helle, Shawn for working on an early draft at the [http://www.w3.org/2012/11/02-eo-minutes f2f in Nov].<br />
* Sharron for help making all the drafts and versions less confusing.<br />
* Wayne and Ian for sharing colleagues' related work.<br />
* Denis for edits to the old page content.</div>Wdickhttps://www.w3.org/WAI/EO/wiki/index.php?title=Web_Accessibility_Preliminary_Evaluation&diff=2078Web Accessibility Preliminary Evaluation2012-11-16T08:09:30Z<p>Wdick: /* A Deeper Look */</p>
<hr />
<div>Nav: [[Main Page|EOWG wiki main page]] > [[Main_Page#Evaluation_pages | Evaluation Pages ]]<br/><br />
Old page on WAI website: [http://www.w3.org/WAI/eval/preliminary.html Prelim Eval]<br/><br />
<br />
Note:<br />
* '''A template for the check items is at the top of the [http://www.w3.org/WAI/EO/wiki/Talk:Web_Accessibility_Preliminary_Evaluation discussion tab].'''<br />
* For tasks, example user cases with audience, and focus for this and related documents, see the [[Eval Analysis]] page<br />
* For previous drafts and contributed material, see:<br />
** Old page with Denis' edits and Ian's input in [[Preliminary Eval - old notes]]<br />
** Extensive revisions and suggestions at [[Archived_Work_on_PreLimEval]]<br />
** From Wayne & Tom [[Prelim Eval input: Smart analysis simplified]]<br />
<br />
<span style="background:yellow;">'''''Important Note''''': For this draft we have some tool-specific guidance. However, there are potential issues with vendor-neutraility and we might need to address this a different way &mdash; for example, moving tool-specific guidance to WebPlatform Docs or the WAI-Engage wiki where people can easily add other tools.</span><br />
<br />
<br />
__TOC__<br />
<br />
<span style="background:yellow;">'''''Important Note''''': For this draft we have some tool-specific guidance. However, there are potential issues with vendor-neutraility and we might need to address this a different way &mdash; for example, moving tool-specific guidance to WebPlatform Docs or the WAI-Engage wiki where people can easily add other tools.</span><br />
<br />
=Preliminary Review|Evaluation: Checking the Accessibility of a Web Page=<br />
<br />
==Introduction==<br />
<p>Testing and evaluating a web site for accessibility may seem intimidating but it need not be. There are simple ways to check on some basic features that do not require special skills or tools beyond your browser controls. Here you will find two approaches to doing Preliminary Evaluation of your pages. The first is a Quick Check - a list of 5 things you can do in 5 minutes. The second, while not a full conformance validation of WCAG2 Guidelines, will help ensure basic accessibility across a broader range of issues. While the second can quickly determine if the most important elements of a web page can be used by most persons with disabilities, it also requires more knowledge of accessibility principles and a few testing tools.</p><br />
<br />
<p>... @@ first run on good BAD page to see what it should look like, then on the bad page ... </p><br />
<br />
==Quick Checks==<br />
<br />
<p>Here are 5 things you can do to quickly check for accessibility barriers on a web page:<br /><br />
<span style="color:#808080;">{EOWG note: Let's work on the longer section first, then decide what we can move up to the quick checks section later.</span></p><br />
#First thing.<br />
#Second thing.<br />
#Third thing. <br />
#Fourth thing. <br />
#Fifth thing.<br />
<br />
Once you have taken this quick dip you may be ready to dive a bit deeper. The next section provides more context and additional things you can do to check for accessibility barriers.<br />
<br />
==A Deeper Look==<br />
<p>If you are interested in a more comprehensive look at the page(s), here more tests that require a little more time, skills, and/or tools.</p><br />
<br />
<span style="color:#808080;">''{reminder: A template for the check draft items is at the top of the [http://www.w3.org/WAI/EO/wiki/Talk:Web_Accessibility_Preliminary_Evaluation discussion tab].}''</span><br />
<br />
===Check text descriptions for images [mostly drafted]===<br />
<span style="color:#808080;">EOWG notes - importance: HIGH; 5min?: yes.</span><br />
<br />
Text alternatives convey the purpose of an image or function to provide an equivalent user experience. For instance, an text alternative for a search button is "search". See also:<br />
* [http://www.w3.org/WAI/intro/people-use-web/principles#alternatives Text alternatives for non-text content section in Accessibility Principles]<br />
* [BAD Example]<br />
<br />
Notes:<br />
<ul><br />
<li>Text that is actually an image.</li><br />
<li>Important image should have alt text that provides adequate alternative of the image for people who cannot see it...</li><br />
<li>Image that doesn't convey important information...</li><br />
<li>@@ Some guidance on not saying things like "this is an image..." or "this is a link..."</li><br />
</ul><br />
<br />
====Checking with WAVE====<br />
<ol><br />
<li>Open [http://wave.webaim.org/ WAVE]</li><br />
<li>In the "Enter a web site address" put the URI (for example, <code>www.w3.org</code>) and click the "WAVE the page!" button.</li><br />
<li>Look for a [http://wave.webaim.org/waveicons/no_alt.png no alt icon] that indicates that alt text is missing.</li><br />
<li>Look for the [http://wave.webaim.org/waveicons/alt_text_link.png alt icon] that has the alt text next to it.</li><br />
</ol><br />
<br />
====Disable images====<br />
* Do: Disable images...<br />
**Check: @@For contrast problems...<br />
* Turn off CSS...<br />
<br />
====More====<br />
''(See also Video & Sound below.)''<br />
<br />
===Check headings and other semantic structure [some parts drafted]===<br />
<span style="color:#808080;">EOWG notes - importance: HIGH; level: easy.</span><br />
<br />
... @@ brief summary of why & what to check for ...<br />
See also:<br />
* ? [http://www.w3.org/TR/2012/NOTE-WCAG20-TECHS-20120103/G141 G141 technique]<br />
* ? [http://www.w3.org/TR/2012/NOTE-WCAG20-TECHS-20120103/H42 H42 technique]<br />
<br />
What you're looking for: @@<br />
<ul><br />
<li>Does the page have any headings?</li><br />
<li>Are the things that look like headings that aren't marked up as heading?</li><br />
<li>Are there things that are marked up as headings that aren't really headings?</li><br />
</ul><br />
<br />
====Checking with WAVE====<br />
<ol><br />
<li>Open [http://wave.webaim.org/ WAVE]</li><br />
<li>Enter the web page:<br />
<ul><br />
<li>If the website is online: Enter a web site address and click the "WAVE the page!" button.</li><br />
<li>... Upload a file...</li><br />
<li>... Check HTML code...</li><br />
</ul></li><br />
<li>Check headings:<br />
<ul><br />
<li>...</li><br />
</ul></li><br />
<li>Check lists:<br />
<ul><br />
<li>...</li><br />
</ul></li><br />
</ol><br />
<br />
====Checking headings with HTML Validator====<br />
<ol><br />
<li> Open the [http://validator.w3.org/ W3C HTML Validator (The W3C Markup Validation Service)].</li><br />
<li>Select the appropriate tab and input the page:<br />
<ul><br />
<li>If the web page is online, leave the '''Validate by URI''' tab selected. <br />In the Address field, type the URI (e.g., www.w3.org).</li><br />
<li>If the web page is on your local computer, click the '''Validate by File Upload''' tab.<br />In the File field, select &quot;Choose...&quot; and find the file on your computer.</li><br />
<li>If you will paste the HTML code/markup, '''Validate by Direct Input''' tab.<br />Paste your HTML in the Enter the Markup to validate: field.</li><br />
</ul><br />
</li><br />
<li>Click the More Options link.</li><br />
<li>Select the Outline checkbox.</li><br />
<li>Click the Check button.</li><br />
<li>In the results page at the top, click the Outline link.</li><br />
<li>Compare the Document Outline to the visual rendering of the page. <ul><br />
<li>Are the things that look like headings listed in the Document Outline?</li><br />
<li>Are there things in the Document Outline that aren't really headings?<br /><br />
</li><br />
</ul></li><br />
</ol><br />
<br />
===Check keyboard access and visual focus [mostly drafted]===<br />
<span style="color:#808080;">EOWG notes - importance: HIGH; 5min?: some yes.</span><br />
<br />
Many people do not use the mouse and rely on the keyboard to interact with the Web. This requires keyboard access to all functionality, including links, form controls, input, and other user interface components. See also:<br />
* [http://www.w3.org/WAI/intro/people-use-web/principles#keyboard Functionality is available from a keyboard]<br />
* [http://www.w3.org/WAI/users/browsing#keyboard Browsing the Web by Keyboard] section in [http://www.w3.org/WAI/users/browsing Better Web Browsing: Tips for Customizing Your Computer]<br />
* [BAD example]<br />
<br />
Checks:<br />
* Click in the address bar, then put your mouse aside and don't use it. Press the 'tab' key to move around the page.<br />
** Can you tab to all the elements, including links, form fields, buttons, and @@? Are there any actions you can't get to (e.g., if they are only available on mouse hover)?<br />
** Does the focus get stuck anywhere - that is, you can't tab away from a control (called a "keyboard trap")?<br />
** Does the order that items get focus make sense? (e.g., you don't jump around the page out of order logically)<br />
** Can you tab right through to the bottom of the page and then resume again from the top? (e.g. you don't get stuck anywhere and can't move on)<br />
** Can you clearly see where you've 'tabbed' to - that is, is the focus clearly visible all the time?<br />
** If there is a drop-down box (for example, for navigating to a different page): If you tab into the drop-down box, can you use the down/up arrow keys to move through the options, and @@use 'tab' to the following item@@? (Make sure it doesn't automatically select the first item.)<br />
''(see also Forms)''<br />
<br />
Notes:<br />
* maybe don't see focus at all and are confused...<br />
* Mac browsers by default only tab through forms, will need to turn on...<br />
* not work easily in Opera...<br />
* ...<br />
<br />
===Check the page title [mostly drafted]===<br />
<span style="color:#808080;">EOWG notes - importance: medium; 5min?: yes.</span><br />
<br />
@@ add image showing only a few words with multiple tabs in browser...<br />
<br />
Page titles are the first information read by a screen reader; useful for when users have multiple web pages opens, e.g., on different tabs and go between different windows. (Also good for adding to bookmarks & also search engine results.) See also:<br />
* [http://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-title.html Page Titled- Understanding SC 2.4.2]<br />
* [BAD examples]<br />
<br />
Checks:<br />
* Do: Look at the browser's window title bar.<br />
** Check: Should indicate the specific page and website as appropriate (often it is similar to the heading of the page).<br />
<br />
Common failures:<br />
* Every page has the same title.<br />
* Long name of the website is first, then the specific page title.<br />
<br />
Note:<br />
* Some browsers don't show title in browser title bar (Chrome, IE)<br />
<br />
===Check link text [partly drafted]===<br />
<span style="color:#808080;">EOWG notes - importance: @@; 5min?: @@.</span><br />
<br />
Wording the text that is linked to indicate clearly where the link goes or what the link does. Some people use a list of links where they don't see the text around it. See also:<br />
* [http://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-refs.html Link Purpose (In Context): Understanding SC 2.4.4] (Level A)<br />
* [http://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-link.html Link Purpose (Link Only): Understanding SC 2.4.9] (Level AAA)<br />
* [BAD]<br />
<br />
Check this<br />
* @@<br />
** @@<br />
<br />
Common failures:<br />
* Link text is something like "Click here" or "More" without any additional clarifying text.<br />
<br />
Notes:<br />
* List links (Can't find this in regular Firefox but easy in Opera where you can get a list of links from the standard tools menu, showing both title and url)<br />
* Issue - titles... ([http://ianpouncey.com/weblog/2010/01/title-attributes/ Ian P says never use titles on links], Sylvie agrees.)<br />
<br />
===Check usable with page zoomed and text enlarged [open for drafting]===<br />
* Zoom to 200%<br />
* Text-only enlargement... (e.g., text actually changes in IE)<br />
<br />
===Check color contrast [open for drafting]===<br />
<span style="color:#808080;">{If no one gets to this by Thursday, Wayne and Tom will do it on Friday}</span><br />
<br />
===Check color coding [open for drafting]===<br />
<br />
===Content order [open for drafting]===<br />
<br />
===Visual focus ===<br />
<p>Use keyboard only navigation to ensure that a user who relies on the keyboard will be able to know which element among multiple elements has the keyboard focus. This is an important element in facilitating success for keyboard users to operate the page, by letting them visually determine the component on which keyboard operations will interact at any point in time. People with attention limitations, short term memory limitations, or limitations in executive processes benefit by being able to discover where the focus is located.</p><br />
<br />
====WAI References====<br />
* WCAG Guideline 2.4.7 is the relevant guideline for this test. <br /><br />
* (***Note: No BAD condition found***) <br />
<br />
====To check visual focus====<br />
# Use the keyboard to set the focus to all focusable elements on the page.<br />
# Visually examine progress through elements and verify that the focus indicator is visible.<br />
<br />
====Common Failures====<br />
<p>Common failures occur when the default focus indicator is turned off in CSS or when the element is styled with borders that occlude the focus indicator.</p><br />
<br />
===Video, Sound, (multimedia) [open for drafting]===<br />
alt...<br />
<br />
===Forms [open for drafting]===<br />
...<br />
<br />
===Tables [open for drafting]===<br />
...<br />
<br />
===Check flickering, flashing, blinking [open for drafting]===<br />
<br />
===WAI-ARIA [probably not including this one]===<br />
(note: not a requirement for accessibility and WAI-ARIA is not finalized yet, so probably won't include WAI-ARIA in the 15 minute check)<br/><br />
<span style="color:#808080;">{If no one gets to this by Thursday, Wayne and Tom will do it on Friday}</span><br />
<br />
===Time-dependent responses [probably not including this one]===<br />
<br />
===Window resize [probably not including this one]===<br />
... probably too complex an issue for preliminary eval ...<br />
<br />
===Validate HTML & CSS [probably not including this one]===<br />
Note: Validation not WCAG requirement...<br />
* ...<br />
* Check that the document language is declared<br />
<br />
===Check usable without CSS, javascript [probably not including this one]===<br />
NOTE: saz not WCAG requirement<br />
* Disable CSS<br />
* core content available<br />
* check images, check content displayed or not displayed (e.g., display:none), sequence<br />
* links<br />
* ...<br />
Reasonable display without style is a US Section 508 requirement, and is a significant weakening of accessibility in WCAG 2.0. I think this needs to be discussed. Most pages than cannot pass this, cannot pass SC 1.4.4 (Resize Text). Also, pages that pass this pass SC 1.4.4 . The user applies no style, then enlarges at will. I will cover this. Wayne<br />
<br />
===Use an evaluation tool [probably won't include this generically]===<br />
*Use one-page auto checker<br />
EOWG discussion:<br />
* There are a number of simple tools where you just put in the URL of the page of interest and the results are returned automatically eg WAVE and TAW. The results aren't necessarily so easy to interpret if you are a newbie to accessibility. Perhaps we should put this after the top 5 easy checks - and add a paragraph to confirm the benefits and limitations, or discuss some of the common types of problem found {Suzette}<br />
<br />
Change the question list to:<br />
<br />
Check the Following<br />
<ul><br />
<li>Text descriptions for images </li><br />
<li>Headings and other semantic structure</li><br />
<li>Keyboard access and visual focus </li><br />
<li>Page title </li><br />
<li>Link text </li><br />
<li>Text enlargement </li><br />
<li>Color contrast </li><br />
<li>Color coding</li><br />
<li>Content order </li><br />
<li>Visual focus </li><br />
<li>Time Based Media</li><br />
<li>Forms </li><br />
<li>Tables </li><br />
<li>Flickering, flashing, blinking</li><br />
<li>WAI-ARIA </li><br />
<li>Time-dependent responses</li><br />
<li>Valid HTML &amp; CSS </li><br />
<li>Usability without CSS </li><br />
</ul><br />
<br />
==More Thorough Evaluation==<br />
@@ point to Conformance Evaluation page and WCAG-EM.<br />
<br />
==Contributors==<br />
Thanks to:<br />
* Those who drafted items for EOWG to review on Thursday 15 November:<br />
** <span style="background:yellow;">{name} for drafting {section}</span><br />
** {name} for drafting {section}<br />
* Andrew & Shawn for editing the [http://www.w3.org/WAI/EO/wiki/Web_Accessibility_Preliminary_Evaluation#Check_keyboard_access_and_visual_focus_.5Bmostly_drafted.5D keyboard access & visual focus section] in early Nov.<br />
* Ian, Suzette, Vicki, Sylvie, Helle, Shawn for working on an early draft at the [http://www.w3.org/2012/11/02-eo-minutes f2f in Nov].<br />
* Sharron for help making all the drafts and versions less confusing.<br />
* Wayne and Ian for sharing colleagues' related work.<br />
* Denis for edits to the old page content.</div>Wdickhttps://www.w3.org/WAI/EO/wiki/index.php?title=Web_Accessibility_Preliminary_Evaluation&diff=2069Web Accessibility Preliminary Evaluation2012-11-13T20:12:40Z<p>Wdick: /* Check usable without CSS, javascript [probably not including this one] */</p>
<hr />
<div>Nav: [[Main Page|EOWG wiki main page]] > [[Main_Page#Evaluation_pages | Evaluation Pages ]]<br/><br />
Old page on WAI website: [http://www.w3.org/WAI/eval/preliminary.html Prelim Eval]<br/><br />
<br />
Note:<br />
* '''A template for the check items is at the top of the [http://www.w3.org/WAI/EO/wiki/Talk:Web_Accessibility_Preliminary_Evaluation discussion tab].'''<br />
* For tasks, example user cases with audience, and focus for this and related documents, see the [[Eval Analysis]] page<br />
* For previous drafts and contributed material, see:<br />
** Old page with Denis' edits and Ian's input in [[Preliminary Eval - old notes]]<br />
** Extensive revisions and suggestions at [[Archived_Work_on_PreLimEval]]<br />
** From Wayne & Tom [[Prelim Eval input: Smart analysis simplified]]<br />
<br />
<span style="background:yellow;">'''''Important Note''''': For this draft we have some tool-specific guidance. However, there are potential issues with vendor-neutraility and we might need to address this a different way &mdash; for example, moving tool-specific guidance to WebPlatform Docs or the WAI-Engage wiki where people can easily add other tools.</span><br />
<br />
<br />
__TOC__<br />
<br />
<span style="background:yellow;">'''''Important Note''''': For this draft we have some tool-specific guidance. However, there are potential issues with vendor-neutraility and we might need to address this a different way &mdash; for example, moving tool-specific guidance to WebPlatform Docs or the WAI-Engage wiki where people can easily add other tools.</span><br />
<br />
=Preliminary Review|Evaluation: Checking the Accessibility of a Web Page=<br />
<br />
==Introduction==<br />
<p>Testing and evaluating a web site for accessibility may seem intimidating but it need not be. There are simple ways to check on some basic features that do not require special skills or tools beyond your browser controls. Here you will find two approaches to doing Preliminary Evaluation of your pages. The first is a Quick Check - a list of 5 things you can do in 5 minutes. The second, while not a full conformance validation of WCAG2 Guidelines, will help ensure basic accessibility across a broader range of issues. While the second can quickly determine if the most important elements of a web page can be used by most persons with disabilities, it also requires more knowledge of accessibility principles and a few testing tools.</p><br />
<br />
<p>... @@ first run on good BAD page to see what it should look like, then on the bad page ... </p><br />
<br />
==Quick Checks==<br />
<br />
<p>Here are 5 things you can do to quickly check for accessibility barriers on a web page:<br /><br />
<span style="color:#808080;">{EOWG note: Let's work on the longer section first, then decide what we can move up to the quick checks section later.</span></p><br />
#First thing.<br />
#Second thing.<br />
#Third thing. <br />
#Fourth thing. <br />
#Fifth thing.<br />
<br />
Once you have taken this quick dip you may be ready to dive a bit deeper. The next section provides more context and additional things you can do to check for accessibility barriers.<br />
<br />
==A Deeper Look==<br />
<p>If you are interested in a more comprehensive look at the page(s), here more tests that require a little more time, skills, and/or tools.</p><br />
<br />
<span style="color:#808080;">''{reminder: A template for the check draft items is at the top of the [http://www.w3.org/WAI/EO/wiki/Talk:Web_Accessibility_Preliminary_Evaluation discussion tab].}''</span><br />
<br />
===Check text descriptions for images [mostly drafted]===<br />
<span style="color:#808080;">EOWG notes - importance: HIGH; 5min?: yes.</span><br />
<br />
Text alternatives convey the purpose of an image or function to provide an equivalent user experience. For instance, an text alternative for a search button is "search". See also:<br />
* [http://www.w3.org/WAI/intro/people-use-web/principles#alternatives Text alternatives for non-text content section in Accessibility Principles]<br />
* [BAD Example]<br />
<br />
Notes:<br />
<ul><br />
<li>Text that is actually an image.</li><br />
<li>Important image should have alt text that provides adequate alternative of the image for people who cannot see it...</li><br />
<li>Image that doesn't convey important information...</li><br />
<li>@@ Some guidance on not saying things like "this is an image..." or "this is a link..."</li><br />
</ul><br />
<br />
====Checking with WAVE====<br />
<ol><br />
<li>Open [http://wave.webaim.org/ WAVE]</li><br />
<li>In the "Enter a web site address" put the URI (for example, <code>www.w3.org</code>) and click the "WAVE the page!" button.</li><br />
<li>Look for a [http://wave.webaim.org/waveicons/no_alt.png no alt icon] that indicates that alt text is missing.</li><br />
<li>Look for the [http://wave.webaim.org/waveicons/alt_text_link.png alt icon] that has the alt text next to it.</li><br />
</ol><br />
<br />
====Disable images====<br />
* Do: Disable images...<br />
**Check: @@For contrast problems...<br />
* Turn off CSS...<br />
<br />
====More====<br />
''(See also Video & Sound below.)''<br />
<br />
===Check headings and other semantic structure [some parts drafted]===<br />
<span style="color:#808080;">EOWG notes - importance: HIGH; level: easy.</span><br />
<br />
... @@ brief summary of why & what to check for ...<br />
See also:<br />
* ? [http://www.w3.org/TR/2012/NOTE-WCAG20-TECHS-20120103/G141 G141 technique]<br />
* ? [http://www.w3.org/TR/2012/NOTE-WCAG20-TECHS-20120103/H42 H42 technique]<br />
<br />
What you're looking for: @@<br />
<ul><br />
<li>Does the page have any headings?</li><br />
<li>Are the things that look like headings that aren't marked up as heading?</li><br />
<li>Are there things that are marked up as headings that aren't really headings?</li><br />
</ul><br />
<br />
====Checking with WAVE====<br />
<ol><br />
<li>Open [http://wave.webaim.org/ WAVE]</li><br />
<li>Enter the web page:<br />
<ul><br />
<li>If the website is online: Enter a web site address and click the "WAVE the page!" button.</li><br />
<li>... Upload a file...</li><br />
<li>... Check HTML code...</li><br />
</ul></li><br />
<li>Check headings:<br />
<ul><br />
<li>...</li><br />
</ul></li><br />
<li>Check lists:<br />
<ul><br />
<li>...</li><br />
</ul></li><br />
</ol><br />
<br />
====Checking headings with HTML Validator====<br />
<ol><br />
<li> Open the [http://validator.w3.org/ W3C HTML Validator (The W3C Markup Validation Service)].</li><br />
<li>Select the appropriate tab and input the page:<br />
<ul><br />
<li>If the web page is online, leave the '''Validate by URI''' tab selected. <br />In the Address field, type the URI (e.g., www.w3.org).</li><br />
<li>If the web page is on your local computer, click the '''Validate by File Upload''' tab.<br />In the File field, select &quot;Choose...&quot; and find the file on your computer.</li><br />
<li>If you will paste the HTML code/markup, '''Validate by Direct Input''' tab.<br />Paste your HTML in the Enter the Markup to validate: field.</li><br />
</ul><br />
</li><br />
<li>Click the More Options link.</li><br />
<li>Select the Outline checkbox.</li><br />
<li>Click the Check button.</li><br />
<li>In the results page at the top, click the Outline link.</li><br />
<li>Compare the Document Outline to the visual rendering of the page. <ul><br />
<li>Are the things that look like headings listed in the Document Outline?</li><br />
<li>Are there things in the Document Outline that aren't really headings?<br /><br />
</li><br />
</ul></li><br />
</ol><br />
<br />
===Check keyboard access and visual focus [mostly drafted]===<br />
<span style="color:#808080;">EOWG notes - importance: HIGH; 5min?: some yes.</span><br />
<br />
Many people do not use the mouse and rely on the keyboard to interact with the Web. This requires keyboard access to all functionality, including links, form controls, input, and other user interface components. See also:<br />
* [http://www.w3.org/WAI/intro/people-use-web/principles#keyboard Functionality is available from a keyboard]<br />
* [http://www.w3.org/WAI/users/browsing#keyboard Browsing the Web by Keyboard] section in [http://www.w3.org/WAI/users/browsing Better Web Browsing: Tips for Customizing Your Computer]<br />
* [BAD example]<br />
<br />
Checks:<br />
* Click in the address bar, then put your mouse aside and don't use it. Press the 'tab' key to move around the page.<br />
** Can you tab to all the elements, including links, form fields, buttons, and @@? Are there any actions you can't get to (e.g., if they are only available on mouse hover)?<br />
** Does the focus get stuck anywhere - that is, you can't tab away from a control (called a "keyboard trap")?<br />
** Does the order that items get focus make sense? (e.g., you don't jump around the page out of order logically)<br />
** Can you tab right through to the bottom of the page and then resume again from the top? (e.g. you don't get stuck anywhere and can't move on)<br />
** Can you clearly see where you've 'tabbed' to - that is, is the focus clearly visible all the time?<br />
** If there is a drop-down box (for example, for navigating to a different page): If you tab into the drop-down box, can you use the down/up arrow keys to move through the options, and @@use 'tab' to the following item@@? (Make sure it doesn't automatically select the first item.)<br />
''(see also Forms)''<br />
<br />
Notes:<br />
* maybe don't see focus at all and are confused...<br />
* Mac browsers by default only tab through forms, will need to turn on...<br />
* not work easily in Opera...<br />
* ...<br />
<br />
===Check the page title [mostly drafted]===<br />
<span style="color:#808080;">EOWG notes - importance: medium; 5min?: yes.</span><br />
<br />
@@ add image showing only a few words with multiple tabs in browser...<br />
<br />
Page titles are the first information read by a screen reader; useful for when users have multiple web pages opens, e.g., on different tabs and go between different windows. (Also good for adding to bookmarks & also search engine results.) See also:<br />
* [http://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-title.html Page Titled- Understanding SC 2.4.2]<br />
* [BAD examples]<br />
<br />
Checks:<br />
* Do: Look at the browser's window title bar.<br />
** Check: Should indicate the specific page and website as appropriate (often it is similar to the heading of the page).<br />
<br />
Common failures:<br />
* Every page has the same title.<br />
* Long name of the website is first, then the specific page title.<br />
<br />
Note:<br />
* Some browsers don't show title in browser title bar (Chrome, IE)<br />
<br />
===Check link text [partly drafted]===<br />
<span style="color:#808080;">EOWG notes - importance: @@; 5min?: @@.</span><br />
<br />
Wording the text that is linked to indicate clearly where the link goes or what the link does. Some people use a list of links where they don't see the text around it. See also:<br />
* [http://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-refs.html Link Purpose (In Context): Understanding SC 2.4.4] (Level A)<br />
* [http://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-link.html Link Purpose (Link Only): Understanding SC 2.4.9] (Level AAA)<br />
* [BAD]<br />
<br />
Check this<br />
* @@<br />
** @@<br />
<br />
Common failures:<br />
* Link text is something like "Click here" or "More" without any additional clarifying text.<br />
<br />
Notes:<br />
* List links (Can't find this in regular Firefox but easy in Opera where you can get a list of links from the standard tools menu, showing both title and url)<br />
* Issue - titles... ([http://ianpouncey.com/weblog/2010/01/title-attributes/ Ian P says never use titles on links], Sylvie agrees.)<br />
<br />
===Check usable with page zoomed and text enlarged [open for drafting]===<br />
* Zoom to 200%<br />
* Text-only enlargement... (e.g., text actually changes in IE)<br />
<br />
===Check color contrast [open for drafting]===<br />
Wayne and Tom:<br />
<br />
===Check color coding [open for drafting]===<br />
<br />
===Content order [open for drafting]===<br />
<br />
===Visual focus [open for drafting]===<br />
<br />
===Video, Sound, (multimedia) [open for drafting]===<br />
alt...<br />
<br />
===Forms [open for drafting]===<br />
...<br />
<br />
===Tables [open for drafting]===<br />
...<br />
<br />
===Check flickering, flashing, blinking [open for drafting]===<br />
<br />
===Window resize [open for drafting]===<br />
... probably too complex an issue for preliminary eval ...<br />
<br />
===WAI-ARIA [open for drafting]===<br />
(note: not a requirement for accessibility)<br />
Wayne and Tom<br />
<br />
===Time-dependent responses [maybe not including this one]===<br />
<br />
===Validate HTML & CSS [maybe not including this one]===<br />
Note: Validation not WCAG requirement...<br />
* ...<br />
* Check that the document language is declared<br />
<br />
===Check usable without CSS, javascript [probably not including this one]===<br />
NOTE: saz not WCAG requirement<br />
* Disable CSS<br />
* core content available<br />
* check images, check content displayed or not displayed (e.g., display:none), sequence<br />
* links<br />
* ...<br />
Reasonable display without style is a US Section 508 requirement, and is a significant weakening of accessibility in WCAG 2.0. I think this needs to be discussed. Most pages than cannot pass this, cannot pass SC 1.4.4 (Resize Text). Also, pages that pass this pass SC 1.4.4 . The user applies no style, then enlarges at will. I will cover this. Wayne<br />
<br />
===Use an evaluation tool [probably won't include this generically]===<br />
*Use one-page auto checker<br />
EOWG discussion:<br />
* There are a number of simple tools where you just put in the URL of the page of interest and the results are returned automatically eg WAVE and TAW. The results aren't necessarily so easy to interpret if you are a newbie to accessibility. Perhaps we should put this after the top 5 easy checks - and add a paragraph to confirm the benefits and limitations, or discuss some of the common types of problem found {Suzette}<br />
<br />
==More Thorough Evaluation==<br />
@@ point to Conformance Evaluation page and WCAG-EM.<br />
<br />
==Contributors==<br />
Thanks to:<br />
* Those who drafted items for EOWG to review on Thursday 15 November:<br />
** <span style="background:yellow;">{name} for drafting {section}</span><br />
** {name} for drafting {section}<br />
* Andrew & Shawn for editing the [http://www.w3.org/WAI/EO/wiki/Web_Accessibility_Preliminary_Evaluation#Check_keyboard_access_and_visual_focus_.5Bmostly_drafted.5D keyboard access & visual focus section] in early Nov.<br />
* Ian, Suzette, Vicki, Sylvie, Helle, Shawn for working on an early draft at the [http://www.w3.org/2012/11/02-eo-minutes f2f in Nov].<br />
* Sharron for help making all the drafts and versions less confusing.<br />
* Wayne and Ian for sharing colleagues' related work.<br />
* Denis for edits to the old page content.</div>Wdickhttps://www.w3.org/WAI/EO/wiki/index.php?title=Web_Accessibility_Preliminary_Evaluation&diff=2068Web Accessibility Preliminary Evaluation2012-11-13T20:02:27Z<p>Wdick: /* Check usable without CSS, javascript [probably not including this one] */</p>
<hr />
<div>Nav: [[Main Page|EOWG wiki main page]] > [[Main_Page#Evaluation_pages | Evaluation Pages ]]<br/><br />
Old page on WAI website: [http://www.w3.org/WAI/eval/preliminary.html Prelim Eval]<br/><br />
<br />
Note:<br />
* '''A template for the check items is at the top of the [http://www.w3.org/WAI/EO/wiki/Talk:Web_Accessibility_Preliminary_Evaluation discussion tab].'''<br />
* For tasks, example user cases with audience, and focus for this and related documents, see the [[Eval Analysis]] page<br />
* For previous drafts and contributed material, see:<br />
** Old page with Denis' edits and Ian's input in [[Preliminary Eval - old notes]]<br />
** Extensive revisions and suggestions at [[Archived_Work_on_PreLimEval]]<br />
** From Wayne & Tom [[Prelim Eval input: Smart analysis simplified]]<br />
<br />
<span style="background:yellow;">'''''Important Note''''': For this draft we have some tool-specific guidance. However, there are potential issues with vendor-neutraility and we might need to address this a different way &mdash; for example, moving tool-specific guidance to WebPlatform Docs or the WAI-Engage wiki where people can easily add other tools.</span><br />
<br />
<br />
__TOC__<br />
<br />
<span style="background:yellow;">'''''Important Note''''': For this draft we have some tool-specific guidance. However, there are potential issues with vendor-neutraility and we might need to address this a different way &mdash; for example, moving tool-specific guidance to WebPlatform Docs or the WAI-Engage wiki where people can easily add other tools.</span><br />
<br />
=Preliminary Review|Evaluation: Checking the Accessibility of a Web Page=<br />
<br />
==Introduction==<br />
<p>Testing and evaluating a web site for accessibility may seem intimidating but it need not be. There are simple ways to check on some basic features that do not require special skills or tools beyond your browser controls. Here you will find two approaches to doing Preliminary Evaluation of your pages. The first is a Quick Check - a list of 5 things you can do in 5 minutes. The second, while not a full conformance validation of WCAG2 Guidelines, will help ensure basic accessibility across a broader range of issues. While the second can quickly determine if the most important elements of a web page can be used by most persons with disabilities, it also requires more knowledge of accessibility principles and a few testing tools.</p><br />
<br />
<p>... @@ first run on good BAD page to see what it should look like, then on the bad page ... </p><br />
<br />
==Quick Checks==<br />
<br />
<p>Here are 5 things you can do to quickly check for accessibility barriers on a web page:<br /><br />
<span style="color:#808080;">{EOWG note: Let's work on the longer section first, then decide what we can move up to the quick checks section later.</span></p><br />
#First thing.<br />
#Second thing.<br />
#Third thing. <br />
#Fourth thing. <br />
#Fifth thing.<br />
<br />
Once you have taken this quick dip you may be ready to dive a bit deeper. The next section provides more context and additional things you can do to check for accessibility barriers.<br />
<br />
==A Deeper Look==<br />
<p>If you are interested in a more comprehensive look at the page(s), here more tests that require a little more time, skills, and/or tools.</p><br />
<br />
<span style="color:#808080;">''{reminder: A template for the check draft items is at the top of the [http://www.w3.org/WAI/EO/wiki/Talk:Web_Accessibility_Preliminary_Evaluation discussion tab].}''</span><br />
<br />
===Check text descriptions for images [mostly drafted]===<br />
<span style="color:#808080;">EOWG notes - importance: HIGH; 5min?: yes.</span><br />
<br />
Text alternatives convey the purpose of an image or function to provide an equivalent user experience. For instance, an text alternative for a search button is "search". See also:<br />
* [http://www.w3.org/WAI/intro/people-use-web/principles#alternatives Text alternatives for non-text content section in Accessibility Principles]<br />
* [BAD Example]<br />
<br />
Notes:<br />
<ul><br />
<li>Text that is actually an image.</li><br />
<li>Important image should have alt text that provides adequate alternative of the image for people who cannot see it...</li><br />
<li>Image that doesn't convey important information...</li><br />
<li>@@ Some guidance on not saying things like "this is an image..." or "this is a link..."</li><br />
</ul><br />
<br />
====Checking with WAVE====<br />
<ol><br />
<li>Open [http://wave.webaim.org/ WAVE]</li><br />
<li>In the "Enter a web site address" put the URI (for example, <code>www.w3.org</code>) and click the "WAVE the page!" button.</li><br />
<li>Look for a [http://wave.webaim.org/waveicons/no_alt.png no alt icon] that indicates that alt text is missing.</li><br />
<li>Look for the [http://wave.webaim.org/waveicons/alt_text_link.png alt icon] that has the alt text next to it.</li><br />
</ol><br />
<br />
====Disable images====<br />
* Do: Disable images...<br />
**Check: @@For contrast problems...<br />
* Turn off CSS...<br />
<br />
====More====<br />
''(See also Video & Sound below.)''<br />
<br />
===Check headings and other semantic structure [some parts drafted]===<br />
<span style="color:#808080;">EOWG notes - importance: HIGH; level: easy.</span><br />
<br />
... @@ brief summary of why & what to check for ...<br />
See also:<br />
* ? [http://www.w3.org/TR/2012/NOTE-WCAG20-TECHS-20120103/G141 G141 technique]<br />
* ? [http://www.w3.org/TR/2012/NOTE-WCAG20-TECHS-20120103/H42 H42 technique]<br />
<br />
What you're looking for: @@<br />
<ul><br />
<li>Does the page have any headings?</li><br />
<li>Are the things that look like headings that aren't marked up as heading?</li><br />
<li>Are there things that are marked up as headings that aren't really headings?</li><br />
</ul><br />
<br />
====Checking with WAVE====<br />
<ol><br />
<li>Open [http://wave.webaim.org/ WAVE]</li><br />
<li>Enter the web page:<br />
<ul><br />
<li>If the website is online: Enter a web site address and click the "WAVE the page!" button.</li><br />
<li>... Upload a file...</li><br />
<li>... Check HTML code...</li><br />
</ul></li><br />
<li>Check headings:<br />
<ul><br />
<li>...</li><br />
</ul></li><br />
<li>Check lists:<br />
<ul><br />
<li>...</li><br />
</ul></li><br />
</ol><br />
<br />
====Checking headings with HTML Validator====<br />
<ol><br />
<li> Open the [http://validator.w3.org/ W3C HTML Validator (The W3C Markup Validation Service)].</li><br />
<li>Select the appropriate tab and input the page:<br />
<ul><br />
<li>If the web page is online, leave the '''Validate by URI''' tab selected. <br />In the Address field, type the URI (e.g., www.w3.org).</li><br />
<li>If the web page is on your local computer, click the '''Validate by File Upload''' tab.<br />In the File field, select &quot;Choose...&quot; and find the file on your computer.</li><br />
<li>If you will paste the HTML code/markup, '''Validate by Direct Input''' tab.<br />Paste your HTML in the Enter the Markup to validate: field.</li><br />
</ul><br />
</li><br />
<li>Click the More Options link.</li><br />
<li>Select the Outline checkbox.</li><br />
<li>Click the Check button.</li><br />
<li>In the results page at the top, click the Outline link.</li><br />
<li>Compare the Document Outline to the visual rendering of the page. <ul><br />
<li>Are the things that look like headings listed in the Document Outline?</li><br />
<li>Are there things in the Document Outline that aren't really headings?<br /><br />
</li><br />
</ul></li><br />
</ol><br />
<br />
===Check keyboard access and visual focus [mostly drafted]===<br />
<span style="color:#808080;">EOWG notes - importance: HIGH; 5min?: some yes.</span><br />
<br />
Many people do not use the mouse and rely on the keyboard to interact with the Web. This requires keyboard access to all functionality, including links, form controls, input, and other user interface components. See also:<br />
* [http://www.w3.org/WAI/intro/people-use-web/principles#keyboard Functionality is available from a keyboard]<br />
* [http://www.w3.org/WAI/users/browsing#keyboard Browsing the Web by Keyboard] section in [http://www.w3.org/WAI/users/browsing Better Web Browsing: Tips for Customizing Your Computer]<br />
* [BAD example]<br />
<br />
Checks:<br />
* Click in the address bar, then put your mouse aside and don't use it. Press the 'tab' key to move around the page.<br />
** Can you tab to all the elements, including links, form fields, buttons, and @@? Are there any actions you can't get to (e.g., if they are only available on mouse hover)?<br />
** Does the focus get stuck anywhere - that is, you can't tab away from a control (called a "keyboard trap")?<br />
** Does the order that items get focus make sense? (e.g., you don't jump around the page out of order logically)<br />
** Can you tab right through to the bottom of the page and then resume again from the top? (e.g. you don't get stuck anywhere and can't move on)<br />
** Can you clearly see where you've 'tabbed' to - that is, is the focus clearly visible all the time?<br />
** If there is a drop-down box (for example, for navigating to a different page): If you tab into the drop-down box, can you use the down/up arrow keys to move through the options, and @@use 'tab' to the following item@@? (Make sure it doesn't automatically select the first item.)<br />
''(see also Forms)''<br />
<br />
Notes:<br />
* maybe don't see focus at all and are confused...<br />
* Mac browsers by default only tab through forms, will need to turn on...<br />
* not work easily in Opera...<br />
* ...<br />
<br />
===Check the page title [mostly drafted]===<br />
<span style="color:#808080;">EOWG notes - importance: medium; 5min?: yes.</span><br />
<br />
@@ add image showing only a few words with multiple tabs in browser...<br />
<br />
Page titles are the first information read by a screen reader; useful for when users have multiple web pages opens, e.g., on different tabs and go between different windows. (Also good for adding to bookmarks & also search engine results.) See also:<br />
* [http://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-title.html Page Titled- Understanding SC 2.4.2]<br />
* [BAD examples]<br />
<br />
Checks:<br />
* Do: Look at the browser's window title bar.<br />
** Check: Should indicate the specific page and website as appropriate (often it is similar to the heading of the page).<br />
<br />
Common failures:<br />
* Every page has the same title.<br />
* Long name of the website is first, then the specific page title.<br />
<br />
Note:<br />
* Some browsers don't show title in browser title bar (Chrome, IE)<br />
<br />
===Check link text [partly drafted]===<br />
<span style="color:#808080;">EOWG notes - importance: @@; 5min?: @@.</span><br />
<br />
Wording the text that is linked to indicate clearly where the link goes or what the link does. Some people use a list of links where they don't see the text around it. See also:<br />
* [http://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-refs.html Link Purpose (In Context): Understanding SC 2.4.4] (Level A)<br />
* [http://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-link.html Link Purpose (Link Only): Understanding SC 2.4.9] (Level AAA)<br />
* [BAD]<br />
<br />
Check this<br />
* @@<br />
** @@<br />
<br />
Common failures:<br />
* Link text is something like "Click here" or "More" without any additional clarifying text.<br />
<br />
Notes:<br />
* List links (Can't find this in regular Firefox but easy in Opera where you can get a list of links from the standard tools menu, showing both title and url)<br />
* Issue - titles... ([http://ianpouncey.com/weblog/2010/01/title-attributes/ Ian P says never use titles on links], Sylvie agrees.)<br />
<br />
===Check usable with page zoomed and text enlarged [open for drafting]===<br />
* Zoom to 200%<br />
* Text-only enlargement... (e.g., text actually changes in IE)<br />
<br />
===Check color contrast [open for drafting]===<br />
Wayne and Tom:<br />
<br />
===Check color coding [open for drafting]===<br />
<br />
===Content order [open for drafting]===<br />
<br />
===Visual focus [open for drafting]===<br />
<br />
===Video, Sound, (multimedia) [open for drafting]===<br />
alt...<br />
<br />
===Forms [open for drafting]===<br />
...<br />
<br />
===Tables [open for drafting]===<br />
...<br />
<br />
===Check flickering, flashing, blinking [open for drafting]===<br />
<br />
===Window resize [open for drafting]===<br />
... probably too complex an issue for preliminary eval ...<br />
<br />
===WAI-ARIA [open for drafting]===<br />
(note: not a requirement for accessibility)<br />
Wayne and Tom<br />
<br />
===Time-dependent responses [maybe not including this one]===<br />
<br />
===Validate HTML & CSS [maybe not including this one]===<br />
Note: Validation not WCAG requirement...<br />
* ...<br />
* Check that the document language is declared<br />
<br />
===Check usable without CSS, javascript [probably not including this one]===<br />
NOTE: saz not WCAG requirement<br />
* Disable CSS<br />
* core content available<br />
* check images, check content displayed or not displayed (e.g., display:none), sequence<br />
* links<br />
* ...<br />
Reasonable display without style is a US Section 508 requirement, and is a significant weakening of accessibility for people with low vision in WCAG 2.0.<br />
<br />
===Use an evaluation tool [probably won't include this generically]===<br />
*Use one-page auto checker<br />
EOWG discussion:<br />
* There are a number of simple tools where you just put in the URL of the page of interest and the results are returned automatically eg WAVE and TAW. The results aren't necessarily so easy to interpret if you are a newbie to accessibility. Perhaps we should put this after the top 5 easy checks - and add a paragraph to confirm the benefits and limitations, or discuss some of the common types of problem found {Suzette}<br />
<br />
==More Thorough Evaluation==<br />
@@ point to Conformance Evaluation page and WCAG-EM.<br />
<br />
==Contributors==<br />
Thanks to:<br />
* Those who drafted items for EOWG to review on Thursday 15 November:<br />
** <span style="background:yellow;">{name} for drafting {section}</span><br />
** {name} for drafting {section}<br />
* Andrew & Shawn for editing the [http://www.w3.org/WAI/EO/wiki/Web_Accessibility_Preliminary_Evaluation#Check_keyboard_access_and_visual_focus_.5Bmostly_drafted.5D keyboard access & visual focus section] in early Nov.<br />
* Ian, Suzette, Vicki, Sylvie, Helle, Shawn for working on an early draft at the [http://www.w3.org/2012/11/02-eo-minutes f2f in Nov].<br />
* Sharron for help making all the drafts and versions less confusing.<br />
* Wayne and Ian for sharing colleagues' related work.<br />
* Denis for edits to the old page content.</div>Wdickhttps://www.w3.org/WAI/EO/wiki/index.php?title=Web_Accessibility_Preliminary_Evaluation&diff=2067Web Accessibility Preliminary Evaluation2012-11-13T20:01:46Z<p>Wdick: /* Check usable without CSS, javascript [probably not including this one] */</p>
<hr />
<div>Nav: [[Main Page|EOWG wiki main page]] > [[Main_Page#Evaluation_pages | Evaluation Pages ]]<br/><br />
Old page on WAI website: [http://www.w3.org/WAI/eval/preliminary.html Prelim Eval]<br/><br />
<br />
Note:<br />
* '''A template for the check items is at the top of the [http://www.w3.org/WAI/EO/wiki/Talk:Web_Accessibility_Preliminary_Evaluation discussion tab].'''<br />
* For tasks, example user cases with audience, and focus for this and related documents, see the [[Eval Analysis]] page<br />
* For previous drafts and contributed material, see:<br />
** Old page with Denis' edits and Ian's input in [[Preliminary Eval - old notes]]<br />
** Extensive revisions and suggestions at [[Archived_Work_on_PreLimEval]]<br />
** From Wayne & Tom [[Prelim Eval input: Smart analysis simplified]]<br />
<br />
<span style="background:yellow;">'''''Important Note''''': For this draft we have some tool-specific guidance. However, there are potential issues with vendor-neutraility and we might need to address this a different way &mdash; for example, moving tool-specific guidance to WebPlatform Docs or the WAI-Engage wiki where people can easily add other tools.</span><br />
<br />
<br />
__TOC__<br />
<br />
<span style="background:yellow;">'''''Important Note''''': For this draft we have some tool-specific guidance. However, there are potential issues with vendor-neutraility and we might need to address this a different way &mdash; for example, moving tool-specific guidance to WebPlatform Docs or the WAI-Engage wiki where people can easily add other tools.</span><br />
<br />
=Preliminary Review|Evaluation: Checking the Accessibility of a Web Page=<br />
<br />
==Introduction==<br />
<p>Testing and evaluating a web site for accessibility may seem intimidating but it need not be. There are simple ways to check on some basic features that do not require special skills or tools beyond your browser controls. Here you will find two approaches to doing Preliminary Evaluation of your pages. The first is a Quick Check - a list of 5 things you can do in 5 minutes. The second, while not a full conformance validation of WCAG2 Guidelines, will help ensure basic accessibility across a broader range of issues. While the second can quickly determine if the most important elements of a web page can be used by most persons with disabilities, it also requires more knowledge of accessibility principles and a few testing tools.</p><br />
<br />
<p>... @@ first run on good BAD page to see what it should look like, then on the bad page ... </p><br />
<br />
==Quick Checks==<br />
<br />
<p>Here are 5 things you can do to quickly check for accessibility barriers on a web page:<br /><br />
<span style="color:#808080;">{EOWG note: Let's work on the longer section first, then decide what we can move up to the quick checks section later.</span></p><br />
#First thing.<br />
#Second thing.<br />
#Third thing. <br />
#Fourth thing. <br />
#Fifth thing.<br />
<br />
Once you have taken this quick dip you may be ready to dive a bit deeper. The next section provides more context and additional things you can do to check for accessibility barriers.<br />
<br />
==A Deeper Look==<br />
<p>If you are interested in a more comprehensive look at the page(s), here more tests that require a little more time, skills, and/or tools.</p><br />
<br />
<span style="color:#808080;">''{reminder: A template for the check draft items is at the top of the [http://www.w3.org/WAI/EO/wiki/Talk:Web_Accessibility_Preliminary_Evaluation discussion tab].}''</span><br />
<br />
===Check text descriptions for images [mostly drafted]===<br />
<span style="color:#808080;">EOWG notes - importance: HIGH; 5min?: yes.</span><br />
<br />
Text alternatives convey the purpose of an image or function to provide an equivalent user experience. For instance, an text alternative for a search button is "search". See also:<br />
* [http://www.w3.org/WAI/intro/people-use-web/principles#alternatives Text alternatives for non-text content section in Accessibility Principles]<br />
* [BAD Example]<br />
<br />
Notes:<br />
<ul><br />
<li>Text that is actually an image.</li><br />
<li>Important image should have alt text that provides adequate alternative of the image for people who cannot see it...</li><br />
<li>Image that doesn't convey important information...</li><br />
<li>@@ Some guidance on not saying things like "this is an image..." or "this is a link..."</li><br />
</ul><br />
<br />
====Checking with WAVE====<br />
<ol><br />
<li>Open [http://wave.webaim.org/ WAVE]</li><br />
<li>In the "Enter a web site address" put the URI (for example, <code>www.w3.org</code>) and click the "WAVE the page!" button.</li><br />
<li>Look for a [http://wave.webaim.org/waveicons/no_alt.png no alt icon] that indicates that alt text is missing.</li><br />
<li>Look for the [http://wave.webaim.org/waveicons/alt_text_link.png alt icon] that has the alt text next to it.</li><br />
</ol><br />
<br />
====Disable images====<br />
* Do: Disable images...<br />
**Check: @@For contrast problems...<br />
* Turn off CSS...<br />
<br />
====More====<br />
''(See also Video & Sound below.)''<br />
<br />
===Check headings and other semantic structure [some parts drafted]===<br />
<span style="color:#808080;">EOWG notes - importance: HIGH; level: easy.</span><br />
<br />
... @@ brief summary of why & what to check for ...<br />
See also:<br />
* ? [http://www.w3.org/TR/2012/NOTE-WCAG20-TECHS-20120103/G141 G141 technique]<br />
* ? [http://www.w3.org/TR/2012/NOTE-WCAG20-TECHS-20120103/H42 H42 technique]<br />
<br />
What you're looking for: @@<br />
<ul><br />
<li>Does the page have any headings?</li><br />
<li>Are the things that look like headings that aren't marked up as heading?</li><br />
<li>Are there things that are marked up as headings that aren't really headings?</li><br />
</ul><br />
<br />
====Checking with WAVE====<br />
<ol><br />
<li>Open [http://wave.webaim.org/ WAVE]</li><br />
<li>Enter the web page:<br />
<ul><br />
<li>If the website is online: Enter a web site address and click the "WAVE the page!" button.</li><br />
<li>... Upload a file...</li><br />
<li>... Check HTML code...</li><br />
</ul></li><br />
<li>Check headings:<br />
<ul><br />
<li>...</li><br />
</ul></li><br />
<li>Check lists:<br />
<ul><br />
<li>...</li><br />
</ul></li><br />
</ol><br />
<br />
====Checking headings with HTML Validator====<br />
<ol><br />
<li> Open the [http://validator.w3.org/ W3C HTML Validator (The W3C Markup Validation Service)].</li><br />
<li>Select the appropriate tab and input the page:<br />
<ul><br />
<li>If the web page is online, leave the '''Validate by URI''' tab selected. <br />In the Address field, type the URI (e.g., www.w3.org).</li><br />
<li>If the web page is on your local computer, click the '''Validate by File Upload''' tab.<br />In the File field, select &quot;Choose...&quot; and find the file on your computer.</li><br />
<li>If you will paste the HTML code/markup, '''Validate by Direct Input''' tab.<br />Paste your HTML in the Enter the Markup to validate: field.</li><br />
</ul><br />
</li><br />
<li>Click the More Options link.</li><br />
<li>Select the Outline checkbox.</li><br />
<li>Click the Check button.</li><br />
<li>In the results page at the top, click the Outline link.</li><br />
<li>Compare the Document Outline to the visual rendering of the page. <ul><br />
<li>Are the things that look like headings listed in the Document Outline?</li><br />
<li>Are there things in the Document Outline that aren't really headings?<br /><br />
</li><br />
</ul></li><br />
</ol><br />
<br />
===Check keyboard access and visual focus [mostly drafted]===<br />
<span style="color:#808080;">EOWG notes - importance: HIGH; 5min?: some yes.</span><br />
<br />
Many people do not use the mouse and rely on the keyboard to interact with the Web. This requires keyboard access to all functionality, including links, form controls, input, and other user interface components. See also:<br />
* [http://www.w3.org/WAI/intro/people-use-web/principles#keyboard Functionality is available from a keyboard]<br />
* [http://www.w3.org/WAI/users/browsing#keyboard Browsing the Web by Keyboard] section in [http://www.w3.org/WAI/users/browsing Better Web Browsing: Tips for Customizing Your Computer]<br />
* [BAD example]<br />
<br />
Checks:<br />
* Click in the address bar, then put your mouse aside and don't use it. Press the 'tab' key to move around the page.<br />
** Can you tab to all the elements, including links, form fields, buttons, and @@? Are there any actions you can't get to (e.g., if they are only available on mouse hover)?<br />
** Does the focus get stuck anywhere - that is, you can't tab away from a control (called a "keyboard trap")?<br />
** Does the order that items get focus make sense? (e.g., you don't jump around the page out of order logically)<br />
** Can you tab right through to the bottom of the page and then resume again from the top? (e.g. you don't get stuck anywhere and can't move on)<br />
** Can you clearly see where you've 'tabbed' to - that is, is the focus clearly visible all the time?<br />
** If there is a drop-down box (for example, for navigating to a different page): If you tab into the drop-down box, can you use the down/up arrow keys to move through the options, and @@use 'tab' to the following item@@? (Make sure it doesn't automatically select the first item.)<br />
''(see also Forms)''<br />
<br />
Notes:<br />
* maybe don't see focus at all and are confused...<br />
* Mac browsers by default only tab through forms, will need to turn on...<br />
* not work easily in Opera...<br />
* ...<br />
<br />
===Check the page title [mostly drafted]===<br />
<span style="color:#808080;">EOWG notes - importance: medium; 5min?: yes.</span><br />
<br />
@@ add image showing only a few words with multiple tabs in browser...<br />
<br />
Page titles are the first information read by a screen reader; useful for when users have multiple web pages opens, e.g., on different tabs and go between different windows. (Also good for adding to bookmarks & also search engine results.) See also:<br />
* [http://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-title.html Page Titled- Understanding SC 2.4.2]<br />
* [BAD examples]<br />
<br />
Checks:<br />
* Do: Look at the browser's window title bar.<br />
** Check: Should indicate the specific page and website as appropriate (often it is similar to the heading of the page).<br />
<br />
Common failures:<br />
* Every page has the same title.<br />
* Long name of the website is first, then the specific page title.<br />
<br />
Note:<br />
* Some browsers don't show title in browser title bar (Chrome, IE)<br />
<br />
===Check link text [partly drafted]===<br />
<span style="color:#808080;">EOWG notes - importance: @@; 5min?: @@.</span><br />
<br />
Wording the text that is linked to indicate clearly where the link goes or what the link does. Some people use a list of links where they don't see the text around it. See also:<br />
* [http://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-refs.html Link Purpose (In Context): Understanding SC 2.4.4] (Level A)<br />
* [http://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-link.html Link Purpose (Link Only): Understanding SC 2.4.9] (Level AAA)<br />
* [BAD]<br />
<br />
Check this<br />
* @@<br />
** @@<br />
<br />
Common failures:<br />
* Link text is something like "Click here" or "More" without any additional clarifying text.<br />
<br />
Notes:<br />
* List links (Can't find this in regular Firefox but easy in Opera where you can get a list of links from the standard tools menu, showing both title and url)<br />
* Issue - titles... ([http://ianpouncey.com/weblog/2010/01/title-attributes/ Ian P says never use titles on links], Sylvie agrees.)<br />
<br />
===Check usable with page zoomed and text enlarged [open for drafting]===<br />
* Zoom to 200%<br />
* Text-only enlargement... (e.g., text actually changes in IE)<br />
<br />
===Check color contrast [open for drafting]===<br />
Wayne and Tom:<br />
<br />
===Check color coding [open for drafting]===<br />
<br />
===Content order [open for drafting]===<br />
<br />
===Visual focus [open for drafting]===<br />
<br />
===Video, Sound, (multimedia) [open for drafting]===<br />
alt...<br />
<br />
===Forms [open for drafting]===<br />
...<br />
<br />
===Tables [open for drafting]===<br />
...<br />
<br />
===Check flickering, flashing, blinking [open for drafting]===<br />
<br />
===Window resize [open for drafting]===<br />
... probably too complex an issue for preliminary eval ...<br />
<br />
===WAI-ARIA [open for drafting]===<br />
(note: not a requirement for accessibility)<br />
Wayne and Tom<br />
<br />
===Time-dependent responses [maybe not including this one]===<br />
<br />
===Validate HTML & CSS [maybe not including this one]===<br />
Note: Validation not WCAG requirement...<br />
* ...<br />
* Check that the document language is declared<br />
<br />
===Check usable without CSS, javascript [probably not including this one]===<br />
NOTE: saz not WCAG requirement<br />
* Disable CSS<br />
* core content available<br />
* check images, check content displayed or not displayed (e.g., display:none), sequence<br />
* links<br />
* ...<br />
Reasonable display without style is a US Section 508 requirement, and is a significant weakening of accessibility for people with low vision.<br />
<br />
===Use an evaluation tool [probably won't include this generically]===<br />
*Use one-page auto checker<br />
EOWG discussion:<br />
* There are a number of simple tools where you just put in the URL of the page of interest and the results are returned automatically eg WAVE and TAW. The results aren't necessarily so easy to interpret if you are a newbie to accessibility. Perhaps we should put this after the top 5 easy checks - and add a paragraph to confirm the benefits and limitations, or discuss some of the common types of problem found {Suzette}<br />
<br />
==More Thorough Evaluation==<br />
@@ point to Conformance Evaluation page and WCAG-EM.<br />
<br />
==Contributors==<br />
Thanks to:<br />
* Those who drafted items for EOWG to review on Thursday 15 November:<br />
** <span style="background:yellow;">{name} for drafting {section}</span><br />
** {name} for drafting {section}<br />
* Andrew & Shawn for editing the [http://www.w3.org/WAI/EO/wiki/Web_Accessibility_Preliminary_Evaluation#Check_keyboard_access_and_visual_focus_.5Bmostly_drafted.5D keyboard access & visual focus section] in early Nov.<br />
* Ian, Suzette, Vicki, Sylvie, Helle, Shawn for working on an early draft at the [http://www.w3.org/2012/11/02-eo-minutes f2f in Nov].<br />
* Sharron for help making all the drafts and versions less confusing.<br />
* Wayne and Ian for sharing colleagues' related work.<br />
* Denis for edits to the old page content.</div>Wdickhttps://www.w3.org/WAI/EO/wiki/index.php?title=Web_Accessibility_Preliminary_Evaluation&diff=2066Web Accessibility Preliminary Evaluation2012-11-13T19:58:16Z<p>Wdick: /* WAI-ARIA [open for drafting] */</p>
<hr />
<div>Nav: [[Main Page|EOWG wiki main page]] > [[Main_Page#Evaluation_pages | Evaluation Pages ]]<br/><br />
Old page on WAI website: [http://www.w3.org/WAI/eval/preliminary.html Prelim Eval]<br/><br />
<br />
Note:<br />
* '''A template for the check items is at the top of the [http://www.w3.org/WAI/EO/wiki/Talk:Web_Accessibility_Preliminary_Evaluation discussion tab].'''<br />
* For tasks, example user cases with audience, and focus for this and related documents, see the [[Eval Analysis]] page<br />
* For previous drafts and contributed material, see:<br />
** Old page with Denis' edits and Ian's input in [[Preliminary Eval - old notes]]<br />
** Extensive revisions and suggestions at [[Archived_Work_on_PreLimEval]]<br />
** From Wayne & Tom [[Prelim Eval input: Smart analysis simplified]]<br />
<br />
<span style="background:yellow;">'''''Important Note''''': For this draft we have some tool-specific guidance. However, there are potential issues with vendor-neutraility and we might need to address this a different way &mdash; for example, moving tool-specific guidance to WebPlatform Docs or the WAI-Engage wiki where people can easily add other tools.</span><br />
<br />
<br />
__TOC__<br />
<br />
<span style="background:yellow;">'''''Important Note''''': For this draft we have some tool-specific guidance. However, there are potential issues with vendor-neutraility and we might need to address this a different way &mdash; for example, moving tool-specific guidance to WebPlatform Docs or the WAI-Engage wiki where people can easily add other tools.</span><br />
<br />
=Preliminary Review|Evaluation: Checking the Accessibility of a Web Page=<br />
<br />
==Introduction==<br />
<p>Testing and evaluating a web site for accessibility may seem intimidating but it need not be. There are simple ways to check on some basic features that do not require special skills or tools beyond your browser controls. Here you will find two approaches to doing Preliminary Evaluation of your pages. The first is a Quick Check - a list of 5 things you can do in 5 minutes. The second, while not a full conformance validation of WCAG2 Guidelines, will help ensure basic accessibility across a broader range of issues. While the second can quickly determine if the most important elements of a web page can be used by most persons with disabilities, it also requires more knowledge of accessibility principles and a few testing tools.</p><br />
<br />
<p>... @@ first run on good BAD page to see what it should look like, then on the bad page ... </p><br />
<br />
==Quick Checks==<br />
<br />
<p>Here are 5 things you can do to quickly check for accessibility barriers on a web page:<br /><br />
<span style="color:#808080;">{EOWG note: Let's work on the longer section first, then decide what we can move up to the quick checks section later.</span></p><br />
#First thing.<br />
#Second thing.<br />
#Third thing. <br />
#Fourth thing. <br />
#Fifth thing.<br />
<br />
Once you have taken this quick dip you may be ready to dive a bit deeper. The next section provides more context and additional things you can do to check for accessibility barriers.<br />
<br />
==A Deeper Look==<br />
<p>If you are interested in a more comprehensive look at the page(s), here more tests that require a little more time, skills, and/or tools.</p><br />
<br />
<span style="color:#808080;">''{reminder: A template for the check draft items is at the top of the [http://www.w3.org/WAI/EO/wiki/Talk:Web_Accessibility_Preliminary_Evaluation discussion tab].}''</span><br />
<br />
===Check text descriptions for images [mostly drafted]===<br />
<span style="color:#808080;">EOWG notes - importance: HIGH; 5min?: yes.</span><br />
<br />
Text alternatives convey the purpose of an image or function to provide an equivalent user experience. For instance, an text alternative for a search button is "search". See also:<br />
* [http://www.w3.org/WAI/intro/people-use-web/principles#alternatives Text alternatives for non-text content section in Accessibility Principles]<br />
* [BAD Example]<br />
<br />
Notes:<br />
<ul><br />
<li>Text that is actually an image.</li><br />
<li>Important image should have alt text that provides adequate alternative of the image for people who cannot see it...</li><br />
<li>Image that doesn't convey important information...</li><br />
<li>@@ Some guidance on not saying things like "this is an image..." or "this is a link..."</li><br />
</ul><br />
<br />
====Checking with WAVE====<br />
<ol><br />
<li>Open [http://wave.webaim.org/ WAVE]</li><br />
<li>In the "Enter a web site address" put the URI (for example, <code>www.w3.org</code>) and click the "WAVE the page!" button.</li><br />
<li>Look for a [http://wave.webaim.org/waveicons/no_alt.png no alt icon] that indicates that alt text is missing.</li><br />
<li>Look for the [http://wave.webaim.org/waveicons/alt_text_link.png alt icon] that has the alt text next to it.</li><br />
</ol><br />
<br />
====Disable images====<br />
* Do: Disable images...<br />
**Check: @@For contrast problems...<br />
* Turn off CSS...<br />
<br />
====More====<br />
''(See also Video & Sound below.)''<br />
<br />
===Check headings and other semantic structure [some parts drafted]===<br />
<span style="color:#808080;">EOWG notes - importance: HIGH; level: easy.</span><br />
<br />
... @@ brief summary of why & what to check for ...<br />
See also:<br />
* ? [http://www.w3.org/TR/2012/NOTE-WCAG20-TECHS-20120103/G141 G141 technique]<br />
* ? [http://www.w3.org/TR/2012/NOTE-WCAG20-TECHS-20120103/H42 H42 technique]<br />
<br />
What you're looking for: @@<br />
<ul><br />
<li>Does the page have any headings?</li><br />
<li>Are the things that look like headings that aren't marked up as heading?</li><br />
<li>Are there things that are marked up as headings that aren't really headings?</li><br />
</ul><br />
<br />
====Checking with WAVE====<br />
<ol><br />
<li>Open [http://wave.webaim.org/ WAVE]</li><br />
<li>Enter the web page:<br />
<ul><br />
<li>If the website is online: Enter a web site address and click the "WAVE the page!" button.</li><br />
<li>... Upload a file...</li><br />
<li>... Check HTML code...</li><br />
</ul></li><br />
<li>Check headings:<br />
<ul><br />
<li>...</li><br />
</ul></li><br />
<li>Check lists:<br />
<ul><br />
<li>...</li><br />
</ul></li><br />
</ol><br />
<br />
====Checking headings with HTML Validator====<br />
<ol><br />
<li> Open the [http://validator.w3.org/ W3C HTML Validator (The W3C Markup Validation Service)].</li><br />
<li>Select the appropriate tab and input the page:<br />
<ul><br />
<li>If the web page is online, leave the '''Validate by URI''' tab selected. <br />In the Address field, type the URI (e.g., www.w3.org).</li><br />
<li>If the web page is on your local computer, click the '''Validate by File Upload''' tab.<br />In the File field, select &quot;Choose...&quot; and find the file on your computer.</li><br />
<li>If you will paste the HTML code/markup, '''Validate by Direct Input''' tab.<br />Paste your HTML in the Enter the Markup to validate: field.</li><br />
</ul><br />
</li><br />
<li>Click the More Options link.</li><br />
<li>Select the Outline checkbox.</li><br />
<li>Click the Check button.</li><br />
<li>In the results page at the top, click the Outline link.</li><br />
<li>Compare the Document Outline to the visual rendering of the page. <ul><br />
<li>Are the things that look like headings listed in the Document Outline?</li><br />
<li>Are there things in the Document Outline that aren't really headings?<br /><br />
</li><br />
</ul></li><br />
</ol><br />
<br />
===Check keyboard access and visual focus [mostly drafted]===<br />
<span style="color:#808080;">EOWG notes - importance: HIGH; 5min?: some yes.</span><br />
<br />
Many people do not use the mouse and rely on the keyboard to interact with the Web. This requires keyboard access to all functionality, including links, form controls, input, and other user interface components. See also:<br />
* [http://www.w3.org/WAI/intro/people-use-web/principles#keyboard Functionality is available from a keyboard]<br />
* [http://www.w3.org/WAI/users/browsing#keyboard Browsing the Web by Keyboard] section in [http://www.w3.org/WAI/users/browsing Better Web Browsing: Tips for Customizing Your Computer]<br />
* [BAD example]<br />
<br />
Checks:<br />
* Click in the address bar, then put your mouse aside and don't use it. Press the 'tab' key to move around the page.<br />
** Can you tab to all the elements, including links, form fields, buttons, and @@? Are there any actions you can't get to (e.g., if they are only available on mouse hover)?<br />
** Does the focus get stuck anywhere - that is, you can't tab away from a control (called a "keyboard trap")?<br />
** Does the order that items get focus make sense? (e.g., you don't jump around the page out of order logically)<br />
** Can you tab right through to the bottom of the page and then resume again from the top? (e.g. you don't get stuck anywhere and can't move on)<br />
** Can you clearly see where you've 'tabbed' to - that is, is the focus clearly visible all the time?<br />
** If there is a drop-down box (for example, for navigating to a different page): If you tab into the drop-down box, can you use the down/up arrow keys to move through the options, and @@use 'tab' to the following item@@? (Make sure it doesn't automatically select the first item.)<br />
''(see also Forms)''<br />
<br />
Notes:<br />
* maybe don't see focus at all and are confused...<br />
* Mac browsers by default only tab through forms, will need to turn on...<br />
* not work easily in Opera...<br />
* ...<br />
<br />
===Check the page title [mostly drafted]===<br />
<span style="color:#808080;">EOWG notes - importance: medium; 5min?: yes.</span><br />
<br />
@@ add image showing only a few words with multiple tabs in browser...<br />
<br />
Page titles are the first information read by a screen reader; useful for when users have multiple web pages opens, e.g., on different tabs and go between different windows. (Also good for adding to bookmarks & also search engine results.) See also:<br />
* [http://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-title.html Page Titled- Understanding SC 2.4.2]<br />
* [BAD examples]<br />
<br />
Checks:<br />
* Do: Look at the browser's window title bar.<br />
** Check: Should indicate the specific page and website as appropriate (often it is similar to the heading of the page).<br />
<br />
Common failures:<br />
* Every page has the same title.<br />
* Long name of the website is first, then the specific page title.<br />
<br />
Note:<br />
* Some browsers don't show title in browser title bar (Chrome, IE)<br />
<br />
===Check link text [partly drafted]===<br />
<span style="color:#808080;">EOWG notes - importance: @@; 5min?: @@.</span><br />
<br />
Wording the text that is linked to indicate clearly where the link goes or what the link does. Some people use a list of links where they don't see the text around it. See also:<br />
* [http://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-refs.html Link Purpose (In Context): Understanding SC 2.4.4] (Level A)<br />
* [http://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-link.html Link Purpose (Link Only): Understanding SC 2.4.9] (Level AAA)<br />
* [BAD]<br />
<br />
Check this<br />
* @@<br />
** @@<br />
<br />
Common failures:<br />
* Link text is something like "Click here" or "More" without any additional clarifying text.<br />
<br />
Notes:<br />
* List links (Can't find this in regular Firefox but easy in Opera where you can get a list of links from the standard tools menu, showing both title and url)<br />
* Issue - titles... ([http://ianpouncey.com/weblog/2010/01/title-attributes/ Ian P says never use titles on links], Sylvie agrees.)<br />
<br />
===Check usable with page zoomed and text enlarged [open for drafting]===<br />
* Zoom to 200%<br />
* Text-only enlargement... (e.g., text actually changes in IE)<br />
<br />
===Check color contrast [open for drafting]===<br />
Wayne and Tom:<br />
<br />
===Check color coding [open for drafting]===<br />
<br />
===Content order [open for drafting]===<br />
<br />
===Visual focus [open for drafting]===<br />
<br />
===Video, Sound, (multimedia) [open for drafting]===<br />
alt...<br />
<br />
===Forms [open for drafting]===<br />
...<br />
<br />
===Tables [open for drafting]===<br />
...<br />
<br />
===Check flickering, flashing, blinking [open for drafting]===<br />
<br />
===Window resize [open for drafting]===<br />
... probably too complex an issue for preliminary eval ...<br />
<br />
===WAI-ARIA [open for drafting]===<br />
(note: not a requirement for accessibility)<br />
Wayne and Tom<br />
<br />
===Time-dependent responses [maybe not including this one]===<br />
<br />
===Validate HTML & CSS [maybe not including this one]===<br />
Note: Validation not WCAG requirement...<br />
* ...<br />
* Check that the document language is declared<br />
<br />
===Check usable without CSS, javascript [probably not including this one]===<br />
NOTE: saz not WCAG requirement<br />
* Disable CSS<br />
* core content available<br />
* check images, check content displayed or not displayed (e.g., display:none), sequence<br />
* links<br />
* ...<br />
<br />
===Use an evaluation tool [probably won't include this generically]===<br />
*Use one-page auto checker<br />
EOWG discussion:<br />
* There are a number of simple tools where you just put in the URL of the page of interest and the results are returned automatically eg WAVE and TAW. The results aren't necessarily so easy to interpret if you are a newbie to accessibility. Perhaps we should put this after the top 5 easy checks - and add a paragraph to confirm the benefits and limitations, or discuss some of the common types of problem found {Suzette}<br />
<br />
==More Thorough Evaluation==<br />
@@ point to Conformance Evaluation page and WCAG-EM.<br />
<br />
==Contributors==<br />
Thanks to:<br />
* Those who drafted items for EOWG to review on Thursday 15 November:<br />
** <span style="background:yellow;">{name} for drafting {section}</span><br />
** {name} for drafting {section}<br />
* Andrew & Shawn for editing the [http://www.w3.org/WAI/EO/wiki/Web_Accessibility_Preliminary_Evaluation#Check_keyboard_access_and_visual_focus_.5Bmostly_drafted.5D keyboard access & visual focus section] in early Nov.<br />
* Ian, Suzette, Vicki, Sylvie, Helle, Shawn for working on an early draft at the [http://www.w3.org/2012/11/02-eo-minutes f2f in Nov].<br />
* Sharron for help making all the drafts and versions less confusing.<br />
* Wayne and Ian for sharing colleagues' related work.<br />
* Denis for edits to the old page content.</div>Wdickhttps://www.w3.org/WAI/EO/wiki/index.php?title=Web_Accessibility_Preliminary_Evaluation&diff=2065Web Accessibility Preliminary Evaluation2012-11-13T19:57:23Z<p>Wdick: /* Check color contrast [open for drafting] */</p>
<hr />
<div>Nav: [[Main Page|EOWG wiki main page]] > [[Main_Page#Evaluation_pages | Evaluation Pages ]]<br/><br />
Old page on WAI website: [http://www.w3.org/WAI/eval/preliminary.html Prelim Eval]<br/><br />
<br />
Note:<br />
* '''A template for the check items is at the top of the [http://www.w3.org/WAI/EO/wiki/Talk:Web_Accessibility_Preliminary_Evaluation discussion tab].'''<br />
* For tasks, example user cases with audience, and focus for this and related documents, see the [[Eval Analysis]] page<br />
* For previous drafts and contributed material, see:<br />
** Old page with Denis' edits and Ian's input in [[Preliminary Eval - old notes]]<br />
** Extensive revisions and suggestions at [[Archived_Work_on_PreLimEval]]<br />
** From Wayne & Tom [[Prelim Eval input: Smart analysis simplified]]<br />
<br />
<span style="background:yellow;">'''''Important Note''''': For this draft we have some tool-specific guidance. However, there are potential issues with vendor-neutraility and we might need to address this a different way &mdash; for example, moving tool-specific guidance to WebPlatform Docs or the WAI-Engage wiki where people can easily add other tools.</span><br />
<br />
<br />
__TOC__<br />
<br />
<span style="background:yellow;">'''''Important Note''''': For this draft we have some tool-specific guidance. However, there are potential issues with vendor-neutraility and we might need to address this a different way &mdash; for example, moving tool-specific guidance to WebPlatform Docs or the WAI-Engage wiki where people can easily add other tools.</span><br />
<br />
=Preliminary Review|Evaluation: Checking the Accessibility of a Web Page=<br />
<br />
==Introduction==<br />
<p>Testing and evaluating a web site for accessibility may seem intimidating but it need not be. There are simple ways to check on some basic features that do not require special skills or tools beyond your browser controls. Here you will find two approaches to doing Preliminary Evaluation of your pages. The first is a Quick Check - a list of 5 things you can do in 5 minutes. The second, while not a full conformance validation of WCAG2 Guidelines, will help ensure basic accessibility across a broader range of issues. While the second can quickly determine if the most important elements of a web page can be used by most persons with disabilities, it also requires more knowledge of accessibility principles and a few testing tools.</p><br />
<br />
<p>... @@ first run on good BAD page to see what it should look like, then on the bad page ... </p><br />
<br />
==Quick Checks==<br />
<br />
<p>Here are 5 things you can do to quickly check for accessibility barriers on a web page:<br /><br />
<span style="color:#808080;">{EOWG note: Let's work on the longer section first, then decide what we can move up to the quick checks section later.</span></p><br />
#First thing.<br />
#Second thing.<br />
#Third thing. <br />
#Fourth thing. <br />
#Fifth thing.<br />
<br />
Once you have taken this quick dip you may be ready to dive a bit deeper. The next section provides more context and additional things you can do to check for accessibility barriers.<br />
<br />
==A Deeper Look==<br />
<p>If you are interested in a more comprehensive look at the page(s), here more tests that require a little more time, skills, and/or tools.</p><br />
<br />
<span style="color:#808080;">''{reminder: A template for the check draft items is at the top of the [http://www.w3.org/WAI/EO/wiki/Talk:Web_Accessibility_Preliminary_Evaluation discussion tab].}''</span><br />
<br />
===Check text descriptions for images [mostly drafted]===<br />
<span style="color:#808080;">EOWG notes - importance: HIGH; 5min?: yes.</span><br />
<br />
Text alternatives convey the purpose of an image or function to provide an equivalent user experience. For instance, an text alternative for a search button is "search". See also:<br />
* [http://www.w3.org/WAI/intro/people-use-web/principles#alternatives Text alternatives for non-text content section in Accessibility Principles]<br />
* [BAD Example]<br />
<br />
Notes:<br />
<ul><br />
<li>Text that is actually an image.</li><br />
<li>Important image should have alt text that provides adequate alternative of the image for people who cannot see it...</li><br />
<li>Image that doesn't convey important information...</li><br />
<li>@@ Some guidance on not saying things like "this is an image..." or "this is a link..."</li><br />
</ul><br />
<br />
====Checking with WAVE====<br />
<ol><br />
<li>Open [http://wave.webaim.org/ WAVE]</li><br />
<li>In the "Enter a web site address" put the URI (for example, <code>www.w3.org</code>) and click the "WAVE the page!" button.</li><br />
<li>Look for a [http://wave.webaim.org/waveicons/no_alt.png no alt icon] that indicates that alt text is missing.</li><br />
<li>Look for the [http://wave.webaim.org/waveicons/alt_text_link.png alt icon] that has the alt text next to it.</li><br />
</ol><br />
<br />
====Disable images====<br />
* Do: Disable images...<br />
**Check: @@For contrast problems...<br />
* Turn off CSS...<br />
<br />
====More====<br />
''(See also Video & Sound below.)''<br />
<br />
===Check headings and other semantic structure [some parts drafted]===<br />
<span style="color:#808080;">EOWG notes - importance: HIGH; level: easy.</span><br />
<br />
... @@ brief summary of why & what to check for ...<br />
See also:<br />
* ? [http://www.w3.org/TR/2012/NOTE-WCAG20-TECHS-20120103/G141 G141 technique]<br />
* ? [http://www.w3.org/TR/2012/NOTE-WCAG20-TECHS-20120103/H42 H42 technique]<br />
<br />
What you're looking for: @@<br />
<ul><br />
<li>Does the page have any headings?</li><br />
<li>Are the things that look like headings that aren't marked up as heading?</li><br />
<li>Are there things that are marked up as headings that aren't really headings?</li><br />
</ul><br />
<br />
====Checking with WAVE====<br />
<ol><br />
<li>Open [http://wave.webaim.org/ WAVE]</li><br />
<li>Enter the web page:<br />
<ul><br />
<li>If the website is online: Enter a web site address and click the "WAVE the page!" button.</li><br />
<li>... Upload a file...</li><br />
<li>... Check HTML code...</li><br />
</ul></li><br />
<li>Check headings:<br />
<ul><br />
<li>...</li><br />
</ul></li><br />
<li>Check lists:<br />
<ul><br />
<li>...</li><br />
</ul></li><br />
</ol><br />
<br />
====Checking headings with HTML Validator====<br />
<ol><br />
<li> Open the [http://validator.w3.org/ W3C HTML Validator (The W3C Markup Validation Service)].</li><br />
<li>Select the appropriate tab and input the page:<br />
<ul><br />
<li>If the web page is online, leave the '''Validate by URI''' tab selected. <br />In the Address field, type the URI (e.g., www.w3.org).</li><br />
<li>If the web page is on your local computer, click the '''Validate by File Upload''' tab.<br />In the File field, select &quot;Choose...&quot; and find the file on your computer.</li><br />
<li>If you will paste the HTML code/markup, '''Validate by Direct Input''' tab.<br />Paste your HTML in the Enter the Markup to validate: field.</li><br />
</ul><br />
</li><br />
<li>Click the More Options link.</li><br />
<li>Select the Outline checkbox.</li><br />
<li>Click the Check button.</li><br />
<li>In the results page at the top, click the Outline link.</li><br />
<li>Compare the Document Outline to the visual rendering of the page. <ul><br />
<li>Are the things that look like headings listed in the Document Outline?</li><br />
<li>Are there things in the Document Outline that aren't really headings?<br /><br />
</li><br />
</ul></li><br />
</ol><br />
<br />
===Check keyboard access and visual focus [mostly drafted]===<br />
<span style="color:#808080;">EOWG notes - importance: HIGH; 5min?: some yes.</span><br />
<br />
Many people do not use the mouse and rely on the keyboard to interact with the Web. This requires keyboard access to all functionality, including links, form controls, input, and other user interface components. See also:<br />
* [http://www.w3.org/WAI/intro/people-use-web/principles#keyboard Functionality is available from a keyboard]<br />
* [http://www.w3.org/WAI/users/browsing#keyboard Browsing the Web by Keyboard] section in [http://www.w3.org/WAI/users/browsing Better Web Browsing: Tips for Customizing Your Computer]<br />
* [BAD example]<br />
<br />
Checks:<br />
* Click in the address bar, then put your mouse aside and don't use it. Press the 'tab' key to move around the page.<br />
** Can you tab to all the elements, including links, form fields, buttons, and @@? Are there any actions you can't get to (e.g., if they are only available on mouse hover)?<br />
** Does the focus get stuck anywhere - that is, you can't tab away from a control (called a "keyboard trap")?<br />
** Does the order that items get focus make sense? (e.g., you don't jump around the page out of order logically)<br />
** Can you tab right through to the bottom of the page and then resume again from the top? (e.g. you don't get stuck anywhere and can't move on)<br />
** Can you clearly see where you've 'tabbed' to - that is, is the focus clearly visible all the time?<br />
** If there is a drop-down box (for example, for navigating to a different page): If you tab into the drop-down box, can you use the down/up arrow keys to move through the options, and @@use 'tab' to the following item@@? (Make sure it doesn't automatically select the first item.)<br />
''(see also Forms)''<br />
<br />
Notes:<br />
* maybe don't see focus at all and are confused...<br />
* Mac browsers by default only tab through forms, will need to turn on...<br />
* not work easily in Opera...<br />
* ...<br />
<br />
===Check the page title [mostly drafted]===<br />
<span style="color:#808080;">EOWG notes - importance: medium; 5min?: yes.</span><br />
<br />
@@ add image showing only a few words with multiple tabs in browser...<br />
<br />
Page titles are the first information read by a screen reader; useful for when users have multiple web pages opens, e.g., on different tabs and go between different windows. (Also good for adding to bookmarks & also search engine results.) See also:<br />
* [http://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-title.html Page Titled- Understanding SC 2.4.2]<br />
* [BAD examples]<br />
<br />
Checks:<br />
* Do: Look at the browser's window title bar.<br />
** Check: Should indicate the specific page and website as appropriate (often it is similar to the heading of the page).<br />
<br />
Common failures:<br />
* Every page has the same title.<br />
* Long name of the website is first, then the specific page title.<br />
<br />
Note:<br />
* Some browsers don't show title in browser title bar (Chrome, IE)<br />
<br />
===Check link text [partly drafted]===<br />
<span style="color:#808080;">EOWG notes - importance: @@; 5min?: @@.</span><br />
<br />
Wording the text that is linked to indicate clearly where the link goes or what the link does. Some people use a list of links where they don't see the text around it. See also:<br />
* [http://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-refs.html Link Purpose (In Context): Understanding SC 2.4.4] (Level A)<br />
* [http://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-link.html Link Purpose (Link Only): Understanding SC 2.4.9] (Level AAA)<br />
* [BAD]<br />
<br />
Check this<br />
* @@<br />
** @@<br />
<br />
Common failures:<br />
* Link text is something like "Click here" or "More" without any additional clarifying text.<br />
<br />
Notes:<br />
* List links (Can't find this in regular Firefox but easy in Opera where you can get a list of links from the standard tools menu, showing both title and url)<br />
* Issue - titles... ([http://ianpouncey.com/weblog/2010/01/title-attributes/ Ian P says never use titles on links], Sylvie agrees.)<br />
<br />
===Check usable with page zoomed and text enlarged [open for drafting]===<br />
* Zoom to 200%<br />
* Text-only enlargement... (e.g., text actually changes in IE)<br />
<br />
===Check color contrast [open for drafting]===<br />
Wayne and Tom:<br />
<br />
===Check color coding [open for drafting]===<br />
<br />
===Content order [open for drafting]===<br />
<br />
===Visual focus [open for drafting]===<br />
<br />
===Video, Sound, (multimedia) [open for drafting]===<br />
alt...<br />
<br />
===Forms [open for drafting]===<br />
...<br />
<br />
===Tables [open for drafting]===<br />
...<br />
<br />
===Check flickering, flashing, blinking [open for drafting]===<br />
<br />
===Window resize [open for drafting]===<br />
... probably too complex an issue for preliminary eval ...<br />
<br />
===WAI-ARIA [open for drafting]===<br />
(note: not a requirement for accessibility)<br />
<br />
===Time-dependent responses [maybe not including this one]===<br />
<br />
===Validate HTML & CSS [maybe not including this one]===<br />
Note: Validation not WCAG requirement...<br />
* ...<br />
* Check that the document language is declared<br />
<br />
===Check usable without CSS, javascript [probably not including this one]===<br />
NOTE: saz not WCAG requirement<br />
* Disable CSS<br />
* core content available<br />
* check images, check content displayed or not displayed (e.g., display:none), sequence<br />
* links<br />
* ...<br />
<br />
===Use an evaluation tool [probably won't include this generically]===<br />
*Use one-page auto checker<br />
EOWG discussion:<br />
* There are a number of simple tools where you just put in the URL of the page of interest and the results are returned automatically eg WAVE and TAW. The results aren't necessarily so easy to interpret if you are a newbie to accessibility. Perhaps we should put this after the top 5 easy checks - and add a paragraph to confirm the benefits and limitations, or discuss some of the common types of problem found {Suzette}<br />
<br />
==More Thorough Evaluation==<br />
@@ point to Conformance Evaluation page and WCAG-EM.<br />
<br />
==Contributors==<br />
Thanks to:<br />
* Those who drafted items for EOWG to review on Thursday 15 November:<br />
** <span style="background:yellow;">{name} for drafting {section}</span><br />
** {name} for drafting {section}<br />
* Andrew & Shawn for editing the [http://www.w3.org/WAI/EO/wiki/Web_Accessibility_Preliminary_Evaluation#Check_keyboard_access_and_visual_focus_.5Bmostly_drafted.5D keyboard access & visual focus section] in early Nov.<br />
* Ian, Suzette, Vicki, Sylvie, Helle, Shawn for working on an early draft at the [http://www.w3.org/2012/11/02-eo-minutes f2f in Nov].<br />
* Sharron for help making all the drafts and versions less confusing.<br />
* Wayne and Ian for sharing colleagues' related work.<br />
* Denis for edits to the old page content.</div>Wdickhttps://www.w3.org/WAI/EO/wiki/index.php?title=Web_Accessibility_Preliminary_Evaluation&diff=1933Web Accessibility Preliminary Evaluation2012-10-26T00:16:23Z<p>Wdick: /* More Thorough Evaluation */</p>
<hr />
<div>Nav: [[Main Page|EOWG wiki main page]] > [[Main_Page#Evaluation_pages | Evaluation Pages ]]<br/><br />
Old page on WAI website: [http://www.w3.org/WAI/eval/preliminary.html Prelim Eval]<br/><br />
Related: [[Preliminary Eval - old notes]]<br/><br />
'''''See also:'' [[Eval Analysis]] for tasks, example user cases with audience, and focus for this and related documents.'''<br />
<br />
__TOC__<br />
<br />
Note:<br />
* Tasks, use cases, and audiences are in the [[Eval Analysis]] page<br />
* Recent outline ideas, considerations, etc. are in the [http://www.w3.org/WAI/EO/wiki/Talk:Web_Accessibility_Preliminary_Evaluation Discussion tab]<br />
* Material from the old page with Denis' edits and Ian's input is at [[Preliminary Eval - old notes]] and extensive revisions and suggestions at [[Archived_Work_on_PreLimEval]]<br />
<br />
=Preliminary Review|Evaluation: Checking the Accessibility of a Web Page=<br />
<br />
==Introduction==<br />
<p>Testing and evaluating a web site for accessibility may seem intimidating but it need not be. There are simple ways to check on some basic features that do not require special skills or tools beyond your browser controls. Here you will find two approaches to doing Preliminary Evaluation of your pages. The first is a Quick Check - a list of 5 things you can do in 5 minutes. The second, while still a relatively "light" evaluation, may require more knowledge of accessibility principles and a few testing tools.</p><br />
<br />
==Quick Checks==<br />
<br />
Here are 5 things you can do to quickly check for accessibility barriers on a web page:<br />
<span style="color:#808080;">Group input needed to develop the top five list of things to include</span><br />
#First thing.<br />
#Second thing.<br />
#Third thing. <br />
#Fourth thing. <br />
#Fifth thing.<br />
<br />
Once you have taken this quick dip you may be ready to dive a bit deeper. The next section provides more context and additional things you can do to check for accessibility barriers.<br />
<br />
==A Deeper Look==<br />
<p>If you are interested in a more comprehensive look at the page(s), here more tests that require a little more time, skills, and/or tools.</p><br />
#Load your tool kit. (List tools that can be freely accessed and/or installed in browser, or link to [http://webaim.org/articles/freetools/ Complete list of Web Accessibility Evaluation Tools] and [http://webaim.org/articles/freetools/ Web AIM's Review of Free, Online Accessibility Tools])<br />
#Choose or create a reporting template (Introduce [http://www.w3.org/WAI/eval/template.html Evaluation Templates from WAI])<br />
#select a representative page sample (Introduce and link to [http://www.w3.org/WAI/eval/conformance.html WAI Conformance Evaluation Page]<br />
#Using your chosen template as a guide, examine the following features of the web page(s) you are evaluating: (Note to EO: Here is where we can describe testing procedures for each of these - and likely additional ones. Please suggest structure and additional content) <br />
===Text equivalents for non-text content===<br />
===Content structure and semantics=== <br />
===Use of color and contrast===<br />
===Form fields and labels=== <br />
===Keyboard navigation===<br />
===Significant hyperlinks===<br />
===Language identification===<br />
<br />
==More Thorough Evaluation==<br />
@@ point to Conformance Evaluation page and WCAG-EM.<br />
<br />
<h1 id="smart">Smart analysis simplified <span class="view">(Basic web view)</span></h1><cite>Contributed by Tom Jewett</cite> <br><br />
<p class="first"><strong>This human-intelligence-based method</strong><br />
can quickly determine if the most important elements of a web page can<br />
be used by most persons with disabilities. This checklist is no<br />
substitute for training, but once trained designers and developers can<br />
use this as they move from task to task. Used throughout the design and<br />
development process, this quick check will help to avoid accessibility<br />
errors that require major changes to the website's design or<br />
implementation.<br><br />
</p><br />
<ol><br />
<li id="temp"><strong>Validation check:</strong> HTML and CSS code should comply with W3C standards. <br><br />
<ul><br />
<li>Always check with W3C HTML and CSS Validators <br><br />
</li><br />
<li>Check that the document language is declared</li><br />
</ul><br><br />
</li><br />
<li id="visual"><strong>Visual check:</strong> Do each of the following common sense tests.<br><br />
</li><br />
<ul><br />
<li id="visual">All text should be easily legible to fully-sighted readers. <br><br />
</li><br />
<li id="visual">When text-only enlargement is used in the<br />
browser, all text (except banner logos) should respond and nothing<br />
should overlap or be hidden. <br><br />
</li><br />
<li id="visual">Make sure nothing is flickering or flashing unless this activity is necessary for the meaning of the content.</li><br />
<li id="visual">Make sure the Title of the page (in the browser title bar) is descriptive of the content. <br><br />
</li><br />
<li id="visual">Check to see that there is a clear luminosity<br />
difference between the background and text in the foreground. Be sure to<br />
test special states like hover for contrast problems. An easy way to<br />
test contrast is to reduce the luminosity of the monitor by about 40%.<br />
Foreground and background should still be distinct. <br><br />
</li><br />
</ul><br />
<li id="dynamic"><strong>Dynamic Content:</strong> This category<br />
includes time based media, animations, and content management system<br />
content, and rich internet applications. You will only identify the most<br />
obvious barriers; most dynamic content will require specialized,<br />
detailed analysis to insure complete accessibility. <br><br />
<ul><br />
<li>Visually, confirm access to captions and transcripts (when appropriate) for all time based media; <br><br />
</li><br />
<li>Do all testing with keyboard only.</li><br />
<li>Identify any time dependent responses.</li><br />
<li>Give all animation a quick Visual Check. Embedded text<br />
should be readable, enlargement capability should be present and<br />
effective, flashing and blinking should be confined to necessary<br />
semantic role, and test all states. <br><br />
</li><br />
<li>Treat CMS generated data just like normal web content, but try to separate template issues from local instance issues. <br><br />
</li><br />
<li>Check for WAI ARIA role, state and property presence in all ARIA widgets.</li><br />
<li>Check for WAI ARIA landmarks in all widgets.</li><br />
<li>Test every rich internet application with keyboard only.</li><br />
</ul><br />
</li><br />
<li id="text"><strong>Parallel Content:</strong> Frequently a page will require an alternative page to support accessibility. This is OK when required but check: <br><br />
<ul><br />
<li>Is there an automatic mechanism to update both versions simultaneously? There should be.<br><br />
</li><br />
<li>Is the alternative as rich semantically. For example replacing structured HTML with plain text is not acceptable. <br><br />
</li><br />
</ul><br />
</li><br />
<li id="headings"><strong>Color:</strong> Make sure that<br />
information is not conveyed by color alone. Verify that color contrast<br />
does not substitute for luminosity contrast. <br><br />
</li><br />
<li id="headings"><strong>Headings:</strong> Headings should match<br />
the actual semantic structure of the document and should be properly<br />
nested by level. Headings should also be used to identify and navigate<br />
between groups of related links. Proper use of headings is now more<br />
accessible than adding "skip navigation" links. For ARIA widgets, use<br />
landmarks as you would use headings for text based content.<br><br />
</li><br />
<li><strong>Image maps:</strong> HTML still has a MAP element, but<br />
today image maps are also implemented with CSS, sprites, and live<br />
regions. All maps and map equivalents still need to provide alternative<br />
text equivalents and full keyboard access. All image map objects contain<br />
graphical regions with hot spots that contain links or controls. The<br />
same issues arise with all image map objects. So always check: <br><br />
<ul><br />
<li>&nbsp;Active graphical hot spots of an image map must have associated text alternatives to activate controls and links.</li><br />
<li>Keyboard traversal should be possible through the controls<br />
and links present in the map. This includes visual access for sighted<br />
users who want to tab through an image map visually.<br><br />
</li><br />
</ul><br />
</li><br />
<li id="links"><strong>Links:</strong> All links must have text;<br />
each link's text should describe its destination clearly; duplicate link<br />
text should not point to different destinations, but links that point<br />
to the same destination may have different text depending on context. If<br />
any link has "javascript" as the target, it is likely to be an<br />
accessibility barrier that will require additional evaluation. All links<br />
should be reachable and visible using only the Tab key. </li><br />
<li id="forms"><strong>Forms:</strong> Each form control must have<br />
an associated label that describes its purpose. Tab order between form<br />
controls must match the order in which a user would normally complete<br />
them. Complex forms benefit from grouping controls with the FIELDSET<br />
element. The form title is optional if the purpose of the form can be<br />
determined from context. "Placeholder" text inside text boxes is no<br />
longer needed for screen readers; it is redundant in a properly-labeled<br />
form. Many forms will also have to be evaluated separately for dynamic<br />
behavior such as error response. </li><br />
<li id="frames"><strong>Frames:</strong> Frames are deprecated and<br />
should never be used in new development. If your software maintenance<br />
cycle includes upgrading code that includes frames, it is time to remove<br />
them.</li><br />
<li id="frames"><strong>I</strong><strong>frames:</strong> This tool is necessary for multi server access. Content introduced through iframes should be tested like any content.<br><br />
</li><br />
<li id="images"><strong>Images:</strong> With images replaced by<br />
their text equivalents, no information or navigation should be lost to<br />
any visitor to the page. Purely decorative images should have null<br />
(empty) text equivalents. All images should have text alternatives,<br />
content or explicit null. </li><br />
<li id="styles"><strong>Styles and layout:</strong> View the page<br />
with all style off. The semantic structure of the page content should be<br />
readily understandable from the browser's default rendering (of<br />
headings, lists, and so on) and navigable by assistive technologies. No<br />
content should appear that was made visible by CSS solely with mouse<br />
action (hover) or otherwise hidden from sighted readers. With layout<br />
tables removed, the page should read in logical order from top to<br />
bottom; use of layout tables should be kept to an absolute minimum. </li><br />
<li id="tables"><strong>Data Tables:</strong> Layout tables (those<br />
with no heading elements) should never be used to contain truly tabular<br />
data, and should never have summary attributes. True data tables should<br />
have each data cell associated with its column (and row, if<br />
appropriate) header or headers. Complex tables should have each data<br />
cell associated with all applicable heading levels. </li><br />
</ol><br />
(edited by Wayne Dick)</div>Wdickhttps://www.w3.org/WAI/EO/wiki/index.php?title=Web_Accessibility_Preliminary_Evaluation&diff=1932Web Accessibility Preliminary Evaluation2012-10-26T00:15:00Z<p>Wdick: /* More Thorough Evaluation */</p>
<hr />
<div>Nav: [[Main Page|EOWG wiki main page]] > [[Main_Page#Evaluation_pages | Evaluation Pages ]]<br/><br />
Old page on WAI website: [http://www.w3.org/WAI/eval/preliminary.html Prelim Eval]<br/><br />
Related: [[Preliminary Eval - old notes]]<br/><br />
'''''See also:'' [[Eval Analysis]] for tasks, example user cases with audience, and focus for this and related documents.'''<br />
<br />
__TOC__<br />
<br />
Note:<br />
* Tasks, use cases, and audiences are in the [[Eval Analysis]] page<br />
* Recent outline ideas, considerations, etc. are in the [http://www.w3.org/WAI/EO/wiki/Talk:Web_Accessibility_Preliminary_Evaluation Discussion tab]<br />
* Material from the old page with Denis' edits and Ian's input is at [[Preliminary Eval - old notes]] and extensive revisions and suggestions at [[Archived_Work_on_PreLimEval]]<br />
<br />
=Preliminary Review|Evaluation: Checking the Accessibility of a Web Page=<br />
<br />
==Introduction==<br />
<p>Testing and evaluating a web site for accessibility may seem intimidating but it need not be. There are simple ways to check on some basic features that do not require special skills or tools beyond your browser controls. Here you will find two approaches to doing Preliminary Evaluation of your pages. The first is a Quick Check - a list of 5 things you can do in 5 minutes. The second, while still a relatively "light" evaluation, may require more knowledge of accessibility principles and a few testing tools.</p><br />
<br />
==Quick Checks==<br />
<br />
Here are 5 things you can do to quickly check for accessibility barriers on a web page:<br />
<span style="color:#808080;">Group input needed to develop the top five list of things to include</span><br />
#First thing.<br />
#Second thing.<br />
#Third thing. <br />
#Fourth thing. <br />
#Fifth thing.<br />
<br />
Once you have taken this quick dip you may be ready to dive a bit deeper. The next section provides more context and additional things you can do to check for accessibility barriers.<br />
<br />
==A Deeper Look==<br />
<p>If you are interested in a more comprehensive look at the page(s), here more tests that require a little more time, skills, and/or tools.</p><br />
#Load your tool kit. (List tools that can be freely accessed and/or installed in browser, or link to [http://webaim.org/articles/freetools/ Complete list of Web Accessibility Evaluation Tools] and [http://webaim.org/articles/freetools/ Web AIM's Review of Free, Online Accessibility Tools])<br />
#Choose or create a reporting template (Introduce [http://www.w3.org/WAI/eval/template.html Evaluation Templates from WAI])<br />
#select a representative page sample (Introduce and link to [http://www.w3.org/WAI/eval/conformance.html WAI Conformance Evaluation Page]<br />
#Using your chosen template as a guide, examine the following features of the web page(s) you are evaluating: (Note to EO: Here is where we can describe testing procedures for each of these - and likely additional ones. Please suggest structure and additional content) <br />
===Text equivalents for non-text content===<br />
===Content structure and semantics=== <br />
===Use of color and contrast===<br />
===Form fields and labels=== <br />
===Keyboard navigation===<br />
===Significant hyperlinks===<br />
===Language identification===<br />
<br />
==More Thorough Evaluation==<br />
@@ point to Conformance Evaluation page and WCAG-EM.<br />
<br />
<h1 id="smart">Smart analysis simplified <span class="view">(Basic web view)</span></h1><cite>Contributed by Tom Jewett</cite> <br><br />
<p class="first"><strong>This human-intelligence-based method</strong><br />
can quickly determine if the most important elements of a web page can<br />
be used by most persons with disabilities. This checklist is no<br />
substitute for training, but once trained designers and developers can<br />
use this as they move from task to task. Used throughout the design and<br />
development process, this quick check will help to avoid accessibility<br />
errors that require major changes to the website's design or<br />
implementation.<br><br />
</p><br />
<ol><br />
<li id="temp"><strong>Validation check:</strong> HTML and CSS code should comply with W3C standards. <br><br />
<ul><br />
<li>Always check with W3C HTML and CSS Validators <br><br />
</li><br />
<li>Check that the document language is declared</li><br />
</ul><br><br />
</li><br />
<li id="visual"><strong>Visual check:</strong> Do each of the following common sense tests.<br><br />
</li><br />
<ul><br />
<li id="visual">All text should be easily legible to fully-sighted readers. <br><br />
</li><br />
<li id="visual">When text-only enlargement is used in the<br />
browser, all text (except banner logos) should respond and nothing<br />
should overlap or be hidden. <br><br />
</li><br />
<li id="visual">Make sure nothing is flickering or flashing unless this activity is necessary for the meaning of the content.</li><br />
<li id="visual">Make sure the Title of the page (in the browser title bar) is descriptive of the content. <br><br />
</li><br />
<li id="visual">Check to see that there is a clear luminosity<br />
difference between the background and text in the foreground. Be sure to<br />
test special states like hover for contrast problems. An easy way to<br />
test contrast is to reduce the luminosity of the monitor by about 40%.<br />
Foreground and background should still be distinct. <br><br />
</li><br />
</ul><br />
<li id="dynamic"><strong>Dynamic Content:</strong> This category<br />
includes time based media, animations, and content management system<br />
content, and rich internet applications. You will only identify the most<br />
obvious barriers; most dynamic content will require specialized,<br />
detailed analysis to insure complete accessibility. <br><br />
<ul><br />
<li>Visually, confirm access to captions and transcripts (when appropriate) for all time based media; <br><br />
</li><br />
<li>Do all testing with keyboard only.</li><br />
<li>Identify any time dependent responses.</li><br />
<li>Give all animation a quick Visual Check. Embedded text<br />
should be readable, enlargement capability should be present and<br />
effective, flashing and blinking should be confined to necessary<br />
semantic role, and test all states. <br><br />
</li><br />
<li>Treat CMS generated data just like normal web content, but try to separate template issues from local instance issues. <br><br />
</li><br />
<li>Check for WAI ARIA role, state and property presence in all ARIA widgets.</li><br />
<li>Check for WAI ARIA landmarks in all widgets.</li><br />
<li>Test every rich internet application with keyboard only.</li><br />
</ul><br />
</li><br />
<li id="text"><strong>Parallel Content:</strong> Frequently a page will require an alternative page to support accessibility. This is OK when required but check: <br><br />
<ul><br />
<li>Is there an automatic mechanism to update both versions simultaneously? There should be.<br><br />
</li><br />
<li>Is the alternative as rich semantically. For example replacing structured HTML with plain text is not acceptable. <br><br />
</li><br />
</ul><br />
</li><br />
<li id="headings"><strong>Color:</strong> Make sure that<br />
information is not conveyed by color alone. Verify that color contrast<br />
does not substitute for luminosity contrast. <br><br />
</li><br />
<li id="headings"><strong>Headings:</strong> Headings should match<br />
the actual semantic structure of the document and should be properly<br />
nested by level. Headings should also be used to identify and navigate<br />
between groups of related links. Proper use of headings is now more<br />
accessible than adding "skip navigation" links. For ARIA widgets, use<br />
landmarks as you would use headings for text based content.<br><br />
</li><br />
<li><strong>Image maps:</strong> HTML still has a MAP element, but<br />
today image maps are also implemented with CSS, sprites, and live<br />
regions. All maps and map equivalents still need to provide alternative<br />
text equivalents and full keyboard access. All image map objects contain<br />
graphical regions with hot spots that contain links or controls. The<br />
same issues arise with all image map objects. So always check: <br><br />
<ul><br />
<li>&nbsp;Active graphical hot spots of an image map must have associated text alternatives to activate controls and links.</li><br />
<li>Keyboard traversal should be possible through the controls<br />
and links present in the map. This includes visual access for sighted<br />
users who want to tab through an image map visually.<br><br />
</li><br />
</ul><br />
</li><br />
<li id="links"><strong>Links:</strong> All links must have text;<br />
each link's text should describe its destination clearly; duplicate link<br />
text should not point to different destinations, but links that point<br />
to the same destination may have different text depending on context. If<br />
any link has "javascript" as the target, it is likely to be an<br />
accessibility barrier that will require additional evaluation. All links<br />
should be reachable and visible using only the Tab key. </li><br />
<li id="forms"><strong>Forms:</strong> Each form control must have<br />
an associated label that describes its purpose. Tab order between form<br />
controls must match the order in which a user would normally complete<br />
them. Complex forms benefit from grouping controls with the FIELDSET<br />
element. The form title is optional if the purpose of the form can be<br />
determined from context. "Placeholder" text inside text boxes is no<br />
longer needed for screen readers; it is redundant in a properly-labeled<br />
form. Many forms will also have to be evaluated separately for dynamic<br />
behavior such as error response. </li><br />
<li id="frames"><strong>Frames:</strong> Frames are deprecated and<br />
should never be used in new development. If your software maintenance<br />
cycle includes upgrading code that includes frames, it is time to remove<br />
them.</li><br />
<li id="frames"><strong>I</strong><strong>frames:</strong> This tool is necessary for multi server access. Content introduced through iframes should be tested like any content.<br><br />
</li><br />
<li id="images"><strong>Images:</strong> With images replaced by<br />
their text equivalents, no information or navigation should be lost to<br />
any visitor to the page. Purely decorative images should have null<br />
(empty) text equivalents. All images should have text alternatives,<br />
content or explicit null. </li><br />
<li id="styles"><strong>Styles and layout:</strong> View the page<br />
with all style off. The semantic structure of the page content should be<br />
readily understandable from the browser's default rendering (of<br />
headings, lists, and so on) and navigable by assistive technologies. No<br />
content should appear that was made visible by CSS solely with mouse<br />
action (hover) or otherwise hidden from sighted readers. With layout<br />
tables removed, the page should read in logical order from top to<br />
bottom; use of layout tables should be kept to an absolute minimum. </li><br />
<li id="tables"><strong>Data Tables:</strong> Layout tables (those<br />
with no heading elements) should never be used to contain truly tabular<br />
data, and should never have summary attributes. True data tables should<br />
have each data cell associated with its column (and row, if<br />
appropriate) header or headers. Complex tables should have each data<br />
cell associated with all applicable heading levels. </li><br />
</ol></div>Wdickhttps://www.w3.org/WAI/EO/wiki/index.php?title=Web_Accessibility_Preliminary_Evaluation&diff=1931Web Accessibility Preliminary Evaluation2012-10-26T00:12:29Z<p>Wdick: /* More Thorough Evaluation */</p>
<hr />
<div>Nav: [[Main Page|EOWG wiki main page]] > [[Main_Page#Evaluation_pages | Evaluation Pages ]]<br/><br />
Old page on WAI website: [http://www.w3.org/WAI/eval/preliminary.html Prelim Eval]<br/><br />
Related: [[Preliminary Eval - old notes]]<br/><br />
'''''See also:'' [[Eval Analysis]] for tasks, example user cases with audience, and focus for this and related documents.'''<br />
<br />
__TOC__<br />
<br />
Note:<br />
* Tasks, use cases, and audiences are in the [[Eval Analysis]] page<br />
* Recent outline ideas, considerations, etc. are in the [http://www.w3.org/WAI/EO/wiki/Talk:Web_Accessibility_Preliminary_Evaluation Discussion tab]<br />
* Material from the old page with Denis' edits and Ian's input is at [[Preliminary Eval - old notes]] and extensive revisions and suggestions at [[Archived_Work_on_PreLimEval]]<br />
<br />
=Preliminary Review|Evaluation: Checking the Accessibility of a Web Page=<br />
<br />
==Introduction==<br />
<p>Testing and evaluating a web site for accessibility may seem intimidating but it need not be. There are simple ways to check on some basic features that do not require special skills or tools beyond your browser controls. Here you will find two approaches to doing Preliminary Evaluation of your pages. The first is a Quick Check - a list of 5 things you can do in 5 minutes. The second, while still a relatively "light" evaluation, may require more knowledge of accessibility principles and a few testing tools.</p><br />
<br />
==Quick Checks==<br />
<br />
Here are 5 things you can do to quickly check for accessibility barriers on a web page:<br />
<span style="color:#808080;">Group input needed to develop the top five list of things to include</span><br />
#First thing.<br />
#Second thing.<br />
#Third thing. <br />
#Fourth thing. <br />
#Fifth thing.<br />
<br />
Once you have taken this quick dip you may be ready to dive a bit deeper. The next section provides more context and additional things you can do to check for accessibility barriers.<br />
<br />
==A Deeper Look==<br />
<p>If you are interested in a more comprehensive look at the page(s), here more tests that require a little more time, skills, and/or tools.</p><br />
#Load your tool kit. (List tools that can be freely accessed and/or installed in browser, or link to [http://webaim.org/articles/freetools/ Complete list of Web Accessibility Evaluation Tools] and [http://webaim.org/articles/freetools/ Web AIM's Review of Free, Online Accessibility Tools])<br />
#Choose or create a reporting template (Introduce [http://www.w3.org/WAI/eval/template.html Evaluation Templates from WAI])<br />
#select a representative page sample (Introduce and link to [http://www.w3.org/WAI/eval/conformance.html WAI Conformance Evaluation Page]<br />
#Using your chosen template as a guide, examine the following features of the web page(s) you are evaluating: (Note to EO: Here is where we can describe testing procedures for each of these - and likely additional ones. Please suggest structure and additional content) <br />
===Text equivalents for non-text content===<br />
===Content structure and semantics=== <br />
===Use of color and contrast===<br />
===Form fields and labels=== <br />
===Keyboard navigation===<br />
===Significant hyperlinks===<br />
===Language identification===<br />
<br />
==More Thorough Evaluation==<br />
@@ point to Conformance Evaluation page and WCAG-EM.<br />
<html><head><br />
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"><br />
<meta content="Wayne Dick" name="author"><br />
<title>Checklist</title><br />
</head><br />
<body>&nbsp;<h1 id="smart">Smart analysis simplified <span class="view">(Basic web view)</span></h1><cite>Contributed by Tom Jewett</cite> <br><br />
<p class="first"><strong>This human-intelligence-based method</strong><br />
can quickly determine if the most important elements of a web page can<br />
be used by most persons with disabilities. This checklist is no<br />
substitute for training, but once trained designers and developers can<br />
use this as they move from task to task. Used throughout the design and<br />
development process, this quick check will help to avoid accessibility<br />
errors that require major changes to the website's design or<br />
implementation.<br><br />
</p><br />
<ol><br />
<li id="temp"><strong>Validation check:</strong> HTML and CSS code should comply with W3C standards. <br><br />
<ul><br />
<li>Always check with W3C HTML and CSS Validators <br><br />
</li><br />
<li>Check that the document language is declared</li><br />
</ul><br><br />
</li><br />
<li id="visual"><strong>Visual check:</strong> Do each of the following common sense tests.<br><br />
</li><br />
<ul><br />
<li id="visual">All text should be easily legible to fully-sighted readers. <br><br />
</li><br />
<li id="visual">When text-only enlargement is used in the<br />
browser, all text (except banner logos) should respond and nothing<br />
should overlap or be hidden. <br><br />
</li><br />
<li id="visual">Make sure nothing is flickering or flashing unless this activity is necessary for the meaning of the content.</li><br />
<li id="visual">Make sure the Title of the page (in the browser title bar) is descriptive of the content. <br><br />
</li><br />
<li id="visual">Check to see that there is a clear luminosity<br />
difference between the background and text in the foreground. Be sure to<br />
test special states like hover for contrast problems. An easy way to<br />
test contrast is to reduce the luminosity of the monitor by about 40%.<br />
Foreground and background should still be distinct. <br><br />
</li><br />
</ul><br />
<li id="dynamic"><strong>Dynamic Content:</strong> This category<br />
includes time based media, animations, and content management system<br />
content, and rich internet applications. You will only identify the most<br />
obvious barriers; most dynamic content will require specialized,<br />
detailed analysis to insure complete accessibility. <br><br />
<ul><br />
<li>Visually, confirm access to captions and transcripts (when appropriate) for all time based media; <br><br />
</li><br />
<li>Do all testing with keyboard only.</li><br />
<li>Identify any time dependent responses.</li><br />
<li>Give all animation a quick Visual Check. Embedded text<br />
should be readable, enlargement capability should be present and<br />
effective, flashing and blinking should be confined to necessary<br />
semantic role, and test all states. <br><br />
</li><br />
<li>Treat CMS generated data just like normal web content, but try to separate template issues from local instance issues. <br><br />
</li><br />
<li>Check for WAI ARIA role, state and property presence in all ARIA widgets.</li><br />
<li>Check for WAI ARIA landmarks in all widgets.</li><br />
<li>Test every rich internet application with keyboard only.</li><br />
</ul><br />
</li><br />
<li id="text"><strong>Parallel Content:</strong> Frequently a page will require an alternative page to support accessibility. This is OK when required but check: <br><br />
<ul><br />
<li>Is there an automatic mechanism to update both versions simultaneously? There should be.<br><br />
</li><br />
<li>Is the alternative as rich semantically. For example replacing structured HTML with plain text is not acceptable. <br><br />
</li><br />
</ul><br />
</li><br />
<li id="headings"><strong>Color:</strong> Make sure that<br />
information is not conveyed by color alone. Verify that color contrast<br />
does not substitute for luminosity contrast. <br><br />
</li><br />
<li id="headings"><strong>Headings:</strong> Headings should match<br />
the actual semantic structure of the document and should be properly<br />
nested by level. Headings should also be used to identify and navigate<br />
between groups of related links. Proper use of headings is now more<br />
accessible than adding "skip navigation" links. For ARIA widgets, use<br />
landmarks as you would use headings for text based content.<br><br />
</li><br />
<li><strong>Image maps:</strong> HTML still has a MAP element, but<br />
today image maps are also implemented with CSS, sprites, and live<br />
regions. All maps and map equivalents still need to provide alternative<br />
text equivalents and full keyboard access. All image map objects contain<br />
graphical regions with hot spots that contain links or controls. The<br />
same issues arise with all image map objects. So always check: <br><br />
<ul><br />
<li>&nbsp;Active graphical hot spots of an image map must have associated text alternatives to activate controls and links.</li><br />
<li>Keyboard traversal should be possible through the controls<br />
and links present in the map. This includes visual access for sighted<br />
users who want to tab through an image map visually.<br><br />
</li><br />
</ul><br />
</li><br />
<li id="links"><strong>Links:</strong> All links must have text;<br />
each link's text should describe its destination clearly; duplicate link<br />
text should not point to different destinations, but links that point<br />
to the same destination may have different text depending on context. If<br />
any link has "javascript" as the target, it is likely to be an<br />
accessibility barrier that will require additional evaluation. All links<br />
should be reachable and visible using only the Tab key. </li><br />
<li id="forms"><strong>Forms:</strong> Each form control must have<br />
an associated label that describes its purpose. Tab order between form<br />
controls must match the order in which a user would normally complete<br />
them. Complex forms benefit from grouping controls with the FIELDSET<br />
element. The form title is optional if the purpose of the form can be<br />
determined from context. "Placeholder" text inside text boxes is no<br />
longer needed for screen readers; it is redundant in a properly-labeled<br />
form. Many forms will also have to be evaluated separately for dynamic<br />
behavior such as error response. </li><br />
<li id="frames"><strong>Frames:</strong> Frames are deprecated and<br />
should never be used in new development. If your software maintenance<br />
cycle includes upgrading code that includes frames, it is time to remove<br />
them.</li><br />
<li id="frames"><strong>I</strong><strong>frames:</strong> This tool is necessary for multi server access. Content introduced through iframes should be tested like any content.<br><br />
</li><br />
<li id="images"><strong>Images:</strong> With images replaced by<br />
their text equivalents, no information or navigation should be lost to<br />
any visitor to the page. Purely decorative images should have null<br />
(empty) text equivalents. All images should have text alternatives,<br />
content or explicit null. </li><br />
<li id="styles"><strong>Styles and layout:</strong> View the page<br />
with all style off. The semantic structure of the page content should be<br />
readily understandable from the browser's default rendering (of<br />
headings, lists, and so on) and navigable by assistive technologies. No<br />
content should appear that was made visible by CSS solely with mouse<br />
action (hover) or otherwise hidden from sighted readers. With layout<br />
tables removed, the page should read in logical order from top to<br />
bottom; use of layout tables should be kept to an absolute minimum. </li><br />
<li id="tables"><strong>Data Tables:</strong> Layout tables (those<br />
with no heading elements) should never be used to contain truly tabular<br />
data, and should never have summary attributes. True data tables should<br />
have each data cell associated with its column (and row, if<br />
appropriate) header or headers. Complex tables should have each data<br />
cell associated with all applicable heading levels. </li><br />
</ol><br />
<br><br />
<br />
<br />
</body></html></div>Wdickhttps://www.w3.org/WAI/EO/wiki/index.php?title=WCAG-EM_review&diff=1666WCAG-EM review2012-09-28T14:45:08Z<p>Wdick: /* Comments for discussion */</p>
<hr />
<div>Nav: [[Main Page|EOWG wiki main page]]<br />
<br />
__TOC__<br />
Links:<br />
* [http://www.w3.org/TR/WCAG-EM/ WCAG-EM document]<br />
* [http://lists.w3.org/Archives/Public/w3c-wai-ig/2012JulSep/0414.html Call for Review e-mail 20 Sept]<br />
* [http://www.w3.org/WAI/ER/2011/eval/track/issues/open Open Issues]<br />
<br />
Reminder: EOWG will focus on the types of questions below. If you have comments on specific technical points in the document, you can submit them directly yourself -- that is, e-mail them to public-wai-evaltf@w3.org by 20 October.<br />
<br />
If you're not sure, feel free to put your comments here and the Group will decide if they are ones you should send yourself.<br />
<br />
==EOWG Comments specifically requested==<br />
The following questions have been asked by the WCAG-EM Working Group for consideration and comment from EOWG. Please consider these items and comment below.<br />
#Is it clear that this set of methodologies is only for websites after they are built and does not address methodologies that might be used prior to and during development? If not, please suggest ways to clarify the scope.<br />
#How should we communicate the importance of evaluating throughout website development, not just at the end?<br />
#How much should we refer to and link to existing material as reference and how much should we include directly in the new material? Balance the inconvenience of jumping back and forth between existing documents against our reluctance to unnecessarily duplicate information.<br />
#What specific revisions will make the document more readable and usable?<br />
#Are there any major considerations that we have overlooked or misrepresented?<br />
#How should we align the WCAG-EM work with the [http://www.w3.org/WAI/EO/wiki/Web_Accessibility_Preliminary_Evaluation Preliminary Evaluation document] now in process at EOWG?<br />
<br />
(Note: We plan to separately provide guidance for the developers of evaluation tools.)<br />
<br />
==Comments for discussion==<br />
* ...comment <span style="color: #808080;">{Wayne Dick}</span><br />
(minor) Relied Upon - Just hangs there without inclusion in the context of accessibility supported.<br />
<br />
(Med) The note to (Web Applications): It may not be feasible to exhaustively examine all possible settings, but sampling should apply just as any website.<br />
<br />
(Very Important) Methodology Requirement 1.d: This requirement appears to claim that the website owner and evaluator are free to<br />
choose which users may be excluded. Human rights do not work that way. What reasonable base technologies are required<br />
for conformance? This is particularly disturbing within the context of intranets where employers may choose to limit users to assistive technologies the employer can purchase cheaply. The note at the end is not sufficient.<br />
<br />
Example, many sites prescribe large print with high contrast to be a universal cure for low vision. This discounts the need for albinos to have lower luminosity. Without high luminosity, high contrast is not possible.<br />
<br />
* ...comment <span style="color: #808080;">{Wayne Dick}</span><br />
(important) 3.1.5 Step d, appeared to invite employer determined prescription of assistive techonolgy and accessibility support. The result will be employer defined necessary<br />
employment discrimination.<br />
<br />
* ...comment <span style="color: #808080;">{Wayne Dick}</span><br />
3.1.5 Step 3. The evaluation commissioner, must be informed that if the self defined sufficient techniques are used then a future accessibility audit may ask for a proof of<br />
sufficiency.<br />
<br />
* ...comment <span style="color: #808080;">{Wayne Dick}</span><br />
Throughout 3.1.5 PDF and Silver light are <br />
basic web technologies. They are no more <br />
technologie than docx or raw text. They <br />
as basic web technologies. The accessibility <br />
open question.<br />
<br />
This issue is particularly important if this document is going to be normative. I do specific reference to Adobe or Microsoft products as basic web technologies is serious vendor preference.<br />
<br />
* ...comment <span style="color: #808080;">{Vicki}</span><br />
3.3 Step 3: Select a Representative Sample<br />
(First sentence)<br />
"While ideally every web page of a web site is evaluated, usually this is not possible on most web sites."<br />
<br />
I think it is too strong to say "usually this is not possible". It may sound like we are contradicting what we are hoping to achieve. Suggested text:<br />
"While ideally every web page of a website should be evaluated, this may not be possible for very large websites."<br />
* ...comment <span style="color: #808080;">{Vicki}</span><br />
Responding to the term "with reasonable confidence": I have no problem with the term. Alternatively, if the above term is a point of discussion, you could simply modify the sentence to "that is representative of the entire target website".<br />
<br />
* ...comment <span style="color: #808080;">{Wayne Dick}</span><br />
3.3 Step 3: Select a Representative Sample <br />
website with many heterogeneous sub-<br />
university example, the sample selection <br />
include users. Focus groups are an effective <br />
probably necessary.<br />
<br />
Large heterogenous sites behave more like a set of independent sites placed under one URL. As such it is important to organize focus groups within the different autonomous site owners to determine usage patterns and prioritize pages for evaluation. When organizing the CSU System, 23 Campuses, each having more than 50 academic departments, and more administrative departments, we found that the IT unit could not get a handle on usage patterns on its own. Individual site owners had to give direct input on priority and usage. Example: At CSU Long Beach the Computer Science lab invokes the Computer Science Department Website every time a student logs into a lab machine. That makes the Computer Science Department the most referenced site on the Campus. But it is not the most important.<br />
<br />
* ...comment <span style="color: #808080;">{Vicki}</span><br />
2.5 Involving Users (Optional)<br />
Second last sentence.<br />
"While not required, it is strongly recommended to involve real people covering a wide range of abilities...."<br />
Suggest removing "real".<br />
<br />
* ...comment <span style="color: #808080;">{Vicki}</span><br />
3.1.4 Methodology Requirement 1.d: <br />
<br />
Third paragraph: second last sentence.<br />
"For example, ….., then the website is effectively not accessible for some users."<br />
Suggest adding something about conformance for emphasis e.g., "and therefore does not conform to the specified conformance level of WCAG 2.0. (3.1.3 Step 1.c.)"<br />
<br />
* ...comment <span style="color: #808080;">{Vicki}</span><br />
Feedback requested on the definition on "Common Functionality". <br />
<br />
Having read through the document, I don’t have a problem with the term "common functionality. However, it might pose a question mark to some. Therefore, I’ve put forth a few options below depending on what you mean and if you wish to be more specific:<br />
<br />
If it is the general functionality of the site, you could simply leave out the word "common" or use "basic functionality"<br />
<br />
If "common functionality" has a more technical connotation (referring to the style sheets, javascript, classes, i.e., the technical mandatory requirements for multiple device support and functionality), leave it as "common"<br />
<br />
Another suggestion in the line of "common" and "key" is “core”.<br />
<br />
Suggestion to modify the description (in line with the "Note"):<br />
Functionality of a website includes tasks that users of a website perform in order to achieve a goal.<br />
<br />
<br />
* ...comment <span style="color: #808080;">{Suzette - readability}</span><br />
Re point 4: readability and usability, plus section 1.1 scope and 1.2 audience. I think this is a difficult read for the intended audience. I have no problem with clarifying the scope that this is what educationalists call summative assessment (like the final exam!) rather that formative assessment (feedback you can learn from. To improve usability I would suggest there is a need for better tailored use cases that match 1.2 and are then addressed consistently. There seem to be some examples included about commerce but I think it needs to use a better defined range - that better capture the context of the audience be it large scale government sites, large commercial sites, banks and utilities, and big agencies through to smaller operators eg a local school, a local charity, small organic food retailer.<br />
<br />
==Comments that probably don't need discussion==<br />
* ...comment <span style="color: #808080;">{Vicki}</span><br />
3.1.2 Step 1.b.<br />
<br />
In-Depth Analyis.<br />
<br />
End of last sentence is missing a fullstop.<br />
<br />
* ...comment <span style="color: #808080;">{Vicki}</span><br />
3.2.3<br />
"Note: This step is intended to identify groups of web page instances, including in web applications."<br />
<br />
Suggest drop the "in" as in "including web applications" or add "including those in web applications".<br />
<br />
<br />
__NOINDEX__</div>Wdickhttps://www.w3.org/WAI/EO/wiki/index.php?title=WCAG-EM_review&diff=1659WCAG-EM review2012-09-28T13:20:58Z<p>Wdick: /* Comments for discussion */</p>
<hr />
<div>Nav: [[Main Page|EOWG wiki main page]]<br />
<br />
__TOC__<br />
Links:<br />
* [http://www.w3.org/TR/WCAG-EM/ WCAG-EM document]<br />
* [http://lists.w3.org/Archives/Public/w3c-wai-ig/2012JulSep/0414.html Call for Review e-mail 20 Sept]<br />
* [http://www.w3.org/WAI/ER/2011/eval/track/issues/open Open Issues]<br />
<br />
Reminder: EOWG will focus on the types of questions below. If you have comments on specific technical points in the document, you can submit them directly yourself -- that is, e-mail them to public-wai-evaltf@w3.org by 20 October.<br />
<br />
If you're not sure, feel free to put your comments here and the Group will decide if they are ones you should send yourself.<br />
<br />
==EOWG Comments specifically requested==<br />
The following questions have been asked by the WCAG-EM Working Group for consideration and comment from EOWG. Please consider these items and comment below.<br />
#Is it clear that this set of methodologies is only for websites after they are built and does not address methodologies that might be used prior to and during development? If not, please suggest ways to clarify the scope.<br />
#How should we communicate the importance of evaluating throughout website development, not just at the end?<br />
#How much should we refer to and link to existing material as reference and how much should we include directly in the new material? Balance the inconvenience of jumping back and forth between existing documents against our reluctance to unnecessarily duplicate information.<br />
#What specific revisions will make the document more readable and usable?<br />
#Are there any major considerations that we have overlooked or misrepresented?<br />
#How should we align the WCAG-EM work with the [http://www.w3.org/WAI/EO/wiki/Web_Accessibility_Preliminary_Evaluation Preliminary Evaluation document] now in process at EOWG?<br />
<br />
(Note: We plan to separately provide guidance for the developers of evaluation tools.)<br />
<br />
==Comments for discussion==<br />
* ...comment <span style="color: #808080;">{Wayne Dick}</span><br />
Relied Upon - Just hangs there without inclusion in the context of accessibility supported.<br />
<br />
The note to (Web Applications): It may not be feasible to exhaustively examine all possible settings, but sampling should apply just as any website.<br />
<br />
Methodology Requirement 1.d: This requirement appears to claim that the website owner and evaluator are free to<br />
choose which users may be excluded. Human rights do not work that way. What reasonable base technologies are required<br />
for conformance? This is particularly disturbing within the context of intranets where employers may choose to limit users to assistive technologies the employer can purchase cheaply. The note at the end is not sufficient.<br />
<br />
Example, many sites prescribe large print with high contrast to be a universal cure for low vision. This discounts the need for albinos to have lower luminosity. Without high luminosity, high contrast is not possible.<br />
<br />
* ...comment <span style="color: #808080;">{Wayne Dick}</span><br />
3.1.5 Step d, appeared to invite employer determined prescription of assistive techonolgy and accessibility support. The result will be employer defined necessary<br />
employment discrimination.<br />
<br />
* ...comment <span style="color: #808080;">{Wayne Dick}</span><br />
3.1.5 Step 3. The evaluation commissioner, must be informed that if the self defined sufficient techniques are used then a future accessibility audit may ask for a proof of<br />
sufficiency.<br />
<br />
* ...comment <span style="color: #808080;">{Wayne Dick}</span><br />
Throughout 3.1.5 PDF and Silver light are <br />
basic web technologies. They are no more <br />
technologie than docx or raw text. They <br />
as basic web technologies. The accessibility <br />
open question.<br />
<br />
This issue is particularly important if this document is going to be normative. I do specific reference to Adobe or Microsoft products as basic web technologies is serious vendor preference.<br />
<br />
* ...comment <span style="color: #808080;">{Vicki}</span><br />
3.3 Step 3: Select a Representative Sample<br />
(First sentence)<br />
"While ideally every web page of a web site is evaluated, usually this is not possible on most web sites."<br />
<br />
I think it is too strong to say "usually this is not possible". It may sound like we are contradicting what we are hoping to achieve. Suggested text:<br />
"While ideally every web page of a website should be evaluated, this may not be possible for very large websites."<br />
* ...comment <span style="color: #808080;">{Vicki}</span><br />
Responding to the term "with reasonable confidence": I have no problem with the term. Alternatively, if the above term is a point of discussion, you could simply modify the sentence to "that is representative of the entire target website".<br />
<br />
* ...comment <span style="color: #808080;">{Wayne Dick}</span><br />
3.3 Step 3: Select a Representative Sample <br />
website with many heterogeneous sub-<br />
university example, the sample selection <br />
include users. Focus groups are an effective <br />
probably necessary.<br />
<br />
* ...comment <span style="color: #808080;">{Vicki}</span><br />
2.5 Involving Users (Optional)<br />
Second last sentence.<br />
"While not required, it is strongly recommended to involve real people covering a wide range of abilities...."<br />
Suggest removing "real".<br />
<br />
* ...comment <span style="color: #808080;">{Vicki}</span><br />
3.1.4 Methodology Requirement 1.d: <br />
<br />
Third paragraph: second last sentence.<br />
"For example, ….., then the website is effectively not accessible for some users."<br />
Suggest adding something about conformance for emphasis e.g., "and therefore does not conform to the specified conformance level of WCAG 2.0. (3.1.3 Step 1.c.)"<br />
<br />
* ...comment <span style="color: #808080;">{Vicki}</span><br />
Feedback requested on the definition on "Common Functionality". <br />
<br />
Having read through the document, I don’t have a problem with the term "common functionality. However, it might pose a question mark to some. Therefore, I’ve put forth a few options below depending on what you mean and if you wish to be more specific:<br />
<br />
If it is the general functionality of the site, you could simply leave out the word "common" or use "basic functionality"<br />
<br />
If "common functionality" has a more technical connotation (referring to the style sheets, javascript, classes, i.e., the technical mandatory requirements for multiple device support and functionality), leave it as "common"<br />
<br />
Another suggestion in the line of "common" and "key" is “core”.<br />
<br />
Suggestion to modify the description (in line with the "Note"):<br />
Functionality of a website includes tasks that users of a website perform in order to achieve a goal.<br />
<br />
<br />
* ...comment <span style="color: #808080;">{Suzette - readability}</span><br />
Re point 4: readability and usability, plus section 1.1 scope and 1.2 audience. I think this is a difficult read for the intended audience. I have no problem with clarifying the scope that this is what educationalists call summative assessment (like the final exam!) rather that formative assessment (feedback you can learn from. To improve usability I would suggest there is a need for better tailored use cases that match 1.2 and are then addressed consistently. There seem to be some examples included about commerce but I think it needs to use a better defined range - that better capture the context of the audience be it large scale government sites, large commercial sites, banks and utilities, and big agencies through to smaller operators eg a local school, a local charity, small organic food retailer.<br />
<br />
==Comments that probably don't need discussion==<br />
* ...comment <span style="color: #808080;">{Vicki}</span><br />
3.1.2 Step 1.b.<br />
<br />
In-Depth Analyis.<br />
<br />
End of last sentence is missing a fullstop.<br />
<br />
* ...comment <span style="color: #808080;">{Vicki}</span><br />
3.2.3<br />
"Note: This step is intended to identify groups of web page instances, including in web applications."<br />
<br />
Suggest drop the "in" as in "including web applications" or add "including those in web applications".<br />
<br />
<br />
__NOINDEX__</div>Wdickhttps://www.w3.org/WAI/EO/wiki/index.php?title=WCAG-EM_review&diff=1646WCAG-EM review2012-09-28T01:13:58Z<p>Wdick: /* Comments for discussion */</p>
<hr />
<div>Nav: [[Main Page|EOWG wiki main page]]<br />
<br />
__TOC__<br />
Links:<br />
* [http://www.w3.org/TR/WCAG-EM/ WCAG-EM document]<br />
* [http://lists.w3.org/Archives/Public/w3c-wai-ig/2012JulSep/0414.html Call for Review e-mail 20 Sept]<br />
* [http://www.w3.org/WAI/ER/2011/eval/track/issues/open Open Issues]<br />
<br />
Reminder: EOWG will focus on the types of questions below. If you have comments on specific technical points in the document, you can submit them directly yourself -- that is, e-mail them to public-wai-evaltf@w3.org by 20 October.<br />
<br />
If you're not sure, feel free to put your comments here and the Group will decide if they are ones you should send yourself.<br />
<br />
==EOWG Comments specifically requested==<br />
The following questions have been asked by the WCAG-EM Working Group for consideration and comment from EOWG. Please consider these items and comment below.<br />
#Is it clear that this set of methodologies is only for websites after they are built and does not address methodologies that might be used prior to and during development? If not, please suggest ways to clarify the scope.<br />
#How should we communicate the importance of evaluating throughout website development, not just at the end?<br />
#How much should we refer to and link to existing material as reference and how much should we include directly in the new material? Balance the inconvenience of jumping back and forth between existing documents against our reluctance to unnecessarily duplicate information.<br />
#What specific revisions will make the document more readable and usable?<br />
#Are there any major considerations that we have overlooked or misrepresented?<br />
#How should we align the WCAG-EM work with the [http://www.w3.org/WAI/EO/wiki/Web_Accessibility_Preliminary_Evaluation Preliminary Evaluation document] now in process at EOWG?<br />
<br />
(Note: We plan to separately provide guidance for the developers of evaluation tools.)<br />
<br />
==Comments for discussion==<br />
* ...comment <span style="color: #808080;">{Wayne Dick}</span><br />
Relied Upon - Just hangs there without inclusion in the context of accessibility supported.<br />
<br />
The note to (Web Applications): It may not be feasible to exhaustively examine all possible settings, but sampling should apply just as any website.<br />
<br />
Methodology Requirement 1.d: This requirement appears to claim that the website owner and evaluator are free to<br />
choose which users may be excluded. Human rights do not work that way. What reasonable base technologies are required<br />
for conformance? This is particularly disturbing within the context of intranets where employers may choose to limit users to assistive technologies the employer can purchase cheaply. The note at the end is not sufficient.<br />
<br />
Example, many sites prescribe large print with high contrast to be a universal cure for low vision. This discounts the need for albinos to have lower luminosity. Without high luminosity, high contrast is not possible.<br />
<br />
3.1.5 Step d, appeared to invite employer determined prescription of assistive techonolgy and accessibility support. The result will be employer defined necessary<br />
employment discrimination.<br />
<br />
3.1.5 Step 3. The evaluation commissioner, must be informed that if the self defined sufficient techniques are used then a future accessibility audit may ask for a proof of<br />
sufficiency.<br />
<br />
Throughout 3.1.5 PDF and Silver light are <br />
basic web technologies. They are no more <br />
technologie than docx or raw text. They <br />
as basic web technologies. The accessibility <br />
open question.<br />
<br />
3.3 Step 3: Select a Representative Sample <br />
website with many heterogeneous sub-<br />
university example, the sample selection <br />
include users. Focus groups are an effective <br />
probably necessary.<br />
<br />
==Comments that probably don't need discussion==<br />
* ...comment <span style="color: #808080;">{name}</span><br />
<br />
<br />
__NOINDEX__</div>Wdickhttps://www.w3.org/WAI/EO/wiki/index.php?title=Promoting_Accessibility_in_Courses&diff=1394Promoting Accessibility in Courses2012-08-22T18:37:20Z<p>Wdick: /* Audience */</p>
<hr />
<div>Nav: [[Main Page|EOWG wiki main page]]<br />
<br />
== Resources & Pointers ==<br />
<br />
* Main document: [http://www.w3.org/WAI/training/ Developing Web Accessibility Presentations and Training]<br />
* Old draft: [http://www.w3.org/WAI/EO/Drafts/promos/courses.php Integrating Web Accessibility in Courses] <br />
* Related Materials: [http://www.w3.org/WAI/EO/Drafts/training/ Training Resource Suite]; [http://www.w3.org/community/webed/wiki/Main_Page#Accessibility Accessibility Modules on Web Education Community Group]<br />
<br />
== Audience & Messages ==<br />
=== Audience ===<br />
<p>We have identified <strike> two </strike> three main audience types. First is the general public which includes providers of informal meet-ups and continuing education of the kind that occurs at conferences and "unconferences." The second is the academic community. Messaging will overlap, but in some instances will be specific to one group or the other.</p><br />
* General Audience - may need foundational messaging about accessibility issues as well as specifics about the materials available. May not know much about how PWD use the web or the need for accessibility. <br />
* Professional Audience - May have strong understanding of one or two aspects of web accessibility, but requires focused training to meet the accessibility requirements of their job. This group includes advocates, managers, developers, graphic artists etc. Focus is on missing knowledge: accessibility techniques for web developers, technology issues for disability advocates, social responsibility and requirement issues for managers. <br />
* Academic Audience - should be more aware of need for educational inclusion. Messaging may be more focused on industry trends, skills development, creating technical graduates who are ready to meet requirements of the information technology industry.<br />
<br />
=== Messages ===<br />
<p>An important aspect of high quality Web courses is making the Web accessible to people with disabilities. [or: An important aspect of high quality Web courses is including instruction on developing Web sites that are accessible to people with disabilities.] ''This principle applies whether the audience consists of web developers, graphic designers, managers, advocates or college students.''</p><br />
<br />
<p> ''The Suite provides several presentation outlines that enable the presenter to address a variety of skill levels, interests and time constraints.''</p><br />
<br />
== Tweet ideas you can use==<br />
...<br />
<br />
== Blog, newsletter, e-mail ideas you can use ==<br />
Subject/Headline: '''W3C WAI materials to help you update your web course for accessibility'''<br />
<br />
@@ students get current info, zingy @@<br /><br />
An important aspect of high quality Web courses is making the Web accessible to people with disabilities. [<em>or:</em> An important aspect of high quality Web courses is including instruction on developing Web sites that are accessible to people with disabilities.] To help you integrate accessibility in your Web courses, W3C WAI provides materials that you can use for lecture, activities, and student study.<br />
See Developing Web Accessibility Presentations and Training at http://www.w3.org/WAI/training/<br />
<br />
@@ It's like open source courseware @@<br />
<br />
'''Web accessibility is an important social, technical, and business issue.<br />
'''<br />
<p>Web accessibility means that people with disabilities can perceive, understand, navigate, and interact with the Web, and that they can contribute to the Web. Currently most Web sites and Web software have accessibility barriers that make it difficult or impossible for many people with disabilities to use the Web. Teaching Web designers, developers, and authors accessibility is a key factor in making Web sites and software accessible, so that people with disabilities can use and contribute to the Web more effectively.</p><br />
<p>@@consider integrating shorter in first bit @@<br /> Web courses that are up-to-date with the latest trends in the industry include accessibility. Accessibility is being requested more and more in Web site development, as people realize the many benefits of making the Web accessible&mdash;for people with and without disabilities, and for Web site owners&mdash;and as legal requirements increase. Social, technical, financial, and legal factors of Web accessibility are described in the Web Accessibility Business Case at: http://www.w3.org/WAI/bcase/Overview.html</p><br />
<br />
'''W3C WAI provides material to support Web accessibility.'''<br />
...<br />
<br />
'''You can use WAI material for your Web accessibility instruction.'''<br />
<br />
<p>To help you incorporate accessibility in your upcoming Web design and development courses, we put together a resource suite @@<br />
<p>* @@use it - make your students happy</p><br />
<p> We hope that you will @@bookmark &quot;@@training resource suite&quot; and come back to it as you prepare Web course syllabus and materials.</p><br />
<p>Thank you for your attention to Web accessibility.</p><br />
<br />
<br />
@@'' College Instructors of Web Technologies, User Interface Design or Human Factors''@@<br />
<p>Do you want to integrate accessibility for people with disabilities into your core curriculum, but are not sure where to start? Consider using, [http://www.w3.org/WAI/training/ Developing Web Accessibility Presentations and Training], a W3C publications. This resource provides several detailed presentation outlines. These can be used for a variety of audiences, skill levels and time constraints. </p><br />
<p>The outline, [http://www.w3.org/WAI/training/presentation-outlines#design Web Accessibility Design], is an excellent one-week introduction to accessibility for students in computer science, information technology or human factors psychology. It can be presented in two lecture hours with an optional 2 to 3 hour lab. This resource comes with several suggested readings for the instructor's preparation. Many of these are excellent reading assignments for students. Web standards originate at the W3C, so many of the referenced documents are primary source materials.</p><br />
<br />
== Conference Presentation Possibilities==<br />
[http://www.w3.org/WAI/EO/wiki/Contacts_for_promotion Overall Contacts for Promotion]<br />
* [http://www.colorado.edu/ATconference/ Accessing Higher Ground] in November in Colorado. Any more room? See if anyone we know has had a paper accepted who could mention the training suite. Howard Kramer and Glenda S. may have ideas. See [http://www.colorado.edu/ATconference/about2012.html#contactus Accessing Higher Ground - Accessible Media, Web and Technology ConferenceContact page] -- November 12 - 16, 2012 (Note that Derek is keynoting; perhaps he might mention the training suite) (JS)<br />
* Maybe a [http://www.csun.edu/cod/conference/index.php CSUN] presentation for 2013<br />
* AccessU for 2013 could do a "train the trainers" track and use the training suite (SR)<br />
* South by Southwest (SR)<br />
* South by Southwest Edu open for papers until the end of this year, helping K -- 12 teachers too, focuses on those who are making curriculum products (SR)<br />
* [http://www.ozewai.org/ OZeWAI conference] - annually in December<br />
* Meetups and unconferences for short workshops -- especially start with these two, at the general level (JS):<br />
** [http://www.a11ycamp.org/ a11y Camp] <br />
** [http://www.accessibilitycamp.org/ Accessibility Camp]<br />
<br />
== EOWG planning & record keeping ==<br />
<br />
=== Old and related material ===<br />
* Old material:<br />
** [http://www.w3.org/WAI/EO/Drafts/promos/courses.php Integrating Web Accessibility in Courses]<br />
** [http://www.w3.org/WAI/EO/changelogs/cl-promo-courses.html Requirements and Changelog for Promotional Campaign to Web Development Course Instructors]<br />
* '''Non-W3C''' related info:<br />
** [http://uiaccess.com/teachDI.html Teach Digital Inclusion] presentation (with draft video) encouraging instructors to teach digital inclusion in their ICT courses<br />
<br />
<br />
=== 2012 blogs, newsletters, references, etc. ===<br />
...<br />
<br />
=== Mailing lists ===<br />
* Access Technology Higher Education Network [http://mailman1.u.washington.edu/mailman/listinfo/athen-list ATHEN email list]<br />
* Association on Higher Education and Disability [http://www.ahead.org/membership/mailing-list-policy | AHEAD email list]<br />
* US Federal Government Webmaster lists [http://www.howto.gov/communities How-To.Gov Communities]<br />
* WAI-Engage Community Group [mailto:public-wai-engage@w3.org WAI-Engage Group List]<br />
* Leadership Exchange in Arts and Disability [mailto:culturalartsaccess@yahoogroups.com LEAD mailing list]<br />
<br />
<br />
=== Tweets ===<br />
...<br />
<br />
=== 2012 EOWG Recent Contacts ===<br />
<br />
==== Done: ====<br />
...<br />
<br />
==== To Do: ====<br />
<p>Outcome of brainstorming of Outreach Subcommittee Meeting Aug 15, 2012 plus additions. Note that many of these ideas are U.S.-centric and we will ask EO for more global perspective</p><br />
<br />
* Finalize outreach plan and present to EO by Aug 24, 2012 (JS, WD, SR)<br />
* Glenda Sims -- any associations? Suggestions of newsletters or conferences? (SR)<br />
* [http://www.webteacher.ws/ Web Teacher -- Virginia DeBolt] (SR)<br />
* [http://www.mediaaccess.org.au/learn 6-week course on building websites with WCAG 2.0 compliance] Professional Certificate in Web Accessibility from Media Access Australia. <br />
* Terry Thompson<br />
* Sarah Bourne in MA for government curricula connections<br />
* CA system -- both UC and state (WD)<br />
* Ideas about TX systems? (SR)<br />
* Maybe set up an online one-hour seminar to go over how to use this training suite? Volunteer(s) to teach? How to arrange payments and assure platform accessibility?<br />
* Post announcement to both the ATHEN and AHEAD email Lists (JS)<br />
* Craft email message for the WAI-Engage email list encouraging discussion of the training suite on the [http://www.w3.org/community/wai-engage/ WAI-Engage Wiki]. Capture tips and tricks for conducting effective training sessions using the suite. (SR with help from EO)<br />
* Getting materials adopted into an official curriculum -- Wayne can offer guidance about that; what they did at Long Beach, integrated into learning materials and modules<br />
* Develop a press release draft related to Longbeach and saying: "Here is what they did at Long Beach, if you want to do the same, use these resources." (SR)<br />
* [http://www.rit.edu/%7Eeasi/index.htm Norm Coombs and EASI]<br />
* John Gunderson at U. of IL<br />
<br />
===== Additional Ideas extracted/Copied from EO WG Promotion Wiki Pages =====<br />
<br />
* WSG Announcements (If you have an event, resource or relevant job you'd like posted (from any country), please let me know - russ at maxdesign.com.au)<br />
[http://www.maxdesign.com.au/category/light-reading/ Links for light reading] Max Design / Russ Weakley - distributed through [http://webstandardsgroup.org/ Web Standards Group]<br />
* [http://www.webstandards.org/ Web Standards Project (WasP)]<br />
* [http://www.d.umn.edu/itss/training/online/webdesign/ Web Design References, UMD] - Laura Carlson. [http://www.d.umn.edu/itss/training/online/webdesign/urlform.html<br />
form to Suggest a Link]<br />
* WritersUA monthly user assistance update resource_directory@writersua.com contact: Joe W.<br />
* LinkedIn Groups - Jennison A.<br />
* [http://webaim.org/discussion/ The WebAIM Email Discussion List]<br />
* [http://webaim.org/newsletter/ The WebAIM Newsletter] (Jared Smith) <br />
* [http://blog.knowbility.org/ Knowbility Blog, Universally Designed] - posters: Sharron, Wayne<br />
* [http://accessibilityindia.wordpress.com/ Accessibility India Maxability blog] accessibilityindia @ gmail.com<br />
* [http://www.nomensa.com/blog/ Nomensa's Humanizing Technology Blog] - Léonie W (has contact info: Jennifer, Shawn)<br />
* [http://www.paciellogroup.com/blog/ The Paciello Group Blog]<br />
* [http://www.highedweb.org/<br />
Higher Education Web Professionals Association (HighEdWeb)]<br />
* [http://www.iwanet.org/ International Webmasters Association/HTML Writers Guild (IWA/HWG) Is this still active enough?<br />
* [http://www.wdda.org/ Web Design and Developers Association]<br />
* [http://wipa.org.au/ Web Industry Professionals Association Incorporated (WIPA) of Australia]<br />
* [http://webprofessionals.org/ World Organization of Webmasters (WOW)] <br />
* [http://www.wait-till-i.com Chris Heilmann's site]<br />
<br />
__NOINDEX__</div>Wdickhttps://www.w3.org/WAI/EO/wiki/index.php?title=Promoting_Accessibility_in_Courses&diff=1393Promoting Accessibility in Courses2012-08-22T18:36:46Z<p>Wdick: /* Audience */</p>
<hr />
<div>Nav: [[Main Page|EOWG wiki main page]]<br />
<br />
== Resources & Pointers ==<br />
<br />
* Main document: [http://www.w3.org/WAI/training/ Developing Web Accessibility Presentations and Training]<br />
* Old draft: [http://www.w3.org/WAI/EO/Drafts/promos/courses.php Integrating Web Accessibility in Courses] <br />
* Related Materials: [http://www.w3.org/WAI/EO/Drafts/training/ Training Resource Suite]; [http://www.w3.org/community/webed/wiki/Main_Page#Accessibility Accessibility Modules on Web Education Community Group]<br />
<br />
== Audience & Messages ==<br />
=== Audience ===<br />
<p>We have identified <strike> two </strike> main three audience types. First is the general public which includes providers of informal meet-ups and continuing education of the kind that occurs at conferences and "unconferences." The second is the academic community. Messaging will overlap, but in some instances will be specific to one group or the other.</p><br />
* General Audience - may need foundational messaging about accessibility issues as well as specifics about the materials available. May not know much about how PWD use the web or the need for accessibility. <br />
* Professional Audience - May have strong understanding of one or two aspects of web accessibility, but requires focused training to meet the accessibility requirements of their job. This group includes advocates, managers, developers, graphic artists etc. Focus is on missing knowledge: accessibility techniques for web developers, technology issues for disability advocates, social responsibility and requirement issues for managers. <br />
* Academic Audience - should be more aware of need for educational inclusion. Messaging may be more focused on industry trends, skills development, creating technical graduates who are ready to meet requirements of the information technology industry.<br />
<br />
=== Messages ===<br />
<p>An important aspect of high quality Web courses is making the Web accessible to people with disabilities. [or: An important aspect of high quality Web courses is including instruction on developing Web sites that are accessible to people with disabilities.] ''This principle applies whether the audience consists of web developers, graphic designers, managers, advocates or college students.''</p><br />
<br />
<p> ''The Suite provides several presentation outlines that enable the presenter to address a variety of skill levels, interests and time constraints.''</p><br />
<br />
== Tweet ideas you can use==<br />
...<br />
<br />
== Blog, newsletter, e-mail ideas you can use ==<br />
Subject/Headline: '''W3C WAI materials to help you update your web course for accessibility'''<br />
<br />
@@ students get current info, zingy @@<br /><br />
An important aspect of high quality Web courses is making the Web accessible to people with disabilities. [<em>or:</em> An important aspect of high quality Web courses is including instruction on developing Web sites that are accessible to people with disabilities.] To help you integrate accessibility in your Web courses, W3C WAI provides materials that you can use for lecture, activities, and student study.<br />
See Developing Web Accessibility Presentations and Training at http://www.w3.org/WAI/training/<br />
<br />
@@ It's like open source courseware @@<br />
<br />
'''Web accessibility is an important social, technical, and business issue.<br />
'''<br />
<p>Web accessibility means that people with disabilities can perceive, understand, navigate, and interact with the Web, and that they can contribute to the Web. Currently most Web sites and Web software have accessibility barriers that make it difficult or impossible for many people with disabilities to use the Web. Teaching Web designers, developers, and authors accessibility is a key factor in making Web sites and software accessible, so that people with disabilities can use and contribute to the Web more effectively.</p><br />
<p>@@consider integrating shorter in first bit @@<br /> Web courses that are up-to-date with the latest trends in the industry include accessibility. Accessibility is being requested more and more in Web site development, as people realize the many benefits of making the Web accessible&mdash;for people with and without disabilities, and for Web site owners&mdash;and as legal requirements increase. Social, technical, financial, and legal factors of Web accessibility are described in the Web Accessibility Business Case at: http://www.w3.org/WAI/bcase/Overview.html</p><br />
<br />
'''W3C WAI provides material to support Web accessibility.'''<br />
...<br />
<br />
'''You can use WAI material for your Web accessibility instruction.'''<br />
<br />
<p>To help you incorporate accessibility in your upcoming Web design and development courses, we put together a resource suite @@<br />
<p>* @@use it - make your students happy</p><br />
<p> We hope that you will @@bookmark &quot;@@training resource suite&quot; and come back to it as you prepare Web course syllabus and materials.</p><br />
<p>Thank you for your attention to Web accessibility.</p><br />
<br />
<br />
@@'' College Instructors of Web Technologies, User Interface Design or Human Factors''@@<br />
<p>Do you want to integrate accessibility for people with disabilities into your core curriculum, but are not sure where to start? Consider using, [http://www.w3.org/WAI/training/ Developing Web Accessibility Presentations and Training], a W3C publications. This resource provides several detailed presentation outlines. These can be used for a variety of audiences, skill levels and time constraints. </p><br />
<p>The outline, [http://www.w3.org/WAI/training/presentation-outlines#design Web Accessibility Design], is an excellent one-week introduction to accessibility for students in computer science, information technology or human factors psychology. It can be presented in two lecture hours with an optional 2 to 3 hour lab. This resource comes with several suggested readings for the instructor's preparation. Many of these are excellent reading assignments for students. Web standards originate at the W3C, so many of the referenced documents are primary source materials.</p><br />
<br />
== Conference Presentation Possibilities==<br />
[http://www.w3.org/WAI/EO/wiki/Contacts_for_promotion Overall Contacts for Promotion]<br />
* [http://www.colorado.edu/ATconference/ Accessing Higher Ground] in November in Colorado. Any more room? See if anyone we know has had a paper accepted who could mention the training suite. Howard Kramer and Glenda S. may have ideas. See [http://www.colorado.edu/ATconference/about2012.html#contactus Accessing Higher Ground - Accessible Media, Web and Technology ConferenceContact page] -- November 12 - 16, 2012 (Note that Derek is keynoting; perhaps he might mention the training suite) (JS)<br />
* Maybe a [http://www.csun.edu/cod/conference/index.php CSUN] presentation for 2013<br />
* AccessU for 2013 could do a "train the trainers" track and use the training suite (SR)<br />
* South by Southwest (SR)<br />
* South by Southwest Edu open for papers until the end of this year, helping K -- 12 teachers too, focuses on those who are making curriculum products (SR)<br />
* [http://www.ozewai.org/ OZeWAI conference] - annually in December<br />
* Meetups and unconferences for short workshops -- especially start with these two, at the general level (JS):<br />
** [http://www.a11ycamp.org/ a11y Camp] <br />
** [http://www.accessibilitycamp.org/ Accessibility Camp]<br />
<br />
== EOWG planning & record keeping ==<br />
<br />
=== Old and related material ===<br />
* Old material:<br />
** [http://www.w3.org/WAI/EO/Drafts/promos/courses.php Integrating Web Accessibility in Courses]<br />
** [http://www.w3.org/WAI/EO/changelogs/cl-promo-courses.html Requirements and Changelog for Promotional Campaign to Web Development Course Instructors]<br />
* '''Non-W3C''' related info:<br />
** [http://uiaccess.com/teachDI.html Teach Digital Inclusion] presentation (with draft video) encouraging instructors to teach digital inclusion in their ICT courses<br />
<br />
<br />
=== 2012 blogs, newsletters, references, etc. ===<br />
...<br />
<br />
=== Mailing lists ===<br />
* Access Technology Higher Education Network [http://mailman1.u.washington.edu/mailman/listinfo/athen-list ATHEN email list]<br />
* Association on Higher Education and Disability [http://www.ahead.org/membership/mailing-list-policy | AHEAD email list]<br />
* US Federal Government Webmaster lists [http://www.howto.gov/communities How-To.Gov Communities]<br />
* WAI-Engage Community Group [mailto:public-wai-engage@w3.org WAI-Engage Group List]<br />
* Leadership Exchange in Arts and Disability [mailto:culturalartsaccess@yahoogroups.com LEAD mailing list]<br />
<br />
<br />
=== Tweets ===<br />
...<br />
<br />
=== 2012 EOWG Recent Contacts ===<br />
<br />
==== Done: ====<br />
...<br />
<br />
==== To Do: ====<br />
<p>Outcome of brainstorming of Outreach Subcommittee Meeting Aug 15, 2012 plus additions. Note that many of these ideas are U.S.-centric and we will ask EO for more global perspective</p><br />
<br />
* Finalize outreach plan and present to EO by Aug 24, 2012 (JS, WD, SR)<br />
* Glenda Sims -- any associations? Suggestions of newsletters or conferences? (SR)<br />
* [http://www.webteacher.ws/ Web Teacher -- Virginia DeBolt] (SR)<br />
* [http://www.mediaaccess.org.au/learn 6-week course on building websites with WCAG 2.0 compliance] Professional Certificate in Web Accessibility from Media Access Australia. <br />
* Terry Thompson<br />
* Sarah Bourne in MA for government curricula connections<br />
* CA system -- both UC and state (WD)<br />
* Ideas about TX systems? (SR)<br />
* Maybe set up an online one-hour seminar to go over how to use this training suite? Volunteer(s) to teach? How to arrange payments and assure platform accessibility?<br />
* Post announcement to both the ATHEN and AHEAD email Lists (JS)<br />
* Craft email message for the WAI-Engage email list encouraging discussion of the training suite on the [http://www.w3.org/community/wai-engage/ WAI-Engage Wiki]. Capture tips and tricks for conducting effective training sessions using the suite. (SR with help from EO)<br />
* Getting materials adopted into an official curriculum -- Wayne can offer guidance about that; what they did at Long Beach, integrated into learning materials and modules<br />
* Develop a press release draft related to Longbeach and saying: "Here is what they did at Long Beach, if you want to do the same, use these resources." (SR)<br />
* [http://www.rit.edu/%7Eeasi/index.htm Norm Coombs and EASI]<br />
* John Gunderson at U. of IL<br />
<br />
===== Additional Ideas extracted/Copied from EO WG Promotion Wiki Pages =====<br />
<br />
* WSG Announcements (If you have an event, resource or relevant job you'd like posted (from any country), please let me know - russ at maxdesign.com.au)<br />
[http://www.maxdesign.com.au/category/light-reading/ Links for light reading] Max Design / Russ Weakley - distributed through [http://webstandardsgroup.org/ Web Standards Group]<br />
* [http://www.webstandards.org/ Web Standards Project (WasP)]<br />
* [http://www.d.umn.edu/itss/training/online/webdesign/ Web Design References, UMD] - Laura Carlson. [http://www.d.umn.edu/itss/training/online/webdesign/urlform.html<br />
form to Suggest a Link]<br />
* WritersUA monthly user assistance update resource_directory@writersua.com contact: Joe W.<br />
* LinkedIn Groups - Jennison A.<br />
* [http://webaim.org/discussion/ The WebAIM Email Discussion List]<br />
* [http://webaim.org/newsletter/ The WebAIM Newsletter] (Jared Smith) <br />
* [http://blog.knowbility.org/ Knowbility Blog, Universally Designed] - posters: Sharron, Wayne<br />
* [http://accessibilityindia.wordpress.com/ Accessibility India Maxability blog] accessibilityindia @ gmail.com<br />
* [http://www.nomensa.com/blog/ Nomensa's Humanizing Technology Blog] - Léonie W (has contact info: Jennifer, Shawn)<br />
* [http://www.paciellogroup.com/blog/ The Paciello Group Blog]<br />
* [http://www.highedweb.org/<br />
Higher Education Web Professionals Association (HighEdWeb)]<br />
* [http://www.iwanet.org/ International Webmasters Association/HTML Writers Guild (IWA/HWG) Is this still active enough?<br />
* [http://www.wdda.org/ Web Design and Developers Association]<br />
* [http://wipa.org.au/ Web Industry Professionals Association Incorporated (WIPA) of Australia]<br />
* [http://webprofessionals.org/ World Organization of Webmasters (WOW)] <br />
* [http://www.wait-till-i.com Chris Heilmann's site]<br />
<br />
__NOINDEX__</div>Wdickhttps://www.w3.org/WAI/EO/wiki/index.php?title=Promoting_Accessibility_in_Courses&diff=1330Promoting Accessibility in Courses2012-08-15T22:45:55Z<p>Wdick: /* Blog, newsletter, e-mail ideas you can use */</p>
<hr />
<div>Nav: [[Main Page|EOWG wiki main page]]<br />
<br />
== Resources & Pointers ==<br />
<br />
* Main document: [http://www.w3.org/WAI/training/ Developing Web Accessibility Presentations and Training]<br />
* Old draft: [http://www.w3.org/WAI/EO/Drafts/promos/courses.php Integrating Web Accessibility in Courses]<br />
<br />
== Audience & Messages ==<br />
...<br />
<br />
<br />
<p>An important aspect of high quality Web courses is making the Web accessible to people with disabilities. [or: An important aspect of high quality Web courses is including instruction on developing Web sites that are accessible to people with disabilities.] ''This principle applies whether the audience consists of web developers, graphic designers, managers, advocates or college students.''</p><br />
<br />
<p> ''The Suite provides several presentation outlines that enable the presenter to address a variety of skill levels, interests and time constraints.''</p><br />
<br />
<br />
<br />
== Tweet ideas you can use==<br />
...<br />
<br />
== Blog, newsletter, e-mail ideas you can use ==<br />
Subject/Headline: '''W3C WAI materials to help you update your web course for accessibility'''<br />
<br />
@@ students get current info, zingy @@<br /><br />
An important aspect of high quality Web courses is making the Web accessible to people with disabilities. [<em>or:</em> An important aspect of high quality Web courses is including instruction on developing Web sites that are accessible to people with disabilities.] To help you integrate accessibility in your Web courses, W3C WAI provides materials that you can use for lecture, activities, and student study.<br />
See Developing Web Accessibility Presentations and Training at http://www.w3.org/WAI/training/<br />
<br />
@@ It's like open source courseware @@<br />
<br />
'''Web accessibility is an important social, technical, and business issue.<br />
'''<br />
<p>Web accessibility means that people with disabilities can perceive, understand, navigate, and interact with the Web, and that they can contribute to the Web. Currently most Web sites and Web software have accessibility barriers that make it difficult or impossible for many people with disabilities to use the Web. Teaching Web designers, developers, and authors accessibility is a key factor in making Web sites and software accessible, so that people with disabilities can use and contribute to the Web more effectively.</p><br />
<p>@@consider integrating shorter in first bit @@<br /> Web courses that are up-to-date with the latest trends in the industry include accessibility. Accessibility is being requested more and more in Web site development, as people realize the many benefits of making the Web accessible&mdash;for people with and without disabilities, and for Web site owners&mdash;and as legal requirements increase. Social, technical, financial, and legal factors of Web accessibility are described in the Web Accessibility Business Case at: http://www.w3.org/WAI/bcase/Overview.html</p><br />
<br />
'''W3C WAI provides material to support Web accessibility.'''<br />
...<br />
<br />
'''You can use WAI material for your Web accessibility instruction.'''<br />
<br />
<p>To help you incorporate accessibility in your upcoming Web design and development courses, we put together a resource suite @@<br />
<p>* @@use it - make your students happy</p><br />
<p> We hope that you will @@bookmark &quot;@@training resource suite&quot; and come back to it as you prepare Web course syllabus and materials.</p><br />
<p>Thank you for your attention to Web accessibility.</p><br />
<br />
<br />
@@'' College Instructors of Web Technologies, User Interface Design or Human Factors''@@<br />
<p>Do you want to integrate accessibility for people with disabilities into your core curriculum, but are not sure where to start? Consider using, [http://www.w3.org/WAI/training/ Developing Web Accessibility Presentations and Training], a W3C publications. This resource provides several detailed presentation outlines. These can be used for a variety of audiences, skill levels and time constraints. </p><br />
<p>The outline, [http://www.w3.org/WAI/training/presentation-outlines#design http://www.w3.org/WAI/training/presentation-outlines#design Web Accessibility Design], is an excellent one-week introduction to accessibility for students in computer science, information technology or human factors psychology. It can be presented in two lecture hours with an optional 2 to 3 hour lab. This resource comes with several suggested readings for the instructor's preparation. Many of these are excellent reading assignments for students. Web standards originate at the W3C, so many of the referenced documents are primary source materials.</p><br />
<br />
== EOWG planning & record keeping ==<br />
<br />
=== Old and related material ===<br />
* Old material:<br />
** [http://www.w3.org/WAI/EO/Drafts/promos/courses.php Integrating Web Accessibility in Courses]<br />
** [http://www.w3.org/WAI/EO/changelogs/cl-promo-courses.html Requirements and Changelog for Promotional Campaign to Web Development Course Instructors]<br />
* '''Non-W3C''' related info:<br />
** [http://uiaccess.com/teachDI.html Teach Digital Inclusion] presentation (with draft video) encouraging instructors to teach digital inclusion in their ICT courses<br />
<br />
<br />
=== 2012 blogs, newsletters, references, etc. ===<br />
...<br />
<br />
=== Mailing lists ===<br />
...<br />
<br />
=== Tweets ===<br />
...<br />
<br />
=== 2012 EOWG Recent Contacts ===<br />
<br />
==== Done: ====<br />
...<br />
<br />
==== To Do: ====<br />
...<br />
<br />
__NOINDEX__</div>Wdickhttps://www.w3.org/WAI/EO/wiki/index.php?title=Promoting_Accessibility_in_Courses&diff=1329Promoting Accessibility in Courses2012-08-15T22:44:37Z<p>Wdick: </p>
<hr />
<div>Nav: [[Main Page|EOWG wiki main page]]<br />
<br />
== Resources & Pointers ==<br />
<br />
* Main document: [http://www.w3.org/WAI/training/ Developing Web Accessibility Presentations and Training]<br />
* Old draft: [http://www.w3.org/WAI/EO/Drafts/promos/courses.php Integrating Web Accessibility in Courses]<br />
<br />
== Audience & Messages ==<br />
...<br />
<br />
<br />
<p>An important aspect of high quality Web courses is making the Web accessible to people with disabilities. [or: An important aspect of high quality Web courses is including instruction on developing Web sites that are accessible to people with disabilities.] ''This principle applies whether the audience consists of web developers, graphic designers, managers, advocates or college students.''</p><br />
<br />
<p> ''The Suite provides several presentation outlines that enable the presenter to address a variety of skill levels, interests and time constraints.''</p><br />
<br />
<br />
<br />
== Tweet ideas you can use==<br />
...<br />
<br />
== Blog, newsletter, e-mail ideas you can use ==<br />
Subject/Headline: '''W3C WAI materials to help you update your web course for accessibility'''<br />
<br />
@@ students get current info, zingy @@<br /><br />
An important aspect of high quality Web courses is making the Web accessible to people with disabilities. [<em>or:</em> An important aspect of high quality Web courses is including instruction on developing Web sites that are accessible to people with disabilities.] To help you integrate accessibility in your Web courses, W3C WAI provides materials that you can use for lecture, activities, and student study.<br />
See Developing Web Accessibility Presentations and Training at http://www.w3.org/WAI/training/<br />
<br />
@@ It's like open source courseware @@<br />
<br />
'''Web accessibility is an important social, technical, and business issue.<br />
'''<br />
<p>Web accessibility means that people with disabilities can perceive, understand, navigate, and interact with the Web, and that they can contribute to the Web. Currently most Web sites and Web software have accessibility barriers that make it difficult or impossible for many people with disabilities to use the Web. Teaching Web designers, developers, and authors accessibility is a key factor in making Web sites and software accessible, so that people with disabilities can use and contribute to the Web more effectively.</p><br />
<p>@@consider integrating shorter in first bit @@<br /> Web courses that are up-to-date with the latest trends in the industry include accessibility. Accessibility is being requested more and more in Web site development, as people realize the many benefits of making the Web accessible&mdash;for people with and without disabilities, and for Web site owners&mdash;and as legal requirements increase. Social, technical, financial, and legal factors of Web accessibility are described in the Web Accessibility Business Case at: http://www.w3.org/WAI/bcase/Overview.html</p><br />
<br />
'''W3C WAI provides material to support Web accessibility.'''<br />
...<br />
<br />
'''You can use WAI material for your Web accessibility instruction.'''<br />
<br />
<p>To help you incorporate accessibility in your upcoming Web design and development courses, we put together a resource suite @@<br />
<p>* @@use it - make your students happy</p><br />
<p> We hope that you will @@bookmark &quot;@@training resource suite&quot; and come back to it as you prepare Web course syllabus and materials.</p><br />
<p>Thank you for your attention to Web accessibility.</p><br />
<br />
<br />
'' College Instructors of Web Technologies, User Interface Design or Human Factors''<br />
<p>Do you want to integrate accessibility for people with disabilities into your core curriculum, but are not sure where to start? Consider using, [http://www.w3.org/WAI/training/ Developing Web Accessibility Presentations and Training], a W3C publications. This resource provides several detailed presentation outlines. These can be used for a variety of audiences, skill levels and time constraints. </p><br />
<p>The outline, [http://www.w3.org/WAI/training/presentation-outlines#design http://www.w3.org/WAI/training/presentation-outlines#design Web Accessibility Design], is an excellent one-week introduction to accessibility for students in computer science, information technology or human factors psychology. It can be presented in two lecture hours with an optional 2 to 3 hour lab. This resource comes with several suggested readings for the instructor's preparation. Many of these are excellent reading assignments for students. Web standards originate at the W3C, so many of the referenced documents are primary source materials.</p><br />
<br />
== EOWG planning & record keeping ==<br />
<br />
=== Old and related material ===<br />
* Old material:<br />
** [http://www.w3.org/WAI/EO/Drafts/promos/courses.php Integrating Web Accessibility in Courses]<br />
** [http://www.w3.org/WAI/EO/changelogs/cl-promo-courses.html Requirements and Changelog for Promotional Campaign to Web Development Course Instructors]<br />
* '''Non-W3C''' related info:<br />
** [http://uiaccess.com/teachDI.html Teach Digital Inclusion] presentation (with draft video) encouraging instructors to teach digital inclusion in their ICT courses<br />
<br />
<br />
=== 2012 blogs, newsletters, references, etc. ===<br />
...<br />
<br />
=== Mailing lists ===<br />
...<br />
<br />
=== Tweets ===<br />
...<br />
<br />
=== 2012 EOWG Recent Contacts ===<br />
<br />
==== Done: ====<br />
...<br />
<br />
==== To Do: ====<br />
...<br />
<br />
__NOINDEX__</div>Wdickhttps://www.w3.org/WAI/EO/wiki/index.php?title=Promoting_Accessibility_in_Courses&diff=1328Promoting Accessibility in Courses2012-08-15T22:36:39Z<p>Wdick: </p>
<hr />
<div>Nav: [[Main Page|EOWG wiki main page]]<br />
<br />
== Resources & Pointers ==<br />
<br />
* Main document: [http://www.w3.org/WAI/training/ Developing Web Accessibility Presentations and Training]<br />
* Old draft: [http://www.w3.org/WAI/EO/Drafts/promos/courses.php Integrating Web Accessibility in Courses]<br />
<br />
== Audience & Messages ==<br />
...<br />
<br />
<br />
<p>An important aspect of high quality Web courses is making the Web accessible to people with disabilities. [or: An important aspect of high quality Web courses is including instruction on developing Web sites that are accessible to people with disabilities.] ''This principle applies whether the audience consists of web developers, graphic designers, managers, advocates or college students.''</p><br />
<br />
<p> ''The Suite provides several presentation outlines that enable the presenter to address a variety of skill levels, interests and time constraints.''</p><br />
<br />
<br />
<br />
== Tweet ideas you can use==<br />
...<br />
<br />
== Blog, newsletter, e-mail ideas you can use ==<br />
Subject/Headline: '''W3C WAI materials to help you update your web course for accessibility'''<br />
<br />
@@ students get current info, zingy @@<br /><br />
An important aspect of high quality Web courses is making the Web accessible to people with disabilities. [<em>or:</em> An important aspect of high quality Web courses is including instruction on developing Web sites that are accessible to people with disabilities.] To help you integrate accessibility in your Web courses, W3C WAI provides materials that you can use for lecture, activities, and student study.<br />
See Developing Web Accessibility Presentations and Training at http://www.w3.org/WAI/training/<br />
<br />
@@ It's like open source courseware @@<br />
<br />
'''Web accessibility is an important social, technical, and business issue.<br />
'''<br />
<p>Web accessibility means that people with disabilities can perceive, understand, navigate, and interact with the Web, and that they can contribute to the Web. Currently most Web sites and Web software have accessibility barriers that make it difficult or impossible for many people with disabilities to use the Web. Teaching Web designers, developers, and authors accessibility is a key factor in making Web sites and software accessible, so that people with disabilities can use and contribute to the Web more effectively.</p><br />
<p>@@consider integrating shorter in first bit @@<br /> Web courses that are up-to-date with the latest trends in the industry include accessibility. Accessibility is being requested more and more in Web site development, as people realize the many benefits of making the Web accessible&mdash;for people with and without disabilities, and for Web site owners&mdash;and as legal requirements increase. Social, technical, financial, and legal factors of Web accessibility are described in the Web Accessibility Business Case at: http://www.w3.org/WAI/bcase/Overview.html</p><br />
<br />
'''W3C WAI provides material to support Web accessibility.'''<br />
...<br />
<br />
'''You can use WAI material for your Web accessibility instruction.'''<br />
<br />
<p>To help you incorporate accessibility in your upcoming Web design and development courses, we put together a resource suite @@<br />
<p>* @@use it - make your students happy</p><br />
<p> We hope that you will @@bookmark &quot;@@training resource suite&quot; and come back to it as you prepare Web course syllabus and materials.</p><br />
<p>Thank you for your attention to Web accessibility.</p><br />
<br />
<br />
== College Instructors of Web Technologies, User Interface Design or Human Factors> ==<br />
<br />
<p>Do you want to integrate accessibility for people with disabilities into your core curriculum, but are not sure where to start? Consider using, [http://www.w3.org/WAI/training/ Developing Web Accessibility Presentations and Training], a W3C publications. This resource provides several detailed presentation outlines. These can be used for a variety of audiences, skill levels and time constraints. </p><br />
<p>The outline, [http://www.w3.org/WAI/training/presentation-outlines#design http://www.w3.org/WAI/training/presentation-outlines#design Web Accessibility Design], is an excellent one-week introduction to accessibility for students in computer science, information technology or human factors psychology. It can be presented in two lecture hours with an optional 2 to 3 hour lab. This resource comes with several suggested readings for the instructor's preparation. Many of these are excellent reading assignments for students. Web standards originate at the W3C, so many of the referenced documents are primary source materials.</p><br />
<br />
== EOWG planning & record keeping ==<br />
<br />
=== Old and related material ===<br />
* Old material:<br />
** [http://www.w3.org/WAI/EO/Drafts/promos/courses.php Integrating Web Accessibility in Courses]<br />
** [http://www.w3.org/WAI/EO/changelogs/cl-promo-courses.html Requirements and Changelog for Promotional Campaign to Web Development Course Instructors]<br />
* '''Non-W3C''' related info:<br />
** [http://uiaccess.com/teachDI.html Teach Digital Inclusion] presentation (with draft video) encouraging instructors to teach digital inclusion in their ICT courses<br />
<br />
<br />
=== 2012 blogs, newsletters, references, etc. ===<br />
...<br />
<br />
=== Mailing lists ===<br />
...<br />
<br />
=== Tweets ===<br />
...<br />
<br />
=== 2012 EOWG Recent Contacts ===<br />
<br />
==== Done: ====<br />
...<br />
<br />
==== To Do: ====<br />
...<br />
<br />
__NOINDEX__</div>Wdickhttps://www.w3.org/WAI/EO/wiki/index.php?title=Promoting_Accessibility_in_Courses&diff=1327Promoting Accessibility in Courses2012-08-15T22:33:54Z<p>Wdick: </p>
<hr />
<div>Nav: [[Main Page|EOWG wiki main page]]<br />
<br />
== Resources & Pointers ==<br />
<br />
* Main document: [http://www.w3.org/WAI/training/ Developing Web Accessibility Presentations and Training]<br />
* Old draft: [http://www.w3.org/WAI/EO/Drafts/promos/courses.php Integrating Web Accessibility in Courses]<br />
<br />
== Audience & Messages ==<br />
...<br />
<br />
<br />
<p>An important aspect of high quality Web courses is making the Web accessible to people with disabilities. [or: An important aspect of high quality Web courses is including instruction on developing Web sites that are accessible to people with disabilities.] ''This principle applies whether the audience consists of web developers, graphic designers, managers, advocates or college students.''</p><br />
<br />
<p> ''The Suite provides several presentation outlines that enable the presenter to address a variety of skill levels, interests and time constraints.''</p><br />
<br />
<br />
<br />
== Tweet ideas you can use==<br />
...<br />
<br />
== Blog, newsletter, e-mail ideas you can use ==<br />
Subject/Headline: '''W3C WAI materials to help you update your web course for accessibility'''<br />
<br />
@@ students get current info, zingy @@<br /><br />
An important aspect of high quality Web courses is making the Web accessible to people with disabilities. [<em>or:</em> An important aspect of high quality Web courses is including instruction on developing Web sites that are accessible to people with disabilities.] To help you integrate accessibility in your Web courses, W3C WAI provides materials that you can use for lecture, activities, and student study.<br />
See Developing Web Accessibility Presentations and Training at http://www.w3.org/WAI/training/<br />
<br />
@@ It's like open source courseware @@<br />
<br />
'''Web accessibility is an important social, technical, and business issue.<br />
'''<br />
<p>Web accessibility means that people with disabilities can perceive, understand, navigate, and interact with the Web, and that they can contribute to the Web. Currently most Web sites and Web software have accessibility barriers that make it difficult or impossible for many people with disabilities to use the Web. Teaching Web designers, developers, and authors accessibility is a key factor in making Web sites and software accessible, so that people with disabilities can use and contribute to the Web more effectively.</p><br />
<p>@@consider integrating shorter in first bit @@<br /> Web courses that are up-to-date with the latest trends in the industry include accessibility. Accessibility is being requested more and more in Web site development, as people realize the many benefits of making the Web accessible&mdash;for people with and without disabilities, and for Web site owners&mdash;and as legal requirements increase. Social, technical, financial, and legal factors of Web accessibility are described in the Web Accessibility Business Case at: http://www.w3.org/WAI/bcase/Overview.html</p><br />
<br />
'''W3C WAI provides material to support Web accessibility.'''<br />
...<br />
<br />
'''You can use WAI material for your Web accessibility instruction.'''<br />
<br />
<p>To help you incorporate accessibility in your upcoming Web design and development courses, we put together a resource suite @@<br />
<p>* @@use it - make your students happy</p><br />
<p> We hope that you will @@bookmark &quot;@@training resource suite&quot; and come back to it as you prepare Web course syllabus and materials.</p><br />
<p>Thank you for your attention to Web accessibility.</p><br />
<br />
<p>''College Instructors of Web Technologies, User Interface Design or Human Factors''</p><br />
<p>Do you want to integrate accessibility for people with disabilities into your core curriculum, but are not sure where to start? Consider using, [http://www.w3.org/WAI/training/ Developing Web Accessibility Presentations and Training], a W3C publications. This resource provides several detailed presentation outlines. These can be used for a variety of audiences, skill levels and time constraints. </p><br />
<p>The outline, [http://www.w3.org/WAI/training/presentation-outlines#design http://www.w3.org/WAI/training/presentation-outlines#design Web Accessibility Design], is an excellent one-week introduction to accessibility for students in computer science, information technology or human factors psychology. It can be presented in two lecture hours with an optional 2 to 3 hour lab. This resource comes with several suggested readings for the instructor's preparation. Many of these are excellent reading assignments for students. Web standards originate at the W3C, so many of the referenced documents are primary source materials.</p><br />
<br />
== EOWG planning & record keeping ==<br />
<br />
=== Old and related material ===<br />
* Old material:<br />
** [http://www.w3.org/WAI/EO/Drafts/promos/courses.php Integrating Web Accessibility in Courses]<br />
** [http://www.w3.org/WAI/EO/changelogs/cl-promo-courses.html Requirements and Changelog for Promotional Campaign to Web Development Course Instructors]<br />
* '''Non-W3C''' related info:<br />
** [http://uiaccess.com/teachDI.html Teach Digital Inclusion] presentation (with draft video) encouraging instructors to teach digital inclusion in their ICT courses<br />
<br />
<br />
=== 2012 blogs, newsletters, references, etc. ===<br />
...<br />
<br />
=== Mailing lists ===<br />
...<br />
<br />
=== Tweets ===<br />
...<br />
<br />
=== 2012 EOWG Recent Contacts ===<br />
<br />
==== Done: ====<br />
...<br />
<br />
==== To Do: ====<br />
...<br />
<br />
__NOINDEX__</div>Wdick