JW Not sure who's chairing this one, if JG wants to our I should. Since it's during WCAG I'll go ahead. Congratulations to JG for receiving an award.
JG "Academic professional excellence award." nominated by the college. recognition by peers through the university. did not mention accessibility.
GJR so no minority opinions then?
JG they didn't talk to any UA WG folks.
JW essentially there is a longstanding issue with structured documents. if the document structure has been marked up correctly, one could navigate through it. knowing where one stands and then locate particular points and then browse the document by kinds of content. e.g. moving through an outline to read headings in order to provide an overview of the contents of a document. there are issues that relate to both UA WG and WCAG WG. What markup conventions should be used for the UAs to interpret? Two fold issue:
1. what can be retrieved from DOM. connection to hierarchy and XML tree structure.
2. use of appropriate markup so that the structure is explicit.
Al has suggested that the document hierarchy is not isomorphic to the navigational hierarchy, at least not in all cases. We need to consider UA capabilities and future versions of WCAG to make sure they are in synch. In SVG one has the advantage of identifying portions of an image. Concept of structural hierarchy and navigating it. Can apply to documents, images, and multimedia. Jon - want to elaborate on any aspects of the issues?
JG From what I see, there is agreement that the MAP element should be used for collection of links. My understanding is that "title" attribute of MAP should be a label for what the group of links is. The navigation issues are still cloudy. For example, I've got different stuff on the page. I use speech output. I go to Yahoo - navigation bars, ads, info, that is static and a dynamic area. When linearized, the static stuff is at the beginning. The 2 questions I have: can we mark up the 2 areas? MAP is clear, but what about a list of phone numbers? A New York Times article? When someone comes to the site they have to go through all of the links to get to the new information.
CS would changing the page title help with that?
JG possibility. more specifically, is there an easy way for people to get to the new info?
GJR individual pages should have individual titles. using a hotkey, someone could quickly get the title. we should have invited henter joyce (HJ) as they have support for this. Jaws will skip over what it has run into before.
DP on a shopping site, and click "buy" it leaves you were you were so you can continue on. it's very helpful.
GJR another thing, that both Productivity Works (PW) and HJ do, is structured navigation. the ability to move by element or header. these are implementation scenarios. not sure if heuristics have to do with markup or other techniques. we ought to find out what they are doing.
JG that's my main question: is this a UA function? rather than require more work for authors, is there sufficient info for UAs?
JW depends on if there is structure in the markup. if lists, tables, etc. are not marked up then it will be impossible for the UA to compensate. HTML does not encourage the use of proper container elements to designate the scope of content. Even tho headings may be used correctly, the section to which it applies may not be clear since there are no specific container elements.
CS might also work to have something like tabindex for named anchors.
GJR tabindex is allowable to put in named anchors but it is not supported. HTML spec says that A element can take accesskey.
CS i want to define where people can go. it makes sense to skip over nav if not using it. i want them to go to ads.
GJR offering blind user same functionality as sighted user. how many people actually read the ads?
CS if you make it easy to skip over, developers will have issues with funding. but my issue goes beyond ads.
GJR two-fold process. the functionality could be used to skip "foo" it could be used to return to "foo."
JP the UA could use that info in the user interface.
GJR when we had the discussion on GL re: reformatting pages with Scott Luebking I said that would not fly. authors don't want ads on the bottom.
RS and they won't want you to skip the rest.
GJR i don't see the difference between someone who goes to Yahoo and their brain is trained to start at a certain place. despite things beeping and flashing, they ignore. Most people when they get to a page with a lot of ads will ignore.
DP I browse as a disabled user, one of my favorite things, is to go to the first field on a form. i don't even listen to anything up to that point.
CS my concern is not so much for other users of auditory interfaces, like the car computer, people who are supplying content will want their ads to be read. the user and the author should have some control.
GJR yes, we need to be careful. there are times when you want that info.
JW no user should be forced to read anything on a page. as a print user or speech user they should have a choice. it should be possible to avoid or return to particular pieces of the content and to move through the structure as quickly and easily as possible.
GJR I am loathe to use comparisons to hard-copy print media, but when people read magazines, there are lots of gutters on the far right column. some people go specifically for ads, some people don't. this is obviously an issue wrestled with in other media. We want to satisfy both sides of the equation: skip over and return to.
CS that's reasonable. my initial point was that i'm not certain that existing markup handles this scenario rather than trying to find a kludge.
GJR interested if the kludges that are already in effect could point us in a direction to solve the problem.
JW where is the markup missing? DIV could be used to denote block level content. title could be added to it for human readable characterization.
CS not saying that there are missing feature, but that we ought to explore it. DIV makes sense. but is tabbing between DIVs supported?
GJR but we can consider it here. Al has floated such a proposal. Here is navigation section. here is content. etc. Ads are routinely skipped over by people who are blind because there usually is not any info. You usually get "click here" or file size. By not assigning alt-text to areas the areas become useless.
JW we have techniques to markup image maps and correct markup for groups of links. i don't think we have any discussion for the proper use of DIV elements. links, tables, forms, are there because of distinctive markup and can be readily identified. At one level, provide appropriate container elements (DIV in HTML, group in SVG) there is the larger issue of whether there are cases that even if this is done the tree that occurs in the DOM corresponds to a good navigation tree. is there a need to provide support for navigational features. that has an impact on UA capabilities more so than markup. question of relationships that are not reflected in document tree that need to be represented. AG raised it in his message.
@@WCAG WG investigate the proper use of DIV.
AG want to respond to CS question. i don't see any difficulty in devising a markup plan that would work in the UA. I suggest using things like CSS selectors to provide a precedence order, e.g. title vs no title. This is an area for forward motion, but hard work. Won't fly unless we can present it to the author. The author has to care about it enough to articulate the structure.
CS and take the download hit as well.
AG perhaps 3% character hit.
CS we have hour long arguments about adding bytes of any amount.
AG interesting. we get very different reads on this issue. history with LINK element to provide info. but it died because authors did not use. it was not in the default presentation of the page. it is technically possible to use a DIV tree...i'm concerned that we take the theory of the structure and feed it to the author.
CS keyboard shortcuts and faster navigation for power users.
AG still needs to be something in the markup to drive the keyboard shortcuts. it takes a while to tab through stuff if you use the tab order.
JW an absolute requirement (p2 level) that appropriate markup should be used. we need to provide examples and make the necessity as clear as possible...
RS in the next release of UAAG??
JG If just techniques, put in techniques. we have other checkpoints related to moving to active elements.
GJR there is a responsibility of people who rely on advertising revenue to set up standards that the content that they pull in reformulate pages.
CS e.g. banner ads. saying it should have appropriate alt-text?
GJR yes. and the container should be marked appropriately.
AG only in the actual graph of how many hands it pushes through, it is more removed from chief editor of the page. my scenario: go to advertiser and ad agency. if they want to provide alt-text, that's cool. but to the extent not informative in audio, should get out of the way in audio.
GJR easy argument to make to advertiser: you're missing people. if they're ok with that then ok
CS there are advertisement aggregation companies. that may be where alt-text gets lost.
GJR suggest that to EO group. we need to raise consciousness with them.
DP that knowledge would be welcome.
@@HB suggest to the EO group that they need to raise consciousness with advertisement aggregation companies (that's one place where alt-text might be getting lost).
JW concerned that examples have all been so HTML-specific. With this next version we are hoping to address wider variety of technologies. What type of structure and semantics should be provided for different types of content.
GJR we could affect great change by using XHTML as baby steps for authors...it's XML with training wheels. increasing functionality of it. take the power of example. do a technique in HTML. then XHTML. then port with use of RDF to XML. we have a blueprint for people to migrate to XML.
@@GJR show what a possible blueprint migration from HTML to XHTML to XML might look like.
JW Yes, a great idea. One of the principal ways we can develop the relationship between HTML and XML to show how structure will be beneficial. In a generic markup language such as HTML there is a limited range of semantics. In this context, MAP designates an image map or a navigation cluster of links, generic DIV while useful to capture structure does not give semantics. There are ways to address it, one of which is to use an attribute (class) but we don't have conventions for values to use. Or use human-readable title. But, there are issues with capturing specific semantics in using general containers elements. Therefore, using XHTML module with XML defined in it, with a style sheet....techniques need to be developed.
@@WCAG WG create techniques that show how to use XML with a style sheet.
WL encouraging the use of CSS in effect causes the author to become agent of structure insertion.
IJ misuse of style to convey semantics. sounds like since applying style and adding semantics wrong way to go.
JW think the argument was that when using style sheets to convey presentation, a tendency to use proper markup.
IJ would like to be shown that that is the case.
AG that is a good candidate for the survey - to survey what is out there.
@@?? Is it the case that when style sheets are used to convey presentation that proper markup is used? Do pages that use style sheets use more structure markup than those that do not use style sheets?
GJR a friend filling out a tax form, did not fill out a piece of it because it was not in bold. people have been trained to look for style. it gives people scannability.
IJ your argument is that there are semantics in style and that's a good thing, but that you shouldn't convey semantics first through style.
AG I would not believe WL's claim based on what comes out of word. IJ - ideal way of doing it. making distinctions is valuable. making them in style sheet is more valuable.
JW there is a dependency. if proper markup is used, one can reflect the structure using the style sheet in a particular presentation medium. high-quality visual design is intended to reflect the structure and semantic distinctions as clearly as possible. from author perspective, consider that the markup captures the structure properties and style sheet will act upon the markup to create presentation that captures distinctions. then get rich rendering in the variety of platforms you provide style sheets for. one thing we have not addressed is to highlight the relationships between style and well-designed markup. there is an argument in using markup and adding style to make sure the distinctions are expressed in presentation.
GJR need to address. one of the more common uses of style sheets - to supplement what is there.
WL rather than beautify it.
CS because people have to support older browsers.
JW even in XML document the purpose of the SS is to provide presentation of semantics in the markup. one should think of dependency in that way and the relationship between good markup and high quality presentation.
HB more than one style sheets for clients. the SS should be generic to an XML application. with recursion, the style has to handle recursive objects. those represent significant challenges for e.g. going from braille to visual style sheet.
AG the SS ideally are not into the specific application but into the vocabulary of app widgets - paragraphs or toolbars. i thought that one of the things you said was the idea that, "who are designing people so that it shows up well is radically different media?" people are getting more interested with phone stuff in market.
WL that's why a "C" in CSS.
AG perhaps another one for harvey. i'm interested in WAI getting as smart as can about industry. where find people practicing what we preach.
JG I have some immediate concerns. Not suggesting that any guidelines be changed, but I am hearing about bridges to new technologies, are there things that we can use beside MAP to markup this info? how long to resolution? 3 months or so?
JW already today, the use of container elements and structural elements is important practice. guidelines and techniques in WCAG already suggest how to do that. at the block level that make up macro structure of document...a generic markup language does not provide semantics. need to use generic div elements. use title or class to provide semantics. in XML we have more options. I would be interested to where were people think more work needs to be done and what issues should be settled soon.
AG there are 2 examples that have constituencies in author population. in ISO, they require that headers have to be nested properly. if there is an HTML page that claims it is ISO-HTML you can apply their algorithm and say these are structural divisions. Similarly, there are few people converting from latex that use divs. I've been reluctant to say that UA should try to get UAs in large to do this. It would only be beneficial for small percentage of page problems.
CS but if in the UAs more authors will use it.
AG yes, definite chicken and egg philosophy. but want mock-ups to show authors to sell them.
@@WC find examples of ISO-HTML pages that are conformant (i.e., have properly nested headers).
@@WC check out ISO-HTML algorithm to determine structural divisions. take to ER WG.
JW that's authoring tools, eh?
IJ am I hearing Jon say, "tell me WCAG techniques to help UAs identify navigable structures."
IJ there are 3 classes of things i can think of:
IJ it is useful to identify key components and what can use legitimately. against twisting. want to make sure schemas meet the needs of these groups.
JW reaction to technique that says, "enclose sections of doc in a container element with div and class"
IJ don't want to push to checkpoint level in UA.
JG not talking about checkpoints in UA.
IJ if in techniques, there's no conformance with that technique so what will be the impact on UA?
RS anything in WCAG about your suggestion?
AG it's there in generic language. it says "structure you page well."
IJ I have been against "class=navbar"
WL this is something for people making UAs.
IJ solution is not to give them specific cases to deal with but language to do that properly. still waiting for schemas.
GJR modularized techniques as baby-steps to HTML (not optimal)..
IJ how get any browsers to support it?
RS i don't like hacks because they break. i'd rather have a solution that you know will work. let's work on a second one, after we get this out that talks about XML solutions.
WL browser won't do this...maybe a screen reader will....regular UAs never will.
CS power users.
JW if there is a requirement to traverse tree structure that will pick up any container elements irrespective of the semantics. reading of labels on them is up to the UA. the legacy DIV element would be supported automatically as far as the UA is concerned. then, appropriate authoring practices to use it. agree that generic elements such as DIV with class attribute that has no agreed upon usage is open-ended and no way to develop common usage patterns.
WL whatever happened to object?
IJ not well supported. not in IE5, NS6, Opera4.
AG report from HTML WG is that Object is viewed as a camel. no one was happy with it.
GJR if we want to retain OBJECT and its power, we need to strip out attributes that were thrown in to move forward.
AG that is continuing a thread in PF.
JW continue that in PF.
IJ seems to me that the topic that has been in UA for a while, "how should the UA provide useful navigation and what can we get out of content to identify them?" there have been many discussions about what is available in markup and it seems that we end up saying, "there is limit to what we can rely on in the spec and we need schemas." the dependency fell away and the issue became more in the realm of UAs. given markup what functionality can we provide. "allow the user to navigate easily to important components..." but requires nothing special from authors. AG pointed out that just providing nav mechanism based on spec is not sufficient. have not heard any more about what authors can do to help UAs pick up on things. not sure we need additional techniques.
AG what authors can do: go back to the amazon rewrite.
@@WCAG WG review AG's amazon rewrite.
IJ i have not heard any new information about what authors can do. we had a victory with map for navigation mechanisms. have people identified other components that we can identify with reliability with standard HTML. if not, should we focus on ...
AG back to headers, forms, etc.
IJ yes, but that is not beyond what HTML specifies. if we are saying to UA and authors "use specs" then nothing else to say.
AG even tho map was designated for image maps...
IJ let me get to it easily, let me skip over it, let me delve in.
JW we know that the authoring techniques: use markup according to spec, use structural markup (e.g., DIV), use more specific semantics in markup. on UA side: skip particular elements, read elements... if I were to suggest that UA were to navigate through tree would it be appropriate to achieve this? when there are relationships in markup (siblings but not in container elements) bring doc tree in synch with semantic tree, some way to determine structure with transformations?
AG can you focus on one question at a time?
IJ 1st question: what is the minimal requirement for UAs to provide structural navigation?
JW not min. req. but would the option of traversing the doc tree be appropriate way from user's perspective and UA developer to satisfy the requirement.
RS use DOM as path to get element. within that path the user should have option to nav by major structures. they have to be able to access all elements in the document. as simple as that. following dom path to get to elements. use significant elements to skip over details.
WL not just headers - everything.
Cs add accesskey to divs, spans, etc.
GJR can add to : anchors, forms, etc.
CS on DIV, does not do anything. could solve problem.
JW a kludge.
CS why not allowed.
JG can not take focus.
CS can take tabindex. it highlights. in IE5.
IJ working draft: user interface css3. some are pushed to this document. with the "enabled" class you should be able to say that something belongs to tab order.
JG /* summarizes */ not much more we can do with HTML, schemas give us more flexibility.
@@GJR re-ping glen gordon and mark hakkinen to find out what they are doing to skip over repeated text. could be simple comparison. good for techniques doc.
/* many will be at ER meeting next week */
JW will have meeting next week, and whoever can make it will.
$Date: 2000/11/08 08:30:15 $ Wendy Chisholm