Prelim Eval 2013-May-30

From Education & Outreach

Nav: EOWG wiki main page > Evaluation Pages

This is an old archive of Easy Checks wiki page

Easy Checks - A First Look at Web Accessibility

Overall Comments

  • [EOWG please add comments] Any edits based on input from Tom J. (Wayne's forwarded e-mail)
    • comment {name}
  • 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}
    • 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}
    • with unapproved Editors' Draft
    • 10 May telecon: Try to get it in better shape next week then put up the sections that are ready
  • 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}



  • To see all illustrations, make sure to "expand all sections" because some of the illustrations are in collapsed sections. (however, keep in mind that most of the images will be collapsed by default)
  • Make sure to evaluate the images in context, that is, read the text around it and imagine you are a user.

Questions: How is the current use of images for illustrations throughout the draft? Too much? Not enough? Mostly helpful? Too cluttering? Feel free to comment in general, and on specific images.

  • comment {name}
  • EOWG 24 May:
    • Generally the conceptual images are useful for contrast and zoom; simply the page title images {done 24 May}.
    • Mixed perspectives on the images showing menu items and such. For some people they are just clutter, the word instructions are clear enough. For other people, the images really help.
    • For now:
      • Include images showing menu items and such judiciously — if in doubt, do not include an image.
      • Crop or gray out all unnecessary clutter in images. (for example, page-title-image has the content of the web page grayed out.)



  • terminology: "drop-down box", "drop-down list" ? "drop-downs" OK for short?
    • comment - "drop-down menu" or "drop-down list" for me{Vicki - May 31}
  • [done] Search throughout for 'users' and probably replace with 'people' {Shawn}
  • [closed] Suggestion: Change Firefox abbreviation from "FF" to "Fx" throughout.
    Rationale: Mozilla prefers it {Suzette}: "The preferred abbreviation is "Fx" or "fx"." from Mozilla FAQ {Shawn}
    • Quick research shows FF is more commonly used... Personally I don't fee strongly on this and am happy to go with whatever the group prefers.{Shawn}
    • Common usage was accepted {EOWG 10 May}
  • [closed] 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}
    • Suzette's usability tests answer my concerns so I am fine with leaving BAD sections in.{Anna Belle}
  • [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}

