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
(Background)
(open items on forms)
Line 136: Line 136:
 
<ul>
 
<ul>
 
<li>Why will it take "a while" for that change and what are the parameters for that timeframe? What is needed...programming resources? a volunteer? group consensus? Making that change in BAD is by far the best solution, so maybe we can focus on getting that done. <span style="color:#808080;">{Sharron 11 Nov}</span></li>
 
<li>Why will it take "a while" for that change and what are the parameters for that timeframe? What is needed...programming resources? a volunteer? group consensus? Making that change in BAD is by far the best solution, so maybe we can focus on getting that done. <span style="color:#808080;">{Sharron 11 Nov}</span></li>
 +
<li>I agree with Sharron, we should continue to use BAD.  Any idea what is causing the browser to not have focus go to the error messages?  What browser / version is this occurring in? <span style="color:#808080;">{Paul, 11/21}</span></li>
 
<li>comment <span style="color:#808080;">{name}</span></li>
 
<li>comment <span style="color:#808080;">{name}</span></li>
 
</ul>
 
</ul>

Revision as of 07:10, 22 November 2013

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


Easy Checks - A First Look at Web Accessibility

Related pages:


Completion Plan

  1. open issues
    • everyone comment on all open issues below marked with "[EOWG..." by Wed 13 Nov
    • Discuss open issues in EOWG telecon on Fri 15
    • Shawn update Forms section based on comments
  2. fresh perspective review
    • Jan & Anthony review & comment on all sections — except Forms — by Wed 13 Nov
    • Discuss comments in EOWG telecon on Fri 15
  3. illustrations
    • Anna Belle... :-)
  4. usability testing
    • @@
  5. publication approval
    • @@

To Do Throughout:

  • EOWG folks: search for "EOWG" below and add your comments.
  • [wait until illustration strategy is decided] Check img alts - some might have @@
  • [wait until illustration strategy is decided] Decide if we want more images for the steps. Search for [image].
  • [done for now] Search for other open things in [brackets].
  • 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}
  • comment {name}

Overall

  • When I followed the Page Title link from the top of the easy check page, I was a little confused by the icon next to link. I thought it might be some kind of a drop-down. I realized that it was just part of an anchor link when I followed the "markup" link inside the Page Title description and was jumped to the "Back Ground" section.{Jan}
  • [slh to fix] This is off-topic, but as I was looking at this I noticed something else that seems worth a double-check. Specifically when I went to look at the Resize section at http://www.w3.org/WAI/eval/preliminary#resize (which appears to have replaced http://www.w3.org/WAI/eval/preliminary#zoom), I was distracted by the page "bouncing." It turns out in at least Chrome on Mac (and I bet other browsers) on hover over things like "To check contrast with IE WAT" (that is h4 .f_panelHead) it adds a solid border-bottom, when there isn't a border-bottom in non-hover state. Maybe add a solid border of background color for default to stop this jiggle?{Anna Belle 8 Nov}

Intro

  • [question for Jan :-] Under "Easy Checks, A First Review of Accessibility," possibly change the third paragraph to read, "This page provides checks for specific aspects of a web page and suggestions for Next Steps(link)." (Then remove the phrase below the specific aspects anchors that refers to next steps). {Jan}
    • Can you say why? I'm missing the rationale for moving the link to Next Steps up before the links to the main content? {shawn}
    • [response to Shawn :-] I thought about moving the Next Steps up because I thought that it was visually lost after the anchor links and seemed disconnected to the flow of content. It just seemed to me that the information about "Next Steps" flowed better as a part of the introduction sentence instead of being on its own after the anchor link content. {Jan}
    • comment {name}

Using these Easy Checks

  • [closed until usability testing] Maybe move the expand/collapse buttons that are directly above this heading to be underneath this heading. {Jan}
    • Those expand/collapse buttons apply to the entire page, not just the "Using these Easy Checks" section. Do we need to say explain that better? We can check during usability testing... {Shawn}

