Prelim Eval 2013-Dec-20

From Education & Outreach

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


This is an old archive of the Easy Checks wiki page



Easy Checks - A First Look at Web Accessibility

Related pages:


Completion Plan

  1. open issues
    • everyone comment on all open issues below marked with "[EOWG..." by Wed 13 Nov
    • Discuss open issues in EOWG telecon on Fri 15 Nov
    • [done] Shawn update Forms section based on comments
  2. [done] fresh perspective review
    • [done] Anthony & Jan review & comment on all sections — except Forms — by Wed 13 Nov
    • [done] Discuss comments in EOWG telecon on Fri 15 Nov
  3. publish it as an EOWG-approved Working Draft on Friday 29 December
    [EOWG +1 below if you're OK with it, or -1 if not and note what needs to be changed before you're OK with publication]
    • +1 Shawn
    • +1 Suzette, well done everyone
    • +1 Denis
    • +1 Jan
    • +1 Howard
    • +1 Vicki - bravo!
    • +1 Sharron
    • +1 Wayne (and would like a worksheet as next step project
    • +1 Emmanuelle
    • +1 Sylvie
    • +1 Shadi - good to get it out as a draft for more review
    • more +1s in 20 Dec minutes
  4. illustrations
    • Anna Belle... :-)
  5. usability testing
    • @@
  6. publication approval
    • @@

To Do Throughout:

  • 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}
  • illustrations
    • Check img alts - some might have @@
    • Decide if we want more images for the steps. Search for [image].

[template for new comments]

  • comment {name}

Image alts

  • [Anthony: are you OK with below? <<Yes>>] Under Tips, in 5th point its better to mention about html longdesc element. We can write something like "......, and then the detailed description of the information should be provided elsewhere using html attribute "longdesc" [1]." {Anthony}
    • Maybe that's too technical for this document. How about: "If the image has complex information — such as charts or graphs — the image should have a short alt text, and then the detailed description of the information should be provided elsewhere (for example, in a data table)." {Shawn}
    • Sorry to be bunt, but I'd much prefer if we didn't refer to anything W3Schools.com has to say about, well... anything. +1 to Shawn's proposal above: we don't need to refer to longdesc in a document like this, just the concept of describing a complex image. I would just be a little more specific, by adding: "the image should have a short alt text describing the nature or purpose of the image, and then the detailed..." {dboudreau, 131217}
    • How about a little more simple: "... the image should have a short alt text identifying the image, and then the detailed..." (wording from the Images tutorial :) {Shawn}
      • I don't think just saying "identifying the image" sends the right message. How about "identifying what the image is about, and then the detailed..."? {dboudreau, 131218}
        +1 {Vicki, 20.12.2013}
        +1 {Emmanuelle, 20.12.2013}
        • [EOWG thoughts?] ?
      • [closed]I like the current text (5th bullet point under tips): "If the image has complex information — such as charts or graphs — the image should have a short alt text identifying the image, and then the detailed description of the information should be provided elsewhere (for example, in a data table)." How about adding "or longdesc description" in the parens with longdesc linked to an external page with more information.
        Suggested sentence: "If the image has complex information — such as charts or graphs — the image should have a short alt text identifying the image, and then the detailed description of the information should be provided elsewhere (for example, in a data table or longdesc description)" {Howard, 19 Dec, 2013}
      • longdesc is too complicated an issue for Easy Checks (per 20 Dec telecon)
  • [done] In the interest of visibility and progressive disclosure, how about the accordion expansion occurring on "Appropriate alt text:" and "What is not needed in the alt text:", leaving the sentence below "Tips" always visible. I think this provides a better (more semantic) cue to the information currently hidden under "Tips". {Howard, 19 Dec, 2013}

