Comment 1 by jteh on 2013-02-04 12:46
There is text in those links. If there weren't, NVDA would be falling back to title already. The text is unpronounceable by the synthesiser in this case, but that doesn't mean it isn't text (and doesn't mean that all synthesiser won't pronounce it). I'm not sure how the text is being generated - probably !JavaScript - but it's there.
Changes:
Added labels: invalid
State: closed

Comment 2 by Q (in reply to comment 1) on 2013-02-04 18:02
Replying to jteh:

There is text in those links. If there weren't, NVDA would be falling back to title already. The text is unpronounceable by the synthesiser in this case, but that doesn't mean it isn't text (and doesn't mean that all synthesiser won't pronounce it). I'm not sure how the text is being generated - probably !JavaScript - but it's there.

Um, no there isn't. Do *you see any text inside those links? What is happening is the same as on my website, and the same as on a whole crapton of new websites, namely unicode font-based icons. It is completely invalid to call an icon glyph readable text. What is more useful here, being technically correct and reading garbage, or actually reading some text that could give a chance of correctly interacting with the link? I can understand if you had said, it would be heuristically difficult to detect what text to relate to the user in this situation, but to simply say it's impossible?

Not to nitpick, but I am rather frustrated to be a monthly donator to the NVDA project and to be so cavalierly dismissed over an actual issue which is clear for anyone who is not intentionally blinding themselves to it.

Comment 3 by ondrosik on 2013-02-04 18:19
I am asking just as normal user as I can not do much about it, can you provide another example where registration is not needed? you wrote "the same as on my website", I looked to q-continuum.net if you mean that and I can't see nothing strange, but i probably missed it.

Comment 4 by Q (in reply to comment 3) on 2013-02-04 18:21
Replying to ondrosik:

I am asking just as normal user as I can not do much about it, can you provide another example where registration is not needed? you wrote "the same as on my website", I looked to q-continuum.net if you mean that and I can't see nothing strange, but i probably missed it.

You don't notice the icons on my site because I add text to the actual links and not to the title attribute. You might be able to hear the synthesizer pause slightly before it announces some links when it reads the unicode character though, the sort of questionmark pause before some links.

Comment 5 by jteh on 2013-02-04 18:38
My intent wasn't to be pedantic about being "technically correct". The problem/confusion here is the definition of "text". Any Unicode character (apart from whitespace) is considered to be useful text/content. This is not an unreasonable assumption and I doubt we're the only ones to make it. Those characters could just as well be valid symbols or even alphabetic characters in some language. By your logic, we shouldn't allow for symbolic characters at all.

As for your inference that I'm intentionally blinding myself to a clear issue, your definition of text is pretty narrow if this issue is so amazingly clear. If you'd rather insult me than provide constructive arguments, I'll be quite happy to spend my time on something more deserving.

Comment 6 by Q (in reply to comment 5) on 2013-02-04 18:59
Replying to jteh:

My intent wasn't to be pedantic about being "technically correct". The problem/confusion here is the definition of "text". Any Unicode character (apart from whitespace) is considered to be useful text/content.

Yes. Precisely this. This is the heuristic which I opened this ticket to discuss. This is the point where we talk about alternatives like, "longest wins", or, those characters don't exist in this locale's default encoding but those in the title attribute do or maybe we need a keystroke to read a link's title, if it has one or any of a hundred other things that aren't, simply, we're already doing the right thing, accept it and shut up.

This is not an unreasonable assumption and I doubt we're the only ones to make it.

Except, now, I am pointing out to you that it is an unreasonable assumption, and showing you a test case on an extremely popular website to prove it. What does whether or not another screen reader handles it correctly have to do with if NVDA should?

Those characters could just as well be valid symbols or even alphabetic characters in some language.

Of course they could. It would be silly to ignore Chinese symbols if, for instance, the user's language were set to Chinese. It may not even be possible to tell if a given symbol maps to a given language's character set, in which case we have to fall back to guessing. See my discussion of the heuristic to use above.

By your logic, we shouldn't allow for symbolic characters at all.

No. By my logic we should actually think about how we present things to the user. Not simply assume we have the ultimate way already figured out.

As for your inference that I'm intentionally blinding myself to a clear issue, your definition of text is pretty narrow if this issue is so amazingly clear.

No. It isn't. My definition of useable text is narrow and constrained by the usefulness of the text. I am extremely aware of all the potential technical issues here. That said, in the state that you've left this, very important functionality on GitHub doesn't work. I was originally going to report this issue to GitHub, before examining their markup and noticing the very obvious title attributes of their links. They are giving us this information. Why are we ignoring it?

