Re: assistive tech and layout tables

1.  The conventional wisdom is that it is not that hard to do programming tricks in the construction of layouts by TABLE to make the content linearize reasonably.  So not much attention has gone into intrapage navigation as a TABLE issue per se.

Intrapage navigation is an unsolved problem, indeed.

For classic page organizations with major functional subdivisions where the functional roles repeat across many pages:

masthead (fullwide, top) 
-- may contain toolbar
navbar (left)
body (center, possibly with flowing columns)
featurebar (right)
footer (fullwide, bottom)

The functional roles form a bag and do not imply any 'natural' linear order.  Here hierarchical access -- knowing that there are these functions supported on the page and being able to go to one that the user selects -- is more important than creating an author-fixed reading order. 

People vary as to whether they start with the table of contents or the first chapter or the first stop in the highlights tour.

The best I can offer you are things that have to be regarded as experimental.  But ACCESSKEY is worth working with.

This reminds me that in XHTML 2.0 we should ask that SUMMARY be made an XML substructure.  Promoted from plain-text META junk.  This is where the Table of Contents should go.  It goes in the user experience as part of an introductory page summary and it would make sense to incorporate in search reports, too.

Al

-- rough notes below (sorry for tone) below may contain a few details of interest

At 02:53 AM 2002-02-21 , jukka.korpela@tieke.fi wrote:
>
>Michael Fry wrote:
>
>> I've been asked to determine if assistive technologies, e.g.
>> screen readers, can be "directed" by HTML (or something else)
>> to read specific cells in a layout table in a particular order
>
>Your assumption that the answer is "no" sounds correct, since there
>is no HTML markup or CSS properties for suggesting a reading order,

Have you heard of TABINDEX?

But for the general content of the page, it is true that the governing philosophy in the design of HTML4 and CSS2 was that the linear order should be the order of the content in the source, and that placement if different was done in advanced processing such as CSS positioning.

This is still the best plan, and can be followed in SVG (see SVG access note) but there are outstanding problems in currently implemented HTML+CSS as demonstrated by the recent thread on multicolumns by CSS.  The problem would seem to have been handily solved by floating the navbar but then the navbar text would have to come before the main text in the source order.

>and any heuristic guesses would really be shots in the dark.
>There might be some work in progress to add features into CSS for this,
>but what comes closes in _current_ CSS (which is still poorly implemented
>in browsers) in section "Audio rendering of tables" in CSS2:
>http://www.w3.org/TR/REC-CSS2/tables.html#q21
>and it deals with rendering of tables used for presenting tabular data,
>not layout tables, and it's interested in the (very important) question
>of association data cells with headers, to indicate the meanings of
>data in cells.

>
>Even if something related will be added into CSS, it will take quite
>some to get it implemented. Besides, there would be the problem that
>we now have with a somewhat analogous construct, the tabindex attribute:
>authors who use it often _rely_ on it, causing problems to people using
>programs that don't support the construct at all.
>
>And, basically, layout tables are something we should try to get rid of,
>replacing them with the use of CSS positioning and other CSS features
>for suggesting layout. Authors who keep using layout tables might
>consider using tricks like Delorie's trick of using a dummy cell to make
>the order better when tables are processed rowwise, see
>http://www.delorie.com/web/ses-hint.html
>DJ Delorie presents that as a trick to make search engines "see" a
>document's content in a certain order, but it would work for speech
>synthesis, too, when performed rowwise by the table structure (and not
>according to what has been written onto the screen)
>
>> On a potentially related note, what do people think about providing
>> *several* 'skip navigation' links on a page, e.g. one for 'main content,'
>> one for 'main navigation,' 'local navigation,' etc.
>
>It might help, if the page is confusingly complex. I'd say it could be
>useful partial workaround if you don't want to _solve_ the problem. :-)
>But if you ask me, I wouldn't intuitively know, for example, what
>"local navigation" means. Local to what? (The page? The site? Some
>geographic locality?)

