Comment 1 by jteh on 2011-04-28 22:37
The issue is that the dot is after a link, so it is actually treated as a separate word. One reason for doing this is so that "a"b, where the quotes indicate a link, doesn't get spoken as "link ab" but instead gets spoken as "link a b". Coincidentally, Mick and i were discussing this issue yesterday. We're considering changing it in future to do the former, but you will get "link ab" in my example.

Comment 2 by deependra230 on 2013-11-28 19:12
Yes, "a"b is parsed as start(link)+a+end(link)+b.
And speakTextInfo() in speech.py ensures that after each control field, a new chunk is started(variable 'inTextChunk' does this). That is why 'b' is considered as a new chunk i.e. dot in our case is considered a new word and therefore gets spoken.
Parsing this way makes sense too because for each control-start there has to be a control-end and "a"(the link text) is enclosed between one pair of such control-fields.

And since parsing is done using expat parser of xml formatting which is standard, i think we should not interfere with it. Instead, what i think we can do is that, in speakTextInfo() we should keep a inLink flag similar to inTextChunk which we should set true after link controlstart comes. Then in controlend case, if this inLink is true then keep the chunk going(and make inLink false) otherwise default i.e. start new chunk. I am adding the screenshot of snippet changed. If this doesn't interfere with other functionality, i think we are good to go.

    #variable initialization
    inLink=False
    inTextChunk = False
    #some code.....


        elif isinstance(command,textInfos.FieldCommand):
            newLanguage=None
            if  command.command=="controlStart":
                # Control fields always start a new chunk, even if they have no field text.
                inTextChunk=False
                fieldText=info.getControlFieldSpeech(command.field,newControlFieldStack,"start_relative",formatConfig,extraDetail,reason=reason)
                # If a link has started
                if fieldText:
                    # Of course, we should get the link information from the field
                    # rather than ascii encoding and then searching 'link', i don't know how to do this
                    if 'link' in fieldText.encode('ascii','ignore'):
                        inLink = True
                newControlFieldStack.append(command.field)
            elif command.command=="controlEnd":
                # Control fields always start a new chunk, even if they have no field text.
                # with one exception - if it is control end for a link
                if inLink:
                    inTextChunk=True
                    inLink == False
                else:
                    inTextChunk=False
                fieldText=info.getControlFieldSpeech(newControlFieldStack[newControlFieldStack[-1](-1],newControlFieldStack[0:-1],"end_relative",formatConfig,extraDetail,reason=reason)
                del)
                if commonFieldCount>len(newControlFieldStack):
                    commonFieldCount=len(newControlFieldStack)
            elif command.command=="formatChange":
#REST CODE-----

Comment 3 by jteh on 2013-11-29 00:14
The question is: is it bad that we hear "link ab" even though the "b" isn't part of the link? It's probably a rare enough use case that it isn't hugely important.
If we ever do provide an option for "link" to be spoken after the text as some people want, this can't be fixed. You will always hear "a link b", or in the case of a full stop, "a link .".
Finally, are links particularly special here? Should we be doing this for other control fields as well? My feeling is that we shouldn't. I guess it can be argued that links are special because they can occur in normal text flow, though clickables can as well.

Comment 4 by deependra230 on 2013-11-29 05:06
i think it is fine to make "link ab", because there are no other cases. I mean if 'b' is a text then it is spoken continuously by default and we don't interfere with its formatting. In case of other punctuation marks(i have tried '?', '!') it works well either way. So i don't think it will interfere with any other case and is fine to implement. If you can find some cases where this will cause problems?
Yes, if 'link' is spoken after the text, then it can not be fixed. Control field will take charge and b will come in a new chunk.
No, we shouldn't do this for other control fields, i also think so. We are fine unless someone complaints about something or we can find some cases.
So should i implement it properly and commit? Also how to get the link identifier from the control field, can you give me some insights?

