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.


WCAG-EM review

From Education & Outreach
Revision as of 09:54, 11 October 2012 by Skeith (Talk | contribs)

Jump to: navigation, search

Nav: EOWG wiki main page

Links:

Reminder: EOWG will focus on the types of questions below. If you have comments on specific technical points in the document, you can submit them directly yourself -- that is, e-mail them to public-wai-evaltf@w3.org by 20 October.
If you're not sure, feel free to put your comments here and the Group will decide if they are ones you should send yourself.

WCAG-EM Working Group asked the questions below for consideration and comment from EOWG.

(Note: We plan to separately provide guidance for the developers of evaluation tools.)

Readability & Usability

What specific revisions will make the document more readable and usable?

  • linked terms distracting- Every time a term is mentioned, there's a link to the definition e.g. "web pages",websites, I find this quite distracting and I think it reduces the readability {Vicki}.
    Strongly agree. Some ideas: just link it the first time in the document, or a new section. OR provide an option for users to turn off these links. {shawn}
  • linked references in sentences - the linked reference (e.g. "3.5 Step 5: Report the Evaluation Findings") in the middle of a sentence is also a little distracting but alas... I have no suggestion to offer to include it seamlessly {Vicki}
  • examples matching use cases - readability, section 1.1 scope and 1.2 audience. I think this is a difficult read for the intended audience. To improve usability I would suggest there is a need for better tailored use cases that match 1.2 and are then addressed consistently. There seem to be some examples included about commerce but I think it needs to use a better defined range - that better capture the context of the audience be it large scale government sites, large commercial sites, banks and utilities, and big agencies through to smaller operators eg a local school, a local charity, small organic food retailer. {Suzette}
  • comment {name}

Scope