Background

  • [EOWG discuss] I think the statement, "screen readers are software that reads aloud the information in a web page. They are used by people who are blind and by some people with reading disabilities" might be misleading. People with "reading disabilities" typically use "text readers," which are different from "screen readers." Screen readers not only read aloud the information on a web page, they also allow for mouseless navigation, which I think is an important distinction. Maybe consider changing the statement to something like, "screen readers are software that reads aloud the information in a web page and provide for navigation without a mouse. They are used by people who are blind or visually impaired." I just think that there needs to be a distinction between screen readers and text readers and who the targeted populations are. If the group agrees with this suggestion, then we would need to change the definition for screen readers under Diversity in Web Use as well @ http://www.w3.org/WAI/intro/people-use-web/browsing#sr {Jan}
    • +1 for ths change to both places, since it is a more accurate functional distinction that has impact for different disabilities. I also appreciate the fact that it makes the relation clear to mouse-less navigation. {Sharron}
    • I'm not so certain that this distinction should be made. Perhaps it's a regional difference, but in UK screen readers are frequently used by people with reading difficulties, and the mousless navigation is more to do with the functioning of the screen reader, rather than of the visual ability of the user. {Bim}
    • I think I like Jan's suggestion, but am doing a local (Australian) check before I confirm {Andrew - 15 Nov}
    • I think this distinction is valid, but will be lost on someone who is performing an "easy check." Let's not get lost in minutiae. {Paul 11/21}
    • comment {name}

Page Title

  • I think its better to give the easy option as the 1st point for the user. 4th option is the easiest: "With your mouse, hover over the browser tab to see the full page title, like this:" {Anthony}
  • comment {name}

Image alts

  • Under Tips, in 5th point its better to mention about html longdesc element. We can write something like "......, and then the detailed description of the information should be provided elsewhere using html longdesc [1] element." {Anthony}
  • comment {name}

Headings

  • comment {name}

Contrast

  • comment {name}
  • [EOWG - OPEN action] To check contrast with IE WAT - finish instructions
    • Don't understand question: [@@ how to show where it is on the page]{Helle 1. Nov.}
      • Someone said there is a way to get from the table to where it is on the web page -- that is, from a row or cell in the table you can see where that is on the page -- but I don't know how to do that...
      • Is this a case where an illustration might be helpful? Show the table and show how the table-based output relates to whatever is onscreen? {Sharron 11 Nov}
      • I'm pretty certain the JuicyStudio table which opens in a new tab/window does not link back to the tested page and the only way to find where the colours are mapped is by mapping the nodes to the HTML (or doing some visual identification) {Andrew, 15 Nov}

Resize Text

  • comment {name}
  • [open] Zoom - keyboard shortcuts. Following up public comments I rechecked the content of text only and whole page zoom. In Mac Safari and Mac FF, when you use the View drop down and select text only zoom - it puts in a tick and then any increase/decrease impacts text only (using cmd with + or -). BUT in Windows FF, you can chose either page or text zoom from View menu. However, the keyboard short cuts are different for text an page zoom. Zoom page is the default ctrl + or - with ctrl zero for reset to default. Text only zoom is thus "control key AND shift key with + key all at the same time". I recommend we add this as an extra line to step 2.
    I don't use IE much and I don't use a mouse - but does anyone know if it still does zoom using the mouse wheel? Also is this only page zoom? (For reference I am on v22 for both Mac FF and Windows FF){Suzette}
  • [open] A minor edit change: In the firts item at "What to check for" say: "A common problem is that text is in images and it doesn't get bigger" and it should say: "A common problem is the text is in images and it doesn't get bigger" {Emmanuelle}
    • I think this is not substantially more clear than the previous. How about a completely different approach? Perhaps something like "A common problem occurs when text is not presented in a real text format but is actually an image of text. In such a case, when text zoom is used, the size of the image is not changed and so the graphic of the text does not enlarge." {Sharron 11 Nov}
  • +1 for Sharron's revision - I think that makes it a bit more clear {Jan}

Keyboard access and visual focus

  • comment {name}

Forms

Forms in WAI draft page

DRAFT of addition to Forms Section

If you have a basic familiarity with HTML, you can drill down on how the form is coded. While HTML allows both explicit and implicit form labels, some assistive technologies do not correctly handle implicit labels. One of the most reliable techniques for making forms accessible to assistive technology is therefore to use the label element to explicitly associate the form control with the label. This ensures that however the user comes to the form control, its purpose will be clear. If you are comfortable looking at the code, the following will help you identify accessibility features.

What to do:

  • Open the source code of the page you are testing and find the section that contains the form.

What to look for:

  • Verify that a label is attached to the form control through the use of the for attribute. The value of the for attribute must be the same as the value of the id attribute of the form control. The id attribute may have the same value as the name attribute, but both must be provided, and the id must be unique in the Web page.

{Sharron, 3 Sept 2013}

