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
(Keyboard access, content order, visual focus: using tabs)
(Forms, form labels, and error messages)
Line 181: Line 181:
* SK/MC case study - Good to have forms, but new post form was not available for public view. Really need to have a developers toolbar or IE WAT or WAVE to test this easily. Developer could not access tools from his machine and I could not access the page from my machine! We looked at BAD in order to consider the principles, having an example really helps. <span style="color:#808080;">{Suzette}</span>
* comment <span style="color:#808080;">{name}</span>
* comment <span style="color:#808080;">{name}</span>

Revision as of 13:31, 6 May 2013

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

Easy Checks - A First Look at Web Accessibility

Overall Comments

  • [EOWG add your thoughts] This Easy Checks page is to replace the old Preliminary Review page. Is the new page in good enough shape yet that we can replace the old page -- leaving on the new page [Draft] in the title and h1 ? {Shawn}
    • ...{name}
  • [EOWG add your thoughts] 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}
    • We thought that newbies might find it helpful in some cases to see how things should and shouldn't look. I think this might be helpful for things like the headings one. Right now we have it 3 times in the doc. I mildy prefer to keep theses sections; however, I could easily be convinced to removed them. :) {shawn}
    • SK/MC case study: BAD was useful for checking correct format and HTML in Forms. We were not able to expose the forms because they were still in development on a Linux machine which couldn't run the IE WAT tool. Equally if this had been a work project would not be allowed to expose development to outsiders for all sorts of security reasons.(I'll summarise the case study details at the end, this is work in progress){Suzette}
    • ...{name}
  • [EOWG add your thoughts] Consider moving the sections we are comfortable with the drafts of across to permanent URI with place holder headings for the sections we still want to work on a bit more {Andrew - 4 May}


    • [closed] According the Chicago Manual of Style Rule 6.8: "Periods and commas precede closing quotation marks, whether double or single." The way I did the previous sentence conforms to that. Things like "not "magnifying glass"." don't. We use this pattern a lot, but that means we're consistent. It just may be consistently wrong. OTOH, it would be an incorrect pattern in code, so coders may cringe if we adopt the Chicago rule. {Anna Belle}
      reply: "punctuation outside quoted terms" is now documented in Style {Shawn}


    Introduction in WAI draft page


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


    • comment {name, date}
    • [expanded by default: will do. heading: done - changed to "Using the Easy Checks"] 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}


    • [closed] 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}
      We generally put commas after introductory prepositional clauses, especially in sentences that are a bit long like this one. added to Style, Punctuation {Shawn}
      Ok by me {Howard, 3-23-13}
    • [done] The h3 heading "Little Background" doesn't make much sense in telling what the following section contains {Andrew, 15/March} tried "A Little Background". welcome other suggestions! What about just "Background"? {Andrew, 22/March}
    • [done] Suggest "assistive technologies (AT) is software or hardware that people with disabilities use ..." should be "assistive technologies (AT) are software or hardware products that people with disabilities use ..." {Andrew, 22/March}
    • [done] Suggest "There are other useful tools ..." becomes "There are many other useful tools ..." {Andrew, 15/March}

    Page title

    Page title in WAI draft page


    • Complete, ready for detailed review.
    • OPEN: a couple things listed in "To be implemented" below
    • 21 March edit: changed "Best practice is for titles to be "front-loaded" with the important and unique identifying information first..."


    • [EOWG] 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}
      re: I still don't get why we would add the steps to use the tool, when all they have to do is look at it. Maybe you just feel like FF instructions are missing? I tried adding: "To check page title with Firefox and most browsers..." to see if that helps. :-) {Shawn}
      I can hover the mouse in IE9 and Chrome v25 too and the earlier Windows IE versions already display in the title-bar too, so why give IE-WAT instructions? {Andrew, 22/March}
      [EOWG open] How do you get the title in IE or Chrome without a mouse? (unless you use the IE WAT toolbar) {Shawn}
      Listen to it, or use a tool. Also, how long will FF keep the title display as IE has dropped it and Chrome doesn't have it? BUT, I can live without FF Toolbar instructions if that is consensus. {Andrew, 22/March}
      Less is more sometimes. This is supposed to be an "EASY CHECKS". I think we provide ample and clear examples of how to find the title - it is clear that it is either found in the tab or in the window title depending on the browser. {Howard, 23/March }
    • [open] I wonder if the line "Most browsers have a window title bar, except Chrome and IE 9 and later" should have a qualifier. Firefox and Opera only show the window title bar if you have the main menu displayed (see under "tool bars" under "view", which is not the default (I believe). In Opera, it's referred to as "main bar" under "toolbars". We should probably mention the instructions for showing the window title bar in Opera and Firefox. {Howard, 22/March }
      Opera - I have the latest version of Opera and I don't even know how to hide the title. (I have Main Bar not visible.) I think the title is always visible in Opera.{Shawn}
      Firefox - I added instructions for how to show the title (via menu bar) under "To check page title with Firefox and most browsers"{Shawn}
      IE & Chrome - Is there a way to show the title bar?{Shawn}
      Not as far as I've been able to find {Andrew, 22/March}
      There is not a way to show the title in Chrome or I.E. without an add-on (verified this via some research). The Opera title (at least in Windows), can be turned on and off. It is displayed when the "main bar" is active. To toggle it on or off in Opera: alt (press & release), 'o', 'm'. Shawn, I think what you have for Firefox is good. You might want to add the instructions for Opera also. Under the "To check page title with Firefox and most browsers" you could add another bullet item for Opera with the instructions I just entered above. {Howard, 3-23-13}
  • SK/MC case study Title of Home page compared with other pages. It would be helpful to be more explicit about the naming strategy for the home page as compared with the strategy for inner pages. Confirmed that in development terms it is easier to use the format Page name>Blog(or site) name than to have the blog or site name first{name}

  • To be implemented:

    • [to be implemented: for images, add title with browser & version] 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 see on my setup, so hovering would show what browser & version was being illustrated {Andrew, 15/March}
    • [to do: change visual example to Easy Checks page] 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}
      e-mail thread with more discussion

    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


    • Complete, ready for detailed review.
    • only minor edits since February


  • SK/MC case study: Support of null attribute - The blog author's photo was decided to be non-essential and alt-text changed to Null. However, the Markdown framework that generated the sidebar HTML would not generate alt="" when left empty. This is an authoring tool issue and a bug report was filed{Suzette}
    • comment {name}


    • [done - also outdented all so no more nested list & bolded the intro phrase] 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}
    • [done] Tips / Appropriate alt text / second bullet - change "Alt text depends on content" to "Alt text depends on context" {Andrew, 15/March}


    Headings in WAI draft page


    • Complete, ready for detailed review.
    • 21 March edits: combined instructions under each tool


  • SK/MC case study: Is H1 essential? H1 was omitted - this was much more obvious with Firefox Information>View document outline which listed H1 as missing. Whereas the other Firefox and IE WAT options identified the headings that were present. The missing H1 was discussed. The blog home page potentially repeats the same text in three places: page title, banner and H1. This raised the question as to whether the H1 was redundant and could be omitted, or otherwise not displayed visually? Is the home page a different use case to the inner pages, for example I don't think people usually use Home Page as H1 even if it is the default page title? (see also Page title){Suzette}
  • * comment {Suzette}


    • [closed] To quote: "Is the hierarchy meaningful? (Ideally the page starts with an "h1" — which is usually similar to the page title — and does not skip levels; however, this is not an absolute requirement)." Following an enquiry from my son who is hand coding a blog: does "this" refer to the requirement to always have an h1 heading, or the similarity of the text content to the page title? In his blog it looks like is is trying to have a banner with his identity followed by a series of weekly blog posts that have h2 headings. He has asked whether he needs to have an h1. By way of profile he is a working open source developer and programmer with a positive approach to accessibility - he would just like to get it right.{Suzette}
      Changed the sentence to: "(Ideally the page starts with an "h1" — which is usually similar to the page title — and does not skip levels; however, these are not absolute requirements.)" {Shawn}
    • [closed] Change the subsection "Headings Checks" title to "Heading Checks" {Howard}
      response: On most pages there should be multiple headings. The title of the overall section is "Headings" plural. OK to leave it plural here, too? {shawn}
      Ok with me {Howard 23/March}
    • [done] 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}
      I concur with grouping tests by tool {Andrew, 15/March}
    • [closed - We indeed want to ask "are there headings marked up" here. added clarification: "(In almost all pages there should be at least one.)] Under "What to check for" change "Are there headings marked up?" to "Are the headings marked up?" {Howard}
    • [done] Under both bullet items "Non-visual check," "Are headings listed." needs a question mark instead of a period. {Howard}

    Luminosity Contrast

    Visual contrast in WAI draft page


    • Overall flow, instructions, text is complete and ready for review.
    • OPEN: Needs someone to fill in some details on using the tools. - Vicki will do it
    • CLOSED: Needs some images. - Vicki sent to Shawn 22.3.2013
    • 22 March edit: changed heading to Luminosity Contrast ("color contrast")
    • 21 March edits:
      • changed heading to Visual contrast ("color contrast", luminosity contrast)
      • tweaked wording a bit and added: This accessibility requirement is sometimes called sufficient "color contrast"; however, that is incorrect — technically it's "luminosity contrast".
    • 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.


    • [open EOWG] 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}
      reply: a mac version is available - {Andrew, 15/March}
      Questions: Is "you don't need to install it so should be able to do even in environments where you cannot install software." true for that TPG Windows & Mac versions as well? The current link goes to Vision Australia page with "Color Contrast Analyzer". The TPG version is called "Contrast Analyser" - which is better. Should we just point to that one?
      Reply: The CA and CCA are the same - when installed, the CA2.2a from TPG is actually 'Colour Contrast Analyser version 2.2a'. Also, the TPG and the Vision Australia downloads are the same tool - it was originally developed at Vision Australia then Steve moved it to TPG when he moved - VA retain up-to-dates version on their site. I don't know if the Mac version needs to be 'installed' or not. {Andrew, 22/March}
      [open action] Someone please check if "you don't need to install it so should be able to do even in environments where you cannot install software." is true for that TPG Windows & Mac versions?
    • SK/MC case study: Luminosity? This was not a known term. Design thinking was in terms of colour selection for text and background and the contrast between the two - colour contrast! Switched to IE in order to access Juicy Studio via WAT. IE is a non-preferred browser for the open source community and not available to the developer. Eye dropper works well for those who like the visual imagery. The 'skip to content' link used white on dark grey and was hidden unless tabbing or listening. It showed up in the table version of the test but appeared to be incorrectly identified, although the developer was better at understanding it in relation to how he had written his HTML. {Suzette}


    • [closed] mention/discuss color blindness? {Andrew}
      reply: is that too much complication for an easy check? If you think not, please draft wording :) {Shawn}
      response: we decided earlier in the year that colour blind issues complicated this section (so I'll accept that we'll ignore 9% of the Caucasian population for now) {Andrew, 15/March}


    Zoom in WAI draft page


    • 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: SK/MC case study

    • SK/MC case study - Mobile friendly zoom - the site was designed to be mobile and tablet friendly. I used a combination of Firefox and NoSquint to control zoom and text resize - OK up to 200% at which point some overlap was occurring. Tech comment: because of Media Queries the CSS was only applied when the browser was above 900 pixels. When zooming above 200% the CSS disappeared meaning that Firefox was reporting that the browser size had gone under 900 pixels. Additional comment: recently found the Ipad and Safari feature where you can centre the story you are reading to the width of your Ipad and zoom from there. It all stays within the screen width. I really like that for my visual needs. {Suzette}
    • comment {name}

    Keyboard access, content order, visual focus

    Keyboard, etc. in WAI draft page


    • Draft in progress


    • comment {name}
    • SK/MC case study - Tab order worked well, including with the hidden links. Useful to add that shift tab allows you to go backwards. One example of 'occluded' focus indicator - where the underline link to the logo was partially overlapping the border to the banner. Occlude is a relatively uncommon word - partially hidden or overlapping might be easier. Noted no reference made to picture links - while not used on the website being tested it is something that could catch a novice unawares, although a developer would be well aware of having used an image as a function. .{Suzette}

    Forms, form labels, and error messages

    Forms in WAI draft page


    • Draft in progress


    • SK/MC case study - Good to have forms, but new post form was not available for public view. Really need to have a developers toolbar or IE WAT or WAVE to test this easily. Developer could not access tools from his machine and I could not access the page from my machine! We looked at BAD in order to consider the principles, having an example really helps. {Suzette}
    • comment {name}

    Multimedia (video, audio) alternatives

    Multimedia in WAI draft page


    • Complete, ready for detailed review.
    • [EOWG review updated multimedia section] 21 March: significant edits.
      EOWG: Feel free to suggest major changes. You can copy some or all of the text here and edit it.


    • comment {name}

    Next Steps


    • rough draft in progress
    • [EOWG review] 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 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 Website Accessibility Conformance Evaluation Methodology (WCAG-EM) 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) [ ]. {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}
      I agree subheadings might help. I think this section still needs work and whomever does that can consider subheadings. :) {Shawn}


    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}

    Internal Notes

    To Do

    Ask Identifying Web Accessibility Issues to link to Easy Checks when it's more done.