Is it clear that this set of methodologies is only for websites after they are built and does not address methodologies that might be used prior to and during development? If not, please suggest ways to clarify the scope.

  • Given that the title is about Compliance evaluation, I have no problem with clarifying that the scope is what educationalists call summative assessment (like the final exam!) rather that formative assessment (feedback you can learn from). I noted a number of mentions in the opening sections about the benefits or effects of iterative testing during the design process. My suggestion is to keep the two types of testing separate because they relate to substantially different scenarios. Developers probably should not do their own formal compliance testing. I would suggest that the EM has a short paragraph to discuss the difference so that the reader is aware of this and can chose whether the Compliance EM document is relevant or if they need to go to the less formal 'Design_and_ Evaluation' section. {Suzette}
  • comment {name}
  • </ul>

    Evaluate throughout

    How should we communicate the importance of evaluating throughout website development, not just at the end?

    • comment {name}

    Missing?

    Are there any major considerations that we have overlooked or misrepresented?

    • Updates, maintenance, drift: An accessibility audit is static - a snapshot in time. By contrast, contemporary websites are organic - constantly evolving and growing. New material and novel features can be added by people who were not part of the original development team and these authors may have very limited editorial skills, and knowledge of development. As part of EM, I would suggest that that we should make a strong case for planned reviews to maintain standards and avoid the effect of drift that has been observed by researchers. {Suzette}
    • comment {name}

    Related material

    How much should we refer to and link to existing material as reference and how much should we include directly in the new material? Balance the inconvenience of jumping back and forth between existing documents against our reluctance to unnecessarily duplicate information.
    How should we align the WCAG-EM work with the Preliminary Evaluation document now in process at EOWG?
    What should the Conformance Evaluation page be in relation to WCAG-EM?
    (see also Eval Analysis)

    • comment {name}

    Other

    • [Very Important] Methodology Requirement 1.d - This requirement appears to claim that the website owner and evaluator are free to choose which users may be excluded. Human rights do not work that way. What reasonable base technologies are required for conformance? This is particularly disturbing within the context of intranets where employers may choose to limit users to assistive technologies the employer can purchase cheaply. The note at the end is not sufficient.
      Example, many sites prescribe large print with high contrast to be a universal cure for low vision. This discounts the need for albinos to have lower luminosity. Without high luminosity, high contrast is not possible. {Wayne Dick}
    • [important] 3.1.5 Step d - appeared to invite employer determined prescription of assistive techonolgy and accessibility support. The result will be employer defined necessary employment discrimination. {Wayne Dick}
    • [minor] Relied Upon - Just hangs there without inclusion in the context of accessibility supported. {Wayne Dick}
    • [Med] The note to (Web Applications): It may not be feasible to exhaustively examine all possible settings, but sampling should apply just as any website. {Wayne Dick}
    • 3.1.5 Step 3. The evaluation commissioner, must be informed that if the self defined sufficient techniques are used then a future accessibility audit may ask for a proof of sufficiency. {Wayne Dick}
    • Throughout 3.1.5 PDF and Silver light are basic web technologies. They are no more technologie than docx or raw text. They as basic web technologies. The accessibility open question.
      This issue is particularly important if this document is going to be normative. I do specific reference to Adobe or Microsoft products as basic web technologies is serious vendor preference. {Wayne Dick}
    • 3.3 Step 3: Select a Representative Sample, (First sentence) "While ideally every web page of a web site is evaluated, usually this is not possible on most web sites."
      I think it is too strong to say "usually this is not possible". It may sound like we are contradicting what we are hoping to achieve.
      Suggested text: "While ideally every web page of a website should be evaluated, this may not be possible for very large websites." {Vicki}
    • Responding to the term "with reasonable confidence": I have no problem with the term. Alternatively, if the above term is a point of discussion, you could simply modify the sentence to "that is representative of the entire target website". {Vicki}
    • 3.3 Step 3: Select a Representative Sample - website with many heterogeneous sub-university example, the sample selection include users. Focus groups are an effective probably necessary.
      Large heterogenous sites behave more like a set of independent sites placed under one URL. As such it is important to organize focus groups within the different autonomous site owners to determine usage patterns and prioritize pages for evaluation. When organizing the CSU System, 23 Campuses, each having more than 50 academic departments, and more administrative departments, we found that the IT unit could not get a handle on usage patterns on its own. Individual site owners had to give direct input on priority and usage. Example: At CSU Long Beach the Computer Science lab invokes the Computer Science Department Website every time a student logs into a lab machine. That makes the Computer Science Department the most referenced site on the Campus. But it is not the most important. {Wayne Dick}
    • 2.5 Involving Users (Optional) Second last sentence. "While not required, it is strongly recommended to involve real people covering a wide range of abilities...."
      Suggest removing "real". {Vicki}
    • 3.1.4 Methodology Requirement 1.d: Third paragraph: second last sentence. "For example, ….., then the website is effectively not accessible for some users."
      Suggest adding something about conformance for emphasis e.g., "and therefore does not conform to the specified conformance level of WCAG 2.0. (3.1.3 Step 1.c.)" {Vicki}
    • Feedback requested on the definition on "Common Functionality". Having read through the document, I don’t have a problem with the term "common functionality. However, it might pose a question mark to some. Therefore, I’ve put forth a few options below depending on what you mean and if you wish to be more specific:
      If it is the general functionality of the site, you could simply leave out the word "common" or use "basic functionality"
      If "common functionality" has a more technical connotation (referring to the style sheets, javascript, classes, i.e., the technical mandatory requirements for multiple device support and functionality), leave it as "common"
      Another suggestion in the line of "common" and "key" is “core”.
      Suggestion to modify the description (in line with the "Note"):
      Functionality of a website includes tasks that users of a website perform in order to achieve a goal. {Vicki}
    • comment {name}

    Copyedits & that probably don't need discussion

    • 3.1.2 Step 1.b. In-Depth Analysis. End of last sentence is missing a fullstop. {Vicki}
    • 3.2.3 "Note: This step is intended to identify groups of web page instances, including in web applications."
      Suggest drop the "in" as in "including web applications" or add "including those in web applications". {Vicki}
    • comment {name}

    Comments sent directly (not through EOWG)