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
(Image text alternatives ("alt text"))
(Image text alternatives ("alt text"))
Line 58: Line 58:
  
 
* To aid visual scanning I would bold bullet items in the tips section (and possibly the first sentence or phrase of each sub-bullet item) <span style="color:#808080;">{Howard}</span>
 
* To aid visual scanning I would bold bullet items in the tips section (and possibly the first sentence or phrase of each sub-bullet item) <span style="color:#808080;">{Howard}</span>
* Tips / Appropriate alt text / second bullet - change "Alt text depends on content" to "Alt text depends on context"<span style="color:#808080;">{Andrew, 15/March}</span>
+
* Tips / Appropriate alt text / second bullet - change "Alt text depends on content" to "Alt text depends on context" <span style="color:#808080;">{Andrew, 15/March}</span>
  
 
==Headings==
 
==Headings==

Revision as of 12:20, 15 March 2013

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


Easy Checks - A First Look at Web Accessibility

Introduction

Introduction in WAI draft page

Status:

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

Comments:

  • comment {name, date}
  • Get rid of comma in 3rd sentence under "WCAG Links" in "Using this page": "In the "Learn more from" sections of this page, there are links" {Howard, 3-14-13}
  • In the interest of visibility, I would have "Using this Page" expanded by default. Having it open gives more information about what's underneath. Otherwise, it's easy to miss the section and there's no link above in the content list to point you to it. This may be too high level but I found the header "Using this Page" unclear. I'd prefer "Using Quickchecks." Sorry I'm reading this material in depth for the first time. These are my reactions as a first time reader.{Howard, 3-14-13}
  • Suggest "There are other useful tools ..." becomes "There are many other useful tools ..." {Andrew, 15/March}
  • The h3 heading "Little Background" doesn't make much sense in telling what the following section contains {Andrew, 15/March}

Page title

Page title in WAI draft page

Status:

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

Comments:

  • [open] Suggest the alt-text on screen grabs include the browser name and version {Andrew}
    reply: I think it would add unnecessary clutter - lots of text and do people who cannot see the image care so much which browser & version? what do others think? {shawn}
    reply: I concur, I would leave it out {Howard}
    response: Let me change the suggestion to indicating this information with a title attribute - the images look different from what I an see, so hovering would show what browser & version was being illustrated {Andrew, 15/March}
  • [open] We should include FF web developer toolbar example too - 'Information' then 'View Page Information' opens a new window with the page title at the top {Andrew}
    reply: why? the page title is shown in the window title bar so why would you need to use the develop toolbar to get it? {shawn}
    response: allows people who can't easily see/interrogate the 'window title bar' to get quick access to the page title {Andrew; 15/March}
  • Title tips: is the visual example and tips inconsistent? Note that in Tips text "About Acme Web Solutions" (subpage then company name) is said to be better than "Acme Web Solutions, Inc. - About Us". But, in the visual from WAI the good example is: "Web Accessibility Initiative (WAI) - home page".(company name then subpage). Personally, in my visual world I find the WAI example order more useful when looking at tabs and in referring to history and bookmarks. One exception to that is when we are working on the WAI agenda, but this is the only time I have multiple pages open from the same organisation. {Suzette}
    And the EO page just has "Education and Outreach Working Group (EOWG)" {Andrew; 15/March}
  • comment {name}

Images for Page Title

  • To check page title - with IE WAT:
    <...image link here...>

Image text alternatives ("alt text")

alt text in WAI draft page

Status:

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

Comments:

  • comment {name}
  • To aid visual scanning I would bold bullet items in the tips section (and possibly the first sentence or phrase of each sub-bullet item) {Howard}
  • Tips / Appropriate alt text / second bullet - change "Alt text depends on content" to "Alt text depends on context" {Andrew, 15/March}

Headings

Headings in WAI draft page

Status:

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

