E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 25 (In chronological order)

From: Fernand van Olphen
Date: Mon, May 08 2017 4:49AM
Subject: Icon instead of text > open in new window
No previous message | Next message →

Hi everyone,

WCAG states that if a new window is opened advanced warning should be given to users (https://www.w3.org/TR/WCAG20-TECHS/G201.html).

This can be done by including the warning-text in the link:

<a href="knitting.html" target="_blank">All about Knitting (opens in new window)</a>

However, what if the link is not text, but an icon (for example a facebook-icon). How can I warn the user that a new window will be opened?

Thanks!

Fernand van Olphen
Accessibility Advisor
Municipality of The Hague

De disclaimer van toepassing op e-mail van de gemeente Den Haag vindt u op: http://www.denhaag.nl/disclaimer

From: Patrick H. Lauke
Date: Mon, May 08 2017 4:51AM
Subject: Re: Icon instead of text > open in new window
← Previous message | Next message →

On 08/05/2017 11:49, Fernand van Olphen wrote:
> Hi everyone,
>
> WCAG states that if a new window is opened advanced warning should be given to users (https://www.w3.org/TR/WCAG20-TECHS/G201.html).
>
> This can be done by including the warning-text in the link:
>
> <a href="knitting.html" target="_blank">All about Knitting (opens in new window)</a>
>
> However, what if the link is not text, but an icon (for example a facebook-icon). How can I warn the user that a new window will be opened?

By adding that to the alternative text (alt in case of <img>, etc).

P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: Fernand van Olphen
Date: Mon, May 08 2017 5:06AM
Subject: Re: Icon instead of text > open in new window
← Previous message | Next message →

@Patrick: Thanks fort he swift answer!

By adding the "opens in new window"-text as an alternative text, only screen reader users will know about this. What about the sighted users? Shouldn't they also be warned?

- Fernand
De disclaimer van toepassing op e-mail van de gemeente Den Haag vindt u op: http://www.denhaag.nl/disclaimer

From: Patrick H. Lauke
Date: Mon, May 08 2017 5:08AM
Subject: Re: Icon instead of text > open in new window
← Previous message | Next message →

On 08/05/2017 12:06, Fernand van Olphen wrote:
> @Patrick: Thanks fort he swift answer!
>
> By adding the "opens in new window"-text as an alternative text, only screen reader users will know about this. What about the sighted users? Shouldn't they also be warned?

Ah, I see what you mean now. Indeed, for non-AT users, that wouldn't
help. Possible to add a title attribute (to show the tooltip to mouse
users), and potentially back-filling this with a custom tooltip to also
work for keyboard users (to show the tooltip when the link receives focus)?

P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: Jonathan Avila
Date: Mon, May 08 2017 5:22AM
Subject: Re: Icon instead of text > open in new window
← Previous message | Next message →

> WCAG states that if a new window is opened advanced warning should be given to users

Actually this is not required for A/AA conformance. It would be advisory at that level and generally be required at AAA.


Jonathan

Sent from my iPhone

> On May 8, 2017, at 6:49 AM, Fernand van Olphen < = EMAIL ADDRESS REMOVED = > wrote:
>
> WCAG states that if a new window is opened advanced warning should be given to users

From: Fernand van Olphen
Date: Mon, May 08 2017 5:30AM
Subject: Re: Icon instead of text > open in new window
← Previous message | Next message →

Something like this?

https://www.w3.org/WAI/WCAG20/Techniques/working-examples/G201/new-window.html

- Fernand




De disclaimer van toepassing op e-mail van de gemeente Den Haag vindt u op: http://www.denhaag.nl/disclaimer

From: lists
Date: Mon, May 08 2017 6:31AM
Subject: Re: Icon instead of text > open in new window
← Previous message | Next message →

This works great even on touch devices.

Regards,
Srinivasu Chakravarthula
+91-9900810881
Sent on my phone. Excuse typos, if any.

> On 08-May-2017, at 17:00, Fernand van Olphen < = EMAIL ADDRESS REMOVED = > wrote:
>
> Something like this?
>
> https://www.w3.org/WAI/WCAG20/Techniques/working-examples/G201/new-window.html
>
> - Fernand
>
>
>
>
> De disclaimer van toepassing op e-mail van de gemeente Den Haag vindt u op: http://www.denhaag.nl/disclaimer
> > > >

From: Sophie Ragas
Date: Mon, May 08 2017 6:49AM
Subject: Re: Icon instead of text > open in new window
← Previous message | Next message →

Hi all,

Just being the devils advocate here: I think that a Facebook-logo (or any
other well-known site/platform) already implies for sighted users they are
leaving the website they are currently on.


Regards,


Sophie

2017-05-08 14:31 GMT+02:00 = EMAIL ADDRESS REMOVED = < = EMAIL ADDRESS REMOVED = >:

> This works great even on touch devices.
>
> Regards,
> Srinivasu Chakravarthula
> +91-9900810881
> Sent on my phone. Excuse typos, if any.
>
> > On 08-May-2017, at 17:00, Fernand van Olphen <
> = EMAIL ADDRESS REMOVED = > wrote:
> >
> > Something like this?
> >
> > https://www.w3.org/WAI/WCAG20/Techniques/working-examples/
> G201/new-window.html
> >
> > - Fernand
> >
> >
> >
> >
> > De disclaimer van toepassing op e-mail van de gemeente Den Haag vindt u
> op: http://www.denhaag.nl/disclaimer
> > > > > > > > > > > > >

From: Patrick H. Lauke
Date: Mon, May 08 2017 7:02AM
Subject: Re: Icon instead of text > open in new window
← Previous message | Next message →

On 08/05/2017 13:49, Sophie Ragas wrote:
> Hi all,
>
> Just being the devils advocate here: I think that a Facebook-logo (or any
> other well-known site/platform) already implies for sighted users they are
> leaving the website they are currently on.

But the question isn't about external vs internal links, but rather
whether or not the link opens a new window.

P

> Regards,
>
>
> Sophie
>
> 2017-05-08 14:31 GMT+02:00 = EMAIL ADDRESS REMOVED = < = EMAIL ADDRESS REMOVED = >:
>
>> This works great even on touch devices.
>>
>> Regards,
>> Srinivasu Chakravarthula
>> +91-9900810881
>> Sent on my phone. Excuse typos, if any.
>>
>>> On 08-May-2017, at 17:00, Fernand van Olphen <
>> = EMAIL ADDRESS REMOVED = > wrote:
>>>
>>> Something like this?
>>>
>>> https://www.w3.org/WAI/WCAG20/Techniques/working-examples/
>> G201/new-window.html
>>>
>>> - Fernand
>>>
>>>
>>>
>>>
>>> De disclaimer van toepassing op e-mail van de gemeente Den Haag vindt u
>> op: http://www.denhaag.nl/disclaimer
>>> >>> >>> >>> >> >> >> >> >>
> > > > >


--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: Sophie Ragas
Date: Mon, May 08 2017 7:13AM
Subject: Re: Icon instead of text > open in new window
← Previous message | Next message →

Well, I just want to give the user control of how he handles links, so I
wouldn´t let links open in new windows at all. Let the user decide if he
wants a new window or tab. I thought that that practice was generally
recommended?


Regards,

Sophie

2017-05-08 15:02 GMT+02:00 Patrick H. Lauke < = EMAIL ADDRESS REMOVED = >:

> On 08/05/2017 13:49, Sophie Ragas wrote:
>
>> Hi all,
>>
>> Just being the devils advocate here: I think that a Facebook-logo (or any
>> other well-known site/platform) already implies for sighted users they are
>> leaving the website they are currently on.
>>
>
> But the question isn't about external vs internal links, but rather
> whether or not the link opens a new window.
>
> P
>
>
> Regards,
>>
>>
>> Sophie
>>
>> 2017-05-08 14:31 GMT+02:00 = EMAIL ADDRESS REMOVED = < = EMAIL ADDRESS REMOVED = >:
>>
>> This works great even on touch devices.
>>>
>>> Regards,
>>> Srinivasu Chakravarthula
>>> +91-9900810881
>>> Sent on my phone. Excuse typos, if any.
>>>
>>> On 08-May-2017, at 17:00, Fernand van Olphen <
>>>>
>>> = EMAIL ADDRESS REMOVED = > wrote:
>>>
>>>>
>>>> Something like this?
>>>>
>>>> https://www.w3.org/WAI/WCAG20/Techniques/working-examples/
>>>>
>>> G201/new-window.html
>>>
>>>>
>>>> - Fernand
>>>>
>>>>
>>>>
>>>>
>>>> De disclaimer van toepassing op e-mail van de gemeente Den Haag vindt u
>>>>
>>> op: http://www.denhaag.nl/disclaimer
>>>
>>>> >>>> >>>> >>>> >>>>
>>> >>> >>> >>> >>>
>>> >> >> >> >>
>>
>
> --
> Patrick H. Lauke
>
> www.splintered.co.uk | https://github.com/patrickhlauke
> http://flickr.com/photos/redux/ | http://redux.deviantart.com
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
> > > > >

From: Birkir R. Gunnarsson
Date: Mon, May 08 2017 8:13AM
Subject: Re: Icon instead of text > open in new window
← Previous message | Next message →

Here is my 1.5 cents (opinions are getting cheap).

1. Notifying users that a link opens in a new window or tab is not a
WCAG A or AA requiements (as JOnathan already said), so you don't have
to worry about it from an accessibility compliance perspective,
however it is good usability to let users know that, even more so when
the link opens a video or a PDF document (change of user agent).
2. If you decide to put an icon on the link that notifies users of
this, it becomes a WCAG 1.1.1 requirement (because all meaningful
non-text content need a text alternative).

I recommend using the title attribute on the link to notify users.
If the image is a background image you can't use an alt attribute anyway.
If it is an <img> just set its alt to ""
<a href="#" title="opens in new window">Facebook <span
icon="external"></span></a>
or
<a href="#" title="opens in new window">Facebook <img
src="externalIcon.jpg" alt=""></a>

I agree that, in general, we should leave it to the user.
The exception is any help content links in a flow (because diverting
the user away from the flow cane make it difficult for them to return
to the flow, and will make them less likely to complete the flow).
I think all help or product links in a checkout flow, for instance,
should open in a new window or tab.
I also think all social media sharing icons should open in a new
window, just because it is such a different task from navigating the
website. But that is just my personal take and no standard.





On 5/8/17, Sophie Ragas < = EMAIL ADDRESS REMOVED = > wrote:
> Well, I just want to give the user control of how he handles links, so I
> wouldn´t let links open in new windows at all. Let the user decide if he
> wants a new window or tab. I thought that that practice was generally
> recommended?
>
>
> Regards,
>
> Sophie
>
> 2017-05-08 15:02 GMT+02:00 Patrick H. Lauke < = EMAIL ADDRESS REMOVED = >:
>
>> On 08/05/2017 13:49, Sophie Ragas wrote:
>>
>>> Hi all,
>>>
>>> Just being the devils advocate here: I think that a Facebook-logo (or any
>>> other well-known site/platform) already implies for sighted users they
>>> are
>>> leaving the website they are currently on.
>>>
>>
>> But the question isn't about external vs internal links, but rather
>> whether or not the link opens a new window.
>>
>> P
>>
>>
>> Regards,
>>>
>>>
>>> Sophie
>>>
>>> 2017-05-08 14:31 GMT+02:00 = EMAIL ADDRESS REMOVED = < = EMAIL ADDRESS REMOVED = >:
>>>
>>> This works great even on touch devices.
>>>>
>>>> Regards,
>>>> Srinivasu Chakravarthula
>>>> +91-9900810881
>>>> Sent on my phone. Excuse typos, if any.
>>>>
>>>> On 08-May-2017, at 17:00, Fernand van Olphen <
>>>>>
>>>> = EMAIL ADDRESS REMOVED = > wrote:
>>>>
>>>>>
>>>>> Something like this?
>>>>>
>>>>> https://www.w3.org/WAI/WCAG20/Techniques/working-examples/
>>>>>
>>>> G201/new-window.html
>>>>
>>>>>
>>>>> - Fernand
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> De disclaimer van toepassing op e-mail van de gemeente Den Haag vindt u
>>>>>
>>>> op: http://www.denhaag.nl/disclaimer
>>>>
>>>>> >>>>> >>>>> >>>>> >>>>>
>>>> >>>> >>>> >>>> >>>>
>>>> >>> >>> >>> >>>
>>>
>>
>> --
>> Patrick H. Lauke
>>
>> www.splintered.co.uk | https://github.com/patrickhlauke
>> http://flickr.com/photos/redux/ | http://redux.deviantart.com
>> twitter: @patrick_h_lauke | skype: patrick_h_lauke
>> >> >> >> >>
> > > > >


--
Work hard. Have fun. Make history.

From: Angela French
Date: Mon, May 08 2017 9:41AM
Subject: Re: Icon instead of text > open in new window
← Previous message | Next message →

Jonathan,
When one looks at a General Technique page, how does one tell which level of conformance it applies to?

Angela French

From: Jonathan Avila
Date: Mon, May 08 2017 9:50AM
Subject: Re: Icon instead of text > open in new window
← Previous message | Next message →

> hen one looks at a General Technique page, how does one tell which level of conformance it applies to?

Follow the link in the applicability section of the technique. Most techniques map to success criteria although this one maps to a guideline. On the page you land on the (understanding techniques page) it should be listed under sufficient techniques, failures, or advisory techniques.

A sufficient technique is not required -- but is known to meet the success criteria. A failure technique is known to fail the success criteria. Advisory techniques are not required and may or may not be sufficient to meet a success criteria. In this case the technique is not listed which seems like an omitted link.

Jonathan

Jonathan Avila
Chief Accessibility Officer
SSB BART Group 
= EMAIL ADDRESS REMOVED =
703.637.8957 (Office)
Visit us online: Website | Twitter | Facebook | LinkedIn | Blog
Download our CSUN Presentations Here!

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: Srinivasu Chakravarthula
Date: Mon, May 08 2017 9:51AM
Subject: Re: Icon instead of text > open in new window
← Previous message | Next message →

Angela,
That's a good question and I see there is no way (as we speak) to know the
level of conformance right from the technique page; though there is a
section titled "applicability" and link to respective SC.

But it would be certainly worth level of conformance along with
applicability SC link. Something we should bring it to AG Working Group's
notice.

Best,
Srinivasu

Regards,

Srinivasu Chakravarthula - Twitter: http://twitter.com/CSrinivasu/
Website: http://www.srinivasu.org | http://serveominclusion.com

Let's create an inclusive web!

Lead Accessibility Consultant, Informatica


On Mon, May 8, 2017 at 9:11 PM, Angela French < = EMAIL ADDRESS REMOVED = > wrote:

> Jonathan,
> When one looks at a General Technique page, how does one tell which level
> of conformance it applies to?
>
> Angela French
>
>

From: Birkir R. Gunnarsson
Date: Mon, May 08 2017 10:54AM
Subject: Re: Icon instead of text > open in new window
← Previous message | Next message →

G200 is a bit odd, because it refers to guideline 3.2 but not to a
specific success criterion. I presume that is because it is a best
practice technique but not one linked to a level A or AA success
riterion.
Compare this with technique H2:
http://www.w3.org/TR/WCAG20-TECHS/H2.html
that references 1.1.1, 2.4.4 etc.
I might be wrong here, but I am guessing that´s how you know.


On 5/8/17, Srinivasu Chakravarthula < = EMAIL ADDRESS REMOVED = > wrote:
> Angela,
> That's a good question and I see there is no way (as we speak) to know the
> level of conformance right from the technique page; though there is a
> section titled "applicability" and link to respective SC.
>
> But it would be certainly worth level of conformance along with
> applicability SC link. Something we should bring it to AG Working Group's
> notice.
>
> Best,
> Srinivasu
>
> Regards,
>
> Srinivasu Chakravarthula - Twitter: http://twitter.com/CSrinivasu/
> Website: http://www.srinivasu.org | http://serveominclusion.com
>
> Let's create an inclusive web!
>
> Lead Accessibility Consultant, Informatica
>
>
> On Mon, May 8, 2017 at 9:11 PM, Angela French < = EMAIL ADDRESS REMOVED = > wrote:
>
>> Jonathan,
>> When one looks at a General Technique page, how does one tell which level
>> of conformance it applies to?
>>
>> Angela French
>>
>>

From: Jeremy Echols
Date: Mon, May 15 2017 10:27AM
Subject: Re: Icon instead of text > open in new window
← Previous message | Next message →

I may be wrong, but I think the title attribute would be incorrect. WebAIM's notes on titles says they should "NOT be used as a replacement for alternative text, form labels, table headers, etc.": http://webaim.org/articles/gonewild/#title

If there's an icon conveying important information, I'm of the opinion it should be an actual image with alt text, and not a background image.

From: Birkir R. Gunnarsson
Date: Mon, May 15 2017 12:23PM
Subject: Re: Icon instead of text > open in new window
← Previous message | Next message →

The purpose of the title attribute is to convey extra information
about an element.
When that element is a link, I believe that is exactly the information
that would work in the title attribute.
There are many ways to convey information, some ideal, some good enough.
That


On 5/15/17, Jeremy Echols < = EMAIL ADDRESS REMOVED = > wrote:
> I may be wrong, but I think the title attribute would be incorrect.
> WebAIM's notes on titles says they should "NOT be used as a replacement for
> alternative text, form labels, table headers, etc.":
> http://webaim.org/articles/gonewild/#title
>
> If there's an icon conveying important information, I'm of the opinion it
> should be an actual image with alt text, and not a background image.
>
>

From: Jeremy Echols
Date: Mon, May 15 2017 12:41PM
Subject: Re: Icon instead of text > open in new window
← Previous message | Next message →

Part of the problem is that it needs to be advisory information only, not information that makes the page accessible. The reason it needs to be unimportant text is that it may not be read by a screen reader. In testing, NVDA isn't reading a title on an <a> tag, nor am I able to see the title in Firefox unless I hover the mouse over it (keyboard focus isn't enough).

From WebAIM again:

"The title attribute is not read for most elements by default in most screen readers. Exceptions are the frame element and form elements that do not have a label. When a form element does not have a label, but does have a title, the title will typically be read. This approach, however, is often a misuse of title - if the title attribute is necessary to ensure accessibility of the form element, then it is certainly contains more than simply advisory information."

If the fact that it opens externally is an important consideration for AT users, a title won't suffice. If opening in an external tab/window isn't important, then there's no need to put it in a title since AT users likely won't get that title anyway.

From: Birkir R. Gunnarsson
Date: Mon, May 15 2017 1:04PM
Subject: Re: Icon instead of text > open in new window
← Previous message | Next message →

The title attribute maps to the element´s accessible description
property when it is not the source of the element's accessible name.
https://www.w3.org/TR/accname-aam-1.1/

Therefore it should be announced by assistive technologies in addition
to the element´s accessible name.
If it isn't, we need to file bugs with browsers and a.t. vendors,
until they fix it.
Announcing when an clicking an element opens a new tab or window is
not a WCAG 2.0 level A or AA requirement, as already discussed.
Now that we have a W3C specification that tells us how the title
attribute should be treated, we need to start respecting that
specification and make sure the vendors and the assistive technologies
do their parts, allowing the authors to use a convenient attribute
that should increase accessibility.
We can´t always tell authors not to do something that is proper use of
an attribute and according to spec, just because it is not supported.
Instead we need to ask ourselves why it is not supported and reach out
to those who are not supporting it.
If we discover reasons wy they technically can´t support it )e.g. a
title attribute on a non focusable element is hard to communicate by
any technology, because we don´t know the context in which it is used
or how users browser to it), we can change the spec.
If there is no reason (I think a title attribute on a focusable
element should always be exposed when that element receives focus), we
need to ask the vendors to support it.
I know this is a slight over simplification, standards and
technologies are complex, but I believe we need to do more to push
consistency between browsers and assistive technologies forward, not
always ask the authors to create workarounds.
The accessible name calculation standard is a huge step forward in
dictating how the title attribute should be treated, it was excellent
work! Now let's go ahead and take advantage of it.
Cheers
-B