Comment 5 by deependra230 on 2013-11-29 05:50
One more thing, in case of MS word too, this dot after a link is spoken. Additionally 'out of link' is spoken after link text irrespective of the extra-detail flag. I think to keep consistency across various applications, it should not speak 'out of link' after the text if the extraDetail is false. Doing this automatically takes care of this dot(MS word object does not use control fields, only format fields). Other formats like 'spelling error' also function according to extraDetail flag, so i think inserting 'out of link' only when extra detail is set, is standard to implement.
If you think this idea is fine then i will implement and ask for commit?

Comment 6 by jteh on 2013-11-29 07:17
Actually, we realised there is one problematic use case that we've seen in the wild. Sometimes, there can be horizontal navigation bars with no spaces between the items. If any item other than the first isn't linked (e.g. because it's the active page), its text will be squashed into the previous link; e.g. "link homeabout".

I don't follow how doing this fixes the "out of link" issue for Word. Unless I'm missing something, that needs to be addressed separately. It requires changes to the code for speaking format fields.

Comment 9 by mhorspool on 2014-04-21 01:10
Create a complexSymbol definition for ". stand-alone". The regex should match a full stop if and only if it occurs by itself. Having said that I don't know enough regexp to code that! I wrote one for a full stop which occurs at the start of a line and it did fix the problem but it is not as foolproof.

@jcsteh: What do you think about this now? Honestly I'm quite accustomed to the current behaviour and I think I even prefer it over the alternative approach that has been brought up here.

I think it's very low priority, but the fact that there are several duplicates of this suggests a few users do care about it. Setting p4.

I guess one way we could get around the problem of text being merged into links is to only merge if the subsequent text is punctuation.

cc: @CyrilleB79 in case you are looking at this in connection with the pdf issue and the table of contents where dots are spoken.

I tend to close this issue because actually hearing the dot after the link is expected behavior due to the dot being a different speech chunk and it is at least a rough indication that the link role ends before the dot.

Regarding the "link ab" issue:
It seems Jaws for example would also speak "link ab" so during text flow reading, there is no indication when a role ends both in Jaws and NVDA unless you use left and right arrows or ctrl+left and right arrows to navigate.

@jcsteh to minimize the use cases where users get confused because they don't know where elements with roles end, do you think it might make sense to just not announce roles with interactions such as links, buttons etc. when using say all or the newly introduced text paragraph quick navigation? I think dropping the coresponding role announcements in these two navigation paterns would make more issues that we already have on Github obsolete (i.e. #14335).
We could restrict the role reporting announcements only to things that do not have any interaction function such as emphasized text, inserted or deleted atributes, spelling errors, footnotes etc.
Role announcement is suppressed already e.g. when Using shift+arrow keys or when navigating in object review or screen review mode.
I think it would be sufficient pointing the users that they can navigate roles by using their associated quick nav keys or by using the arrow and ctrl+arrow keys, tab key, object navigation or document review mode.

@CyrilleB79, @XLTechie do you know if there is a specific use case why people need to hear the roles with interactions while using say all or text paragraph quick nav? Are all other navigation paterns not sufficient to understand the interaction roles used in the design of a document?

actually hearing the dot after the link is expected behavior due to the dot being a different speech chunk

I do not think it is expected because:

• from a user point of view, "speech chunk" has no sense. The text is divided in paragraphs, sentences or words, and that's all; headings, lists or tables are also semantic elements that structure the text. But the "link" role is not dividing nor structuring the text; it's just a property of a part of the text.
• according to Dot spoken with symbol level some at the end of a sentense #1475 (comment), there are many duplicates of this issue; thus if it was really expected, it should at least be explained / teached / documented better.

and it is at least a rough indication that the link role ends before the dot.

It is a side effect of this issue that can be considered positive by some. However, if there is a need to know where a link ends, it should not be done thanks to a badly processed complex punctuation symbol.

So I disagree with closing this issue now.

Regarding role reporting during say all, I'd say that it is quite off-topic in this specific issue and should be discussed elsewhere. Note however that it's already possible to create a say-all profile and to choose, at least partially, what is reported during say-all.