I'm not sure if that's a bug or a feature. <smile>  Physically what is there is not:

  Obituary HD DVD 2002-2008

But rather:

  Obituary
  HD DVD
  2002-2008

i.e. The thing is on separate lines.

My understanding from our UI lead is that we present what's on the line, therefore that's what we're doing.  Mike please comment on whether or not my understanding is correct and, if not, please write a spec defining the desired behavior.  Thanks!

I think we are doing what we intend.  I wonder why they would present a heading that way.  

It's in a narrow sidebar/column on the left and the heading is the title of the article.  That title doesn't have enough room in its narrow column, so it wraps onto subsequent lines.  When I make the font smaller, it winds up on two lines instead of three.

in that case, the presentation is consistent. Sorry I didnt have a sighted person at hand to ask them to describe the page for me.

none the less, I would be grateful for Mikes input on saying "link" on each line, might the user think it is several heading 4 links on several lines?

i.e, the presentation at the moment is exactly the same as seen for:

<h4><a href='url'>word1</a></h4>
<h4><a href='url'>word2</a></h4>
<h4><a href='url'>word3</a></h4>
...

Thank you

 
> none the less, I would be grateful for Mikes input on saying "link" on each
> line, might the user think it is several heading 4 links on several lines?
> 
> i.e, the presentation at the moment is exactly the same as seen for:
> 
> <h4><a href='url'>word1</a></h4>
> <h4><a href='url'>word2</a></h4>
> <h4><a href='url'>word3</a></h4>

I'd appreciate any ideas you might have on this one.  I don't love the way we are doing it now but it seems better than not speaking the header information for all lines.  We actually have the same problem for multi-line links so any good ideas you might have would be great. 

Refering to the attached html document, how does the following sound:

1. split long link issue:
<p>this is a <a href='url'>paragraph with a really long foobar which might be braking over several lines. Its a very long link-label which points to nowhere</a> end of paragraph goes here.</p>

currently spoken as:
"this is a paragraph with a really long foobar which might be braking over several lines. Its a very long link-label which link"
line down:
"points to nowhere link end of paragraph goes here."

maybe instead should be spoken as:
"this is a [keep focus here] paragraph with a really long foobar which might be braking over several lines. Its a very long link-label which" 
line down:
"points to nowhere link end of paragraph goes here."

i.e. we drop the "link" announcement of the first/intervening line.
and we only say "link" right at the end.
Further, if we could keep the caret focus before the link text, while we read the split link, once we have spoken "link" (on the second line) the user would land on the right object if they pressed tab.
Yes, just by listening we dont know where the link started, but we dont know that in the current design anyway.

This also solves another existing problem, namely saying link on the second line, which informs the user that they can tab across to "points to nowhere link", but actually they would end up on the google link.
Hopefully I havent forgotten anything here?


2. the solution of ambiguous split heading follows from above:
i.e. we do not say "heading level x" on each seperate line, but only at the end of the heading.
Again, focus needs to remain just before the heading start if it is split, while we read it.
This way pressing H will read out the heading (analogous to tab in the link case).

This design also eliminates the issue we have with:
<h4><a href='url'>word1</a></h4>
<h4><a href='url'>word2</a></h4>
 <h4><a href='url'>word3</a></h4>

Mike, does this sound reasonable?
Joanie, is this practical in terms of code?

Thank you

Created attachment 105748 [details]
html illustration

After talking with Joanie and Will about this we've decided to keep the current behavior.  My thought behind this is that while it does sound a bit awkword it does the best job of preserving the presentation of the actual page layout.  Also if I understand your proposal correctly it would be possible for the user to navigate to one of these elements and not always be placed at the begining of the current element  which is a change from other orca navigation behavior.   

sorry, where did I introduce a presentation layout change? If i did so it was unintended.

No, the user is always placed at the start of the relevant object, even if it happens to be split over several lines.

If i have been unclear with the description, I'll try to re-word it if you wish.

I might need some re-wording. <smile>

Right now, split objects or not, the default behavior is that moving by line moves you to the beginning of that line (rather than to the beginning of an object).  Will that still be the case with your proposal?

Removing Mike's name from the summary as I don't currently need info from him. Changing the status of the bug to NEEDINFO because I would like to be sure I'm fully understanding Jon's proposal.  If I am and if his proposal changes the caret navigation model, then I'll close this bug out as NOTABUG as per comment 8.  If I'm missing something and there's a way to have our cake and eat it too, as it were, I'm happy to give it a try.

Sorry for the sporadic followups, university work etc.

re comment 10, yes we will still move by line, definately not object.

Let me explain again, sorry for the original explenation.

<p>red long paragraph</p>
<h1>blue long title</h1>

if nothing was split, we would hear
"red long paragraph blue long title <heading level 1>"

lets say the heading was split into 3 segments:
"red long paragraph blue <heading level 1>"
"long <heading level 1>"
"title <heading level 1>"

proposed:
"red long paragraph blue"
"long"
"title <heading level 1>"

