RE: [2.4] Summary of issues for guideline 2.4

John M Slatin writes:
 > Becky writes:
 > <blockquote>
 > BJG:  Is  this example a bit too HTML specific?  Do all web technologies
 > include the concept of headers?  
 > </blockquote>

Shouldn't the term be "headings" rather than "headers"? "Header"
suggests "running header" or in these days of e-mail, the headers at
the start of an e-mail message, not headings in a document.
 > Good question, to which I don't know the answer. But I don't think the
 > success criterion would be invalidated just because some Web
 > technologies don't support the concept of a header-- that's just one
 > instance, not an entire class.

This brings us back to the assumption that if a success criterion is
not applicable it is deemed to have been satisfied. Some people have
objected to this idea but without ever offering a workable alternative.

 >  
 > [...]
 > <blockquote>Do we care how the headers are created?
 >  Unless they are created using <Hx> tags, then assistive technologies
 > nor opera will find them as headers and this example is not valid.  
 >  
 >  
 > This brings up
 > the issue of how to mark the structure programmatically.  I was recently
 > asked by a colleague about using CSS to style the "headers" in a
 > newsletter format
 > web site.  The headers were created using specifically styled divs -
 > they were not created using <Hx> tags.  When this content was tested
 > with a testing
 > tool, these visual headers failed because they were not created with
 > <Hx> tags.  But, it can be argued that they do meet the guideline of
 > structure being
 > programmatically determined as long as the "headers"  are all styled
 > with the same CSS class.  
 > </blockquote>

This is where the "conventional and supported" terminology comes in.
Of course, the representation of the headings in the markup of a
document is a guideline 1.3 issue.
 >  
 > <blockquote>
 > So, is the author responsible if the assistive technologies
 > do not understand how to separate out different content type via CSS
 > styling?  I had a hard time arguing that the content failed to meet the
 > guidelines
 > since the headers could be programmatically determined </blockquote>
 > I don't see how this is making the headers programmatically determined.
 > What can be programmatically determined here is that some bits of text
 > are meant to look different than other bits of text. 

Correct, and no current or reasonably foreseeable user agent can
reliably discern structure from presentation. Thus one of the
assumptions here has to be that unless the structural distinctions are
made explicit in the content, they aren't separable from presentation.
 >  
 > <blockquote>
 > [...]I think
 > we are saying that this is an acceptable way to format heading since the
 > last example suggests using aural stylesheet to specify different voices
 > for different
 > parts of the document.
 > </blockquote>
 > Good catch. I will take an action item to rewrite the example (I think I
 > wrote the one that's there now, so it seems only fair...). In writing
 > this example I made an unspoken *assumption* that the aural styles were
 > attached to markup such as headers, etc.  I further assumed that the
 > aural styling was the auditory equivalent to the visual styling that is
 > so soften associated via CSS with header markup-- to use presentation as
 > a *signal* for structure, while the structure itself is encoded in other
 > ways.  Thus the same structural component (headers, radio buttons,
 > whatever) can be associated with multiple styles suited to different
 > modalities-- you can have visual *and* aural styles associated with the
 > same element.  But if you have no style at all (not even the default
 > style sheets Joe reminds us of), if you have <hx> tags then the
 > structure persists across different presentations-- and, to go back to
 > the particular point at issue in 2.4, it can then be used for navigation
 > as a styled <div> cannot.

I agree with this analysis.

My only quibble is that the word "tag" is being used incorrectly in
much of the above ("element" is the correct term to use). Remember,
"tag" refers to a start tag, and end tag, or an empty element tag in
XML - it is a syntactic concept, whereas "element" refers to the
tag(s) and the content contained therein, which is what is actually
meant in the above discussion.

Received on Monday, 25 April 2005 08:40:36 UTC