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.


Easy Checks

From Education & Outreach
Revision as of 02:13, 19 February 2014 by Shawn (Talk | contribs)

Jump to: navigation, search

Nav: EOWG wiki main page > Evaluation Pages
[Old Web Accessibility Preliminary Evaluation 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. [done] publish it as an EOWG-approved Working Draft on Friday 29 December
  4. illustrations
    • Anna Belle... :-)
  5. usability testing
    • (waiting until illustrations are more updated)
  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}

[template for new comments]

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

Overall

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

Page Title

e1

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}
    • [EOWG] 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}
        • comment {name}
    • [EOWG] 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}
  • I’d also recommend to guide the user through the menu if possible instead of keyboard shortcuts. {Eric}
    • [EOWG] 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}
        • comment {name}
  • [illustrations] I don’t think we need another image here. {Eric}

e2

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}
      • comment {name}
  • 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}
    • [EOWG] Thoughts on how to handle this? {Shawn}
      • comment {name}

e3

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}
    • [EOWG] 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}
      • comment {name}

Image alts

wording tweak on alt for complex image

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 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}
      +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

new comments

  • [EOWG]
    (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}
  • [EOWG]
    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}
  • [EOWG]
    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.

Headings

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

    • [EOWG] Which do you think works better for novice readers? {Shawn}
      • comment {name}
  • [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

  • 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

  • [Paul, 10 Jan] 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?)]
    • comment {name}
  • 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

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

  • As we mention YouTube we could also notice that their admin interface makes it really easy to transform automatic captions into proper ones. {Eric}
  • 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}
  • 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

Next Steps

  • [Anthony, Helle, Andrew, everyone] 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}






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