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.


Easy Checks Comments

From Education & Outreach
Revision as of 14:34, 13 January 2014 by Eeggert (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Nav: EOWG wiki main page > EOWG Easy Checks wiki page


Related pages:

[closed] Tom Worthington Oct 2013

[closed] Vivienne Conway 24 July

(from wai-eo-editors email)

[closed] Comment 1 VC

Section: Zoom
Re-sizing - As far as I'm aware, you need to be able to use zoom or text size largest or similar, not necessarily both to pass this. IE isn't mentioned as providing the ability to re-size the text only while the other browsers are.

EOWG Resolution: Changed the section to "Resize text" and focus on text-only zoom — to keep it simple and focus on the most common accessibility barrier. Included instructions for IE. See edited Resize Text section.




Archived discussion

(EOWG: put any comments on the revised draft in the Resize text section of our wiki page)

EOWG Comments on this resolution


EOWG Comments WCAG requirement:

Sub Discussion of Text Zoom vs. Browser Zoom

{dboudreau, July 26} So while this is somewhat unrelated to the issue brought up by Vivienne Conway for EasyChecks, this is something I feel we need to bring to the WCAG WG. I will be happy to send it to them if you want me to, and welcome your input and feedback to strengthen my plea.

Reasons why I strongly believe we need to make a case for testing for text zoom, not browser zoom.

First, in the HTML context which is the scope of EasyChecks, testing for browser zoom is pointless. Pages can never "break" since everything always turns out looking proportionally consistent. There's really no point in doing browser zoom test on any page, because none of them will ever fail that test.

There are three principles that lead me to lean towards text zoom and not browser zoom: Memory, Acuity, and Flow. These relate to the reading experience of low vision users (thanks to Wayne for helping me see clearly here - no pun intended).

When using a webpage, a person with moderate low vision (say, 20/70 to 20/200) approaches the problems at different levels. First, low vision users often memorize the organization and layout of frequently used pages, probably more than normally sighted people do. They will generally proceed by position rather than actual reading, which obviously becomes very important to them for orientation. With slightly more text enlargement, users can manage to use print near their acuity limit, along with remembered layout to operate pages as efficiently as possible. Finally, when it becomes necessary for them to read with comprehension, low vision users will need to zoom up to a font size that is usually bigger than the critical print size to achieve the state where the only mental concentration required is to comprehend the content itself. Something most of us do, simply using the page as it's presented to us.

For most people with moderate low vision, 200% of say, a 10pt font is between the acuity limit and that critical print size, the point where reading becomes optimal. For people at the upper end of that spectrum, with a vision of 20/140 to 20/200, it may very well be below their acuity limit near point. It is, to them, inadequate to achieve a state of "reading flow". It can be operationally effective for simple tasks, but cannot be used for any kind of "professional reading".

This might be a small issue if this was a small population or if the disability was slight, but neither is the case. Moderate low vision constitutes more than half of all people with visual impairments, including everyone who is blind. This becomes important when we think about testing for text zoom as opposed to browser zoom, since we are the gatekeepers of digital equality.

It is naive to think that enlargement without word-wrapping is minimally effective, especially on a rather small screen resolution. A web page is two dimensional: enlargement without word wrapping means that your reading viewport is effectively linear, with every line on the page being noise except for the one in focus. Reading long difficult documents in this mode is hell. Just think of situations where you have to scroll horizontally for content and how much of a pain in the neck it is to get back to the following line. Multiply that by your current screen magnifying zoom level (thus, less words visible at once and a much harder process to get back to the next line of text) and picture that on every website, all the time. This is not a problem browsing zoom can help avoid.

So, for any serious reading at all, 200% text enlargement is the bottom level where reading becomes possible - some will argue that it's still not enough (after all, a 10pt font becomes only 20pt and most users start feeling comfortable around 28pt). If we neglect to test for this, we leave out a critical aspect of what makes content readable on the web for people with low vision. Moreover, without text-only enlargement, people quit reading all but text that is vital for their livelihood. In summary, they get shut out, 200% text zoom is marginally adequate, and zooming of the entire page can be worse than useless.

Therefore, when we don't make a case of testing specifically for text zoom - the configuration these people ARE USING (not browser zoom), we miss those cases where text starts to overlap or where content becomes lost in the page. Browser zoom never reveals such problems, but text zoom does. Indeed, this is a much bigger problem to solve for developers and most sites might actually fail this because of the way their CSS files are organized, but when there is a real barrier to accessibility, I feel my job is not to go easy on developers who should know better, it is to help foster digital equality for everyone.

Testing for SC 1.4.4 using NoSquint with FireFox is a very simple and effective way to verify if the page has such problems. It takes but a minute to do, results are very clear and the margin for error is next to zero. Also, SC 1.4.4 is probably the only success criterion that really helps low vision users achieve some level of comfort on the web, so it seems totally irresponsible for me to consider anything but text zoom. So above and beyond what the success criterion actually says, my biggest concern is helping low vision users get the best experience they can get on an accessible website. I don't feel I am doing that by only considering browser zoom.

Unfortunately, there is an example in Understanding SC 1.4.4 that lead some people to believe that browser zoom is sufficient (third example): "A user uses a zoom function in his user agent to change the scale of the content. All the content scales uniformly, and the user agent provides scroll bars, if necessary." http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-scale.html - We need to blow this example out of existence. If we can have it removed from the Understanding documentation, we can make a very strong case for text zoom for SC 1.4.4.

  • My view is similar to Denis above. I think the test for text zoom is crucial. Graceful text enlargement is both an accessibility and usability issue. Text that does not enlarge gracefully - i.e. loses readability on enlargement - is likely to not read legibly in at least one browser or on different size view ports. I don't think we should abandon the test for zoom page. Page zooming to 200% without requiring horizontal scroll is also an important accessibility and usability issue. As I mentioned during the last call, the 2 seemed to be linked, at least that's my finding from my very preliminary testing. Pages that don't text zoom gracefully also appear to likely fail (horizontal scroll appears) when page zooming. I think we should recommend to WCAG WG to require testing for both types of zoom control.{Howard, 1 August}
  • relevant articles: Text resizing: Why page zoom is not good enough - or is it? (update 10 January 2012), Why Browser Zoom Testing Sucks for Accessibility, Browser zoom great for accessibility
  • I have to agree with you and to express my amazement at the implication that requiring the user to use a horizontal scroll bar is acceptable. This would make reading text impractical in a real situation.
    Maybe rather than shortening the text, someone could produce a short video of a user having problems with this, even just a screen capture with descriptive voice over. I'm not able to do this, but I imagine it wouldn't be too difficult. It would demonstrate the problem in just a few seconds.
    As for the Easy Checks [1] (I hope I'm looking at the right draft), it would be useful to also include a screenshot with horizontal scrollbars. The text "Some people with disabilities cannot read text that requires horizontal scrolling" doesn't actually say why. This is explained further down under "What to check for," but maybe it would be clearer to put it in the main section. It's obvious to me, but probably won't be to many page designers. {Alan via e-mail}
  • I have nothing to add to this well documented case, but only want to express strong agreement with the general need for text zoom distinguished from page zoom, and agree that the requirement is supported by Andrew's citation of technique G179: Ensuring that there is no loss of content or functionality.{Sharron, 6 August}
  • Agreeing with Sharon's praise of and strong agreement with this well documented case, I'd just like to add another argument for disallowing browser zoom ... people who need text enlargement to 200% are likely to have difficulty even locating the tiny horizontal scroll bar controls. The need to do this 9 times to read both ends of a five-line paragraph, could break the flow so badly that it reduces comprehension. {Bim, 7 August}
  • Agree strongly with all the statements above; text enlargement testing (200% is a reasonable figure) should be required as browser zoom is not a realistic accessibility check (everything is proportionally zoomed). {Paul, 3 October}


EOWG Comments on IE:

  • thank-you for the comment, we had a lot of discussion on how to keep this simple and yet address different user needs. We decided there was still a need for a text only zoom as well as whole page zoom. Thus we pointed to the browsers that continue to support this. As far as I can tell with my IE10 you can use control+ or cogwheel>zoom to zoom the whole page view, but I can't find a text only zoom. I'm not an IE user - have we missed a control option? {Suzette}
  • On I.E. 10 for the PC at least, under the menu option "view", there is a 5-level text size option from largest to smallest{Howard, 25 July}
    • Suzette, in IE10 for Windows you need to enable the 'Menu Bar' - right-click in blank space at top to select (don't know about keystrokes) {Andrew 26 July}
  • Very helpful tip - I'd been frustrated by lack of a menu in IE10, and didn't realise I could switch it on! Interesting effect to use text zoom while keeping page zoom to 100% (on BBC news) but does not meet my visual needs because line spacing looks compressed. However for those who need this option it is good to see it is still available. Recommend that EOWG should add the IE instructions (should we include the instructions to switch the menu on - or assume that IE users will have knowledge of this). {Suzette}
  • We talked about this at the last face-to-face and discovered that IE was all over the place on this, that is, different versions handled it differently, and even the same version in different language. So we decided it was too complicated to include in Easy Checks.{Shawn}

[closed] Comment 2 VC

Section: Keyboard Access and Visual Focus Visual - you state that the focus should be the same for the keyboard focus as for the mouse. While again I totally agree, it isn't stated this way in WCAG (that I've seen at least).

EOWG Resolution: Reworded it to say that all functionality is available with the keyboard. Revised text is in the Keyboard section



Previous EOWG Comments:

(EOWG - put any comments on that text in the Easy Checks comments wiki page - Keyboard section)

EOWG Comments on this resolution

  • Accepted 1 Nov teleconference — pending e-mail opportunity for those who were not on call
  • +1 {Emmanuelle}
  • +1 {Anna Belle}

EOWG teleconference 26 July

  • Current text: "Check that all visible changes that are available with mouse hover, such as highlighting, [are] also triggered with keyboard focus." (Is this the text we think she is referring to? or is it stated elsewhere?)
  • Relevant WCAG wording:
    • SC 2.1.1 All functionality of the content is operable through a keyboard interface
      • G202: Ensuring keyboard control for all functionality
      • G90: Providing keyboard-triggered event handlers
      • F54: Failure of Success Criterion 2.1.1 due to using only pointing-device-specific event handlers (including gesture) for a function
      • functionality is defined as "processes and outcomes achievable through user action"
    • WCAG 2.0: SC 2.4.7 Focus Visible: Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible. (Level AA)
      • Understandings document for SC 2.4.7, under additional advisory techniques: Highlighting a link or control when the mouse hovers over it (future link) and Providing a highly visible highlighting mechanism for links or controls when they receive keyboard focus (future link).
  • Propose that this is indicated as advisory or best practice. {Suzette}
  • I'd propose we amend the text to something like "Check that all visible changes that are available with mouse hover, such as highlighting, [are] also visible when they receive keyboard focus." {Andrew, 26 July}
  • I never found anything in either the wording of SC 2.1.1 or any of the related techniques that specifically says the behaviour on the keyboard needs to be the exact same behaviour as what happens on mouseover or using the mouse. Therefore, I don't think we can say it needs to be the same... There needs to be something provided, absolutely, but if it's different (which usually means a poorer experience), then there's nothing we can say about it and I think therefore, the SC could not be failed. {dboudreau, July 26}
  • I think best practice, if not WCAG requirement, would be something like "equivalent and appropriate feedback for keyboard focus should be provided to match any visible feedback which is provided with mouse hover, such as highlighting, the pulling down of menus, etc. Note: it may be advisable to not exactly mimic the visual feedback provided through mouse hover in certain instances, such as fly out menus where the appearance of such menus for keyboard and screenreader users can be problematic."{Howard, 2 August}
  • EOWG telecon discussion 26 July starting at "Next is Open Comment 2VC" — which boiled down to "it depends on what is 'functionality'" (given 2.1.1 Keyboard: All functionality of the content is operable through a keyboard interface)... and Understanding defines functionality as "processes and outcomes achievable through user action"
  • Actually, I strongly disagree that it is not a requirement. I believe it is a clear failure of 2.1.1 because the way in which a mouse-focused or mouse-hovered element is highlighted or zoomed or opened beyond the default appearance is, in fact, a function of user interaction. This means that the act of focus is a function. The way to test for failure of 2.1.1 is to "check to see whether pointing-device-specific event handlers are the only means to invoke scripting functions" which is exactly what occurs in the scenario described. Mouse-hover is the only means to invoke the function of highlighting or whatever visible changes are referenced. Therefore it is a Failure. voila! {Sharron 8/6}

[closed] Comment 3 VC

Section: Page title
Title - you mention that you can use WAT to check the title through the Structure tab. You might like to add that you can check it also through the Doc Info>Metadata info tab where it also shows clearly

EOWG Resolution: No change. (Rationale: The Metadata window includes information that is not related to Easy Checks and is more techy; where as Heading Structure is used elsewhere in Easy Checks and has only information directly related to Easy Checks. We don't see a reason to complicate the instructions by adding the Metadata option.)

EOWG Comments:

  • I agree that looking at the Info tab/metadata is too technical. But displaying the doc structure may also be complex for some people. Another place to see page title would be to look at the information tab, "page information", it displays less technical information in a new windows such as page title, number of links, cookies etc.
    Keyboard shortcut : ctrl+alt+9, then i for information, they choose "page information". {Sylvie, 25 July}
  • The Info Tab/Page Info may be more readable because of the formatting of the page - i.e. table column format. But I'm not sure the actual content would be any less confusing for a novice, perhaps.{Howard, 25 July}
  • agree with proposed resolution - keep it simple (Title is obvious) {Andrew, 26 July}
  • Approved EOWG telecon 26 July 2013

[closed] Comment 4 VC

Section: Keyboard Access
Elements and Order - your last point says that tabbing through the controls on the page doesn't stop at the bottom but goes back up to the top. While I agree that this is best practice, I haven't seen it in WCAG - unless I've been missing it all along

EOWG Resolution: Delete "Check that the focus does not stop at the end of the page; it goes to the top of the page or to the browser controls and then the page." (because it's rare, and therefore, not fit in easy check criteria)

EOWG Comments:

  • EOWG Proposed Resolution:After "Check that the focus does not stop at the end of the page; it goes to the top of the page or to the browser controls and then the page." Add: "(This is best practice, though not a requirement.)"
  • I agree with this suggestion. Let's call it a best practice. {Sylvie, 25 July}
  • What about: "On tabbing to the last item on the page (or bottom of page), best practice suggests that the focus does not stop there, but then goes to the top of the page or to the browser controls and then the page." {Andrew, 26 July}
  • I would tend to say that if are stopped at the bottom of the page, then you have run into a keyboard trap, which means a violation against SC 2.1.2. And if you need to go over whatever stops you and you can't, then you've failed SC 2.4.1 for bypassing blocks. {dboudreau, July 26}
  • EOWG decision from 26 July telecon: EO decided this issue is highly unlikely, and therefore decided to delete this item entirely.

[closed] Neil Soiffer 8 July

[closed] Comment: In the section on images, there should be a mention that images of math equations should be encoded in MathML and not as a static image. (e-mail with more info)

EOWG Resolution: No change. (Although we agree it is an important issue, it goes beyond the criteria for inclusion in Easy Checks. We will add it to our upcoming tutorial on Images, and will point to that tutorial from Easy Checks. )

EOWG comments:

  • Is this beyond the criteria for inclusion in Easy Checks, or should it be included? If included: How? A note under Tips? Other?
  • Summary from 12 July EOWG teleconference: This is a really important point, thank you for raising it and we discussed it in EOWG meeting.The feeling is that it is a specialised issue and doesn't meet the strict criteria of Easychecks to be commonly occurring and 'easy'. The EOWG proposed resolution is to include this in the Tutorials (currently in preparation) where there is more scope for discussion about best practice. We will link from Easychecks to the tutorials once the content is stable.{Suzette}
  • agree that this is beyond basics {Andrew, 26 July}
  • agree - beyond basics covered in EasyChecks {dboudreau, 26 July}
  • Approved EOWG telecon 26 July 2013

[closed] Peter 2 July

[closed] Comment: for the LTR example you may want to provide a quick RTL example - it seams an often under-documented area.

Current text under Forms, What to check for, Labels:

Check that the labels are positioned correctly. For left-to-right languages, labels should usually be:
Left of text boxes and drop-down lists.
[image]
Right of radio buttons and checkboxes.
[image]

EOWG Resolution: Add note to the bottom of the page about changing the placement of labels as appropriate for right-to-left languages. (Note to Translators placeholder - we'll add it the next update)

Questions for EOWG:

  • pros and cons?
  • Is there a good way to do this without adding confusion?

EOWG comments:

  • Thank-you for the comment. It would be interesting to provide an example that might support anyone offering a translated version of Easychecks into a right to left language. Perhaps EOWG could try adding an image to support discussion as to whether is is easy or confusing. {Suzette}
  • I think it would be confusing to have images showing the opposite, especially for people who are very visual, people who just skim and not read the text carefully, and people with some cognitive disabilities. If people feel it's important, we could consider an option to: "Show images for right-to-left languages" or something. (Personally I think it's not worth the added complexity, though. We could also have something in Notes for Translators that if translating into a language that is not l-to-r, they can change the text and images to match. We could even provide those images (albeit they will probably want it in their own language).{Shawn}
  • agree, too complex for this English document, though a note to translators may be appropriate {Andrew, 26 July}
  • Agree with Andrew +1 {Suzette}
  • 26 July 2013 EOWG teleconf — agreed to not add example, and to add note to bottom of document regarding translations and permission to change illustrations and some instructions (e.g. placement of checkbox labels)

[closed] Ryan E Benson 6 June

  • [closed] Comment: Zoom: The text overlap usually happens when the containers have fixed
    height/width, versus fluid, and you zoom only text.
    EOWG Resolution: No change. Easy Checks scope currently does not include explanations of why.
    • OK with this resolution {Sylvie, 20 June}
    • OK with this resolution - we do link to Understanding and this not a technical tutorial. Having said that, maybe we could link to any of the tutorials when completed for technical advice. {Andrew, 21 June}
    • +1 for this resolution. {Sharron, 21 June}
    • Approved in EOWG teleconference 21 June
  • [closed] Comment: Keyboard Access: The "not Opera" is incorrect in my opinion. You can enable keyboard
    support, and use q/a to navigate.
    EOWG Resolution: Changed from "In a browser that supports keyboard navigation" to: "In a browser that supports keyboard navigation with the Tab key" (Opera keyboard nav is too complex for Easy Checks.)
    • OK with this resolution {Sylvie, 20 June}
    • Agree with this update wording - we're trying to keep it simple {Andrew, 21 June}
    • +1 for this resolution. {Sharron, 21 June}
    • Approved in EOWG teleconference 21 June
  • [closed] Comment: Keyboard Access: "Check that at the end of the page the focus goes to the top of the page."<- I would remove this. Depending on what browser, it goes back to the address bar, then toolbars, then finally the top
    EOWG Resolution: Changed from "Check that at the end of the page the focus goes to the top of the page." to "Check that the focus does not stop at the end of the page; it goes to the top of the page or to the browser controls and then the page."
    • OK with this resolution {Sylvie, 20 June}
    • agree with update wording {Andrew, 21 June}
    • +1 for updated wording. {Sharron, 21 June}
    • Approved in EOWG teleconference 21 June
  • [closed] Comment: Keyboard Access: "(A common problem is that the default focus indicator is turned off in CSS [@@ too jargony?] or elements are styled with borders that overlap or hide the focus indicator.)" <- Yes too jargony. I would throw this in the footnotes for this section, then mention how it is various frameworks/reset sheets that remove it, not automagically just by using CSS.
    EOWG Resolution: Delete the whole sentence in parenthesis. (In Easy Checks we sometimes mention common problems that the evalutor/user might encounter, but we don't elsewhere explain the backend of why it's happening, i.e., what's wrong in the markup.)
    • OK with this resolution {Sylvie, 20 June}
    • an alternative wording - "A common problem is that webpage designers disable the default focus indicator". However, I agree - we don't tell people in other sections why there is a problem (see Ryan's first bullet and response) {Andrew, 21 June}
    • +1 for this resolution. {Sharron, 21 June}
    • Approved in EOWG teleconference 21 June
  • [closed] Comment: Multimedia: It would be good to mention that transcripts are usually not acceptable to use in lieu of captions.
    EOWG Resolution: In first paragraph, changed "Information in podcasts or other audio is not available to people who are deaf or some people who are hard of hearing, unless it is provided in an alternative format such as text transcripts or captions." to "...alternative format such as captions and text transcripts."
    • EOWG questions: Is this beyond the scope of Easy Checks, given we mostly don't cover such specifics on requirements? If not, what is a smooth way to say it within what is already there?
    • Easy checks does not recommend to use transcripts in place of captions. It handles captions, saying it is essential for people who are hard of hearing or deaf, and it says follwoing about transcripts:
      "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."
      So we don't say that transcripts should replace captions and I don't see how we could say it in a smoother way? {Sylvie, 20 June}
    • agree with Sylvie {Andrew, 21 June}
    • Agreed. {Sharron, 21 June}
    • Text in each subsection looks good. In the intro, we could chagne "Information in podcasts or other audio is not available to people who are deaf or some people who are hard of hearing, unless it is provided in an alternative format such as text transcripts or captions." to "...alternative format such as captions and text transcripts." {Shawn, 21 June}
    • Approved in EOWG teleconference 21 June

[closed] Jim Allan 6 June

  • [closed] Comment: Color/Contrast channeling Jared's <rant>!!! can we have an example of wretched grey text on a white background. Folks forget that grey and white are colors and may not think to check it.
    EOWG Resolution: Changed the first illustration to gray text on white background.
  • [closed] Comment: zooming if you control+ in FF the images also get bigger. IE can change text size only (but with limits) main menu - view>text size in windows with wheel mouse, can zoom using control and mouse wheel (forward for larger, backward for smaller)
    EOWG Resolution: No changes. We have in the instructions for FF for text-only "From the menubar, select View > Zoom Text Only or, View > Zoom > Zoom Text Only". Jim must have missed that on quick read. For IE, we previously decided that it was too different across IE versions and also do not want to require mouse wheel for a check.
  • [closed] Comment: you need to describe "visual focus" - something like "usually seen as a dotted rectangle surrounding a link. " Visual focus is jargony
    EOWG note: draft includes: "Check that 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." ... maybe Jim just missed that in quick read?
    EOWG Resolution: Edited it to : "Check that the focus indicator is clearly visible as you tab through the elements, that is, you can tell which element has focus, for example, links have a gray outline around them or are highlighted."
  • [closed] Comment: Page title: you mention checking with WAT toolbar in IE...need a link and what is WAT? Alt text (or anywhere in the page): need links to all mentioned toolbars Also, FF toolbar??? - which one - the one from UIUC, or Pendrick developers, or ??? +1 Wave is linked!!
    EOWG Resolution: Made the headings under "Using these Easy Checks" always visible and added "FF Toolbar and IE WAT " to "Tools" heading
  • [closed] Comment: in section: To practice checking alt text in BAD - what is BAD (I know, but newbies won't), make the link provided active
    EOWG Resolution: Made the headings under "Using these Easy Checks" always visible so "Practicing with BAD, the Before-After Demo" is visible. Also linked all BAD page URIs.
  • [closed] Comment: keyboard access and visual focus a test page would be useful
    EOWG Resolution: Added " To see visual focus with BAD" section