Important note: This Wiki page is edited by participants of the EOWG. It does not necessarily represent consensus and it may have incorrect information or information that is not supported by other Working Group participants, WAI, or W3C. It may also have some very useful information.


Difference between revisions of "Easy Checks"

From Education & Outreach
Jump to: navigation, search
(Comments after 10 June)
(Comments after 10 June)
Line 356: Line 356:
 
* <span style="background:yellow;">[EOWG please comment]</span> 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].
 
* <span style="background:yellow;">[EOWG please comment]</span> 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].
 
** 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>
 
** 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>
** 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. <span style="color:#808080;">{Shawn}</span>
+
** 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>
 
** comment <span style="color:#808080;">{name}</span>
 
** comment <span style="color:#808080;">{name}</span>
  

Revision as of 12:19, 14 June 2013

Nav: EOWG wiki main page > Evaluation Pages
[Old Web Accessibility Preliminary Evaluation page]


Easy Checks - A First Look at Web Accessibility

Related pages:


Related pages:

To Do

Page titles

  • [OPEN action] Find a keyboard way to display the full page title in IE 9 and later and chrome.

Keyboard access and visual focus

  • [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."
  • [EOWG thoughts?] In "what to do", visual focus:
    "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.)"

Forms and error messages

  • [EOWG thoughts?] In "required fields" we may need to explain group label in the beginning.
  • [OPEN action] In "error messages", need to say more specifically how to check if the focus is at the error message.

Multimedia (video, audio) alternatives

  • [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.
  • [EOWG thoughts?] think of other examples for important noise, especially positive ones (instead of slamming and breaking:)

Throughout:

  • Check img alts - some might have @@
  • Decide if we want more images for the steps. Search for [image].
  • Search for other open things in [brackets].
  • 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' {Shawn}

Misc:

Public Comments

Jim Allan 6 June

  • Comment: Color/Contrast channeling Jared's <rant>!!! 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.
    [EOWG thoughts:
    • comment {name, date}
    • We could just change the first one to white background rather than adding another example. {Shawn, 6 June}
  • [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>text size in windows with wheel mouse, can zoom using control and mouse wheel (forward for larger, backward for smaller)
    Resolution proposal: 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.
    [EOWG thoughts:
    • comment {name, date}
  • [closed?] Comment: you need to describe "visual focus" - something like "usually seen as a dotted rectangle surrounding a link. " Visual focus is jargony
    [EOWG thoughts:
    • comment {name, date}
    • 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?
      Resolution proposal: 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."
      Is that good enough?
  • [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!!
    Resolution: Made the headings under "Using these Easy Checks" always visible and added "FF Toolbar and IE WAT " to "Tools"
  • [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
    Resolution: Made the headings under "Using these Easy Checks" always visible so "Practicing with BAD, the Before-After Demo" is visible. Also linked all BAD page URIs.
  • [closed pending EOWG OK] Comment: keyboard access and visual focus a test page would be useful
    Resolution: Added "To see visual focus with BAD" section

Other

6 June, Ryan

Overall Comments

  • Any edits based on input from Tom J. (Wayne's forwarded e-mail) ?
    • comment {name}
    • [in-progress] I agree with Tom's following thought:
      "Looking for an even simpler FIRST check, I've tried this one:
      FF Toolbar, Miscellaneous -> Linearize Page; Images -> Replace Images With Alt Attributes; CSS -> Disable Styles -> Disable All Styles. This is almost a visual "voice reader" simulation, except of course it doesn't say "image," "link," and so on. But if the page looks good this way (headings, organization, sensible alt text, etc.), it's probably close. If it doesn't make sense this way, then more thorough analysis is in order. (Try it on the inaccessible BAD Home page.)"{Sylvie}
    • [closed] Tom writes: "I understand why they've had to include multiple systems (IE + FF), although FF can be used on any OS."
      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}
    • 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}

Comments on Linearize

Drafts:

[EOWG comment]
Do we want to include something like this at the end?
What are the benefits?
What are the cons?
If we do, what comments do you have on the draft text?
What should we call this section? (it's more than linearize, it turns off images & CSS as well)

  • comment {name, date}
  • I like the idea of this section - it adds something more to the checks than just yes/no
    Benefits - gives a little experiential flavour of what some people experience
    Cons - not about 'checking' per se, so could add confusion for readers
    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. {Andrew, 13 June}
  • 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:
    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.
    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.) {Sylvie, June 13}
  • 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. {Sylvie, June 6}

Linearize Page (Optional)

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.

What to do:

The checks below provide instructions with different browsers for how to:

  • Expose text alternatives by removing images
  • Reveal the reading order by turning off the associated style sheets
  • Examine the resulting page display for an approximation of a screen reader experience.

To linearize with IE WAT

  1. Open the page you are checking in the IE browser
  2. Using the toolbar, choose Images > Remove Images
  3. Next choose CSS > Disable CSS
  • comment {name}
  • Shortcuts in WAT toolbar are:
    With keyboard press ctrl+alt+shift+s to display the options dialog box and uncheck the boxes "Images" and "CSS", then select "ok"..
    {Sylvie, June 6}

To linearize with FF web developer toolbar

  1. Open the page you are checking in the FF browser
  2. Using the toolbar, choose Images > Disable Images
  3. Next choose CSS > Disable Styles > Disable All Styles
  • comment {name}
  • 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. {Sylvie, June 6}

What to check for:

Read through the resulting display and notice the following:

  • 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)
  • Verify that the reading order is logical, complete, and makes sense.



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

Linearize the Page for Experiential Learning (Optional)

When a page is converted form text to speech, to Braille, or to very large print, the author's two dimensional presentation format breaks down. Before a page can be converted to an appropriate medium it must be reduced to a one dimensional information stream. This process is called linearizing the page.

Not everyone has access to a screen reader, or powerful text customization tools required to experience linearized content as it is used, but a linearized presentation of content is easy to simulate using the tools we have introduced so far. This can give the fully sighted reader an understanding of the day to day experience of users with blindness or low vision.

Linearization does not focus on any one success criterion, instead it reveals how well a page is organized to support accessibility. Example: Read the linearized view of the inaccessible version in the BAD Demo. That will be fun, and it reveals a lot of what can go wrong.

The checks below provide instructions with different browsers for how to:

  1. Unclutter the linear view and expose text alternatives by removing images
  2. Reveal the reading order by turning off the associated style sheets,
  3. Expose navigation support for a one dimensional content format, and
  4. Reveal the resulting page display for an approximation of a screen reader / customized text experience.

To linearize with IE WAT

  1. Open the page you are checking in the IE browser
  2. Using the toolbar, choose Images > Remove Images
  3. Next choose CSS > Disable CSS

Shortcuts in WAT toolbar are: With keyboard press ctrl+alt+shift+s to display the options dialog box and uncheck the boxes "Images" and "CSS", then select "ok".. {Sylvie, June 6}

To linearize with FF web developer toolbar

  1. Open the page you are checking in the FF browser
  2. Using the toolbar, choose Images > Disable Images
  3. Next choose CSS > Disable Styles > Disable All Styles

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. {Sylvie, June 6}. This doesn't work in the English version {Wayne, June 11}

What to check for:

Read through the resulting display and notice the following:

  1. 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)
  2. Verify that the reading order is logical, complete, and makes sense.
  3. <new> Make sure that there are reasonable ways to skip around long lists of links and other boiler plate content that is repeated on every page in the site. </new>

Introduction

Introduction in WAI draft page

Status:

  • Complete, ready for detailed review.
  • no major edits since February

Comments:

  • comment {name, date}

Page title

Page title in WAI draft page

Status:

  • Complete, ready for detailed review.
  • OPEN: a couple things listed in "To be implemented" below
  • 30 May edit: significantly edited the first part.
  • 24 May edits: changed images.
  • 21 March edit: changed "Best practice is for titles to be "front-loaded" with the important and unique identifying information first..."

Comments:

  • comment {name, 00 month}

Image text alternatives ("alt text")

alt text in WAI draft page

Status:

  • Complete, ready for detailed review.
  • only minor edits since February

Comments:

  • comment {name}

Headings

Headings in WAI draft page

Status:

  • Complete, ready for detailed review.
  • 30 May edits: changed 'What to check for' from questions to statements to be consistent with other sections.
  • 21 March edits: combined instructions under each tool

Comments:

  • comment {name}

Luminosity Contrast

Visual contrast in WAI draft page

Status:

  • Overall flow, instructions, text is complete and ready for review.
  • OPEN: Needs someone to fill in some details on using the tools. - Vicki will do it
  • 10 May edit: changed heading from [Luminosity Contrast ("color contrast")] to [Contrast Ratio ("color contrast")]
  • 22 March edit: changed heading to Luminosity Contrast ("color contrast")
  • 21 March edits:
    • changed heading to Visual contrast ("color contrast", luminosity contrast)
    • tweaked wording a bit and added: This accessibility requirement is sometimes called sufficient "color contrast"; however, that is incorrect — technically it's "luminosity contrast".
  • 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.

Comments:

  • [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." {Anna Belle}
    reply: a mac version is available - http://www.paciellogroup.com/node/18?q=node/20#macdownload {Andrew, 15/March}
    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?
    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. {Andrew, 22/March}
    [open action for Mac] 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?
    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?{Anna Belle. May 30}
    The Windows one required me to be admin as well, so I just deleted this all together. {Shawn}

Zoom

Zoom in WAI draft page

Status:

  • Complete, ready for detailed review.
  • 8 March edit: Added "If possible, you should check zoom text only." and moved "To check zoom text only" up.
  • 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).

Comments:

  • comment {name}

Keyboard access, content order, visual focus

Keyboard, etc. in WAI draft page

Status:

  • Complete, ready for detailed review.
  • 14 May: significant edits.

Comments:

  • comment {name}
  • Illustrations of focus indication would be useful. Shall I send screen shots to the list or how to provide? {Sharron}
    Send them to Shawn & she'll upload them :) {Shawn}

Forms, form labels, and error messages

Forms in WAI draft page

Status:

  • 16 May: significant edits.
    Note: more updates coming

Comments after 10 June

  • comment {name}


  • [EOWG please comment] Background: 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 Criteria for what to include.
    • 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 :) {Andrew, 13/June}
      Anna Belle moaned when I mentioned that option. :) Remember that we added a section on things that are not included in the easy checks {Shawn, 13 June}
    • 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. {Howard, 14 June}
      It works when the label is implicit. Is this false pass? Explicit labels were required with WCAG 1.0 — although not exactly in WCAG 2.0. We should research this more. {Shawn}
    • comment {name}


  • [EOWG please comment] Is there a way to check label markup with FF toolbar? If not, should we not have a FF section at all?
    • As far as I can see, FF toolbar can only display/highlight forms fields without labels: Forms > Outline Form Fields Without Labels {Andrew, 13/June}
      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?]" {Shawn, 13 June}
    • 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? {Howard, 14 June}
      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. {Shawn}
    • comment {name}

Comments before 10 June

  • [done] say explicti lables on radio buttons make the whole thing clickable! {Shawn, Paul}
  • [closed? added to 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. {Howard, 6 June}
  • Other observations/feedback: {Howard, 6 June}
    • [done. fixed] the link to the "preliminary" page is broken
    • [EOWG open - heading for this section simply "Forms?" or more?]
      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
      • Currently the section covers: Labels, Keyboard Access, Instructions, and Error Handling" Maybe keep it short and just use "Forms" ? {Shawn 10 June}
    • [closed. current draft has "Find forms on the page."] "Find Forms" header under "What to do" seems too open. Suggest: "Find the forms on the page" (too wordy?); or "Find form elements" (too technical?)
        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}
    • [closed? 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)
    • [closed current draft covers it in keyboard section] Maybe the "submit button" section could be replaced with a statement such as:
      "Form data should not be submitted without user confirmation" (followed by more detailed instructions?)
    • [closed? edited in 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".
    • @@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.
  • As discussed in EOWG's 31 May teleconference, I suggest changing the checks order as proposed below:
    1. Labels
    2. Instructions
    3. Keyboard access and reading order
    4. Submit buttons
    5. Data input and error messages
    {Sylvie June 4, 2013}
  • In section "error messages", we should give clear instructions on what to look for, avoiding asking for judgement.
    • Check that there is guidance to help user understand and fix the error.
    • The focus moves to the error message
    • Error information is not located at the end of the form, but rather at the beginning.
    • The user is not requested to fill in the whole form again, but only the error fields.
    • If the error concerns a format, such as date, time, address, suggestions are made to enter the correct format.
    • If a required field has been forgotten, that this field is indicated with colour and text such as "mandatory" or *.
    {Sylvie June 4, 2013}
  • [EOWG discuss] Are these easy checks? I wonder if all of what's currently in the Forms section qualifies as easy checks? For example,
    - Is "Instructions" too soft/unclear/nonspecific?
    - 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.
    - Is "Data input and error messages" too hard for an easy check?
    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.
    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")
    Perhaps we want to re-focus this section to just Form Labels? {shawn}
  • 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?) {Shawn}
  • 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> ? {shawn}
  • [closed] Suggest changing:
    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.
    to:
    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. {Howard 23 May}
    Suggest changing:
    Forms are made up of controls such as text entry fields, check boxes, radio buttons, drop-down boxes and finish with submit buttons.
    to:
    Forms CONSIST of data entry fields, including text fields, check boxes, radio buttons, drop-down boxes and controls, usually consisting of a submit button. {Howard 23 May}
    Actually, I think the introduction should take a different approach — not to introduce forms per se, but to introduce some of the accessibility issues with forms — like the other sections do. {Shawn 24 May}
  • [closed] Suggest changing:
    For longer or unusual forms, check for instructions.
    to
    For long or complex forms, check for instructions.
  • Suggest deleting:
    Instructions are usually needed to explain how to fill out the form.{Vicki 24 May}
  • [closed] Suggest changing:
    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?
    to
    Are the instructions positioned appropriately (usually at the beginning of the form and/or at the start of specific sections)?
    Do the instructions clearly explain how to fill out the form?
  • Suggest changing:
    Are required fields explained in the instructions and clearly identified throughout the form?
    to
    Are the required (mandatory) fields explained in the instructions and clearly identified?
    {Vicki 24 May}
  • 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. {Suzette}

Multimedia (video, audio) alternatives

Multimedia in WAI draft page

Status:

  • Complete, ready for detailed review.
  • 24 May minor edits.
  • 21 March: significant edits.

Comments:

  • comment {name}
  • for other captioned sounds, suggest:

Important sound other than dialogue — e.g., door slamming, broken glass, water dripping, applause, laughter, writing on blackboard, tires squealing, etc.[@@other examples of important noise, especially positive ones (instead of slamming and breaking:)] — is included. {Howard, 6 June}

  • accessing cc with keyboard:
    • with nvda in firefox
    • '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)
    • pressing the enter key brings you to player controls;
    • down-arrow will then take you to the closed captioning on/off control.

    • 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.
    • helpful youtube keyboard shortcut page: http://support.google.com/youtube/bin/answer.py?hl=en&answer=189278
{Howard, 6 June}
  • [done] suggest changing
    "Most video on the web that provides captions has "closed captions" that need to be turned on."
    to:
    "Most video on the web that provides captions has "closed captions" that can be turned on and off". {Howard - May 31}

Next Steps

Next Steps in WAI draft page

Status:

  • Complete ready for review - updated 4 June

Comments on Next Steps

  • comment {name, date}
  • maybe summarize other things that need to be checked that aren't covered on this page? {Shawn, 7 June}
    Potential things to list:
    • comment {name, date}

Contributors

Thanks to:

  • Those who participated in the F2F before CSUN in February: Andrew, Anna Belle, Helle, Jennifer, Shadi, Sharron, Shawn, Wayne
  • Those who edited in December and January: Suzette (forms, @@), Sharron (Intro, @@), Shawn (Intro, page titles, headings, alt text), Ian (zoom n text resize).
  • Those who commented in December and January: Sylvie, Wayne, Anna Belle, ...
  • Those who drafted checks 16-28 November:
    • Sharron for drafting {list sections!}
    • Suzette for drafting : Check usable with page zoomed and text enlarged, Check color contrast, Check color coding and shape coding, {?other sections}
    • Wayne for drafting {list sections!}
  • Andrew & Shawn for editing the keyboard access & visual focus section in early Nov.
  • Ian, Suzette, Vicki, Sylvie, Helle, Shawn for working on an early draft at the f2f in Nov.
  • Sharron for help making all the early drafts and versions less confusing.
  • Wayne and Ian for sharing colleagues' related work.
  • Denis for edits to the old page content.

testing image: search-icon.png

Internal Notes

Illustrations

Note:

  • 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)
  • Make sure to evaluate the images in context, that is, read the text around it and imagine you are a user.

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.

  • comment {name}
  • From 24 May teleconference:
    • Generally the conceptual images are useful for contrast and zoom; simply the page title images {done 24 May}.
    • 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.
    • For now:
      • Include images showing menu items and such judiciously — if in doubt, do not include an image.
      • Crop or gray out all unnecessary clutter in images. (for example, page-title-image has the content of the web page grayed out.)

Strategy: I'd like to discuss strategy for illustrations. {Anna Belle, June 9} Here are questions to consider:

  • Do we want to use captions? Always? Sometimes? If sometimes, then what distinguishes when they are needed?
    • 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. {Shawn, 12 June} Agree {Andrew, 13 June}
  • If we use captions, then how? E.g. do we give a 10 pixel padding with a border that encloses both image and captions?
  • Do we have images embedded in the text flow or do we separate them out (e.g. float to right)?
    • I suggest embedded in the text flow. {Shawn, 12 June} Agree {Andrew, 13 June}</li> </ul> </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.
      • 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. {Shawn, 12 June}
    • What is the maximum width for an image?
      • We previously decided to make most images 700px wide. We can revisit that decision. {Shawn, 12 June}
    • 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?
      • I vote let's try to make the images useable in the page, and not add the complexity of linking to a larger image. {Shawn, 12 June}
    • 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.
      • 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. {Shawn, 12 June} Agree {Andrew, 13 June}</li> </ul> </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.)
        • Currently there are 3 types of images:
          1. Illustrate the concept (e.g., page titles, contrast, zoom).
          2. Illustrate the toolbar things to click.
          3. Illustrate the results from the tool, e.g., alt text next to images.
          Currently the concept images (1) are always shown, and the toolbar images (2 & 3) are shown only when that specific checks step is expanded. I think this works well. [Agree {Andrew, 13 June}]
          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. {Shawn, 12 June} [Agree - and we don't need more delays in releasing {Andrew, 13 June}]</li> </ul> </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?
          • 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:
            • 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. [@@ we need to redo this image with a browser that does not have a title bar :-]
            • Contrast - several images that show different color combinations that are mentioned in the text.
            • Zoom - 2 that show a page not zoomed and zoomed.
            I don't think it makes sense to put these one a separate page. {Shawn, 12 June}
        • Do we want to standardize the format to the image? JPG? SVG? PNG?
          • I think png {Shawn, 12 June}
        • 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)?
          • Yes. Please do! ;-) {Shawn, 12 June}
        • </ul>

          Case study notes

          See SK/MC Case Study Notes in the 30 May 2013 snapshot

          Consider for Later

          • 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."
            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}

          previous versions, etc.