open items on forms

  • [EOWG thoughts] In BAD, it seems that the focus does not go to the error messages. Shall we still include BAD for checking errors? We can submit a change request for BAD, but it will likely be a while before it gets implemented.
    • Why will it take "a while" for that change and what are the parameters for that timeframe? What is needed...programming resources? a volunteer? group consensus? Making that change in BAD is by far the best solution, so maybe we can focus on getting that done. {Sharron 11 Nov}
    • I agree with Sharron, we should continue to use BAD. Any idea what is causing the browser to not have focus go to the error messages? What browser / version is this occurring in? {Paul, 11/21}
    • comment {name}
  • [EOWG thoughts] suggest edit for: "Check that the information makes sense, for example, [@@ reading order]."
    • I'm confused, are we focused here on the Forms section? I do not find that text string within the Forms section, but do find it within the Plain Content View section, where it seems to work just fine - no change seems needed from my perspective. {Sharron 11 Nov}
    • comment {name}
  • [EOWG thoughts] suggest edit for: "Data tables will not make sense when linearized -- that's OK -- screen readers have functionality to make them usable (when the table is marked up correctly)."
  • Same comment as previous - this is NOT part of the current forms section {Sharron 11 Nov}
    • comment {name}

    How to check for implicit (aka embedded) labels:

    Using the Mouse:

    • If label is present:
    1. Place the mouse over the label and right click.
    2. A menu will appear; Choose the Inspect Element option
    3. The label code will appear. If it has a "for=formID" attribute the form / control passes.
    4. If the form / control HTML occurs inside the scope of the label element, the form / control passes.
    • If label is not present
    1. Place the mouse on the form / control and right click
    2. Check for a title attribute. If a title is given the form / control passes.
    3. Check for a value attribute. If a value is present the form / control passes.

    I think that handles all programmatically determined cases. {Wayne, 21 November}

    Comments:

    • Wayne, I put this in the wiki as you requested and made the change from "name" to "value" in the second section - "If label is not present." Your most recent post to the list reverts to using "name". Which is correct? {Sharron, 21 November}
    • Also, since H65 says title may be used "when the label element cannot be used" shouldn't we make that qualification clearer? {Sharron, 21 November}
    • Finally, I think the next version of explanation of implicit forms that you posted to the list begins into that territory of complexity that has Suzette tearing her hair and asking us to leave Forms out of Easy Checks altogether. Can we keep the simple, early version for the sake of the "Easy"part of Easy Checks? {Sharron, 21 November}
    • Your comment {name, date}

    Comments after 14 June

    • comment {name}
    • Completing forms: I think some illustrations will be useful to the novice trying to understand forms using the WAT results. I am not sure how the proposed image in step 2 will differ from the image in step 3. In either case showing a present and absent label for or id will be sufficient. For step 5 however, I cannot see how WAT helps - surely you have to look at the code view to see if the asterisk is included or excluded - or am I missing something? Would an image help? {Suzette}
    • Update to WAT: Many many thanks are due to both Steve Faulkner and Jim Thatcher for resolving some issues with form checking using WAT. Newest version of WAT is currently 2013-07-19 and not 2013-06-13 as stated in Easychecks introduction. {Suzette}
    • [EOWG] Reconsider: are the labels checks are too hard for Easy Checks? (Suzette say more here? : I'm trying a typical college application form with no apparent track record on accessibility: http://www.newham.ac.uk/pages/studentshomepage/findacourse/onlineapplication. The tabbing seems to work, including the drop down boxes. {Suzette responded:}Downloaded new version of WAT - it is clearer that something is wrong than in previous version - many things are labelled now as input errors and also select errors and container errors - which Easychecks don't mention. Some specific fields picked up as lacking 'label for'. Is there a simple explanation for input and select errors? WAVE was easier to understand with its red and green luggage labels but there is a lot of other issues identified too. FF has a feature on Forms/ outline form fields without labels - the outline is a bit too subtle and easy to miss! On the other hand, if the form passed most success criteria I guess the whole thing would be much simpler! Is it sufficient that the novice tester can just say that this form needs further investigation?)
      • Forms are one of the most barrier-ridden elements of pages, a common reason that web sites are NOT accessible and one of the most formidable challenges when done incorrectly. I am strongly in favor of finding a way to include basic forms testing even if we carve out some very simple tests and make a host of qualifications. {Sharron 11 Nov}
      • I agree with Sharron - we really do need to include some forms-checking in our Easy Checks. My simple suggestion to people re testing for form labes being associated is to try clicking the lable with the mopuse and if the focus jumps into the form control, then probably ok (not definitive, but an easy check) {Andrew, 15 November}
      • comment {Name date}
    • [EOWG review] "Check that the focus is at the error message."
      Proposal for clearer guidance:
      After you have submitted the form with errors, check that your browser brings you directly to the first error on the page. One best practice is to list all errors at the beginning of the form that contain an internal link leading directly to each error."{Sylvie, 17 June}
      • Two questions with this:
    1. How do people "Check that the focus is at the error message" or "check that your browser brings you directly to the first error on the page"? I think this is easy to check with a screen reader but maybe not visually?
      Response from Sylvie on June 18: if you take the example of search engines like Google, when you open the home page your browser prompts you directly to the search field, and this even without a screen reader. I am right?
      Response from Shawn on 25 June: Yes, but how can the the person doing the check check that? Visually, if it is a text box, there is a cursor. How check non-visually? What if it's a control other than a text box? Or just a plain text message? How check that the focus is there?
      Response from Sharron on 11 Nov: Can we advise the use of a free screen reader - NVDA or the JAWS demo?
      Response from Andrew on 15 Nov: Sharron, I think asking someone to use a screen reader is a big ask in Easy Checks. Sorry, I don't have an alternative suggestion.
      Response from Name on Date: comment
    2. The next bullet says: "Generally it is best if the error messages are before the form, rather than after the form." Is saying "One best practice is to list all errors at the beginning of the form that contain an internal link leading directly to each error." too prescriptive? If not, how can we integrate it into the existing bullet?
      {Shawn, 17 June}
      I am not sure if it is too prescriptive. It is only an example of what can be done to help the users find the errors. {Sylvie, 18 June}
    • [EOWG review] In the note for labels checks, clarify following sentence:
      "Note: These instructions help you check if labels are marked up with 'label', 'for', and 'id'; they do not check if form controls are identified in other ways. Therefore, even if a form does not pass these checks, it might still meet WCAG 2.0 another way."
      {Sylvie, 14 June}
      • I added the sentence before in your blockquote. Can you say what is not clear? How me might clarify it? {Shawn, 17 June}
      • I mean the sentence: "Therefore, even if a form does not pass these checks, it might still meet WCAG 2.0 another way." I am not sure that this "another way" is clear. {Sylvie, 18 June}
      • [EOWG]: Do we want to be more specific? Or how else can we be clear without being too techy and detailed?
      • Would it be any clearer if "be WCAG another way" were changed to "meet WCAG in another way"? {Bim, 28 June}
      • Yes, +1 to Bim's suggestion {Sharron 11 Nov}
      • comment {name date}
    • [closed ?] In Check labels with FF, I don't understand following note:
      (There's not an easy way to check form control labels with the FF toolbar. The Form Labels favelet works with Firefox, yet it requires installation.)
      What does this enable you to do? Why do you mention that it requires installation, as FF toolbar also requires installation. More explanations are needed here. {Sylvie, 14 June}
      • OK, I added more explanation: "The Form Labels favelet works with Firefox and provides the same information as from IE WAT above." We mention it requires installation because in the beginning we say we only use to 2 tools that require installation, so this is an exception. {Shawn, 17 June}
      • Must we include both browsers? If so, I will +1 to the new explanation. If not, I am in favor of omitting the second suggestion for FF in the interests of avoiding still more noise in this section. {Sharron, 11 Nov}
      • comment {name date}

    Earlier comments still open 18 June

    • [EOWG open - heading for this section simply "Forms?" or more?]
      • Currently the section covers: Labels, Keyboard Access, Instructions, and Error Handling" Maybe keep it short and just use "Forms" ? {Shawn 10 June}
      • Title on current version is "Forms and Error Messages" but in this wiki it's "Forms, Form Labels, and Error Messages." I prefer the latter {Howard, 6 June}
      • +1 to "Forms, Form Labels, and Error Messages." {Sharron, 11 Nov}
      • comment {name, date}

    multimedia

    • [OPEN action] In Section "captions", look for a way to turn on open captions with the keyboard, for example in Youtube activating the CC button. (How to do it with nvda from Howard -- but we want more generic instructions, e.g,. sighted keyboard users.)
    • [EOWG thoughts?] "If there are captions, transcripts are not usually required; however providing transcripts in addition to captions has many benefits — both to people with disabilities and to website owners. [EOWG: OK to say??]" Should we point to Benefits?
      • I think this is definitely OK to say, and yes, it should point to benefits. In fact the benefits are even broader than what we claim here. Besides PWD and website owners, captions support literacy for all readers. Captions for Literacy provides links to research if we want to get that detailed.{Sharron 27 Oct}
      • comment {name}
    • [EOWG thoughts?] "Check that transcripts include all audio information, including dialogue with the speakers identified, and all important sound [repeat examples above or not?]."
      • Do not repeat examples, but maybe OK to point to them or make a short reference.{Sharron, 11 Nov}
      • comment {name}

    Plain Content View

    • [EOWG thoughts?] [ Make sure that there are reasonable ways to skip around long lists of links and other boiler plate content that is repeated on every page in the site. @@ need to be more specific on this one - how do they check that? what specifically are they looking for? or is this not a priority and we should leave it out?]
      • No strong feelings, editor's discretion{Sharron 11 Nov}
      • comment {name}
    • [EOWG thoughts?] To practice checking plain text view with BAD section: Do we want to point out other things?
      • No strong feelings, editor's discretion{Sharron 11 Nov}
      • comment {name}
    • comment {name}


    [EOWG open]What to call this section?

    (Keep in mind how it fits with the other items in the contents list.)

    Brainstorms:

    • Plain Text View
    • Linearize the Page for Experiential Learning
    • Basic Display
    • Bare Bones Display
    • How some people "see" the web page
    • Information Organization
    • Different Presentation
    • ...

    Comments:

    • I think plain text is a misleading term. It makes me think of the <pre> element. Very fixed and very rigid. Linearized text, is marked up HTML. There are links, headings, paragraphs everything but style, and regrettably data tables. Actually it is styled with the default HTML style. Links are blue, headings are big and lists are lists.
      Linearizatized text is very structured markup in a different format. If linearize is to geeky how about "reading order" --convert the page to reading order.
      For me plain text has a very bad connotation. People used to give ASCII page equivalents that were rarely equivalent. These alternatives were referred to as "plain text" alternatives.
      {Wayne, 17 June}
    • It's more than linearize or reading order, it turns off images & CSS as well. {Shawn}
    • I think "Linearize" has a foundation that can be explained and is traditional. But it could also be something like, "undress the page", or "stripping the page".{Emmanuelle, 18 June}
    • I agree with Wayne about the bad roof of plain text. I am afraid people think that making a page accessible is providing a text version without images and anythhing else. I like Emmanuelle's "undress the page" (I mean the idea in it). From the proposals above I would prefer "different view", or what about "alternate view or presentation?"? {Sylvie, 20 June}
    • I find the current draft of this section somewhat confusing - sometimes "linearize" is used, sometime "plain text". The difference between the 2 are not clear, at least not spelled out. I found the diagrams confusing because there's no explanation of how you render in 1 column versus "page linearized with styles off." I'm a little concerned with the term linearized - it's not a term, I believe, that is used in any other tool such as Wave or Web Dev'l Toolbar, etc. Perhaps there should be only one example (since this is easy checks) - a page with styles turned off. Explain this is used to hear how a screenreader will render the page. {Howard, 27 June}
    • How about "Text view" or "Reading order"? {Bim, 28 June}
    • Among the suggestions above, I prefer:
      • How some people "see" the web page
      • Information Organization
      • Or Bim's suggested "reading order".
      {Sylvie, 28 June}
    • I also like the idea behind "undress the page". What about "simplify the page" or "basics of the page" or "See the page framework" or similar {Andrew, 28 June}
      • Current title of "Plain Content View" may still have the connotations of "Plain Text" that we tried to avoid. I like moving in this direction. {Sharron 11 Nov}
      • comment {name, date}
    • comment {name, date}

    Next Steps

    • comment {name}



    Internal Notes

    Easy Checks - Illustrations moved to its own page.

    Misc:

    • comment {name}

    Usability Testing

    Things to test with users

    • Expand/Collapse: test to see if the "+/-" icons convey this feature
      • might want to consider putting text such as "expand/collapse" in addition to the "+/-" icons
    • Meaning of terms such as "accessibility," "page title"
      • Do users understand the term "accessibility"
        • We assume that by the time users access this page they understand the term "usability." Perhaps this needs to be reconsidered.
      • Do users understand what we mean by "page title" or do we need to explain further
    • Resize Text - especially check if they understand the horizontal scrolling bits

    Case study notes

    See SK/MC Case Study Notes in the 30 May 2013 snapshot

    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}

    previous versions, etc.