On 5/15/17, Jeremy Echols < = EMAIL ADDRESS REMOVED = > wrote:
> Part of the problem is that it needs to be advisory information only, not
> information that makes the page accessible. The reason it needs to be
> unimportant text is that it may not be read by a screen reader. In testing,
> NVDA isn't reading a title on an <a> tag, nor am I able to see the title in
> Firefox unless I hover the mouse over it (keyboard focus isn't enough).
>
> From WebAIM again:
>
> "The title attribute is not read for most elements by default in most screen
> readers. Exceptions are the frame element and form elements that do not have
> a label. When a form element does not have a label, but does have a title,
> the title will typically be read. This approach, however, is often a misuse
> of title - if the title attribute is necessary to ensure accessibility of
> the form element, then it is certainly contains more than simply advisory
> information."
>
> If the fact that it opens externally is an important consideration for AT
> users, a title won't suffice. If opening in an external tab/window isn't
> important, then there's no need to put it in a title since AT users likely
> won't get that title anyway.
>
>

From: Jeremy Echols
Date: Mon, May 15 2017 2:07PM
Subject: Re: Icon instead of text > open in new window
← Previous message | Next message →

Okay, let me see if I'm reading this correctly. I'm not trying to be obnoxious here, I just don't see how the title can do what you say. I am in agreement that you don't need to announce external pages; at this point I'm just trying to make sure I understand how titles are meant to be handled.

According to https://www.w3.org/TR/wai-aria/roles#link, a link gets its name from content or author. This means a link follows all rules in https://www.w3.org/TR/wai-aria/roles#textalternativecomputation. The link doesn't have aria labeling, so 2A doesn't get triggered. It's not going to trigger 2B as far as I can tell, as it's just a simple link and not some form of widget. 2C appears to apply, as the link role allows "nameFrom: contents ". 2C seems to push for looking at children of the node in question, which triggers rule 3, which seems to me to say that it will use the text, "Facebook" as the accessible name. Rule 2D, which uses the title, will not apply because a suitable accessible name was already found: "The last resort is to use text from a tooltip attribute (such as the title attribute in HTML). This is used only if nothing else, including subtree content, has provided results."

The rules for computing accessible description and accessible name appear to be the same (other than description using aria-describedby if present), so the name and description in this case would both be "Facebook". I can forcibly change the description with an aria-describedby attribute, but not title, as it is only used if the rest of the calculations produced nothing.

Testing in NVDA and Firefox, I see the behavior I expected: "Facebook visited link" when using a title, or "Facebook visited link blah blah blah" when referring to an element via aria-describedby.

I believe this is correct behavior, and not a bug in the browser or screen reader.

From: Patrick H. Lauke
Date: Mon, May 15 2017 3:50PM
Subject: Re: Icon instead of text > open in new window
← Previous message | Next message →

The whole set of documents/specs around accessible name and accessible
description are, to put it mildly, confusing and obtuse. Lots of
overlapping, cross-referencing separate docs, with some very dense and
confusing algorithm sections that aim for brevity but simply result in
more questions than answers. (plus there's both editor's drafts and
working drafts, mixed in with some outdated/deprecated/superseded ones).

I've already vented about this https://github.com/w3c/aria/issues/544
... feel free to add a voice of support / a +1 :)

