Re: Easy Checks

Tom,

That will be very helpful.  We had  a long list of other things to
cover today, so I didn't have to rush you.  Sorry and Thank You.

I think you laid a roadmap for extending Easy to Intermendiate.

Wayne

On 5/24/13, Wayne Dick <wayneedick@gmail.com> wrote:
> ---------- 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 19:22:46 UTC