Yes, we dont know where the heading started, but neither do we know that information in the non-split case.
If the user specifically wanted to know what the exact heading is, they can press h/shift+h, to have the heading read out.

I'll elaborate further if this post is accepted.

Okay, I think I'm with you now.  What happens when we up arrow from the bottom?  Do we not speak the heading role until we have up arrowed to the line where it begins?

Forgot to say, that this also solves our ambiguation problem between split long headings and several contiguous headings.

sence we would read:
"blue"
"long"
"title <heading level 1>"
"orange title <heading level 1>"
"green title <heading level 1>"

(In reply to comment #13)
Yes please, but might that be hard to implement?
Basically we want to say "heading level 1" on exiting the object

My apologies for this comment-turned-dissertation.... You've been warned. ;-)

(In reply to comment #15)
> Yes please, but might that be hard to implement?

I won't know until I try.  I suspect I can pull that off, however. Not tomorrow, but as part of the 2.23/2.24 release.

What might be less doable, however, is this bit from your earlier comment (unless I'm misunderstanding you):

(In reply to comment #6)
> i.e. we drop the "link" announcement of the first/intervening line.
> and we only say "link" right at the end.
> Further, if we could keep the caret focus before the link text, while we read
> the split link, once we have spoken "link" (on the second line) the user would
> land on the right object if they pressed tab.

Let's say we have a link with the text "My Nifty Anchor" occupying three lines.  It is preceded by a line of text which contains "hello world" i.e. our full page content is:

hello world
My
Nifty
Anchor

Current behavior is this:

1. Down Arrow: hello world
2. Down Arrow: My link
3. Down Arrow: Nifty link
4. Down Arrow: Anchor link

Current behavior with caret position marked by an asterisk is this:

1. Down Arrow: *hello world
2. Down Arrow: *My link
3. Down Arrow: *Nifty link
4. Down Arrow: *Anchor link

Based on what you said for headings, here is what I believe you are proposing (just the speech-related change, no caret position):

1. Down Arrow: hello world
2. Down Arrow: My
3. Down Arrow: Nifty
4. Down Arrow: Anchor link

Question is, where's the caret for each press of Down Arrow?  When you say

> Further, if we could keep the caret focus before the link text, while we read
> the split link, once we have spoken "link" (on the second line) the user would
> land on the right object if they pressed tab.

I'm reading that to mean you want something like this (caret position marked)

1. Down Arrow: *hello world
2. Down Arrow: My
3. Down Arrow: Nifty
4. Down Arrow: Anchor link

Or alternatively, at step 2, placing the caret just after the "d" of "world"

That's the only way I know to "keep the caret focus before the link text while we read the split link".  That would be a change in our caret navigation behavior.  

If we move the caret line by line as we currently do, at the end of the split link we'd be here:

4. Down Arrow: *Anchor link

At this point, when the user presses Tab, he/she will not give focus to the My Nifty Anchor link; he/she will give focus to the next focusable object.

As an experiment, I just tried using Accerciser to set the caret offset to the beginning of a link without grabbing focus on it and then pressed Tab, hoping that this would accomplish what you are proposing.  It did not.  Whether we grab focus on the link or not, if we keep our current caret-navigation behavior (which I propose we do), I don't see how we can pull off Tab moving to the link that was just spoken.  Again, my apologies if I'm totally missing the point.

So.... In light of this, here's what I think is on the table:

1. We keep the caret offsets as we currently have them (namely the beginning of each line, regardless of whether or not we're at a split object).

2. We only speak the role of an object which is split across multiple lines when we've encountered the last bit of the object (i.e. when down arrowing, don't speak the role until the very end; when up arrowing don't speak the role until the very beginning).

Question for Jon:  What about braille?  Same thing as speech, or should we display the role on each line?

Question for Mike:  Whatdya think?

For what it's worth.... 

Personally, I'm not convinced this change is desirable.  Visually when I see a link that's split across multiple lines, each line of that link has the same appearance (say blue and underlined).  The fact that each line of the text in question is blue and underlined tells me only that I've got some linkage.  It may be that the link text has wrapped or it may be multiple links separated by line breaks.  If I care about this distinction, I typically tab to the beast and look at the rectangle that surrounds the object with focus.  In other words, my "blue and underlined" is Orca's "link":  I see it for each line; Orca speaks it for each line.  If I'm in the middle of such a creature, I know it visually.  If you arrow to the middle of such a creature, you know it through speech and/or braille.  And what you are proposing, I believe, is to remove some of that information.

That said, I think I can pull of the dropping of the role name if that's what is deemed desirable.

Phew!  I'm going to bed before it's time to get up. ;-)

(In reply to comment #16)
> My apologies for this comment-turned-dissertation.... You've been warned. ;-)

ooh not here too :) exactly what i am trying to escape from

> What might be less doable, however, is this bit from your earlier comment
> (unless I'm misunderstanding you):
> (In reply to comment #6)
> > i.e. we drop the "link" announcement of the first/intervening line.
> > and we only say "link" right at the end.
> > Further, if we could keep the caret focus before the link text, while we read
> > the split link, once we have spoken "link" (on the second line) the user would
> > land on the right object if they pressed tab.
> Let's say we have a link with the text "My Nifty Anchor" occupying three lines.
>  It is preceded by a line of text which contains "hello world" i.e. our full
> page content is:
> hello world
> My
> Nifty
> Anchor
> Current behavior is this:
> 1. Down Arrow: hello world
> 2. Down Arrow: My link
> 3. Down Arrow: Nifty link
> 4. Down Arrow: Anchor link
> Current behavior with caret position marked by an asterisk is this:
> 1. Down Arrow: *hello world
> 2. Down Arrow: *My link
> 3. Down Arrow: *Nifty link
> 4. Down Arrow: *Anchor link
> Based on what you said for headings, here is what I believe you are proposing
> (just the speech-related change, no caret position):
> 1. Down Arrow: hello world
> 2. Down Arrow: My
> 3. Down Arrow: Nifty
> 4. Down Arrow: Anchor link
> Question is, where's the caret for each press of Down Arrow?  When you say
> > Further, if we could keep the caret focus before the link text, while we read
> > the split link, once we have spoken "link" (on the second line) the user would
> > land on the right object if they pressed tab.
> I'm reading that to mean you want something like this (caret position marked)
> 1. Down Arrow: *hello world
> 2. Down Arrow: My
> 3. Down Arrow: Nifty
> 4. Down Arrow: Anchor link
> Or alternatively, at step 2, placing the caret just after the "d" of "world"
> That's the only way I know to "keep the caret focus before the link text while
> we read the split link".  That would be a change in our caret navigation
> behavior.  

yes keeping it after the "d" is what i would have wanted.

> If we move the caret line by line as we currently do, at the end of the split
> link we'd be here:
> 4. Down Arrow: *Anchor link
> At this point, when the user presses Tab, he/she will not give focus to the My
> Nifty Anchor link; he/she will give focus to the next focusable object.
> As an experiment, I just tried using Accerciser to set the caret offset to the
> beginning of a link without grabbing focus on it and then pressed Tab, hoping
> that this would accomplish what you are proposing.  It did not.  

that is a big shame, surely it should focus on the link because it isnt focused.
A hack might be to put the cursor on the last char of the previous object? "d" in world. (i dont know if you can actually do that)


> Whether we grab focus on the link or not, if we keep our current caret-navigation behavior
> (which I propose we do), I don't see how we can pull off Tab moving to the link
> that was just spoken.  Again, my apologies if I'm totally missing the point.

not at all, I think you have successfully decrypted my message :)

> So.... In light of this, here's what I think is on the table:
> 1. We keep the caret offsets as we currently have them (namely the beginning of
> each line, regardless of whether or not we're at a split object).

yes, agreed, unless there is any other way around it.

> 2. We only speak the role of an object which is split across multiple lines
> when we've encountered the last bit of the object (i.e. when down arrowing,
> don't speak the role until the very end; when up arrowing don't speak the role
> until the very beginning).

Yes please.

> Question for Jon:  What about braille?  Same thing as speech, or should we
> display the role on each line?

On initial feeling, same please.

> For what it's worth.... 
> Personally, I'm not convinced this change is desirable.  Visually when I see a
> link that's split across multiple lines, each line of that link has the same
> appearance (say blue and underlined).  The fact that each line of the text in
> question is blue and underlined tells me only that I've got some linkage.  It
> may be that the link text has wrapped or it may be multiple links separated by
> line breaks.  If I care about this distinction, I typically tab to the beast
> and look at the rectangle that surrounds the object with focus.  In other
> words, my "blue and underlined" is Orca's "link":

aah, that clarifies things, (sorry i had no idea how it is visually done, until your explenation)

> I see it for each line; Orca
> speaks it for each line.  If I'm in the middle of such a creature, I know it
> visually.  If you arrow to the middle of such a creature, you know it through
> speech and/or braille.  And what you are proposing, I believe, is to remove
> some of that information.

well, i thought we could reduce a bit of verboseness, and 
not loose information at the same time because it can be infered. 
What about having a toggle for it?
It might be debatable to say that the visual appearance is wrong, and that you shouldnt have to highlight the link to see that it is the same one, rather than several once.

> That said, I think I can pull of the dropping of the role name if that's what
> is deemed desirable.

> Phew!  I'm going to bed before it's time to get up. ;-)
localtime, gmt -7 ish?

After getting a better understanding of the issue here I don't really think I'm in favor of any change.  John and Joanie if you think I'm really incorrect here please push back.  

I for one am not going to push back.  See my comments in the paragraph beginning with "Personally".

Oh and Jon, gmt -5 until spring (then gmt -4).  :-)

no worries, thats me voted down alright :) although i do see your point. we are doing exactly what is visually being displayed.