In the case of links, I'd recommend looking at
https://w3c.github.io/html-aam/#a-element (the HTML specific guidance on
how things should be mapped), as this splits out the name and
description calculations into separate algorithms which are much clearer
to parse for a reader. And if you look at "5.12.2 a Element Accessible
Description Computation" the steps are much more straightforward (and
support what was said on list earlier about title and how it should map
to the accessible description, regardless of accessible name):

"1, If the element has an aria-describedby attribute the accessible
description is to be calculated using the algorithm defined in
Accessible Name and Description: Computation and API Mappings 1.1.
2. Otherwise use the title attribute if it wasn't used as the
accessible name
3. If none of the above yield a usable text string there is no
accessible description"

P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: Jeremy Echols
Date: Mon, May 15 2017 4:25PM
Subject: Re: Icon instead of text > open in new window
← Previous message | Next message →

I put in a long message. Thanks for the other document, that's far more helpful. I'm rather concerned at the apparent inconsistency in the documentation, though - I wonder what other conclusions I've made based on poor docs.

I read and re-read the relevant sections of the links I posted for probably 30 minutes. I didn't want to argue against Birkir without some pretty solid information.

Turns out the information wasn't all that solid after all.

From: Jonathan Avila
Date: Tue, May 16 2017 7:07AM
Subject: Re: Icon instead of text > open in new window
← Previous message | Next message →

