New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Links in Word aren't displayed with the lnk indicator in braille #6780

Closed
dkager opened this Issue Jan 22, 2017 · 5 comments

Comments

Projects
None yet
3 participants
@dkager
Collaborator

dkager commented Jan 22, 2017

STR:

  1. Open Word, tested with Word 2016.
  2. Type "This is something to click on."
  3. Select the word "click", right-click on it, choose Hyperlink... and make it a link.

Speech reads:
This is something to link click out of link on.
Braille shows:
This is something to click on.
Expected:
Braille somehow shows the link, e.g. with the "lnk" indicator.

@dkager

This comment has been minimized.

Show comment
Hide comment
@dkager

dkager Jan 22, 2017

Collaborator

Could be added to braille.getFormatFieldBraille(). But isAtStart is False if a link appears in the middle of some text.

We should probably also work something out for comments/revisions.

Collaborator

dkager commented Jan 22, 2017

Could be added to braille.getFormatFieldBraille(). But isAtStart is False if a link appears in the middle of some text.

We should probably also work something out for comments/revisions.

@jcsteh jcsteh added the p2 label Jan 22, 2017

@jcsteh

This comment has been minimized.

Show comment
Hide comment
@jcsteh

jcsteh Jan 22, 2017

Contributor

P2 because this is important info that isn't available to braille only users.

@dkager commented on 23 Jan. 2017, 5:19 am AEST:

Could be added to braille.getFormatFieldBraille(). But isAtStart is False if a link appears in the middle of some text.

isAtStart isn't useful here, since that's to ensure we don't present info in the middle of the line that should only be presented at the start. However, we're probably going to need a cache of attributes we presented in the last chunk of the line so we don't present them again.

We should probably also work something out for comments/revisions.

Indeed, though I don't consider that quite as high priority (though still important) and we should address it separately.

Contributor

jcsteh commented Jan 22, 2017

P2 because this is important info that isn't available to braille only users.

@dkager commented on 23 Jan. 2017, 5:19 am AEST:

Could be added to braille.getFormatFieldBraille(). But isAtStart is False if a link appears in the middle of some text.

isAtStart isn't useful here, since that's to ensure we don't present info in the middle of the line that should only be presented at the start. However, we're probably going to need a cache of attributes we presented in the last chunk of the line so we don't present them again.

We should probably also work something out for comments/revisions.

Indeed, though I don't consider that quite as high priority (though still important) and we should address it separately.

@dkager

This comment has been minimized.

Show comment
Hide comment
@dkager

dkager Jan 23, 2017

Collaborator

However, we're probably going to need a cache of attributes we presented in the last chunk of the line so we don't present them again.

It looks like this only applies if you have some text selected. Then you have three chunks: text before and after selection, and the selection itself. But that implies there can be multiple "link start" commands for the same text. Is that true?

Collaborator

dkager commented Jan 23, 2017

However, we're probably going to need a cache of attributes we presented in the last chunk of the line so we don't present them again.

It looks like this only applies if you have some text selected. Then you have three chunks: text before and after selection, and the selection itself. But that implies there can be multiple "link start" commands for the same text. Is that true?

@jcsteh

This comment has been minimized.

Show comment
Hide comment
@jcsteh

jcsteh Jan 25, 2017

Contributor
Contributor

jcsteh commented Jan 25, 2017

@dkager

This comment has been minimized.

Show comment
Hide comment
@dkager

dkager Jan 25, 2017

Collaborator

I'm going with a full cache like is used for speech, because that looks the most extensible.

Collaborator

dkager commented Jan 25, 2017

I'm going with a full cache like is used for speech, because that looks the most extensible.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment