- From: Wayne Dick <wayneedick@gmail.com>
- Date: Fri, 24 May 2013 06:31:39 -0700
- To: "EOWG (E-mail)" <w3c-wai-eo@w3.org>
---------- Forwarded message ---------- From: Tom Jewett <tom@tomjewett.com> Date: Fri, 24 May 2013 05:44:30 -0000 Subject: Easy Checks To: WayneEDick@gmail.com Hi, Wayne -- Some thoughts on Easy Checks, as requested (feel free to forward): First of all, I'm delighted to see this in W3C format -- it's got a lot of explanatory material, references, etc., that will save everyone else (like me) from duplication of the work they've done. I understand why they've had to include multiple systems (IE + FF), although FF can be used on any OS. In last week's AccessU presentation, I used the Easy Checks sections on Keyboard, Alt Text, and Forms to illustrate learning about specific barriers with the Before-After Demo. Some possible additional areas to cover (understanding that there's a tradeoff between "easy" and "thorough"): - Links: "All links must have text; each link's text should describe its destination clearly; if link titles are present, they should not duplicate the link text; duplicate link text should not point to different destinations, but links that point to the same destination should have the same text each time. (2.4) FF Toolbar, Information -> Display Link Details." (Quote from my own site, http://www.theenabledweb.com/smart-analysis.html, which also references the Easy Checks page for more information.) - Image maps: "Image maps should have equivalent information available (on the same page) in text form that is also keyboard accessible. If the map is generated from a database, then the equivalent (for example, a data table) must be generated from the same database information. (1.1) Visual check." (ibid.) - Tables: "Tables used for layout only should never have heading elements, should never be used to contain truly tabular data, and should never have summary attributes. True data tables should have each data cell associated with its column (and row, if appropriate) header or headers. Complex tables should have each data cell associated with all applicable heading levels. (1.3) FF Toolbar, Outline -> Outline Tables -> Outline Table Cells; then Information -> Display Table Information." (ibid.) - Movement. Visual check to be sure nothing is moving or flashing without some obvious way to stop it. Looking for an even simpler FIRST check, I've tried this one: FF Toolbar, Miscellaneous -> Linearize Page; Images -> Replace Images With Alt Attributes; CSS -> Disable Styles -> Disable All Styles. This is almost a visual "voice reader" simulation, except of course it doesn't say "image," "link," and so on. But if the page looks good this way (headings, organization, sensible alt text, etc.), it's probably close. If it doesn't make sense this way, then more thorough analysis is in order. (Try it on the inaccessible BAD Home page.) Comments on specific sections of the Easy Checks: Headings: I've thought a lot about starting with h1, and came up with this compromise: "Headings should match the actual semantic structure of the document and should be properly nested by level unless the h1 is preceeded by navigation. Headings should also be used to identify and navigate between groups of related links, and between links and main content. (2.4)" Contrast: I really like this section -- much more helpful than relying solely on the guideline (which nees to be updated). Zoom: might want to say *why* content overlaps and suggest some ways around the problem. I've found that there are some times when table layout is actually the only way to prevent overlap, however nice it might be in theory to use all CSS for layout. Forms: with the FF Toolbar, I also use Forms -> View Form Information, which requires a bit of understanding but might be less confusing than superimposing the form details on the page itself. (Your note "@@ - is this to (sic) complicated in FF?") Hope this is helpful for your meeting, Tom
Received on Friday, 24 May 2013 13:32:08 UTC