Re: [orca-list] Blockquotes?

[Benjamin Hawkes-Lewis <bhawkeslewis googlemail com>]

Re: blockquote navigation

<blockquote> is not a styling, although it is sometimes misused for 
styling. Table and heading elements are often similarly misused and 
authors frequently fail to use <p> for paragraphs, but I assume you're 
not opposed to navigation by table, heading, and paragraph elements.

It's one thing to say another feature should have been implemented 
first, and another thing to call for the removal of a feature. Taking 
features out also requires development time.

I suspect the team's priorities are partly determined by ease of 
implementation, partly by personal interests, and partly by what feature 
requests have been made on the bug tracker. Quite possibly I missed 
something, but I can't find a request to read the titles of frames 
there, for example, even though it's a good feature idea. It's probably 
more efficient to request urgent features explicitly than complain about 
the addition of different features after the event.

Re: Text blocks

The Window-Eyes manual mentions "Next text" (X) and "Previous text" 
(Shift + X):

http://www.gwmicro.com/Window-Eyes/Manual/HTML/index.html?19_15morenavigationoptions.htm

When I tried it out, it ignored the size of text segments entirely, 
happily reading out even tiny snippets of text. Oddly, although it 
skipped links per se, it also read out title attributes from <abbr> 
elements inside links. Presumably that's a bug not a feature.

But JAWS has a similar feature that seems closer to your "large text 
blocks". According to the manual:

> Next Non Link Text use N. Moves the focus to the next block of
> non-link text that is larger than 25 characters.
> Prior Non Link Text use SHIFT+N. Moves the focus to the previous
> block  of non-link text that is larger than 25 characters.
>
> Note: This value can be adjusted in the default.jcf or browseui.jcf
> (Internet Explorer 5 and 6) JAWS configuration files under Set
> Options\HTML.

Dolphin's HAL manual says you can jump to the next text, skipping links, 
with Left Control + Left Shift + Cursor Right. It's not clear from the 
manual whether the text has to be a certain length.

Which of these models is better?

Some users at least seem to use the N key purely to skip groups of 
links. e.g. a request was made to implement this feature in NVDA phrased 
in the following terms:

> Also, in Internet Explorer, can you please add a quick key to jump 
> to next non-link text like in JAWS with the N key, so I can step over a large 
> groups of links without repeatedly tapping down arrow again and again? It just 
> makes me tired!

http://www.freelists.org/archives/nvda/04-2007/msg00343.html

If the use-case for this feature is basically to skip long navigation 
lists, we might (I suppose) be able to devise more efficient algorithms 
for doing so and create a "Skip navigation" command. Just a thought.

Re: background information

The Window-Eyes manual specifies precisely what properties are read out:

> * Description â i.e. Link, Picture, Edit Box, etc
> * Font â i.e. Arial, Verdana, Tahoma, etc.
> * Font Size â i.e. 10pt, 12px, larger, etc.
> * Font Style â i.e. Normal, Bold, Underline, etc.
> * Foreground â Color, either named (i.e. Purple) or in RGB (i.e. 255, 255, 0)
> * Background â Color, either named (i.e. Purple) or in RGB (i.e. 255, 255, 0)
> * ALT text if available
> * TITLE text if available
> * Filename if the element is an image

http://www.gwmicro.com/Window-Eyes/Manual/HTML/19_15morenavigationoptions.htm

Judging from:

http://developer.mozilla.org/en/docs/Accessibility/ATSPI_Support

It should be possible to extract most of this information from AT-SPI.

Would we want to add anything to this list (for example axis, scope, and 
headers attributes for table cells, or language information)? Do we want 
heuristics to try to put approximate names to colour values specified in 
hexadecimal? How about special treatment for microformats using the 
title attribute, e.g. to store an ISO date? Would we want key bindings 
for particular properties or groups of properties, or just one key 
binding for all of them? What order should they come in?

Re: large objects

I guess what these mysterious "large objects" are is something that 
should be explained in the Orca manual. Without knowing what it is 
supposed to be, it's hard to assess the feature. "Large" doesn't seem to 
be the right word for what it's doing, which based on a bit of 
experiment seems to mainly involve skipping over lists.

--
Benjamin Hawkes-Lewis

Hermann wrote:
> Hello Benjamin,
> to make a long story short: I think you've confirmed my point of view that 
> the blockquotes feature is not really necessary, since this styling of 
> webpages is often missused.
> Asking for different features, I referred to developping capacities; I 
> dodn't want to stress the fatct, whether they are comparable or not. Or, to 
> put it in a simple image: The team sometimes tends to serve the pie before 
> they 
> have served the beef; I prefere the other way.
> When I talk about textblocks, I suggest you download and install any 
> Windows screen-reader and check out how Jaws, Window-Eyes or the 
> Webformator handle this feature. It is simple a navigation helper.
> Large Objects: It's not the point whether I can reproduce the navigation, I 
> simply don't know what those "objects" are. It seems to me they can be 
> anything, which means, in the end, they mean nothing. A link is a link is a 
> link, and a heading is a heading is a heading. But I've absolutely no idea 
> about the systematics of that odd "objects"; that's why I call the "large 
> object" navigation stochastical.
> Background information: Download and install the mentioned 
> screen-readers/web-tools. Place the cursor on, let's say a link, Press 
> insert+shift+f1 in Jaws, insert+e in Window-Eyes or f11 in Webformator. 
> Then you know what I mean. And BTW: In Firevox the keystroke is 
> control+shift+q; press it several times and you know what I'm talking 
> about.
> I'm an everyday scren-reader user and a common web user and my point of 
> view is the user's 
> perspective, that's the whole story.
> Hermann