Easy Checks

From Education & Outreach
This is an internal planning page. The published resource is:
Easy Checks - A First Review of Web Accessibility
https://www.w3.org/WAI/eval/preliminary

This is an old page. Some more recent info is in https://www.w3.org/WAI/EO/wiki/Easy_Checks_Next_Gen

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

Related pages

2017 Project Notes

Edit and Review Team: Caleb, Laura, Norah, Robert, Sylvie, Vivienne, [Eric]

Revision Plan

Note: Editing and Review Teams were asked for input on 2 August, and it was listed in Work for this Week for many weeks. Only a couple replied, per below.

Pre-launch

  1. Leave title as is for now; revisit title when revise resource. Issue 64
  2. Minor addition: add brief info about automated tools Issue 85
  3. Everything else assigned to next revision, which we hope will be in early 2018!

Major Revision

  1. Very soon, start major revision as specified in Next Generation specification, which includes GitHub issues labeled "later version"

Review: Title/Name

Title/Name of resource GitHub 84

  • Caleb
  • Laura
  • Sylvie
  • Vivienne
  • Norah [done 1 Sept]
  • Robert [done 5 Sept]
  • Eric [done]

Review #1

Easy Checks - before and after launch - 2 August

  • Caleb
  • Robert
  • Sylvie
  • Vivienne
  • Norah [done? 14 August]
  • Laura [done 8 August]
    • "I am comfortable putting the current version on the new web site as long as the formatting and other currently open issues are addressed pre-launch." -- Laura

Old Completion Plan

To Do

