RE: [2.4] Summary of issues for guideline 2.4

Becky writes:
<blockquote>
BJG:  Is  this example a bit too HTML specific?  Do all web technologies
include the concept of headers?  
</blockquote>
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.
 
[...]
<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 means that the *style* can be detrmined programmatically, but I
don't see how it makes the *headers* programmatically determined. In
this instance, structure is completely bound up in presentation-- if the
presentation changesthe "headers" will be lost  (for example, through
lack of support for CSS or through substitution of a user style sheet).
People are smart enough to infer structure from visual presentation--
*if* they're experienced enough readers to do so (we're not born knowing
how to distinguish a header from body text<grin>).
 
<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. 
 
<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.
 
At any rate, I'll take an action item to make those unspoken assumptions
explicit, to avoid this confusion.
 
 
John

"Good design is accessible design."

Dr. John M. Slatin, Director 
Accessibility Institute
University of Texas at Austin 
FAC 248C 
1 University Station G9600 
Austin, TX 78712 
ph 512-495-4288, fax 512-495-4524 
email jslatin@mail.utexas.edu 
Web  <http://www.ital.utexas.edu/>
http://www.utexas.edu/research/accessibility 

-----Original Message-----
From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On
Behalf Of Becky_Gibson@notesdev.ibm.com
Sent: Sunday, April 24, 2005 11:07 AM
To: w3c-wai-gl@w3.org
Subject: re: [2.4] Summary of issues for guideline 2.4



Here are my comments on the 2.4 issues summary.  I've copied the
relevant parts of other documents and then preceded my comments with
BJG: 


>From Yvette and Wendy: 
>808. Benefits rewording proposal [8]
>
>Andi Snow-Weaver suggests that because jumping from header to header is
>currently only possible in assistive technology, we combine the
benefits for
>physical and vision disabilities by saying " Assistive technology used
by
>people with physical and vision disabilities can provide users with the
>ability to jump from header to header to get an overview or to more
quickly
>"skim" to the section they are interested in." 
>
>YPH: (Same as previous summary) I like it when the 'who benefits'
section
>adresses the benefits for each type of disability separately. I agree
with
>Andi that we should make it clear that this will require assistive
>technology in most of the cases. I propose to discuss this on the list
and
>then decide what to do about this example.
>  
>
>WAC: I propose to leave them as is, because the functionality is not 
>limited to assistive technologies.  Opera provides a way to jump
between 
>headers (s and w keys) -
<http://www.opera.com/features/keyboard/index.dml>
http://www.opera.com/features/keyboard/index.dml. 


BJG:  Is  this example a bit too HTML specific?  Do all web technologies
include the concept of headers?  For example, "Users with blindness or
low vision can jump from header to header to get an overview or to more
quickly "skim" to the section they are interested in."  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.  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 - there just isn't currently an assistive
technology that can accomplish that separation.   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.  Certainly the current state of
assistive technologies encourages the use of the <hx> tags and our HTML
techniques describe how to do that.  With the DHTML roadmap and role and
state information this becomes less of an issue because content can be
marked with a role of "header" or perhaps with a content specific set of
roles such as "by line" for a newspaper format.   Comments? 

>829. Linear reading order should be level 1 [9]
>
>Michael Cooper proposed to move the linear reading order SC to level 1.

>
>YPH: There was no consensus to move the requirement to have a logical
>reading order in a telecon on July, 2004. Since then, a lot of
re-writing
>has been done. The current phrasing is: "When content is arranged in a
>sequence that affects its meaning, that sequence can be determined
>programmatically". I think less people will have trouble with the
current
>wording being at level 1. I propose to re-vote on the level of this
success
>criterion and then close this issue.
>  
>
>WAC: I support moving this to Level 1. Especially since this is an 
>important aspect of making Web applications accessible. 

BJG:  I won't argue against moving this to level 1 but I have to admit
that I needed to look at the HTML techniques in order to completely
understand this.  With CSS sections of the document can be located
anywhere on the page but the linear sequence in the source may be very
different.  I understand that this only implies to content that is
required to be in some specific sequence but is it really the author's
responsibility because the Assistive technologies don't fully understand
CSS, yet? 

>955. TOCs should include information about presentation modes [12]
>
>RNID suggests that contents pages or navigation maps should also
contain
>information about presentation modes available in each area of the site
that
>they refer to. 
>
>YPH: (same as previous summary) I don't think I fully understand this
remark
>and worry that we cannot formulate this in a way that our audience will
>understand it either. This feels to me like something that is
applicable to
>a small number of websites only. Perhaps this can be incorporated in
the
>gateway techniques associated with creating TOCs or navigation maps.
>
>I propose to discuss what to do with this item and then assign some
action
>items to create appropriate techniques.
>
>  
>
>WAC: Agree that this seems like content for the Guide or Techniques. 

BJG:  I think perhaps RNID is suggesting that the visual presentation
used for each item be specified in the TOC or site map and agree it can
be covered in the Guide or techniques.  (although it does go back a bit
to my point above about is styling enough to claim structure?) 

>1214. 2.4: 1194.22-like SC should be level 1 [21]
>
>Loretta Guarino Reid feels that the skip-link requirement should be at
level
>1 to harmonize with section 508.
>
>YPH: I propose to take a vote and decide what level this SC should be
at.
>Perhaps, we first need to find out how people feel about following the
508
>levels in WCAG. 
>  
>
>WAC: Currently, our "skip link" requirement is the level 2 criterion, 
>"Blocks of repeated material, such as navigation menus and document 
>headers, are marked up so that they can be bypassed by people who use 
>assistive technology or who navigate via keyboard or keyboard
interface."
>If we agree to move the other item to level 1 -  "When content is 
>arranged in a sequence that affects its meaning, that sequence can be 
>determined programmatically. " then the only piece missing is the
markup 
>that groups the repeated material.  However, that *could* be covered by

>the existing level 1 criterion, "Structures and relationships within
the 
>content can be programmatically determined."  Then, the current level 2

>criterion for bypassing repeated material could become a technique.  
>Or...is that stretching it too much? 

BJG: agree with Wendy that this could become a technique because it
relies heavily on the technology in use in order to implement. 

>1393. what does "paragraph" imply? [29]
>
>Catherine Brys wonders if the word 'paragraph' refers to the logical
>paragraphs or visual paragraphs. 
>
>YPH: I think we just mean logical paragraphs, as you can never know how
a
>paragraph is rendered for a specific user. Perhaps we could add the
word
>'logical' to make this more clear. Also, I think the fact that we mean
the
>logical paragraphs will be clear from the techniques for this SC. I
propose
>to explain this to the original poster and then close this issue.
>  
>
>WAC: This seems related to 3.1. I don't think "logical" clarifies it
and 
>is not testable. 

BJG: I would question that we need this SC (Text is divided into
paragraphs. [V] ) at all. Isn't this covered by "Structures and
relationships within the content can be
<http://www.w3.org/TR/WCAG20/#programmaticallydetermineddef>
programmatically determined. [I] " ?  Then information about using
paragraphs can be moved into the Guide or specifically using the <p> tag
can be moved into techniques. 




Becky Gibson
Web Accessibility Architect
                                                      
IBM Emerging Internet Technologies
5 Technology Park Drive
Westford, MA 01886
Voice: 978 399-6101; t/l 333-6101
Email:  <mailto:gibsonb@us.ibm.com> gibsonb@us.ibm.com