> The whole set of documents/specs around accessible name and accessible description are, to put it mildly, confusing and obtuse. Lots of overlapping, cross-referencing separate docs

Yes, and the language about concatenation can trip up some people as well. There are also a number of ambiguities that need to be cleared up. For example, what happens with aria-label="" (null) or an aria-label=" " (a space or non-breakable space)? Is a space the accessible or name or does the algorithm consider that there is no valid aria-label and move on to the next step?

There are also a number of edge cases around sub-tree and referenced content that is hidden with different techniques and don't forget to include pseudo content as well!

> In the case of links, I'd recommend looking at https://w3c.github.io/html-aam/#a-element

I'd second this as a great resource.

Jonathan

Jonathan Avila
Chief Accessibility Officer
SSB BART Group 
= EMAIL ADDRESS REMOVED =
703.637.8957 (Office)

Visit us online: Website | Twitter | Facebook | LinkedIn | Blog
Download our CSUN Presentations Here!

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: Tue, May 16 2017 7:17AM
Subject: Re: Icon instead of text > open in new window
← Previous message | Next message →

True, the spec can use lots more work.
In fact, I am not even sure what alt=" " should translate to (to take
an older example). Should it mark the image as presentational, or is
it really assign an empty white space as the alt text for an image. I
have dug around the specs and not seen a definitive answer.
There are series of other ARIA ambituities that are puzzling to people
trying to use it. I will bring up some of those in my presentation on
ID 24 on June 9th (ARIA 51).
Good discussion guys, I never claim infallibility. I believe it one of
my better qualities in fact.
One thing to add re using an icon with an alt text (which is a
perfectly valid technique, and in some ways a better one than the
title attribute).
If you do, make sure the icon and its alt text are placed after the
link text, else every link that opens in a new window will start with
the words "opens in a new window.
It is not a WCAG violation per se, but it will make link text boring,
wordy, and irritating for a screen reader user.