If you'd rather insult me than provide constructive arguments, I'll be quite happy to spend my time on something more deserving.

This sentence is extremely frustrating. I'm not sure what you consider insulting behavior, but I would class your rather rude dismissal of my cogent points as such. I, too, can take my toys and go home. I opened this ticket to improve NVDA's handling of web content for all of us, not to get into a philosophical discussion. That said, if you look back over the thread, I have been presenting constructive suggestions, you have been shooting them down.

Comment 7 by Q on 2013-02-04 18:59
Changes:
Removed labels: invalid
State: reopened

Comment 8 by Q on 2013-02-04 20:30
Here is a simple test case. Run this in Firefox:

<html>
<body>
<p>
This is some text
</p>

<a href="http://q-continuum.net" title="My awesome website!">
</a>
</body>
</html>

Note that the only thing visible to NVDA in Browse mode is the phrase "This is some text"

Comment 9 by jteh (in reply to comment 6) on 2013-02-05 01:59
Replying to Q:

Replying to jteh:

This is the heuristic which I opened this ticket to discuss. This is the point where we talk about alternatives like

Nowhere in your ticket description did you mention alternatives or what you define as "text". That only came after I closed the ticket.

"longest wins", or, those characters don't exist in this locale's default encoding but those in the title attribute do

NVDA can't currently make assumptions about the locale because it's quite possible that a user might be reading multilingual text; i.e. the user's ocnfigured NVDA interface language may not match the text they're reading. Also, the code that renders virtual buffers is in-process and doesn't have access to any of this information. Of course, we could change this somehow, but that would be a huge architectural change.

or maybe we need a keystroke to read a link's title, if it has one

If you press NVDA+tab, NVDA will report the focused object, which includes its description (which in this case is the title).

This is not an unreasonable assumption and I doubt we're the only ones to make it.

Except, now, I am pointing out to you that it is an unreasonable assumption, and showing you a test case on an extremely popular website to prove it.

Just because it's popular doesn't make it right. While I want the best usability just as much as anyone else, I'm not willing to invest a huge amount of effort in hacks which compensate for authoring error and may actually introduce unwanted side effects. This is a very slippery slope. Accuracy has to be the primary objective.

By your logic, we shouldn't allow for symbolic characters at all.

No. By my logic we should actually think about how we present things to the user. Not simply assume we have the ultimate way already figured out.

We do think about how we present things to the user. We also try to interfere and "guess" as little as possible so as to avoid potential inaccuracy and bloat.

I was originally going to report this issue to GitHub, before examining their markup and noticing the very obvious title attributes of their links. They are giving us this information. Why are we ignoring it?

See above regarding the way to report the title. The title essentially becomes secondary information (the description) if the link contains content. (Btw, the browser does this, not us.) Note that if aria-label were used, it should override the content, which is what you want. NVDA probably doesn't support this in this case, which is a separate issue that needs to be fixed and is on my to-do list.

Next step: please report whether NVDA+tab reports the required information.

Comment 10 by jteh (in reply to comment 8) on 2013-02-05 02:02
Replying to Q:

Here is a simple test case. Run this in Firefox:

Assuming trac didn't munge something you typed, this is a different issue. Your link has no content at all, so it's actually invisible even to sighted users, which is why NVDA doesn't render it.

Comment 11 by ppatel on 2013-02-05 02:17
Considering that the recommendation is to avoid the title attribute unless in very limited use cases, I do not see that allowing the title attribute to be spoken by default upon not finding any text would help us convince developers to not rely on the attribute to provide accessibility information. Besides, it has already been stated that NVDA falls back to the title attribute in the situations that warrant it. We should be making attempts to convince developers to use actual text for links--whether done through scripting or not.

Comment 12 by ppatel on 2013-02-05 02:53
Paste this code in an empty file and run it in IE and FF. The first two links are not recognized by NVDA as links. as one down arrows through the file. They are also not recognized as links as one tabs to and from the first two links.

In IE9, all of these links are recognized as such when using the arrow keys to brows through the file. NVDA+tab also provides descriptions.

<head>
<title>example of accessibility</title>
</head>

<body>
<p>my fantastic site</p>
<p>check out this link with no text in it: <a href="http://www.iamhandsome.com" title="I am 

so handsome!"></a></p>
<p>Check out this link with an empty space in it: <a href="http://www.iamhandsome.com" 

title="I am sooooo handsome!"> </a></p>
<p>Checkout this link with text in it it: <a href="http://www.iamhandsome.com" title="I am 

like totally handsome!">I'm totally handsome</a></p>
</body>
</html>

