E-mail List Archives
Thread: Hidden text more robust than title?
Number of posts in this thread: 7 (In chronological order)
From: Lovely, Brian (CONT)
Date: Fri, Jul 14 2017 11:40AM
Subject: Hidden text more robust than title?
No previous message | Next message →
Which is more robust, the title attribute or visually hidden text?
<a href="some/url" title="opens in a new window">read more</a>
<a href="some/url">read more <span class="css_clipping"> opens in a new window</span></a>
I have felt that the title attribute was not fully supported by AT, but I don't actually know of any specific situations where it would fail.
The information contained in this e-mail is confidential and/or proprietary to Capital One and/or its affiliates and may only be used solely in performance of work or services for Capital One. The information transmitted herewith is intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer.
From: Beranek, Nicholas
Date: Fri, Jul 14 2017 1:40PM
Subject: Re: Hidden text more robust than title?
← Previous message | Next message →
Hey Brian, after our discussion we decided that since the title attribute is still being relayed as an accessible description for links (confirmed through MSAA object inspect and NVDA) it is OK to use it in this context. It becomes a problem when we use it for a text input in place of an accessible name.
Nick
From: Jonathan Avila
Date: Fri, Jul 14 2017 1:48PM
Subject: Re: Hidden text more robust than title?
← Previous message | Next message →
> It becomes a problem when we use it for a text input in place of an accessible name.
The title attribute can be used as the accessible name for an input as long as it's accessibility supported. It has been very well support historically but I haven't confirmed its support on mobile recently.
The accessible name calculation can be found here:
https://www.w3.org/TR/html-aam-1.0/#input-type-text-input-type-password-input-type-search-input-type-tel-input-type-url-and-textarea-element
It would not however serve as a visible label for an input that was not otherwise labelled because it is only available on mouse hover in most browsers.
Jonathan
Jonathan Avila
Chief Accessibility Officer
Level Access, inc. (formerly SSB BART Group, inc.)
(703) 637-8957
= EMAIL ADDRESS REMOVED =
Visit us online: Website | Twitter | Facebook | LinkedIn | Blog
Looking to boost your accessibility knowledge? Check out our free webinars!
The information contained in this transmission may be attorney privileged and/or confidential information intended for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any use, dissemination, distribution or copying of this communication is strictly prohibited.
From: Birkir R. Gunnarsson
Date: Fri, Jul 14 2017 1:55PM
Subject: Re: Hidden text more robust than title?
← Previous message | Next message →
Exactly what Jon said.
The title attribute is a valid source of accessible name, but is not
persistent visible label.
It could only be used to provide an accessible name to form fields
visually identified by an adjacent field or part of a
multi-part-input, or as a source of accessible name for a link or
button identified visually with an icon.
That being said, I think the title attribute is the better way to go here.
You don't have to provide this info (unless you do with an icon) so it
is supplementary to the link purpose. That is what the title attribute
is intended for.
If you place too much information into the linktext itself it becomes
cumbersome and confusing.
Also it is very bad pactice (not that you suggested it) to put hidden
text wih instructions before the link text.
On 7/14/17, Jonathan Avila < = EMAIL ADDRESS REMOVED = > wrote:
>> It becomes a problem when we use it for a text input in place of an
>> accessible name.
>
> The title attribute can be used as the accessible name for an input as long
> as it's accessibility supported. It has been very well support historically
> but I haven't confirmed its support on mobile recently.
>
> The accessible name calculation can be found here:
> https://www.w3.org/TR/html-aam-1.0/#input-type-text-input-type-password-input-type-search-input-type-tel-input-type-url-and-textarea-element
>
> It would not however serve as a visible label for an input that was not
> otherwise labelled because it is only available on mouse hover in most
> browsers.
>
> Jonathan
>
> Jonathan Avila
> Chief Accessibility Officer
> Level Access, inc. (formerly SSB BART Group, inc.)
> (703) 637-8957
> = EMAIL ADDRESS REMOVED =
> Visit us online: Website | Twitter | Facebook | LinkedIn | Blog
> Looking to boost your accessibility knowledge? Check out our free webinars!
>
> The information contained in this transmission may be attorney privileged
> and/or confidential information intended for the use of the individual or
> entity named above. If the reader of this message is not the intended
> recipient, you are hereby notified that any use, dissemination, distribution
> or copying of this communication is strictly prohibited.
>
>
From: Beranek, Nicholas
Date: Fri, Jul 14 2017 2:02PM
Subject: Re: Hidden text more robust than title?
← Previous message | Next message →
It's a case where you can pass SC 1.3.1 Info and Relationships with an accessible name but fail SC 3.3.2 Labels or Instructions for not having a visible label (with a few exceptions, like the cases Birkir just mentioned).
Thanks for your responses. Jon, thanks for providing that link; it's very helpful.
Nick
From: Ryan E. Benson
Date: Fri, Jul 14 2017 4:01PM
Subject: Re: Hidden text more robust than title?
← Previous message | Next message →
> That being said, I think the title attribute is the better way to go here.
I have to disagree here. If you have <a href=-- title=-open a new window->text</a> Zoom Text will either only announce 'open a new window link-, or 'text open a new window link- on the beginner/verbose mode.
--
Ryan E. Benson
From: Birkir R. Gunnarsson
Sent: Friday, July 14, 2017 15:55
To: WebAIM Discussion List
Subject: Re: [WebAIM] Hidden text more robust than title?
Exactly what Jon said.
The title attribute is a valid source of accessible name, but is not
persistent visible label.
It could only be used to provide an accessible name to form fields
visually identified by an adjacent field or part of a
multi-part-input, or as a source of accessible name for a link or
button identified visually with an icon.
That being said, I think the title attribute is the better way to go here.
You don't have to provide this info (unless you do with an icon) so it
is supplementary to the link purpose. That is what the title attribute
is intended for.
If you place too much information into the linktext itself it becomes
cumbersome and confusing.
Also it is very bad pactice (not that you suggested it) to put hidden
text wih instructions before the link text.
On 7/14/17, Jonathan Avila < = EMAIL ADDRESS REMOVED = > wrote:
>> It becomes a problem when we use it for a text input in place of an
>> accessible name.
>
> The title attribute can be used as the accessible name for an input as long
> as it's accessibility supported. It has been very well support historically
> but I haven't confirmed its support on mobile recently.
>
> The accessible name calculation can be found here:
> https://www.w3.org/TR/html-aam-1.0/#input-type-text-input-type-password-input-type-search-input-type-tel-input-type-url-and-textarea-element
>
> It would not however serve as a visible label for an input that was not
> otherwise labelled because it is only available on mouse hover in most
> browsers.
>
> Jonathan
>
> Jonathan Avila
> Chief Accessibility Officer
> Level Access, inc. (formerly SSB BART Group, inc.)
> (703) 637-8957
> = EMAIL ADDRESS REMOVED =
> Visit us online: Website | Twitter | Facebook | LinkedIn | Blog
> Looking to boost your accessibility knowledge? Check out our free webinars!
>
> The information contained in this transmission may be attorney privileged
> and/or confidential information intended for the use of the individual or
> entity named above. If the reader of this message is not the intended
> recipient, you are hereby notified that any use, dissemination, distribution
> or copying of this communication is strictly prohibited.
>
>
From: Birkir R. Gunnarsson
Date: Fri, Jul 14 2017 9:10PM
Subject: Re: Hidden text more robust than title?
← Previous message | No next message
This is the dilemma we are always facing though.
Should we recommend that things are coded to standards, and file bugs
when an assistive technology application does not make it useful, or
should we code it around the behaviors of those applications to ensure
the best experience for the end users.
Obviously, the answer is basically both, but I think too often we
relent, ask developers to code around the application bugs, and then
fail to file bugs to have things corrected (myself included, I don't
file nearly enough bugs).
Our job is not only to make developers code around assistive
technology bugs, it is to encourage assistive technology vendors to
fix those bugs so that accessibility can become easier, simpler and
more cost effective.
On 7/14/17, Ryan E. Benson < = EMAIL ADDRESS REMOVED = > wrote:
>> That being said, I think the title attribute is the better way to go here.
>
> I have to disagree here. If you have <a href=-- title=-open a new
> window->text</a> Zoom Text will either only announce 'open a new window
> link-, or 'text open a new window link- on the beginner/verbose mode.
>
> --
> Ryan E. Benson
>
> From: Birkir R. Gunnarsson
> Sent: Friday, July 14, 2017 15:55
> To: WebAIM Discussion List
> Subject: Re: [WebAIM] Hidden text more robust than title?
>
> Exactly what Jon said.
>
> The title attribute is a valid source of accessible name, but is not
> persistent visible label.
> It could only be used to provide an accessible name to form fields
> visually identified by an adjacent field or part of a
> multi-part-input, or as a source of accessible name for a link or
> button identified visually with an icon.
>
> That being said, I think the title attribute is the better way to go here.
> You don't have to provide this info (unless you do with an icon) so it
> is supplementary to the link purpose. That is what the title attribute
> is intended for.
> If you place too much information into the linktext itself it becomes
> cumbersome and confusing.
> Also it is very bad pactice (not that you suggested it) to put hidden
> text wih instructions before the link text.
>
>
>
> On 7/14/17, Jonathan Avila < = EMAIL ADDRESS REMOVED = > wrote:
>>> It becomes a problem when we use it for a text input in place of an
>>> accessible name.
>>
>> The title attribute can be used as the accessible name for an input as
>> long
>> as it's accessibility supported. It has been very well support
>> historically
>> but I haven't confirmed its support on mobile recently.
>>
>> The accessible name calculation can be found here:
>> https://www.w3.org/TR/html-aam-1.0/#input-type-text-input-type-password-input-type-search-input-type-tel-input-type-url-and-textarea-element
>>
>> It would not however serve as a visible label for an input that was not
>> otherwise labelled because it is only available on mouse hover in most
>> browsers.
>>
>> Jonathan
>>
>> Jonathan Avila
>> Chief Accessibility Officer
>> Level Access, inc. (formerly SSB BART Group, inc.)
>> (703) 637-8957
>> = EMAIL ADDRESS REMOVED =
>> Visit us online: Website | Twitter | Facebook | LinkedIn | Blog
>> Looking to boost your accessibility knowledge? Check out our free
>> webinars!
>>
>> The information contained in this transmission may be attorney privileged
>> and/or confidential information intended for the use of the individual or
>> entity named above. If the reader of this message is not the intended
>> recipient, you are hereby notified that any use, dissemination,
>> distribution
>> or copying of this communication is strictly prohibited.
>>
>>