On 5/16/17, Jonathan Avila < = EMAIL ADDRESS REMOVED = > wrote:
>> The whole set of documents/specs around accessible name and accessible
>> description are, to put it mildly, confusing and obtuse. Lots of
>> overlapping, cross-referencing separate docs
>
> Yes, and the language about concatenation can trip up some people as well.
> There are also a number of ambiguities that need to be cleared up. For
> example, what happens with aria-label="" (null) or an aria-label=" " (a
> space or non-breakable space)? Is a space the accessible or name or does
> the algorithm consider that there is no valid aria-label and move on to the
> next step?
>
> There are also a number of edge cases around sub-tree and referenced content
> that is hidden with different techniques and don't forget to include pseudo
> content as well!
>
>> In the case of links, I'd recommend looking at
>> https://w3c.github.io/html-aam/#a-element
>
> I'd second this as a great resource.
>
> Jonathan
>
> Jonathan Avila
> Chief Accessibility Officer
> SSB BART Group
> = EMAIL ADDRESS REMOVED =
> 703.637.8957 (Office)
>
> Visit us online: Website | Twitter | Facebook | LinkedIn | Blog
> Download our CSUN Presentations Here!
>
> 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: Jeremy Echols
Date: Tue, May 16 2017 10:15AM
Subject: Re: Icon instead of text > open in new window
← Previous message | No next message

Very informative discussion for sure. I'm glad I'm not just crazy, but not so glad the specs are so difficult.