- From: Daniel Dardailler <danield@w3.org>
- Date: Tue, 10 Jun 1997 17:17:39 +0200
- To: Al Gilman <asgilman@access.digex.net>
- cc: w3c-wai-wg@w3.org
> Shouldn't the TITLE attribute convey the information about the > destination of a link ? > > I have only tried two, by I have yet to find a browser that does anything > useful with the TITLE if it is annotated onto this anchor in the HTML. > This raises the question: "For the purposes of what timeframe are you > asking? Now or in the ideal future we want to migrate toward?" In > what follows I will try to separate responses related to a) best workaround > now and b) framing requirements for a better solution. The discussion surrounding timeframe are important enough that I'd like to start a new thread about it. Some comments on this particular item. > Given the currently deployed client behavior [range] the best workaround > now is to use the ALT tag for an alternative anchor content (like its > acronymous name) and not for a descripiton of the image. OK, that's one point view, that I tend to agree with. > In terms of framing the context for a solution, I 100% agree that the > model of the process has to distinguish three things: > > 1 - the a_priori characteristics of the resource I appreciate the s in characteristics. > For the purposes of here-and-now guidelines it is absolutely > necessary to deal with the demographics of browser behavior > for the browsers (including versions, sigh) in the field now. I want to understand why "it is absolutely necessary". Your answer will probably better fit in the timeframe thread. > Descriptions for sensitive maps should also embed all the links > in the map. Client side image maps solve the problem using a different but similar mechanism. > As the size of the display pipe > goes down, more and more of this infrastructure wants to migrate > into implicit information displayed only on explicit request and > not be presented in the default "display" view. One would hope that Style sheet will help achieving that. > Appropriate accomodation of browsing is not just changing or > stripping fonts. The focus or viewframe is going to be scoped > differently, as well. Not only breadth of topic but in depth of > detail, as well. One way is for the content form to contain > priorities and the preferences to play off the priorities to > prune the data presented. I'm not sure a priority schema is required, vs. the existing presentation/structured-content dichotomy that SGML is championing. > The navigation buttons > would not turn into presented audio but be aliased to standard > navigation commands. Good point. I guess something in the line of LINK and meta-data is needed (more semantics in the markup). > The more we expand the data model, the more important it is to > understand that there will want to be filter-driven hiding on the > way to the non-visual browse display. > > What do you think, Mark? Am I in the ballpark? Who is Mark ?
Received on Tuesday, 10 June 1997 11:17:54 UTC