Prelim Eval 2013-March-7

From Education & Outreach

Nav: EOWG wiki main page > Evaluation Pages 

This is an old archive of Easy Checks


Contents

[Thanks to #Contributors!]

Introduction

Introduction in WAI draft page

EOWG Comments on the Introduction

  • [done - changed] editor's discretion:section tools.
    First sentence:
    "Most of these checks you can do with any browser, that is, you do not need to download anything."
    Are the words in the right order in this sentence or should it be:
    "You can do most of these checks with any browser, that is, you do not need to download anything"? {Sylvie}
  • [done - this was from the wiki to HTMl conversion -- it added title to all links with the URI. I've removed them. good catch!]Clarity of links:
    It is not easy for the readers to read the links to the different tools as http text. May be the name of the tool/browser would be more useful?
    Example: Link text:
    "http://www.mozilla.org/en-US/firefox/new/".
    Or:
    "https://addons.mozilla.org/en-US/firefox/addon/web-developer/add-on."
    The link text questions seems to concern all the documents linked on this page. {Sylvie}
  • [done] In Introduction, heading 3 "little background", third bullet about things you should know:
    Actual text: "screen readers read aloud the information in a web page. They are used by people who are blind and by some people with reading disabilities."
    During a training, someone told us that he thought a screeen reader was a person reading the content of the screen. Therefore, I suggest that for people who don't know this term one could write that screen readers are a piece of software. This would then read:
    "screen readers are programs/piece of software that read aloud the information in a web page. They are used by people who are blind and by some people with reading disabilities." {Sylvie February, 25 2013}

Page title

Page title in WAI draft page

EOWG Notes on Page Title

  • [done] the shortcut with the WAT toolbar is no direct one:
    You first have to press ctrl+alt+6, then press down arrow key once or type the first menu letter, maybe H for the English version of the toolbar? {Sylvie} [Thanks, Sylvie! I added it. {Shawn}]
  • [add to wish list 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}
  • [done? edited to simplify] The text says: "Most browsers have a window title bar by default, except Chrome and IE versions 9 and later. In those browsers, and most others, you can see the full page title by hovering over the tab".
    Suggested text: "Many browsers have a window title bar and tabs, whereas others, such as Chrome and IE versions 9 and above, use tabs only to display the page title. For browsers with tabs only hover over the tab to view the full page title" {Vicki}.
  • [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}
  • [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}
    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}
  • 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

EOWG Notes on alt text

  • [done? "Some people prefer most images to have more detailed description; and others prefer much less description."] Text reads: "Some people prefer more description of more images; and others prefer less description."
    Suggested simplified wording: "Some people prefer more descriptive text, others prefer less". or "Some people prefer more description of images, others prefer less." I would remove the "more" of "more images" {Vicki}
    The issue is that for a given image, some people think there should be no alt at all, some think there should be brief alt, and some think there should be detailed alt. I think your re-wording misses that some people want some images to have no description at all, whereas others think those images should have some description. I tried another edit in between. :-) {shawn}
  • [done, with slight tweak.] Last paragraph. Text reads: (So "alt tag" is technically incorrect; it's "alt attribute", or you can say "alt text".)
    Minor editorial comment. Suggested text: (So "alt tag" is technically incorrect; "alt attribute" would be the correct term or you can say "alt text".) {Vicki}
  • [done] Editorial plus typo comment: Text reads: "The first one is easiest of you have the WAT toolbar." Corrected text: "The first one is the easiest if you have the WAT toolbar.". {Vicki}
  • [done] First check, point 2.: Guidance indicating color "...on a tan background." I think this might depend on the browser version and also the resolution. My version, for example, shows a pinkish background. Perhaps, you could say "... on a colored background". {Vicki}
  • [done] First check, point 4.: Editorial."... Tips below." The Tips are above. {Vicki}
  • [open EOWG] Finally, I'm mulling over the term "inappropriate alt text". Would that be the correct term? {Vicki}
    other ideas?
  • comment {name}

Keyboard Access {Andrew}

[done - add to WAI draft page 20 Feb {Shawn}]

  • To check alt text - with IE WAT {Andrew}
    • ctrl-alt-4, then arrow down to 'show images' which displays the alt-text adjacent to the image
  • To check alt text - with FF toolbar
    • Alt + 'T' for "Tools", then 'W' for "Web Developer Extension", then 'I' "Images", then 'O' for "Outline Images", then 'A' for "Outline Images Without Alt Attributes"
    • Alt + 'T' for "Tools", then 'W' for "Web Developer Extension", then 'I' "Images", then 'A' for "Display Alt Attributes"

Headings

Headings in WAI draft page

EOWG Notes on Headings

  • [done] heading h4: "To try checking headings in BAD"
    There seems to be one or two words too much:
    "Follow the one of the instructions under "To check headings outline" above"
    Suggestion:
    "Follow one of the instructions under "To check headings outline" above" {Sylvie}
  • comment {name}


Keyboard access {Andrew}:

[done - add to WAI draft page 20 Feb {Shawn}]

  • To check headings outline - with IE WAT
    • Ctrl + 6, then down arrow to "Heading Structure"
  • To check headings outline - with FF toolbar
    • Alt + T, then 'W' for "Web Developer Extension", then 'I' for "Information", then 'm' for "View Document Outline"
  • To show heading markup in the page - with IE WAT
    • Ctrl + 6, then down arrow to "Headings"
  • To show heading markup in the page - with FF toolbar
    • Alt + T for "Tools", then 'W' for "Web Developer Extension", then 'O' for "Outline", then 'S' for "Show Element Tags Names When Outlining"
    • Alt + T for "Tools", then 'W' for "Web Developer Extension", then 'O' for "Outline", then 'H' for "Outline Headings"

Color contrast

Color contrast in WAI draft page


EOWG Notes on Color Contrast

  • mention/discuss color blindness? {Andrew}
  • technical conflict between 'contrast' and 'luminosity' {Shadi}

Suggestion from SAZ:

[[ Some people cannot read text if there is not sufficient contrast between the text and background, for example, light gray text on a light background. High contrast (for example, dark text on light background or bright text on dark background) is required by some people with visual impairments, including many older people who lose contrast sensitivity from ageing. [image low: gray on light; image: black on white; image: yellow on black]

While some people need high contrast, strong lighting (luminosity) can be glaring, distracting, and make the text difficult to read. Web browsers should allow people to change the color of text and background, and web pages need to work when people change these colors.

In addition, web pages should have a default minimum contrast ratio of at least 4.5:1 for normal-size text. The instructions below show you how to check contrast ratios for a web page. ]]

back to Contents

Zoom

Zoome in WAi draft page

EOWG notes on zoom

  • comment {name}



back to contents

Keyboard access, content order, visual focus

EOWG notes - importance: HIGH.
5min: maybe.
15min: yes, at least part of it.
Without visual rendering: @@

Many people do not use the mouse and rely on the keyboard to interact with the Web. While screen reader users rely on the keyboard, they are not the only ones. In addition, sighted users with mobility impairments may rely on the keyboard or have assistive technologies that are controlled through keyboard actions. Without using a mouse, a user must be able to make visible, logical progress through the page elements, including link activation, form inputs, media controls, and other user interface components.

What To Do

In browsers with full support of keyboard navigation, including Firefox, Chrome,IE, and Safari do the following:

  • Click in the address bar, then put your mouse aside and don't use it.
  • Press the 'tab' key to move through the interactive elements on the page.
  • For subsequent movement within elements, such as select boxes or menu bars, press the arrow keys
  • To select a specific item within an element, press the Enter key or Space bar.

What To Look For

  • Can you tab to all the elements, including links, form fields, buttons, and media player controls? Are there any actions you can't get to (e.g., if they are only available on mouse hover or click)?
  • Does the tab order follow the logical reading order, top to bottom, left to right in sequence?
  • Watch as you tab through the elements to verify that the focus indicator is clearly visible - that you can visually determine where the focus has currently landed. (Note that common failures occur when the default focus indicator is turned off in CSS or when the element is styled with borders that occlude the focus indicator.)
  • Verify that any visual changes that occur with mouse hover also are triggered with keyboard focus
  • Can you tab away from all elements that you can tab to and continue tabbing through to the end of the page, circling back again to the top? (e.g. you don't get stuck anywhere and can't move on - known as a "keyboard trap")
  • If there is a drop-down list (for example, for choosing from a select box or navigation to another menu-listed page)
    • When tabbing into the drop-down box, can you use the down/up arrow keys to move through the options?
    • When the listed content receives focus, are items indicated but not selected automatically? Selection should occur only when user signifies choice through additional keyboard action (usually Enter or Space bar)

References


back to contents

Multimedia (video, audio) alternatives

in WAI draft page

EOWG Notes on Multimedia


back to contents

Forms, form labels, and error messages

in WAI draft page

Next Steps

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 Notes on Next Steps

  • comment {name}


Contributors

Thanks to:

  • 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


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.

Retrieved from "https://www.w3.org/WAI/EO/wiki/index.php?title=Prelim_Eval_2013-March-7&oldid=4127"