To be implemented:

  • [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
  • 30 May edit: significantly edited the first part.
  • 24 May edits: changed images.
  • 21 March edit: changed "Best practice is for titles to be "front-loaded" with the important and unique identifying information first..."


  • comment {name, 00 month}


  • [done - 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}
  • [closed. (I haven't been able to turn off the window title bar in Opera, with either the keyboard commands or menu options)] 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}
    This isn't working for me in Opera. I have not been able to turn off the window title bar at all -- in Windows. Perhaps it works on Mac? {Shawn, 30 May}
  • [done] 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 (EO WG)" {Andrew; 15/March}
    e-mail thread with more discussion
  • [closed] In "Tips" add picture of Page title for W3C home page: World Wide Web Consortium (W3C), Edit text "As in the example above, the title for the website home page typically contains just the website name. Best practice for all other page titles is to be "front-loaded" with the important and unique identifying information first.(followed by ACME bad and then good examples) {Suzette}
    • rationale: 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 title>Blog(or site) name than to have the blog or site name first {Suzette}
    • (fyi, current wording is just: "Best practice is for titles to be "front-loaded" with the important and unique identifying information first.")
    • We want to keep the tips short and succinct. (This is an evaluation guide, not a how-to tutorial.) Is it important to spend lots of words saying what the home page should be titled? Also, perhaps it's not worth the clutter to add an image here? {Shawn}
    • added an example relating to "home page" titles {EOWG - 10 May}
  • [closed] 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}
    [Resolved] 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 }
    instruct use of WAT for IE; do not instruct with FF toolbar {EOWG - 10 May}

  • [closed] Drop the first bullet from Tips: "There is flexibility on what makes a good page title. Some guidance is linked from the Related Resources section of Understanding Success Criteria 2.4.2." {EOWG - 10 May}

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.
    • 30 May edits: changed 'What to check for' from questions to statements to be consistent with other sections.
    • 21 March edits: combined instructions under each tool


    • comment {name}


    • [closed] In "What to Check for: Is the hierarchy meaningful?" Change to: Missing headings? For best practice, ideally the page starts with an "h1" — which is usually similar to the page title. All subsections can then start with h2, adding h3 and h4 subheadings as needed to create a meaningful hierarchy, with no missing levels. However this is not an absolute requirement. {Suzette}
      • rationale: 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}
      • fyi, current wording: "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, these are not absolute requirements.)"
      • How about... {Shawn}
      • discussed and addressed on 10 May {EOWG}
    • [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.
    • 10 May edit: changed heading from [Luminosity Contrast ("color contrast")] to [Contrast Ratio ("color contrast")]


    • [open] 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 for Mac] 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?


    • [done] STATUS 10 May - draft page is updated with heading "Contrast ratio ("color contrast")"
      • Ensure the word contrast and color (or colour for the Brits!) appear in the subtitle to help the intended audience who are not aware of luminosity. Note wording of WCAG 1.4.3: Contrast (Minimum): The visual presentation of text and images of text has a contrast ratio of ....Search could not find any mention of luminosity in this section.
      • rationale: 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.
      • (Good to see note from Andrew that there is a Mac version - any chance of a Linux version?) {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).


    • comment {name}

    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}

    Keyboard access, content order, visual focus

    Keyboard, etc. in WAI draft page



    • comment {name}
    • Illustrations of focus indication would be useful. Shall I send screen shots to the list or how to provide? {Sharron}
      Send them to Shawn & she'll upload them :) {Shawn}


    • [closed 31 May telecon] Sometimes, it can be helpful to open a drop down list with alt+down arrow key{Sylvie}
    • [closed] For consistency, I'd turn the following bullet into a question.
      "The focus indicator is clearly visible as you tab through the elements, that is, you can tell which element has focus, for example, because it is highlighted."
      Suggested change:
      "Is the focus indicator clearly visible as you tab through the elements (i.e., can you tell which element has focus, for example, because it is highlighted)?" {Vicki - May 26}
      changed all to statements for consistency {Shawn 30 May}
    • [closed] 1st paragraph, second sentence:
      Reads: "that reply on keyboard commands, such as voice input"
      Suggested change: "that reply to... " etc {Vicki - May 26}
      corrected "that reply on keyboard commands" to "that rely on keyboard commands" {Shawn 30 May}
    • [closed per EOWG telecon 24 May] Shall we call this just "Keyboard access and visual focus"? To simplify and because content order is just part of keyboard access? {Shawn}
    • [closed per EOWG telecon 24 May] The "To learn more..." section has "Example: web page template that does not enable keyboard access from the WAI Before and After Demo (BAD)" I tried using the BAD pages to test keyboard access but they didn't seem particularly useful. afaik, the tab focus disappears after the QUICKMENU drop down. So I'm not sure it's worth listing BAD here at all. Shall we delete it? {Shawn}
    • [done] I brought forward the text for 'What to do' (I just needed to see how it fitted together). {Suzette}
    • [done] 'What to look for' - should this be 'What to check for'? We have some inconsistencies in the headings eg section on Headings has 'what to check for' and then 'Heading checks' followed by a series of checks using different tools. {Suzette}
    • [done] Suggestion: The "What to look for" section looks like it needs some work to match the approach taken in the other sections - I'm happy to do some more work on this. {Suzette}
      Yup, it still needs work. Note the Status in the previous bullet "Draft in progress" :-) Work on it welcome! {Shawn}
    • 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.

    Forms, form labels, and error messages

    Forms in WAI draft page


    • 16 May: significant edits.
      Note: more updates coming


    • comment {name}
    • Suggest changing:

    Forms are used for interacting with websites and are common across the Web. They are used for activities such as search, login, registration, contact, booking, purchasing, banking, and interacting with government and other organizations.


    Forms are used for SUBMITTING DATA TO websites and are common across the Web. They are used for OPERATIONS such as search, login, registration, contact, booking, purchasing, banking, and interacting with government and other organizations. {Howard 23 May}

    • Suggest changing:

    Forms are made up of controls such as text entry fields, check boxes, radio buttons, drop-down boxes and finish with submit buttons.


    Forms CONSIST of data entry fields, including text fields, check boxes, radio buttons, drop-down boxes and controls, usually consisting of a submit button. {Howard 23 May}

    Actually, I think the introduction should take a different approach — not to introduce forms per se, but to introduce some of the accessibility issues with forms — like the other sections do. {Shawn 24 May}

    • Suggest changing:

    For longer or unusual forms, check for instructions.


    For long or complex forms, check for instructions.

    • Suggest deleting

    Instructions are usually needed to explain how to fill out the form.

    {Vicki 24 May}

    • Suggest changing:

    Are there instructions at appropriate places in the form (usually at the beginning and the start of discrete sections) that clearly explain how to fill out the form?


    Are the instructions positioned appropriately (usually at the beginning of the form and/or at the start of specific sections)?

    Do the instructions clearly explain how to fill out the form?

    • Suggest changing

    Are required fields explained in the instructions and clearly identified throughout the form?


    Are the required (mandatory) fields explained in the instructions and clearly identified?

    {Vicki 24 May}

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

    Multimedia (video, audio) alternatives

    Multimedia in WAI draft page



    • [EOWG add your thoughts] I suggest changing first paragraph from:
      If someone cannot hear, they cannot get audio information, unless it is provided in text. For example, the information in a podcast is totally unavailable to a person who is deaf, unless the podcast has captions or a transcript. If someone cannot see a video, they cannot get the visual information, unless it is provided in audio or text.
      Individuals with hearing loss or deafness cannot access the speech and audio content of multimedia or audio-only mediums unless provided through a visual format, such as text in the form of captions or transcripts. Multimedia should be accompanied with synchronized captions. A transcript may be used to provide access to audio-only formats, for example, a podcast.
      Individuals with visual impairments cannot access the visual information of a multimedia file without audio or text description.
      {Howard, 16 2013}
      • What's there now seems simpler and more direct than the suggested rewrite. {Shawn, 24 May}
      • comment {name}

    • [EOWG add your thoughts] I suggest changing "Auto-Start" under "What to Look for" from:
      It is best if audio (including background noise and video with sound) does not start automatically when a web page opens. If it does start automatically, it should either:
      * Stop after 3 seconds.
      * Include controls to pause or stop the audio.
      * Include controls to turn down the volume.
      III. Auto-start
      It is best practice that audio (including background noise and video with sound) not start automatically when a web page loads. If it does start automatically, it should do one of the following:
      • Stop after 3 seconds.
      • Include controls to pause or stop the audio.
      • Include controls to turn down the volume.
      {Howard, 16 2013}
      • What's there now seems simpler and more direct than the suggested rewrite. {Shawn, 24 May}
      • comment {name}

    • [done] With the current formatting, the heading structure and hierarchy is very unclear. For example, it's not clear that auto-start is a sub-heading of "What to look for". {Howard, 16 2013}
    • [done] I looked around for an example of good practice and went to which currently has a video on the home page. I propose text changes (IN CAPS) to:
      • [done] What to do: In other sections these are bulleted and not numbered.
      • [done] Step 1 Follow the steps above for keyboard access to ensure that the media player controls are labeled and KEYBOARD accessible.
      • [done] What to look for should probably be 'What to CHECK for'.
      • [done (moved it from above so not repetitive)] At the risk of repetition (but to make sure the message is not lost), I would suggest that there is a sub-heading for CONTROLS that repeats the need for controls to be labelled and selectable using the tab key.
      • [done (changed to "Auto-start control" since you don't have to avoid it all together] Suggest that Auto-start should be headed AVOID Auto-start (currently it is the first in the list and the only negative requirement - all the others are positive requirements eg captions, transcript and audio description)
      • [done] Heading levels - in my pdf print copy, it visually looks like the heading level for 'What to look for' is lower than for Auto-Start. In the on screen view they look like the same level. This might needed to be addressed for the whole document. {Suzette}
    • SK/MC case study - no multimedia present but may be added or linked to. Developer's podcasts are working well with his community and may be helping to overcome incidence of dyslexia in the tech community that the blog and podcast is aimed at. {Suzette}

    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

    Internal Notes

    SK/MC Case Study Notes

    {See also "SK/MC case study" throughout above for notes on specific sections}

    Notes added and referenced as SK/MC case study are the result of a one off case study evaluation. This is more by way of a formative test which raised a few usability issues that we might wish to discuss.

    The website (blog) tested is a hand built blog created using Geany and at the end of March 2013 was at a late stage of development/beta testing.

    The first page is a news page with a shallow banner and side bar content. New content will be regularly added to the top of the main content area on the news page. Other pages include About and Contact Page.

    The developer is primarily a Linux software developer with some website development experience. The tester participates in EOWG and has worked on some of the editing of Easy Checks. I know some of the issues but not all.

    Tools used:

    Comments have been added to the Wiki under the headings from the Easychecks document.

    General comments

    It was noted that IE tools wouldn't work on a Linux machine (as used by many developers, and also Mac). The developer noted the need for tools that are appropriate to the open source community, that tools such as IE WAT should be moved to an open source platform or that the open source community should be encouraged to participate in developing tools. In his work place he would have difficulty downloading tools and equally could not upload code to an online tool such as WAVE.

    Overall it was easy to follow the tests and explanations. On occasions the instructions for the WIMPS and keyboard shortcuts get a bit confused and could be improved with a minor change to the format. Eg where in Firefox you have to switch on both Outline>Show element tag names when outlining AND Outline>outline heading in order to both see where the heading is, and what tag is applied.

    The test exceeded the one hour set aside for this activity and was extended to 90 minutes. Part of this time was due to discussions as to what was required, making on the fly changes to code, adding notes to the code and filing a bug report on issues with null alt tag and making a few comparisons of best practice with BAD and GooglePlus.

    Design process - although EasyChecks is aimed at testing a finished website, is a website ever finished? Testing this late stage development meant that it was still possible to make modifications to the code. This would also fit with a use case whereby having caught and fixed a few obvious problems you could then proceed to a more rigorous expert testing process or user testing to catch and interpret the more complex issues.

    Fx not FF - Firefox states that its abbreviation should be Fx not FF.{Suzette}