E-mail List Archives
Thread: Truncated links and titles
Number of posts in this thread: 9 (In chronological order)
From: Steven Garvin
Date: Thu, Jun 25 2015 9:14AM
Subject: Truncated links and titles
No previous message | Next message →
Hi,
I've been doing some research on acceptable uses of title attributes on links but can't seem to find anything on a piece of functionality we're about to implement. We have a list of links, each representing a user-entered data set. The link name is a title field which could be up to 100 characters long. In our application this will, in some instances, be too long to display and so needs to be truncated. The desired functionality is to display the shortened version on the link with the full string inside the title attribute on the link so that it will display as a tooltip. For example:
<a href="#" title="This is the full title for the data set">This is the full.</a>
My question is then, is this an acceptably accessible solution? My understanding is that JAWS for one will read both the link name and the title, which seems a bit wrong to me. Is the solution to add an Aria-label with the full title?
Thanks,
Steven
From: Moore,Michael (HHSC)
Date: Thu, Jun 25 2015 9:17AM
Subject: Re: Truncated links and titles
← Previous message | Next message →
The title will not be read for a text link in JAWS by default. It requires the user make changes to their verbosity settings.
Mike Moore
Accessibility Coordinator
Texas Health and Human Services Commission
Civil Rights Office
(512) 438-3431 (Office)
(512) 574-0091 (Cell)
From: Jonathan C. Cohn
Date: Thu, Jun 25 2015 9:50AM
Subject: Re: Truncated links and titles
← Previous message | Next message →
Remember, that JAWS is not the only screen reader. VoiceOVer on the Macintosh will generally read the title rather than the screen text unless you interact with the element. I believe this will be OK in this situation, though on a specific web site there were onClick spans that VoiceOver would read click here for more inofrmation, and one would not know what you were supposed to find more information about.
Jonathan Cohn
> On Jun 25, 2015, at 11:17 AM, Moore,Michael (HHSC) < = EMAIL ADDRESS REMOVED = > wrote:
>
> The title will not be read for a text link in JAWS by default. It requires the user make changes to their verbosity settings.
>
> Mike Moore
> Accessibility Coordinator
> Texas Health and Human Services Commission
> Civil Rights Office
> (512) 438-3431 (Office)
> (512) 574-0091 (Cell)
>
>
>
From: Jared Smith
Date: Thu, Jun 25 2015 10:01AM
Subject: Re: Truncated links and titles
← Previous message | Next message →
This is what we always tell people regarding the title attribute text...
If you want it to be read, expect that it won't be. If you don't want
it to be read, expect that it will be.
Beyond the inconsistent support among screen readers, it's also
entirely inaccessible to all keyboard-only users and touch
screen/mobile users. As such, it should be used with great care to
convey advisory information that you understand will not likely be
presented to the user.
In this particular case, if you presume that the visual link text is
sufficient for sighted users, why would it not be sufficient for
screen reader users? In other words, why (potentially) give screen
reader users extra information that isn't necessary or even available
for everyone else?
Jared
From: deborah.kaplan
Date: Thu, Jun 25 2015 10:06AM
Subject: Re: Truncated links and titles
← Previous message | Next message →
On Thu, 25 Jun 2015, Steven Garvin wrote:
> My question is then, is this an acceptably accessible solution?
Will you be applying JavaScript to make the title appear on keyboard focus? In most browsers that does not happen automatically.
Also, be aware that those hover states with the title attribute can be very difficult or impossible for users at high magnification. Is there a workaround for this use case? In fact, title attribute hover states at high magnification levels can under certain circumstances make a site very difficult to use, because if every point of mouse hover or keyboard focus causes a very large title pop up to appear, how does the zooming user see the rest of the page?
Deborah Kaplan
From: Paul Adam
Date: Thu, Jun 25 2015 11:19AM
Subject: Re: Truncated links and titles
← Previous message | Next message →
That's not correct. VO OS X reads title of links with a default delay
after reading the link text or Accessible name. iOS is the same with a
very short delay.
If you want to control how a screen reader speaks the link text then
modify the accessible name eg aria-label.
Sent from my iPhone
> On Jun 25, 2015, at 10:51 AM, Jonathan C. Cohn < = EMAIL ADDRESS REMOVED = > wrote:
>
> Remember, that JAWS is not the only screen reader. VoiceOVer on the Macintosh will generally read the title rather than the screen text unless you interact with the element. I believe this will be OK in this situation, though on a specific web site there were onClick spans that VoiceOver would read click here for more inofrmation, and one would not know what you were supposed to find more information about.
>
>
>
>
> Jonathan Cohn
>
>> On Jun 25, 2015, at 11:17 AM, Moore,Michael (HHSC) < = EMAIL ADDRESS REMOVED = > wrote:
>>
>> The title will not be read for a text link in JAWS by default. It requires the user make changes to their verbosity settings.
>>
>> Mike Moore
>> Accessibility Coordinator
>> Texas Health and Human Services Commission
>> Civil Rights Office
>> (512) 438-3431 (Office)
>> (512) 574-0091 (Cell)
>>
>>
>>
From: Joy Relton
Date: Thu, Jun 25 2015 1:40PM
Subject: Re: Truncated links and titles
← Previous message | Next message →
Also, unless things have changed significantly Dragon needs both a title and a label to recognize the form field.
From: Sean Curtis
Date: Thu, Jun 25 2015 6:34PM
Subject: Re: Truncated links and titles
← Previous message | Next message →
It really seems like something which should be handled by the browser. I
think Safari is the only one which detects when text is being truncated and
adds a visual title on hover. Try out https://jsbin.com/mijeqi/ in Safari
to see what I mean.
In our components we apply a data-tooltip attribute to the element, and
then display a larger tooltip on hover (and often focus) using a modified
version of http://onehackoranother.com/projects/jquery/tipsy/
Screen readers will announce the full contents of the element, and keyboard
users will see the tooltip. The only downside is that there is (necessary)
duplication in the markup, and that the tooltip displays regardless of
truncation. Unfortunately there's no event (that I know of) to bind to that
fires when something is truncated. There are probably some really
non-performant ways of detecting when something is truncated (clone
element, measure the height as the element width is reduced until wrapping
occurs, then compare to original element), but I haven't found it worth the
cost.
Most of the time we use this technique (as does Gmail) when using icon-only
buttons. Other times we can often design our way around the problem.
Normally when text is being truncated at random widths it's a sign the UX
could use some finessing.
Cheers,
Sean
On Fri, Jun 26, 2015 at 5:40 AM, Joy Relton < = EMAIL ADDRESS REMOVED = > wrote:
> Also, unless things have changed significantly Dragon needs both a title
> and a label to recognize the form field.
>
>
From: _mallory
Date: Fri, Jun 26 2015 5:01AM
Subject: Re: Truncated links and titles
← Previous message | No next message
On another note:
ZoomText on IE reads out titles by default.
ZoomText on Firefox... does not.
Deborah's point about titles and high magnification is also an
issue: often you need to scroll horizontally to read the full
tooltip, meaning your pointer then leaves the link, meaning the
tooltip vanishes. This has been a problem for me, but (un)luckily,
most titles in the wild are mere repeats of the (fully visible) link
text (meaning both redundant and get in the way of seeing stuff).
I have enountered (and built) instances where focus triggers the
tooltip and these help, as I can scroll around the page with the
pointer without losing focus, meaning I could read the whole long
tooltip. Even better, if it's a created element with javascript, you
now suddenly gain the options to style the tooltip-- meaning you
could constrain its width or give it better-than-browser-default
contrasts.
_mallory
On Thu, Jun 25, 2015 at 12:06:39PM -0400, = EMAIL ADDRESS REMOVED = wrote:
> On Thu, 25 Jun 2015, Steven Garvin wrote:
> >My question is then, is this an acceptably accessible solution?
>
> Will you be applying JavaScript to make the title appear on keyboard focus? In most browsers that does not happen automatically.
>
> Also, be aware that those hover states with the title attribute can be very difficult or impossible for users at high magnification. Is there a workaround for this use case? In fact, title attribute hover states at high magnification levels can under certain circumstances make a site very difficult to use, because if every point of mouse hover or keyboard focus causes a very large title pop up to appear, how does the zooming user see the rest of the page?
>
> Deborah Kaplan
> > > >