This is simple.  If there is hierarchical structure, there should be hierarchical navigation.  At all scales.  The point is that the Web cliche only supports inter-page navigation via hyperlinks and headers and footers and all that.  However, for users whose shared buffer of information with the computer is the fleeting moment of sound, more navigation infrastructure is required surrounding all contexts from the phrase up.  So this means that there needs to be navigation support for the structure of the content inside the scope of one page.  The common experience of the Web does not reveal this need to authors.

For more information read

HCI Fundamentals and PWD Failure Modes

http://trace.wisc.edu/docs/ud4grid/#_Toc495220368

>
>> Is there a reason
>> why are 'skip nav' links seem to be limited to one per page?
>
>Not really, I think, but they are commonly presented as a workaround
>needed to skip over _one_ bulk of irrelevant (for normal use) content.

Most of the comment I have heard from consumers is to consider sites which have gone beyond one skip link to be overkill to the point of absurdity.  However, a link from the foot to the head is welcome.

When the page is of sufficient interest, the user can move through it reading all text etc.  The skip is required for a quick way to determine if the user wants this page at all or not.  The motivation for the 'skip nav' link is most clearly seen in online shopping where there is one bit of business per screen (per page), and scores of completely redundant links ahead of that one bit that it new.


For 'go to navbar' etc. try ACCESSKEY.

A table of contents is good but for the standard parts of a page this can be implicit via ACCESSKEY.

What I did in this regard was to put the table of contents on a separate web page.  Oddly enough, this is what the DAISY book structure does.

>That is, all the different sets of navigational links are regarded
>as one bunch, to be skipped. If they contain, say, a table of content
>for the current page, then that set of links is not skippable in the
>same sense as "navbars" are. A table of content, which is of course
>not normally an HTML table but a list, is what users normally start
>with, so I'd make a "skip nav" link point to the start of the table
>of content. If the user wishes to skip to the beginning of the
>content proper, e.g. because he has already studied the table of
>content during his previous visit to the page, he can conveniently
>use the first item in the table of content. Assuming that the items
>there are links to the corresponding parts of the text, of course,
>as they should be.
>
>All these "skip over" links are workarounds, not solutions. It is
>symptomatic that we find it necessary to use _verbs_. Cool links are
>nouns or noun phrases, not verbs, since they refer to something, instead
>of telling to do this or that. (Actually, it isn't always necessary
>to use verbs for "skip over" links; "main content" or something
>like that might be better.)

This is an elitist fetish that is not well connected with how real people relate to their browse experience.  "Click here" is the native language of the Web.  Get over it.

The most universal writing style is not the inline jump-enabling of nouns (which I, as a compleat elite, do love) but Gopheresque paragraph, references, paragraph, references block structure where the links are set of as navigation-dedicated elements of the micro-structure.  Overloading is cool and confusing.

>
>For constructs like a <pre> block or other things that are potentially
>very problematic in some modes of use and to some users, "skip over"
>links are the practical solution at present, unless you can feasibly
>put the problematic content itself behind a link, on a page of its own.
>But it is then important to make clear _why_ the user might wish to
>skip over something and what (if anything) will be missed that way
>and, hopefully, where a more accessible presentation is available.

This is a good point.  If you must use ASCII art, that merits a skip link.

But the structure should be in the page and the verbs in the browser.  ACCESSKEY is as close as we come today.

Al

>
>--
>Jukka K. Korpela, erityisasiantuntija / senior adviser
>TIEKE Tietoyhteiskunnan kehittämiskeskus ry
>Finnish Information Society Development Centre
>Salomonkatu 17 A, 10th floor, FIN-00100 HELSINKI, FINLAND
>Phone: +358 9 4763 0397 Fax: +358 9 4763 0399
>http://www.tieke.fi  jukka.korpela@tieke.fi
>

Received on Friday, 22 February 2002 09:26:37 UTC