Contrast

  • [done] I would recommend that we try to avoid giving examples of types of disabilities because people who have limited experience working with people with disabilities may tend to apply statements we make to "all" people who have that type of disability. For example, the following statement is currently in the Easy Checks under Contrast Settings: "While some people need high contrast, for others — including people with some types of reading disabilities such as dyslexia — bright colors (high luminance) are not readable. They need low luminance." I would recommend that we remove the phrase "such as dyslexia" so that people won't think that "all" people with dyslexia need low luminance. {Jan}
    • I think it's good to provide examples to make it real. Some people have no clue and examples are good to make it concrete. I also agree with your point. How about if we edit it to: "including some people with reading disabilities such as dyslexia"? {Shawn}
    • I am OK with this edit {Jan}
  • [done] If we feel the need to explain what the words "pros and cons" mean, then why not simply say "strengths and weaknesses"? "There are basically three ways to check contrast, each with pros (strengths) and cons (weaknesses)" {dboudreau, 131217} Done. {Shawn}
  • [done] Gez Lemon's toolbar is named "Juicy Studio", not "Juicy Studios" {dboudreau, 131217} Done. {Shawn}
  • [done] In the "Eye-dropper to select colors" step (2), I would replace the three steps by the following:
    • The Color Contrast Analyser application window opens
    • Using the first eye-dropper icon from the foreground color section, pick the foreground color you want to analyze
    • Using the second eye-dropper icon from the background color section, pick the corresponding background color
    • The contrast ratio status and value will show as either "Pass" or "Fail" at the bottom of the window, along with a visual sample. {dboudreau, 131217}
      Thanks! done with a few tweaks. {shawn}
  • [done] In the "Turn off color step" (3), I would add the following:
    • In the toolbar, select Color > Grey Scale. Or, with the keyboard: Ctrl+Alt+5, then down arrow to "Gray Scale".
    • Have a look at the page and determine if some of the information becomes lost or harder to see, once all colors are converted to grayscale. {dboudreau, 131217}
      added: "Check if any information is lost or hard to see when all colors are converted to grayscale." {shawn}
  • [closed] Just a question... but why aren't we following the same sequence with our steps here than what the tool offers? {dboudreau, 131217}
    We're listing them in the order that we think has the most strengths. {shawn}
  • [done] Also, why aren't we also suggesting the Juicy Studio add-on for Firefox as a way to test for contrast? {dboudreau, 131217}
    Added section "Checking contrast with FF" which is how we are handling it when the main toolbar doesn't do it but another tool does. {shawn}

Resize Text

  • [done] keyboard shortcut needed:
    From the menubar... select View > Zoom Text Only.
    Or, with the keyboard: [@@ keyboard for this in Safari???]
    • As best I can tell there is no "keyboard shortcut" for this. However, you can do it with the keyboard commands to put focus in the menu. In this case that is:
      Control-F2 (Fn-Control-F2 on portable keyboards) > v > return > zz {Anna Belle, 16 Dec.}
  • [done] I could not check this in Windows, because the setting won't work with VMWare, but on a Mac, incrementally increasing text-only zoom is not controlled by pressing Command+... that's for browser zoom. What we need to do for Text resizing only is Shift, Command+ (4 times) {dboudreau, 20131217}
    • Step 1. is to set Zoom Text Only. Then command+[+] should work. (previous notes on this are in 15 Nov minutes & wiki page archive) We found making this a 2 step process allowed us to have consistent instructions across browsers because the shift+commend+[+] didn't work the same for all browsers & keyboards.
    • added: "(To confirm that you have text-only zoom set per step 1, make sure that only the text is getting larger, not the images.) " {shawn}
    • All good, thanks! {dboudreau, 131217}

Keyboard access and visual focus

  • [done - new second paragraph under Keyboard access and visual focus ] We might want to consider providing a quick example of what visual focus might look like in the introduction of this section - it's explained in the what to check for, but not earlier. I recently had to explain what this meant to a very experienced developer, so if Easy Checks are for beginners, this might need some additional explanation in the introduction. Maybe consider adding something like, "Visible keyboard focus may look like a dotted-line or colored-line box around elements as you tab through the site." {Jan}
    • I tried moving the last sentence of the intro paragraph into a new paragraph, adding text explanation similar to your suggestion, and moving the illustration up to the intro. Does that work? {Shawn}
    • Shawn - the edit looks good to me. Thanks! {Jan}