2015 Changes for EOWG Review

  • [edits in-progress] disclaimer (not definitive previous discussion)

    • Changes 3 Sept

    1. typo in intro: "these four sections" changed to "these five sections"

    2. typo in "Practicing with BAD..." : changed "box title Note... will open" to "box titled "Note ##" will open"

    3. In Background, changed "To check a couple details, you need to see the visual page or hear audio." to "To check a couple of details, it may be necessary to see the visual page or hear audio"

    4. In "Keyboard Instructions," changed "Ctrl" verses "cmd" in: to 

    "Ctrl" verses "cmd" in different operating systems.

    5. in Image text alternatives: changed "who cannot see the image." to "who do not see the image."

    6. In Keyboard access, changed "Websites need to enable people..." to "Accessible websites enable people..."

    7. In forms labels and errors section, changed "consider skipping it for now and doing the next checks for multimedia and structure." to "consider skipping it for now and proceeding through the remaining checks." Rationale: We added the Flashing content before Multimedia.

    8. Forms section, changed "which enables a person who has difficulty clicking on small radio buttons or checkboxes..." to "increasing the target area and making it easier to select small radio buttons or checkboxes."

    9. Added the section on Flashing Content

    [template for new comments]

    • comment {name}
      • reply to comment {name}
    • another comment {name}

    March 2014 changes

    Suggested: More visible, stronger this is not definitive, have to do more...

    [Status on 8 Dec 2016: Overall issue is moved to GitHub #37 -- however, please check that all edits considered -- specifically Jan's edit to "Encourage thorough accessibility evaluation" section at the end.]

    • How about at the end of each section:

      These checks are not definitive and they cover only a few accessibility issues. A web page could seem to pass these checks, yet still have significant accessibility barriers. More robust evaluation is needed to evaluate all issues comprehensively. Encourage thorough accessibility evaluation.

      {counter proposal, 20140404, dboudreau} These checks are not definitive and only cover some of the most basic accessibility issues. A web page could seem to pass these checks, yet still have significant accessibility barriers. More robust evaluation is needed to evaluate all issues comprehensively. Encourage thorough accessibility evaluation.

      See draft internal page for style ideas & location. {Shawn}

    • OK by me - but a possible rephrase of the second sentence: "More robust evaluation is needed to comprehensively evaluate all potential issues." {Andrew, 01-April-2014}
    • +1 to Andrew's rewrite of the second sentence. We need to do something avoid using "evaluation" twice. I thought the text was noticeable. I think it could be put at the end of each section. A possible rewrite of text when you follow the "Encourage thorough accessibility evaluation" link: "There are accessibility issues that are not covered in these Easy Checks. For example: links, data table markup, reliance on color, content that causes seizures, and much more. More robust evaluation is needed to identify all potential accessibility issues. Guidance is available from:
      • WCAG-EM Website Accessibility Conformance Evaluation Methodology
      • Selecting Web Accessibility Evaluation Tools
      • Involving Users in Evaluating Web Accessibility"
      {Jan, 01-April-2014}
    • +1 for the original text and +1 for Andrew's change. +1 Jan's suggestion to use "identify" (or alternative suggestion, use"address") for the sentence starting "More robust evaluation ..." {Vicki, 01-04-2014}
    • This is all good and I am generally in agreement with comments by Andrew, Jan and Vicki. If I understand correctly, we are suggesting that this shaded box be listed within each and every section, is that right? That is a good idea and I agree with Vicki's rewrite of the "Encourage thorough accessibility evaluation" link. {Sharron, 02-April-2014}
    • +1 to all comments above. But I fear that writing this text at the end of each section would make the document too long. {Sylvie, 03-April-2014}
    • +1 to all of the above. Though I'm not concerned about it being at the end of each section. It's easy enough to bypass after the first reading, both visually and via keyboard. It also makes the point that this is important enough to deserve repetition. {Bim, 04-April-2014}
    • 0 (abstain) - still playing catch up... {Liam, 04-April-2014}
    • re positioning +1 to Sylvie. With the bright visual display it will be distracting in each section - suggest we just place it after the list of checks, just before the 'expand all' button {Andrew, 05-April-2014}
    • I like the bright visual display, and agree with Andrew that it only needs to be listed once...I don't have a preference where. {Paul, 10-April-2014}
    • comment {name, 00-month-2014}

    • Discussion at EOWG, 28-March-2014
    • Sharron to draft language, style, location {EOWG, 28-March-2014}

    closed

    Suggested: Expand the many acronyms, especially BAD and FF

    Rationale: Acronyms are expanded in the intro and on first use in most cases. {Sharron, 03-September-20154}

    • how about BAD-> BAD Demo, FF Toolbar->Firefox Toolbar, IE WAT->IE WAT Toolbar. any others? {shawn, 27-march-2014}
    • For those who don't know that BAD is the acronym for Before and After, could this be written in full on first use, followed by the acronym in brackets? Suggest Before and After Demo (BAD). Rationale: To avoid any suggestion that the demo only shows bad techniques. {Bim, 28-March-2014}
    • Problem is that this would need to be in each section as a visitor might only expand 1 or 2 sections{Andrew, 28-March-2014}
    • Editor's discretion {EOWG, 28-March-2014}

    closed

    • Suggested: add how to record the findings so you can keep track over time.
      • I think goes on wishlist for future -- although it wouldn't be too hard -- just a checklist really... {shawn, 27-march-2014}
      • Not do. see minutes {EOWG, 28-March-2014}
    • Done: In Forms section, deleted: "Check that the text in quotes after the id= is different, that is, there are not two ids with the same text." (because it's rare because usually caught in code checks)

    Overall

    Ctrl for Windows, cmd for Mac

    [Resolved at Editor's Draft page]

    [EOWG please comment]

    How to write it?

    In a previous meeting, we had decided on an approach for covering both Windows and Mac keystrokes, which is 1 below. Once implemented, I felt that was too Windows biased, so tried 2 below. But that was too awkard and confusing. So I tried 3 below. Then to make it visually more clear, I tried putting the "/cmd" in a different color in 4 & 5 below (contrast ratio of #5 is 4.71:1, so WCAG Level AA).

    1. Or, with the keyboard: Ctrl+Alt+6 (Mac: cmd+Alt+6), then down arrow key to "Heading structure".

    2. Or, with the keyboard: Windows: Ctrl+Alt+6 / Mac: cmd+Alt+6, then down arrow key to "Heading structure".

    3. Or, with the keyboard: Ctrl/cmd+Alt+6, then down arrow key to "Heading structure".

    4. Or, with the keyboard: Ctrl/cmd+Alt+6, then down arrow key to "Heading structure".

    5. Or, with the keyboard: Ctrl/cmd+Alt+6, then down arrow key to "Heading structure".

    EOWG: Thoughts on the options above?

    • Solution 1 is clearer to me. No opinion on 4 or 5. Other possibility would be to write a note at the beginning of the doc explaining that for shortcuts when we talk about ctrl it means command for mac. {Sylvie, 25 February}
    • Preference for Solution 1 or 2. {Vicki, 26 February}
    • Prefer 1 or 2. Also like "Ctrl+Alt+6 (Windows) or Ctrl+Alt+6 (Mac)" {Anna Belle 26 Feb.}
    • Options 1 or 2 - preferred. {Bim 28 Feb}
    • Prefer option 2 with no parentheses. {Sharron 28 Feb.}
    • No preference {Paul Feb 28}
    • length and complexity - We have instructions like these all over - and most people will probably use the mouse, not the keyboard instructions - and keyboard users are probably very used to either ctrl or cmd -- therefore, I strongly want the shortest and simplest solution - thus not #2. And I am not at all comfortable with the Windows bias of #1. {Shawn}
    • summary - comment {name}

    Instructions

    We also said to add instructions. These are drafted in Keyboard instructions: Ctrl for Windows, cmd for Mac as:

    Keyboard instructions: Ctrl for Windows, cmd for Mac

    Some of the keyboard instructions are different for Windows and Mac; for example, "Ctrl" verses "cmd" in:

    • For Windows: With the keyboard: Ctrl+Alt+6, then down arrow key to "Heading structure".
    • For Mac: With the keyboard: cmd+Alt+6, then down arrow key to "Heading structure".

    To reduce clutter, these are listed as:

    • With the keyboard: Ctrl/cmd+Alt+6, then down arrow key to "Heading structure".

    For such instructions, Windows users press the Ctrl key, and Mac users press the cmd key.

    EOWG: Thoughts on that wording? (a separate question below asks about the order of the sub-sections in that section)

    • Keep it simple! - I found the use of ctrl/commmand then the rest of the shortcut difficult to read. It sounds better to explain it once and seperate: for windows users press ctrl+alt+6 for mac users press command+option+6. {Sylvie, 25 February}
    • No particular comments. Clear to me. {Vicki - 26 February}
    • Looks OK to me, except I want to capitalize the C of "cmd" for Mac, e.g. in last sentence. {Anna Belle - 26 February}
    • I like Sylvie's idea of "explain once" and separate instructions for Mac and Windows. {Sharron - 28 February}
    • +1 for Sylvie and Sharon - just seems clearer {Bim 28 Feb}
    • summary - comment {name}



    @@note to Shawn -- remember to do the CSS for /cmd when copy over to preliminary.html URI

    other

    • order of Using these Easy Checks sub-sections - it has the following 5 sub-sections:
      • Click headings with [+] buttons to get hidden information [which is alway expanded, and thus should stay first]
      • Tools: FF Toolbar and IE WAT (optional)
      • WCAG Links
      • Practicing with BAD, the Before-After Demo
      • Background
      • Keyboard instructions: Ctrl for Windows, cmd for Mac

      [EOWG: Thoughts on this order, or suggestion for a different order?

      • Other order proposed - I think practical information should be provided together and background and WCAG stuff also together that would then be:
        • Tools: FF Toolbar and IE WAT (optional)
        • Keyboard instructions: [@@These tools can be used with the mouse but also with the keyboard] Ctrl for Windows, cmd for Mac
        • Practicing with BAD, the Before-After Demo
        • Background
        • WCAG Links
        {Sylvie, 25 February}
      • Suggestion for alternate order
        • Background
        • Keyboard instructions
        • Tools: FF Toolbar and IE WAT
        • Practicing with BAD, the Before-After Demo
        • WCAG Links
        • Rationale: "background" pushed higher up because it provides information about who the target audience is (i.e., I can determine immediately if this "package" is for me), then practical information follows in order to understand and perform the easy checks), with the WCAG Links last {Vicki - 26 February}
      • Summary - Comment {Name}
    • [done] Capitalization of H2 headings is consistent. Thus in the body of the text it reads: "Image text alternatives..." v. "Contrast Ratio...." Do we want to conform on title case or sentence case? {Anna Belle, 28-Jan. 2014}
      Most were sentence style. I changed the few that weren't to match/ Let me know if I missed any. Thanks. {Shawn}
    • [closed] reconsider order of sections & how Basic Structure Check fits...
      • comment {name}
      • From 17 Jan 2014 minutes:
        • <Howard> I'm happy with the order
        • Suzette: I am happy with this order. ... it seems consistent with the kinds of tests that might be run.
        • <yatil> I found the order to be alright.
        • <Sylvie> I am also happy with this order.
        • <hbj> me too
        • Sharron: I wonder if we should look at the minutes and see what Ian's point was about the order. I liked the fact that the Basic Structure Check was at the end it opened it up. [update: Shawn looked at 20 Dec minutes and doesn't see anything clear about it.]
        • Bim: Part of what we were doing was making the Easiest Easy Check the first things to do and give them easy wins.
        • Sharron: I seem to recall that it had to do with grouping structural things together, labeling things together, etc.

    Background

    [14 Dec 2016: Moved to Github Issue #59] that the third sentence under "Background" could be clearer. Currently: To check a couple details, you need to see the visual page or hear audio. Suggest: To perform a couple of the checks, you need to see the visual page or hear audio. {Bim}

    Page Title

    e1

    Shawn & Eric discuss

    Firefox: If the title bar isn't displayed, press Alt+V, T, M (or right-mouse click in the empty area after the tab and select Menu Bar), to show the title bar.
    [image? or not needed because earlier in the section?]

    • That doesn’t work on Mac OS X (and possibly on Linux, too). In my current Firefox (Nightly, 29.0a1 (2014-01-12)) there is no possibility to enable the title bar. {Eric}
      • What is the situation across versions? Right now we say "Currently Firefox, Safari, Opera, and some other browsers show the title by default." Do older version of Mac Firefox show the titlebar? Do recent versions of Windows Firefox not let you show a titlebar at all?
        • Just checked: Firefox seems to get more like Chrome on the mac with a new “skin” that’s currently in the beta. In current Firefox versions there is a title bar and I haven’t found a mechanism to hide it. {Eric}
    • I’d also recommend to guide the user through the menu if possible instead of keyboard shortcuts. {Eric}
      • I think if there's no title bar, there's also no menu bar? {Shawn}
        • The menu bar on a mac is not in the window but fixed on the top of the screen for all applications, so even if there is no title bar you still get the menu (and it looks like this). {Eric}
          • So what are the menu commands? :-) {Shawn}
    • [done] [illustrations] I don’t think we need another image here. {Eric}

    e2

    [done]

    Display the Add Bookmark dialog box with the title in it. In some browsers, press Ctrl+D.

    • Again that doesn’t work on OS X. In Firefox/Chrome you can activate the star button in the menubar. In all Browsers the combination of the cmd+D buttons work. {Eric}
      • We could change from "In some browsers, press Ctrl+D." to: "In some Windows browsers, press Ctrl+D. In some Mac browsers, press ⌘+D" ? ... um, let's wait and see what we decide to the broader issue, below. {Shawn}
    • I guess it would make sense to have a section in “Using these Easy Checks” which tells Mac users to use the cmd key instead of ctrl: “If you’re on a Mac, you need to use the cmd (⌘) key instead of the ctrl key for keyboard combinations.” {Eric}
    • [closed] Suggest changing wording under section To Change Page Titles with Different Browsers that says: "Display the add Bookmark dialog box with the title in it. In some browsers, press Ctrl+D." to "Use the Add Bookmark dialog box in order to display the title. In some browsers, press Ctrl+D."{Howard, 17 Jan 2014}
      Used wording from 17 Jan EOWG telecon. {Shawn}

    e3

    [done]

    IE: Press Shift+F10, select Properties. The title is shown in the Properties box.

    • This is also in the Firefox page properties when you right click onto the page and select “View Page Info” (alternative hit cmd/ctrl+I) in the “General” tab. Probably we can unify those tips somehow. {Eric}
      • Does this work in your version of FF?
        • In Windows FF 26: The Page Info dialog box doesn't have the title, and ctrl+I doesn't bring up the Page Info dialog box. :-({Shawn}
        • It is hard to find, but it is there {Eric}
        • If it's hard to find, then we probably don't want it in Easy Checks. :) {Shawn}

    Image alts

    wording tweak on alt for complex image

    [done]

    wording tweak. current draft:

    If the image has complex information — such as charts or graphs — the image should have a short alt text identifying what the image is about, and then the detailed description of the information should be provided elsewhere (for example, in a data table).

    • 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}
      • +1 {Andrew, 10 jan 2014}
    • How about a little more simple: "... the image should have a short alt text identifying the image, and then the detailed..." (wording based on 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}
        +1 - 'identifying' isn't clear; Denis' original (131217) is better {Andrew, 10 Jan 2014}
      • 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)." {Howard, 19 Dec, 2013}
    • 20 Dec minutes discussion
    • I figured out what I don't like about the suggestion: "describing the nature or purpose of the image" - "describing" I think is misleading as a common mistake is to over describe the visual beyond what is functions, and I'm not confident that "nature... of the image' will work well for non-native speakers.
      For now, how about go with the wording from the WAI Tutorials (EOWG draft, published draft):

      ...the image should have a short alt text to identify the image...

      This is a little different from the original and previous suggestions, and might be enough of a tweak to work for now? If we think it needs to be changed, let's do it in both places as part of the Images tutorial. {Shawn}

    new comments

    [Moved to GitHub Issue #60]

    • Shawn & Eric discuss:

      (For example, appropriate text alternative for a search button (search) would be "search", not "magnifying glass".)

      • This text is copied and pasted from the page and the magnifying glass is replaced with the alt text “search”, but it should read “magnifying glass” – even better would be a button with a magnifying glass and the alt text “button with magnifying glass”. {Eric}
      • (Also, very personal nitpicking, the magnifying glass image looks very pixelated here, I can search for a more professional looking one.) {Eric}
    • [done] tweaked it a bit at [http://www.w3.org/WAI/EO/Drafts/eval/checks#images Images

      Alt text is in the web page markup ("code"); you don't usually see it in the browser. Every image should have alt defined. If an image conveys information useful for interacting with or understanding the web page content, then it needs alt text. If an image is just decorative and people don't need to know about the image, it should have null alt (which looks like this in the markup: alt="" with no space between the quotes).

      • This is a long paragraph that is confusing, first “every image should have alt defined”, then only if it is useful for understanding and then it can also be null. What about changing the whole paragraph as such:

        • Usually you don’t see alt text in your browser, yet it is in the page’s markup, like so:

          <img src="…" alt="Alternative text">
          (the src points to the image)

          Every image should come with “alt” as noted above, yet the content (between the quotation marks) changes depending if the image conveys information useful for interacting with or understanding the web page content, then it needs alt text. If an image is just decorative and people don't need to know about the image, it should have null alt (alt="") so it is ignored by assistive technology.

          — We could then remove the alt attribute paragraph, too. {Eric}
          • {Eric} Rewording:

            Usually you won’t see alternative text for images in your browser, but you can find it in the page markup. It looks like this:

            <img src="…" alt="Alternative text">
            (the src points to the image file)

            Every image should have “alt” as noted above, the text in between quotation marks changes depending on the use of that particular image. If the image conveys information useful for interacting or understanding the web page content, then it needs alt text. If an image is just decorative and people don’t need to know about the image at all, it should have null alt (alt="") so it is ignored by assitive technology.

    • [done] markup code

      Alt text is in the web page markup ("code");

      • We already have told people that markup is code, so we don’t have to repeat this here, I think. {Eric}
        • What about for people who jump to this section without reading elsewhere? {Shawn}

    Headings

    • [done] get rid of quotes

      To make these work for everyone, the headings need to be "marked up" in the web page "code" (e.g., HTML).

      Suggested edit: “…need to be marked up in the web page code.” {Eric}

    • [closed] two h1s?

      Heading levels should have a meaningful hierarchy, e.g.: (…)

      Idea: Could/should we include an example with multiple headings level 1? {Eric}

      • reply: We want to keep Easy Checks as simple as possible so I don't think we want to complicate it with this issue. {Shawn}

    Contrast Ratio

    • [done] In the first sentence ("Some people cannot read text if there is not sufficient contrast between the text and background, for example, gray text on a light background"), maybe add the word "light" before gray? Some shades of gray are almost black. {Anna Belle}

    Keyboard access and visual focus

    • [done] In Mac browsers, enable keyboard navigation to all controls, which is usually a setting in Preferences. [@@ need detailed instructions (maybe new section "To check keyboard access in Mac browsers" or WAI-Engage wiki page?)]
      • To check keyboard access of a web site while using a Mac browser:
        • OSX pre-Mavericks: go to System Preferences -> Keyboard -> Keyboard Shortcuts -> in "Full Keyboard Access" section, check "All Controls" {Paul 10 January 2014}
        • OSX 10.9 Mavericks: go to System Preferences -> Keyboard -> Shortcuts -> All controls radio button {Paul 10 January 2014}

    Forms

    Forms section [The issues were resolved through extensive edits to the section.]

    • [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}

    Multimedia

    • [closed] As we mention YouTube we could also notice that their admin interface makes it really easy to transform automatic captions into proper ones. {Eric}
      But usually the automatic ones aren't good enough. Anyway, given this is Easy Checks, I don't think we would include such implementation info. {Shawn}
    • [closed] To enable keyboard navigability in YouTube on a Mac, first ensure that accessibility features have been turned on.
      • With "Mavericks" (the most current version of OSX), you need to enable assistive devices and assistive application support in System Preferences > "Security & Privacy." Select the Privacy tab. Select the checkboxes for the apps you want to control your computer.
      • With older versions of OSX, enable assistive devices and assistive application support in System Preferences > Universal Access > click the checkbox for Enable access for assistive devices.
      • With Chrome and Firefox, use the tab key to navigate to the YouTube video on the page. Tabbing will cycle through each control as follows: pause/play, mute/unmute, volume slider, view later button, tools (options under the tools button are not accessible to keyboard-only users).
      • With Firefox, you will need to click the YouTube video in order to tab through the controls.
      • With Safari, go into Preferences > Advanced > check the "Press Tab to highlight each item on a webpage" You will need to click the YouTube video in order to tab through the controls. checkbox {Paul, January 30, 2014}
    • [closed] To enable closed captions in YouTube on a Mac:
      • With Chrome (version 32), you cannot activate closed captions with a keyboard only. You must use a mouse and click the "cc" button inside the video player.
      • With Firefox (version 26), you cannot activate closed captions with a keyboard only. You must use a mouse and click the "cc" button inside the video player.
      • With Safari (version 7), you cannot activate closed captions with a keyboard only. You must use a mouse and click the "cc" button inside the video player. {Paul, January 30, 2014}

    Basic Structure Check

    [EOWG: please comment on: New Images showing linearized and changed display section (fyi: previous draft)

    • How is the text?
      • +1 {Sylvie, 25 February}
      • +1 {Vicki, 26 February}
      • ... {Name}
    • How are the images?
      • No opinion, abstain! {Sylvie, 25 February}
      • OK. Perhaps slightly larger would be nice but not essential.{Vicki, 26 February}
      • ... {Name}
    • Shall we leave this collapsed/expandable? Or have it always displayed? (Currently we cannot have it expanded by default but collapseable, afaik - right, Shadi?)
      • No opinion, abstain! {Sylvie, 25 February}
      • ... {Name}

    Next Steps

    • [done] 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}
      • may we could point to the tutorials for further information when completed. I also think we should give a hint in the (short) list, e.g. 'understandable links', 'table structural markup'. Re @@more - these are example and not a definitive list or a replacement for WCAG. {Andrew, 10 Jan 2014}
        • OPEN: Andrew & others, please suggest specific working! :-)
          • understandable links / data table structural markup / color used for meaning / flashing content that could cause seizures / page language declaration / enough time provided to read and use content {Andrew, 5 Feb 2014}
      • Robust things... (need to be more specific) {shawn}
        • More thorough evaluation ... {Andrew, 5 Feb 2014}
      • What about following?:
        How to check dynamic updates, How to do markup validation, How to use style sheets to change page view, How users can add Accessible content to the site, What to do with decorative images, What to do with layout tables {Anthony, 10 Jan 2014}
      • Changed to inline list per 17 Jan EOWG minutes




    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

    Suggested approach

    My thinking is that, while we are at CSUN, we find a few willing "victims" who are interested in web accessibility but maybe not extremely experienced. People who go to Whitney Quesenbery's Usability sessions, for example. Find a quiet place and get them to fire up their laptop and give the Easy Checks a whirl. Or bring your own laptop with tools already loaded so that the user will not have to download tools. Ask them to find a page and go through the checks. Take notes on their comments and successes and report back to EO. {Sharron - 5 March 2014}

    Task oriented user testing - it would be great if you could find one or two volunteers who would actually use the Easy Checks to carry out a check. In this case, it would be good to have two laptops available, one for reading the instructions and the other for checking a site or to have a set of the Easy checks in print form and then, observe how the user checks some pages of a site. {Vicki - 26 February}

    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)
    • Illustrations
      • Are there illustrations that are not needed? - e.g., they are too cluttering and not of sufficient value?
      • Are there places where we might want to add an illustration to provide clarification?
      • Specifically, for the instructions on using the toolbars, should we have images or not? Currently we have them in some places, but not others. We have them under "To check alt text with IE WAT" and "To check alt text with FF toolbar".
    • Resize Text - especially check if they understand the horizontal scrolling bits
    • markup
      • We have a "definition" of markup in the beginning (which some people will miss :) Then later we don't explain it, but we have "markup" with a subtle link to the definition. How does this work? Might we want to do differently?
      • A good place to check this is in the Headings section.
    • (low issue) 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

    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}

    archived old notes

    Move updates to main public page March 2014

    EOWG:

    1. OK to move internal version with illustrations and minor edits to Easy Checks main public page in March?
    2. OK to add other new illustrations and non-contentious minor edits to that main public page?

    (Note that the main public page still says "Draft".)

    • OK to move internal draft to Easy Checks Main public page. OK to add new illustrations and minor edits as needed while still in "Draft" status. {Sharron 06-March-2014}
    • +1 {Vicki 06-March-2014}
    • +1 {Andrew, 07-March-2014}
    • comment {name 00-mon-2014}

    Thoughts on whether we should announce the update before CSUN, or not add clutter with Tutorials announcement?

    • I am OK with either decision, announcing or not announcing Easy Checks update. I tend to think it useful to point to the Easy Checks update since it is significant, but understand that many people are already aware of Easy Checks and that we do want attention paid to the first Tutorial Draft. Maybe make a brief Easy Checks statement following the Tutorials announcement. But, again either way is OK with me.{Sharron 06-March-2014}
    • No comment {Vicki 06-March-2014}
    • Happy that this is announced, especially as I don't think we should announce the Tutorials at such an early stage {Andrew, 07-March-2014}
    • comment {name 00-mon-2014}

    previous versions, etc.

    Retrieved from "https://www.w3.org/WAI/EO/wiki/index.php?title=Easy_Checks&oldid=36523"