Comments:

  • I found it confusing that the IE WAT, FF toolbar, & Any browser were split into two groups (outline and markup). I thought I was repeating myself or there was an editorial mistake at first. I would suggest combining all steps for each tool under the tool. {Anna Belle}
  • comment {name}
  • Under "What to check for" change "Are there headings marked up?" to "Are the headings marked up?" {Howard}
  • Change the subsection "Headings Checks" title to "Heading Checks" {Howard}
  • Under both bullet items "Non-visual check," "Are headings listed." needs a question mark instead of a period. {Howard}

Color contrast

Color contrast in WAI draft page

Status:

  • OPEN: Needs someone to fill in some details on using the tools. - Vicki will do it
  • OPEN: Needs some images. - Vicki will do it
  • Overall flow, instructions, text is complete.
  • 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:

  • [open EOWG] mention/discuss color blindness? {Andrew}
    reply: is that too much complication for an easy check? If you think not, please draft wording :) {Shawn}
  • 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}
  • comment {name}

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:

  • Draft in progress

Comments:

  • comment {name}

Forms, form labels, and error messages

Forms in WAI draft page

Status:

  • Draft in progress

Comments:

  • comment {name}

Multimedia (video, audio) alternatives

Multimedia in WAI draft page

Status:

  • Draft in progress

Comments:

  • comment {name}

Next Steps

[Status: Draft in progress - feel free to edit the text or add comments below.]

So, you've spent a little time getting a sense of the accessibility issues that need to be addressed, but what do you do next? How can you flag what you've discovered, while being sure that the information reaches those who can make the changes happen?

If you're a site visitor who doesn't work for the organization but wants to report accessibility-related concerns, you will likely want to reach out by using the site's contact form or by sending email to a "Webmaster" address. Of course, if you have a specific point of contact in the organization, starting with that person can be beneificial.

On the other hand, if you work for the organization that operates the site you've looked at, you might use a bug-tracking/helpdesk system to report your findings. Or you might decide it would be more effective to write a report in which you group problems and possible solutions in a way that makes sense within the company's structure.

Whether or not you work for the company that runs the site you've checked, you'll want to describe the issues clearly, including identifying the browser and any other tools you used. Providing as much detail as you can will help others replicate the issue and identify approaches to resolve it. For examples of recommendations we have developed to guide site visitors who experience difficulty accessing a web site, see a section of [ http://www.w3.org/WAI/users/inaccessible Contacting Organizations about Inaccessible Websites] called "Describe the Problem." These Sources for More Information will help your colleagues familiarize themselves with additional references for more details about problems and solutions.   When it's time to conduct a more thorough evaluation,either internally or by hiring a qualified contractor, the [WCAG-EM Evaluation Methodology Overview] (coming soon) and accompanying documents will help you or others develop plans as we all work together to provide a more accessible web for all.




EOWG comments on Next Steps

  • comment {name}
  • My apologies if I'm not doing this correctly - I don't see another way of entering a comment. I think this reads very nicely. I had to pause briefly at "see a section of ..." to determine what I was supposed to look at first and the relationship to the larger document. I'm not sure however that it could be rearranged to be more clear. Perhaps switching the two urls around to read:

For examples of recommendations we have developed to guide site visitors who experience difficulty accessing a web site,see "Describe the Problem" (also embed url in text) [1], a subsection of "Contacting Organizations about Inaccessible Websites" (also embed url in text) [ http://www.w3.org/WAI/users/inaccessible ].(Howard)

  • Thinking about how people read on the web - via skimming - I wondered if some small sub-headers would be helpful, such as "Reporting about an external site" above the second paragraph or "Preparing your report" above paragraph 3, "A More Thorough Evaluation" above paragraph 4.(Howard)



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

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}
  • When I was using the document to analyze a major redesign, I found the "To practice ... in BAD" sections a bit disruptive. But that may just be me. {Anna Belle}

Internal Notes

Important Note: For this draft we have some tool-specific guidance. However, there are potential issues with vendor-neutraility and we might need to address this a different way — for example, moving tool-specific guidance to WebPlatform Docs or the WAI-Engage wiki where people can easily add other tools.