Comment 13 by jteh on 2013-02-05 23:53
Is there a reference for how these frameworks that use Unicode characters for icon glyphs work? These characters seem to be in a private use Unicode area. If they all are, that's a starting point.
Changes:
Changed title from "Links without text should fall back to the title attribute if it exists" to "Links containing only Unicode icon glyphs should fall back to the title attribute if it exists"

Comment 14 by Q (in reply to comment 13) on 2013-02-06 06:53
Replying to jteh:

Is there a reference for how these frameworks that use Unicode characters for icon glyphs work? These characters seem to be in a private use Unicode area. If they all are, that's a starting point.

I haven't been able to find a standard. Here's one person stating that there are some standard unicode points with meaning, and any others used in an icon font should go in a private range:
http://www.codestyle.org/css/at-font-face/StandardUnicodeIconsWebFonts.shtml
Does it make sense to read things like those that he claims have semantic meaning?
Can you ignore characters in private use areas as simply invalid for now as a test in the development branch and make sure it doesn't hurt anyone else?

Comment 15 by jteh (in reply to comment 14) on 2013-02-06 07:25
I haven't read your reference yet, but:
Replying to Q:

Can you ignore characters in private use areas as simply invalid for now as a test in the development branch and make sure it doesn't hurt anyone else?

That isn't the entire solution. For IA2 browsers, we rely on the browser to make decisions about the name of the object; we don't have direct access to the DOM. If we ignore characters in content, NVDA will fall back to the name, but in this case, the name will just be the content (as decided by the browser), so this solves nothing. If it seems appropriate that private use Unicode characters shouldn't be used, we'd ideally try to get consensus on that from Mozilla so they can do the same. There are possibly other solutions, but that'd be my first approach.

Did you confirm whether NVDA+tab reports the required information?

Comment 16 by Q (in reply to comment 15) on 2013-02-06 08:00

Did you confirm whether NVDA+tab reports the required information?

I made a small test page where it seems to work. It does not work on GitHub (even though they have title in their markup.) Further analysis showed me that they were using something which renames title to original-title in the DOM. I wrote to them and asked that they use aria-label. The Javascript library that they're using which renames title to original-title is Tipsy, a tooltip library. Would it make sense for me to open a ticket against tipsy asking them to add an aria-label attribute if they rename title as well as simply contacting GitHub about their unlabeled links? Are title and aria-label semantically equivalent?
I note that aria-label is ignored if a link has text. If it simply has a linebreak or similar in it, the label is read. Where is that logic (trimming whitespace and falling back to the aria-label?) is that browser-side? How about IE? How does it handle this mess?

Comment 17 by jteh (in reply to comment 16) on 2013-11-27 06:26
Replying to Q:

Would it make sense for me to open a ticket against tipsy asking them to add an aria-label attribute if they rename title as well as simply contacting GitHub about their unlabeled links?

I think so, yes. Based on current browser behaviour, I guess they should use aria-label even if they don't rename title, as browsers will probably use the content as the label if the content isn't whitespace.

Are title and aria-label semantically equivalent?

Not quite. Title will only be used as the label as a last resort. Otherwise, it becomes the description.

I note that aria-label is ignored if a link has text. If it simply has a linebreak or similar in it, the label is read. Where is that logic (trimming whitespace and falling back to the aria-label?)

It's in NVDA's vbuf backends.

We're going to investigate special handling for private use Unicode characters.

Comment 18 by Michael Curran <mick@... on 2013-11-28 02:17
In [788cefb]:

vbufBase: Ignore unicode characters from the private usage range (and 0-width space) at the start end end of text nodes, and also treet these characters as not useful when searching short strings to see if they should be overridden with a parent label. Re #2963.

Specifically:
- Add an isPrivateCharacter inline function to vbufBase/utils.h which checks if a character is from the private use unicode range, or is a 0-width space. The private use unicode range we check is from U+e000 to u+f8ff.
  - VBufBase's nodeHasUsefulContent: rather than calling isWhitespace, write out a for loop directly, and return true if any character that is not whitespace (iswspace) or is from the private use range or 0-width space (isPrivatecharacter) is found.
- VbufStorage_buffer_t::addTextFieldNode: strip private characters from the start and end of the text string if they exist when giving the text to the new text node.

Comment 19 by Michael Curran <mick@... on 2013-11-28 02:17
In [b380b99]:

Merge branch 't2963' into next. Incubates #2963

Changes:
Added labels: incubating

Comment 20 by Michael Curran <mick@... on 2013-12-12 04:19
In [eb86c8e]:

Merge branch 't2963'. Fixes #2963

Changes:
Removed labels: incubating
State: closed

Comment 21 by mdcurran on 2013-12-12 04:20
Changes:
Milestone changed from None to 2014.1