RE: [2.4] Summary of issues for guideline 2.4

I agree that the example is too HTML-specific.   What about 
specifically-styled XML elements using CSS (in the context of the 
discussion following re: "div")?

BTW, what is reference for aural styling mentioned?   Appendix A of CSS2.1 
(non-normative for CSS2.1)?    Functionality in CSS3 Speech Module[1]?

[1]: http://www.w3.org/TR/2004/WD-css3-speech-20041216/

At 05:01 PM 4/24/2005 -0500, you wrote:
>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.utexas.edu/research/accessibility>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