W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > October to December 1998

Minutes Dec 9 telecon

From: Daniel Dardailler <danield@w3.org>
Date: Wed, 09 Dec 1998 19:20:17 +0100
Message-Id: <199812091820.TAA10169@www47.inria.fr>
To: w3c-wai-ua@w3.org

Chair: Jon Gunderson 
Date: Wednesday, December 9th
Time: 12:00 noon to 1:00 pm Eastern Standard Time 

  Harvey, Jon, Scott, Al, Charles, Danield, Ian, Marja

Jon intro: everybody needs to look at the issue list

Scott: is the chucking item in here
Jon: will check

Al: Form sequential navigation may be combined with different kind
    like hierarchical nav.
Scott: careful about hierarchy, people get confused about what
    hierarchy means. Sometimes it's like "jump to end of something",
    which mean up one level in the tree for the agent.
Al: OK
Jon: suggestion ? Al can you take it to the list ?

Danield: related to Browser sniffing, it is a server issue but we
    could ask the HTTP WG to add a note about it
Charles: do we want to add negocation of UA capabilities
    there are other ways to do that (CSS + media)

Jon: Table rendering in CSS, like speakheader
Danield: In PF, while looking in CSS2, Jason made a proposal that
     didn't get in
Jon: DOM is another way
Ian: ask for rendering of table cell as block
Charles: we lose contextual information this way
Danield: how is it different from ignoring table markup
Charles: consider cell as block, not row
Danield, Scott: API is a must, level of native table linearization is
       the issue.
Scott: not hard to do, Opera does it

Jon : can attach a right click script to do linearization
Danield: don't know how to do that
Al: different from JavaScript applied to all pages, it's VBscript

Jon: related to point of regard and navigation
    Screen reader already have 2 different cursor
Danield: seem to remember Opera does cel to cell selection navigation

Ian: combine the guideline: goal is to provide cell by cell access
     linearize is one way, cell by cell navigation is another
Jon: looks OK

Charles: would like a native way in the browser to navigate link,
   header, form controls, *and* table cells. Less interested in
   linearization, more in this richer keyboard support

Ian: should we ask that both linearization and navigation be
     implemented or just one.
Al: they are different are both needed
Ian: then they do not adress the same issue/goal ?

Danield: somewhow navigation is more important because it has to be
    done tightly coupled with the browser

Scott: process question: since I'm not attending the f2f, how are
    decision made ?
Ian: we make consensual decision at meeting but nothing is ever fixed
    and the mailing list can reopen issues. The chair cannot says:
    sorry this is a closed item to the person that didn't come to the

Jon: wonder when this will be implemented
Charles: better ask now than later...
Discussion/chat follow, no more notes
Received on Wednesday, 9 December 1998 13:20:20 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:49:21 UTC