Forms

Forms section

  • [EOWG comment on the new sentence at the top of the Forms section:
    "Note: This section is more complex. If it's too complicated, consider skipping it for now and doing the next checks for multimedia and structure."
    • Yes this works well, +1 {Sharron, 17 Dec}
    • Agree with Sharron, like it. +1 {Helle HBJ, 18.Dec}
    • Agree with Helle who agrees with Sharron - works for me. +1 {Howard, 19 Dec, 2013}
    • Agree too. +1 {Emmanuelle, 20.Dec}
    • Ok for me too. But could the note say that "this section is more complex" than the others? {Sylvie, 20 Dec}
    • If we feel this section is more complex and might end up being skipped by some, then why don't we put it at the very end, as the last test from EasyChecks people might be running? {dboudreau, 131217}
    • We thought the Basic Structure Check was best last because it is different from the others. And we though Multimedia after Forms because multimedia is lass common than forms. [EOWG - let's rethink that - please comment here on the order...{shawn}
    • Think we shall keep order as it is, won't make any difference if we change order, and the arguments for this existing order are fine with me.{Helle HBJ, 18. Dec.}
    • Would lean to keeping order as is although would be open to hearing opposing arguments.{Howard, 19 Dec, 2013}
    • Agree with Howard...keep order as is. Keeping Basic Structure as last makes good sense to me but could be persuaded if a different order is important to others. {Sharron, 19 Dec, 2013}
    • Agree also with Sharron's comment {Sylvie, 20 Dec, 2013}
  • [illustration - Anna Belle] Completing forms: I think some illustrations will be useful to the novice trying to understand forms using the WAT results. I am not sure how the proposed image in step 2 will differ from the image in step 3. In either case showing a present and absent label for or id will be sufficient. For step 5 however, I cannot see how WAT helps - surely you have to look at the code view to see if the asterisk is included or excluded - or am I missing something? Would an image help? {Suzette}

Open the Inaccessible Survey Page: www.w3.org/WAI/demos/bad/before/survey and do the label checks above.
In IE WAT, you get the dialog box saying there are no labels. [@@ does this still happen with the new version of WAT?]

    • Not a dialogue box (unless you use the Jim Thatcher favelet.) What I get on the IE WAT toolbar is this error message: <textarea No Match id="wgjc" Error> <textarea No Match id="wgjs" Error> <textarea No Match id="wgju" Error> with the text "No match" and "Error" in bold red. This may be a good place for illustration. Jim's favelet gives a dialogue box that says "4 errors out of 8 form controls with 4 to review" Those for manual review are usually ones with no onscreen text label.{Sharron 17 Dec}
    • Thanks, Sharron! I downloaded the new toolbar, tested it, and fixed the instructions. {shawn}
  • [closed] In the "To check labels with IE WAT", second bullet ("Structure", then "FieldSet / Labels"), a good, simple example with no errors would be from the Paciello group's blog post with the search field in the top right corner: http://blog.paciellogroup.com/2012/04/web-accessibility-toolbar-2012/ {dboudreau, 131217} OK. I don't think we need to put another example in this doc in addition to BAD. {Shawn}
  • [done] We should consider adding Understanding SC 1.3.1 to the list of resources to learn more about forms: http://www.w3.org/TR/UNDERSTANDING-WCAG20/content-structure-separation-programmatic.html {dboudreau, 131217} agree {shawn}

multimedia

  • [EOWG - open action] [Paul] In Section "captions", look for a way to turn on open captions with the keyboard, for example in Youtube activating the CC button. (How to do it with nvda from Howard -- but we want more generic instructions, e.g,. sighted keyboard users.)
  • [done] "If there are captions, transcripts are not usually required" - why would we want to say that? Captions and transcripts help users in different ways - captions are handled specifically in SC 1.2.2 and transcripts are implicit to SC 1.2.1. I believe we should not mention anything about having the choice to just use one or the other. {dboudreau, 131217}
    • We need to be honest that it's not a requirement in all cases. I edited it to "It is best practice to provide both captions and transcripts, although not always required; providing transcripts has many benefits — both to people with disabilities and to website owners." {shawn}
    • Yes, I agree. There's a fine line that should not be crossed. But still, we don't need to overstate anything either. :) Thank you for the update, I appreciate how it's been toned down. {dboudreau, 131218}

Plain Content View

Latest proposal for calling this section: Basic Structure Check
  • [EOWG open] Are you comfortable calling this section "Basic Structure Check"?
    before commenting against this, please read the background including the minutes, brainstorms, notes on what to call this section
    • looking at the list of sections and draft of this section I wonder if we want to call it just "Basic Structure"? {Shawn}
    • I am really happy with Basic Structure OR Basic Structure Check. This is the right approach to this title and leave the nuance to editor's discretion. {Sharron 17 Dec}
    • I much prefer basic structure check to plain content view. {dboudreau, 131217}
    • Agree. Basic structure Check much better. With or without Check up to editor's discretion. {Helle, HBJ 19. Dec.}
    • "Basic Structure Check" or "Basic Structure" works for me{Howard, 19 Dec., 2013}
    • Both work for me {Vicki, 20 Dec. 2013}
    • I like "Basic Structure Check" {Emmanuelle, 20 Dec. 2013}
    • I also vote for "Basic Structure Check". {Sylvie, 20 December}
    • {name}

  • [EOWG thoughts?] [Sharron, Wayne, Suzette]To practice checking plain text view with BAD section: Do we want to point out other things?
    • No strong feelings, editor's discretion{Sharron 11 Nov}
    • No strong feelings either {dboudreau, 131217}
    • No strong feelings{Vicki}
    • No strong feelings either {Emmanuelle. 20 Dec. 2013}
    • No strong feelings either {Sylvie, 20 December 2013}
    • comment {name}

Next Steps

  • [EOWG thoughts] [Anthony, Helle, Andrew] What else to list as other accessibility issues not covered in these easy checks?
    • I would like to have something about Lists, especially about Definition lists. Not sure how to do it. Maybe we could tell people that it is better to use Headings, or maybe it should be on a to-do list for new easy checks or best practice. {Helle HBJ 19. Dec}
    • Tables are a very important issue out there {Emmanuelle. 20 Dec. 2013}
    • Robust {shawn}


    • [done] As a non-native English speaker, I would appreciate something on language (SC 3.1.1 and SC 3.1.2). Very easy to test for and has devastating effects for screen reader users when not set properly in a page. {dboudreau, 131217}
      • I added it to this list.
      • Should we consider including it as an Easy Check? Does it meet our criteria for checks? Is there an easy test without looking at source code?{Shawn}
        • I'm afraid I don't know of any... besides using a tool like FireEyes, but this tool definitely reaches far beyond the scope of this document {dboudreau, 131217}
        • then I guess the answer is no :-)
    • [closed] No additions to suggest {Sharron 11 Nov}






Internal Notes

Easy Checks - Illustrations moved to its own page.

Misc:

  • When each relevant tutorial is done enough, add link to it in the top of the "Learn more" sections.
  • Ask Identifying Web Accessibility Issues to link to Easy Checks when it's more done.
  • comment {name}

Usability Testing

Things to test with users

  • Expand/Collapse: test to see if the "+/-" icons convey this feature
    • might want to consider putting text such as "expand/collapse" in addition to the "+/-" icons
  • Meaning of terms such as "accessibility," "page title"
    • Do users understand the term "accessibility"
      • We assume that by the time users access this page they understand the term "usability." Perhaps this needs to be reconsidered.
    • Do users understand what we mean by "page title" or do we need to explain further
  • Resize Text - especially check if they understand the horizontal scrolling bits

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.