E-mail List Archives

Search E-mail List Archives for

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

From: Karl Groves
Date: Mon, Aug 04 2014 10:01PM
Subject: Links opening in new windows
No previous message | Next message →

WCAG SC 3.2.2 says: "On Input: Changing the setting of any user interface
component does not automatically cause a change of context unless the user
has been advised of the behavior before using the component."

Change of context specifically includes opening new windows[1]
A user interface component is defined as "a part of the content that is
perceived by users as a single control for a distinct function"[2]

The WCAG documentation for Understanding SC 3.2.2[3]contradicts other
information by saying "Note: This Success Criterion covers changes in
context due to changing the setting of a control. Clicking on links or tabs
in a tab control is activating the control, not changing the setting of
that control."

and yet WCAC Advisory Technique G201 is titled "Giving users advanced
warning when opening a new window", and demonstrates two approaches for
providing this warning on a link.[4]

Similar techniques include H83, SCR24, and G200. In all cases, the
technique discusses the disorientation caused by changing context
unpredictably. However, there are no failure techniques listed for *not*
declaring that a new window is opened.

Questions:
Do you think 3.2.2 includes links?
Do you think the warning(s) must be provided, as is the case in G201?


1 - http://www.w3.org/TR/2008/REC-WCAG20-20081211/#context-changedef
2 -
http://www.w3.org/TR/2008/REC-WCAG20-20081211/#user-interface-componentdef
3 -
http://www.w3.org/TR/UNDERSTANDING-WCAG20/consistent-behavior-unpredictable-change.html
4 - http://www.w3.org/TR/2014/NOTE-WCAG20-TECHS-20140408/G201
--

Karl Groves
www.karlgroves.com
@karlgroves
http://www.linkedin.com/in/karlgroves
Phone: +1 410.541.6829

Modern Web Toolsets and Accessibility
https://www.youtube.com/watch?v=_uq6Db47-Ks

www.tenon.io

From: Karl Groves
Date: Tue, Aug 05 2014 6:00AM
Subject: Re: Links opening in new windows
← Previous message | Next message →

For anyone interested in this topic, it has been well discussed over at
http://lists.w3.org/Archives/Public/w3c-wai-gl/2014JulSep/thread.html#msg14

Thanks to Steve Faulkner for pointing it out


On Tue, Aug 5, 2014 at 12:01 AM, Karl Groves < = EMAIL ADDRESS REMOVED = > wrote:

> WCAG SC 3.2.2 says: "On Input: Changing the setting of any user interface
> component does not automatically cause a change of context unless the user
> has been advised of the behavior before using the component."
>
> Change of context specifically includes opening new windows[1]
> A user interface component is defined as "a part of the content that is
> perceived by users as a single control for a distinct function"[2]
>
> The WCAG documentation for Understanding SC 3.2.2[3]contradicts other
> information by saying "Note: This Success Criterion covers changes in
> context due to changing the setting of a control. Clicking on links or tabs
> in a tab control is activating the control, not changing the setting of
> that control."
>
> and yet WCAC Advisory Technique G201 is titled "Giving users advanced
> warning when opening a new window", and demonstrates two approaches for
> providing this warning on a link.[4]
>
> Similar techniques include H83, SCR24, and G200. In all cases, the
> technique discusses the disorientation caused by changing context
> unpredictably. However, there are no failure techniques listed for *not*
> declaring that a new window is opened.
>
> Questions:
> Do you think 3.2.2 includes links?
> Do you think the warning(s) must be provided, as is the case in G201?
>
>
> 1 - http://www.w3.org/TR/2008/REC-WCAG20-20081211/#context-changedef
> 2 -
> http://www.w3.org/TR/2008/REC-WCAG20-20081211/#user-interface-componentdef
> 3 -
> http://www.w3.org/TR/UNDERSTANDING-WCAG20/consistent-behavior-unpredictable-change.html
> 4 - http://www.w3.org/TR/2014/NOTE-WCAG20-TECHS-20140408/G201
> --
>
> Karl Groves
> www.karlgroves.com
> @karlgroves
> http://www.linkedin.com/in/karlgroves
> Phone: +1 410.541.6829
>
> Modern Web Toolsets and Accessibility
> https://www.youtube.com/watch?v=_uq6Db47-Ks
>
> www.tenon.io
>
>
>


--

Karl Groves
www.karlgroves.com
@karlgroves
http://www.linkedin.com/in/karlgroves
Phone: +1 410.541.6829

Modern Web Toolsets and Accessibility
https://www.youtube.com/watch?v=_uq6Db47-Ks

www.tenon.io

From: Jared Smith
Date: Tue, Aug 05 2014 8:48AM
Subject: Re: Links opening in new windows
← Previous message | Next message →

Karl Groves wrote:

> Do you think 3.2.2 includes links?

No.

3.2.2 is titled "On Input...". Links do not take input. It would,
however, be a 3.2.2 failure if the user is typing in a text box or
changes a select menu, for example, and a new window opens that they
have not been previously informed of.

> Do you think the warning(s) must be provided, as is the case in G201?

Yes, but only if you're talking about input or focus.

The example in G201 is incorrect. It uses a link with target="_blank"
as an example, but it's already been made clear that activating a link
is not "Input" or "Focus". G201 (which is an Advisory Technique, not a
Sufficient Technique) provides a technique for something that is not
even covered by the success criteria it is associated to! This would
be like having a technique for color contrast associated to the
success criteria for alternative text, except that color contrast is
at least covered elsewhere in WCAG. A requirement that users be
informed that links open in new windows is not.

Clearly several in the WCAG working group thread you posted seemed to
want to contort and reinterpret a success criterion (ANY success
criterion for that matter) to somehow force this in as a new failure.

Opening new windows is also not covered by 3.2.5. The other techniques
you list (H83, SCR24, and G200) are quite a stretch in their
applicability to this success criteria. 3.2.5 says that you can't
cause a change of context that is not user initiated. Opening a new
window at a random point in time would be a failure, but clicking a
link is an explicit user request for a change of context and would not
be, even if it opens a new window.

In reality, links that open in new windows without previous
notification can be confusing... but for everyone. It is a usability
issue, but it's not something addressed by WCAG (well, at least the
normative part, not counting these advisory techniques for which there
is no proper success criteria).

I can argue that there are situations where informing users that links
open in new windows could make an interface LESS usable and
accessible. It would be burdensome and unnecessary to indicate that
all links open in new windows in Gmail, for example, where all links
in messages do so consistently.

Jared

From: Karl Groves
Date: Tue, Aug 05 2014 9:33AM
Subject: Re: Links opening in new windows
← Previous message | Next message →

"The example in G201 is incorrect. It uses a link with target="_blank"
as an example, but it's already been made clear that activating a link
is not "Input" or "Focus". G201 (which is an Advisory Technique, not a
Sufficient Technique) provides a technique for something that is not
even covered by the success criteria it is associated to! "

Pretty much my point exactly.

Thanks.


On Tue, Aug 5, 2014 at 10:48 AM, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:

> Karl Groves wrote:
>
> > Do you think 3.2.2 includes links?
>
> No.
>
> 3.2.2 is titled "On Input...". Links do not take input. It would,
> however, be a 3.2.2 failure if the user is typing in a text box or
> changes a select menu, for example, and a new window opens that they
> have not been previously informed of.
>
> > Do you think the warning(s) must be provided, as is the case in G201?
>
> Yes, but only if you're talking about input or focus.
>
> The example in G201 is incorrect. It uses a link with target="_blank"
> as an example, but it's already been made clear that activating a link
> is not "Input" or "Focus". G201 (which is an Advisory Technique, not a
> Sufficient Technique) provides a technique for something that is not
> even covered by the success criteria it is associated to! This would
> be like having a technique for color contrast associated to the
> success criteria for alternative text, except that color contrast is
> at least covered elsewhere in WCAG. A requirement that users be
> informed that links open in new windows is not.
>
> Clearly several in the WCAG working group thread you posted seemed to
> want to contort and reinterpret a success criterion (ANY success
> criterion for that matter) to somehow force this in as a new failure.
>
> Opening new windows is also not covered by 3.2.5. The other techniques
> you list (H83, SCR24, and G200) are quite a stretch in their
> applicability to this success criteria. 3.2.5 says that you can't
> cause a change of context that is not user initiated. Opening a new
> window at a random point in time would be a failure, but clicking a
> link is an explicit user request for a change of context and would not
> be, even if it opens a new window.
>
> In reality, links that open in new windows without previous
> notification can be confusing... but for everyone. It is a usability
> issue, but it's not something addressed by WCAG (well, at least the
> normative part, not counting these advisory techniques for which there
> is no proper success criteria).
>
> I can argue that there are situations where informing users that links
> open in new windows could make an interface LESS usable and
> accessible. It would be burdensome and unnecessary to indicate that
> all links open in new windows in Gmail, for example, where all links
> in messages do so consistently.
>
> Jared
> > > >



--

Karl Groves
www.karlgroves.com
@karlgroves
http://www.linkedin.com/in/karlgroves
Phone: +1 410.541.6829

Modern Web Toolsets and Accessibility
https://www.youtube.com/watch?v=_uq6Db47-Ks

www.tenon.io

From: Andrew Kirkpatrick
Date: Tue, Aug 05 2014 11:24AM
Subject: Re: Links opening in new windows
← Previous message | Next message →

There were a couple of different perspectives offered in the WCAG working group thread. It is worth noting that not everyone on that thread is a member of the working group, but even if you constrain the comments to people who are current members in good standing you'll find differences of opinion.

Karl submitted the question to the working group via the group's comment email address (thank you), so the group will be discussing the question and will be able to offer its view on the subject.

I'm sure that response will be shared here.

Thanks,
AWK

From: Jared Smith
Date: Tue, Aug 05 2014 11:38AM
Subject: Re: Links opening in new windows - 3.2.2
← Previous message | Next message →

Katie wrote:

> But, by the normative WCAG 2 document the
> success criteria says 'user interface component'
> and that term on *that* same page says 'links' are
> a 'user interface component'.

The success criteria reads in full, "Changing the setting of any user
interface component does not automatically cause a change of context
unless the user has been advised of the behavior before using the
component."

You correctly state that a link is a user interface component. "Change
of context" is defined to include moving focus and opening new pages.

So let's follow your flawed logic a bit. You suggest that activating a
link is "changing the setting" of that link. I disagree. How does
activating a link "change the setting" of that link to cause it to
open a new window? It doesn't. The fact that the link is programmed to
open a new window does not change by the user activating it. The
change is not user initiated, but author defined.

And this doesn't even consider the flawed suggestion that activating a
link is "input" to begin with.

But let's say that you're correct and that activating a link is also
"changing the setting" of that link. This means that activating any
link that "automatically causes a change of context" (new window, move
focus, or open a new page) would be a failure. If this is the case,
then ALL links (at least any that do anything useful) fail 3.2.2. The
only way to pass SC3.2.2 would be to identify that all links cause a
change of context, which, by definition, is what links do.

You can't define activating a link as "input" and as "changing a
setting" and then pick and choose which types of changes of context
(only new windows or dialogs, but not change of focus or new pages?)
would be a failure.

> F76: Failure of Success Criterion 3.2.2 due to
> providing instruction material about the change
> of context by change of setting in a user interface
> element at a location that users may bypass

That's is so unintelligible I can hardly comment on it. I'm also
pretty sure it should read "due to NOT providing...", otherwise adding
the instructions results in the failure.

Anyway, the text of this failure talks about "unexpected change of
context due to change of user interface setting". How can a change of
context be unexpected if the user initiates it by clicking a link? As
above, by this flawed logic any user-activated change of context
(links, buttons, etc.) would be a failure.

Jared

From: Greg Gamble
Date: Tue, Aug 05 2014 11:49AM
Subject: Re: Links opening in new windows
← Previous message | Next message →

Does it matter if the link is opening a new window for a site outside the framework of the current site?

For instance, if a user clicks a link and is taken to a site not tied to the one that the user is currently at, as compared to one that is related to the current site ... like a subdomain.

Is a new window expected for one and the other not?


Greg

From: Karl Groves
Date: Tue, Aug 05 2014 11:52AM
Subject: Re: Links opening in new windows
← Previous message | Next message →

Thank you very much!


On Tue, Aug 5, 2014 at 1:24 PM, Andrew Kirkpatrick < = EMAIL ADDRESS REMOVED = >
wrote:

> There were a couple of different perspectives offered in the WCAG working
> group thread. It is worth noting that not everyone on that thread is a
> member of the working group, but even if you constrain the comments to
> people who are current members in good standing you'll find differences of
> opinion.
>
> Karl submitted the question to the working group via the group's comment
> email address (thank you), so the group will be discussing the question and
> will be able to offer its view on the subject.
>
> I'm sure that response will be shared here.
>
> Thanks,
> AWK
>
>

From: Karl Groves
Date: Tue, Aug 05 2014 12:05PM
Subject: Re: Links opening in new windows
← Previous message | Next message →

Greg,

It might be worthwhile to search the archives a bit. I recall (possibly
several years ago) posting some observations I made during usability
studies. The short version is that the way the window/ tab opens is very
important. In usability studies it is very common for participants to not
notice the new window/ tab. The side effect being the exact opposite of
what people intend. Site owners often say "we want the new window so users
don't lose our site" and yet the exact opposite tends to happen.




On Tue, Aug 5, 2014 at 1:49 PM, Greg Gamble < = EMAIL ADDRESS REMOVED = > wrote:

> Does it matter if the link is opening a new window for a site outside the
> framework of the current site?
>
> For instance, if a user clicks a link and is taken to a site not tied to
> the one that the user is currently at, as compared to one that is related
> to the current site ... like a subdomain.
>
> Is a new window expected for one and the other not?
>
>
> Greg
>
>

From: Greg Gamble
Date: Tue, Aug 05 2014 12:23PM
Subject: Re: Links opening in new windows
← Previous message | Next message →

Thanks Karl

What if they were notified? Would that be acceptable?

For example, the links here have a hidden span tag that shows on hover :
https://gedverify.org/contact.aspx



Greg

From: Karl Groves
Date: Tue, Aug 05 2014 12:57PM
Subject: Re: Links opening in new windows
← Previous message | Next message →

Greg,

It depends on the use case. As Jared mentioned, there are likely to be
use cases, like Gmail, where the notifications would not only be
burdensome but unnecessary.

In other cases, it'd be very helpful.

One thing to keep in mind when providing such notifications is that
you should try to avoid being too verbose. For instance, your notice
says "This link opens in a new window". Imagine, for a moment, that
you had to listen to that. What are the *most* important words in
that phrase? IMO they're "opens new window".

This is obviously an area of high subjectivity. Some people might
argue that any kind of warning is unnecessary and they'd prefer not to
have it at all.

On Tue, Aug 5, 2014 at 2:23 PM, Greg Gamble < = EMAIL ADDRESS REMOVED = > wrote:
> Thanks Karl
>
> What if they were notified? Would that be acceptable?
>
> For example, the links here have a hidden span tag that shows on hover :
> https://gedverify.org/contact.aspx
>
>
>
> Greg
>
>
>

From: Greg Gamble
Date: Tue, Aug 05 2014 2:01PM
Subject: Re: Links opening in new windows
← Previous message | Next message →

> One thing to keep in mind when providing such notifications is that you should try to avoid being too verbose. For instance, your notice says "This link opens in a new window". Imagine, for a moment, that you had to listen to that. What are the *most* important words in that phrase? IMO they're "opens new window".

Excellent point ... thank you.


Greg

From: Jared Smith
Date: Tue, Aug 05 2014 2:40PM
Subject: Re: Links opening in new windows - 3.2.2
← Previous message | Next message →

Katie wrote:

> Thank you for your thoughtful comments.

And thank you for your very well articulated response. I don't agree,
but I very much enjoy the dialogue.

> Overlays or Modal Dialogs (components that
> were unknown or very rare when this SC was
> written) that do not identify what will happen
> in advance....do in fact introduce a change of
> context (not content only)

Of course they do. And they introduce a change of context even if they
don't notify in advance. Changes of context are not bad. That's what
links do. What is bad and what WCAG is trying to address is when
unexpected changes of context occur On Input or On Focus. And that's
all.

Nobody is questioning whether these links result in a change of
context - the question is whether the change of context is "automatic"
(generally meaning "unexpected") and also caused On Input (i.e.,
"changing the setting of an interface component").

> The normative definition of UI Component and
> this definition (below) for change of context,
> all make it pretty clear to me that links can be
> included, when they cause a change of context.)

There's no question that links are interface components or that links
almost always cause a change of context. We're in agreement here.

> There is no guidance in the normative spec
> concerning "Changing the setting of any user
> interface component" and whether or not it is
> activating the control

Correct.

> or changing the setting of that control.

Incorrect. The normative success criterion explicitly states it
applies to "changing the setting of any interface component". You
can't argue that changing a setting is somehow not changing a setting.
You can question, however, as I am, whether clicking a link is
changing a setting.

> Clicking on a link does change the state of that link to active.

It's quite a stretch to conflate states and settings. Remember, we're
talking about the "On Input" success criteria. If WCAG were concerned
about the "On Click" state of controls, why did it only address "On
Input" and "On Focus" states? Because "On Click" is SUPPOSED to
initiate a change of context!

> The expectation when a user clicks a
> link, in general, is that the back button
> will return them to where they were before
> they clicked that link.

Right, but the success criterion does not require that the back button
function or even that a back button exist. There is no back button in
Flash or PDF, yet we have links/buttons in them. Are links/buttons in
these technologies non-conformant? Of course not!

Again, the question is not whether there is a change of context, but
what causes the change of context - a "change of setting" or something
else? If it's something else, then it can't be a failure.

Consider the following interactions:

1. Clicking a "Compose" button in an e-mail application sets focus to
the composition window.

2. Clicking the "Close" link or hitting Escape in a dialog closes that
dialog and sets focus back to a logical interface element.

3. Activating a "skip to main content" or table of contents link sets
focus to a page section using scripting (the only way to set focus in
many web technologies).

4. Using an autocomplete search widget to select a suggested item and
have focus set back to the search text box.

5. Clicking a link which opens a PDF or Word document in an external
application.

All of these result in a change of context (as buttons and links do).
None of these result in the back button working. None inform the user
ahead of time of this change of context. Do you believe all of these
to be WCAG failures? If not, can you explain what differentiates these
from a link that opens a dialog or a new window?

> You wrote "You can't define activating a link as
> "input" and as "changing a setting" and then
> pick and choose which types of changes of
> context (only new windows or dialogs, but not
> change of focus or new pages?) would be a
> failure." I would question, why not in the case
> of a scripted link that breaks the back button
> convention?

If you think there needs to be a success criteria that requires an
interface component to return the user to the previous state, then
this would be an interesting consideration for future WCAG updates,
but let's not contort and redefine WCAG 2.0 to try and address this
issue in ways it wasn't intended.

Jared

From: Birkir R. Gunnarsson
Date: Tue, Aug 05 2014 4:45PM
Subject: Re: Links opening in new windows
← Previous message | Next message →

One additional pizza slice for thought.
If _blank is used in the link to tell the browser that link opens in a
new window, it is up to the assistive technology to offer user the
configuration option of reporting that.
I could possibly maybe see value in advising developers who use
Javascript to open a link in a new tab or window to add a "new window"
icon as well as a non-visual indication (title or off-screen text) as
a good usability, not as a WCAG violation.
As a screen reader user, I actually find the biggest "change of
context" to be links to PDF files that are not marked as such when the
default setting is to display PDF in the browser rather than opening
it in AdobeReader.
IE at least half freezes up with Jaws and sometimes I have to restart
the browser.
As uch as I would like to pin that on the site developers and ask them
to get their accessible act together, I cannot see that they are doing
anything. Unless, of course, they provide a file icon visually.



On 8/5/14, Greg Gamble < = EMAIL ADDRESS REMOVED = > wrote:
>> One thing to keep in mind when providing such notifications is that you
>> should try to avoid being too verbose. For instance, your notice says
>> "This link opens in a new window". Imagine, for a moment, that you had to
>> listen to that. What are the *most* important words in that phrase? IMO
>> they're "opens new window".
>
> Excellent point ... thank you.
>
>
> Greg
>
>
>

From: Olaf Drümmer
Date: Wed, Aug 06 2014 1:29AM
Subject: Re: Links opening in new windows
← Previous message | Next message →

Hi Birkir,

On 6 Aug 2014, at 00:45, "Birkir R. Gunnarsson" < = EMAIL ADDRESS REMOVED = > wrote:

> One additional pizza slice for thought.
> If _blank is used in the link to tell the browser that link opens in a
> new window, it is up to the assistive technology to offer user the
> configuration option of reporting that.

yes, please!

> As a screen reader user, I actually find the biggest "change of
> context" to be links to PDF files that are not marked as such when the
> default setting is to display PDF in the browser rather than opening
> it in AdobeReader.

isn't the situation similar in at least some cases when complex non-HT<ML content has to be loaded - Flash, videos, … and of course PDF, especially if it's a complex one.

But again - wouldn't the user agent / assistive technology conceptually be the right place to fix this? Most of the time all the information is in the data provided via the web server.

In general I think that this class of problems is more efficiently solved on the user agent / assistive technology side than on the side of the web server / web site. There are millions and millions of sites, but probably only hundreds or maybe thousands of user agents and assistive technology tools. Once a good user agent and/or piece of assistive technology is available to a user, lots of issues would go away. The only aspect web site developers (in this context at least) would have to adhere to is that the data / content they provide must be 'detectable', programmatically readable in a reasonably consistent fashion (this implies that certain JavaScript based app-like approaches might not work; it would definitely work for PDF files… ).


Olaf

From: Birkir R. Gunnarsson
Date: Wed, Aug 06 2014 7:14AM
Subject: Re: Links opening in new windows
← Previous message | Next message →

I agree 100%
Not to stray too far from the topic, so I will not ellaborate further
on this, except perhaps in a different thread, but it must be said
that sometimes we place an awful lot of undue burden on the content
developers and editors, for problems that the assistive technology
vendors would be able to detect/solve.

WE need accessible authoring (content and code), compliant user agents
such as browsers, compliant, smart and innovative assistive
technology hardware and software that takes advantage of this, and the
necessary end user training.
As a community I often get the feeling we try to pin the problems on
the content authors, perhaps because that is most likely to yield the
short-term goal, which is to make the information accessible to the
users, preferably as quickly as possible.

But we must be mindful to try and strengthen all the links in this
chain and build for the future as well as resolving the immediate
problem.

There is a lot of good things going onin that regard, but we can do even more.
Endof off-topic rant, and good day to you!
-B


On 8/6/14, Olaf Drümmer < = EMAIL ADDRESS REMOVED = > wrote:
> Hi Birkir,
>
> On 6 Aug 2014, at 00:45, "Birkir R. Gunnarsson"
> < = EMAIL ADDRESS REMOVED = > wrote:
>
>> One additional pizza slice for thought.
>> If _blank is used in the link to tell the browser that link opens in a
>> new window, it is up to the assistive technology to offer user the
>> configuration option of reporting that.
>
> yes, please!
>
>> As a screen reader user, I actually find the biggest "change of
>> context" to be links to PDF files that are not marked as such when the
>> default setting is to display PDF in the browser rather than opening
>> it in AdobeReader.
>
> isn't the situation similar in at least some cases when complex non-HT<ML
> content has to be loaded - Flash, videos, ... and of course PDF, especially if
> it's a complex one.
>
> But again - wouldn't the user agent / assistive technology conceptually be
> the right place to fix this? Most of the time all the information is in the
> data provided via the web server.
>
> In general I think that this class of problems is more efficiently solved on
> the user agent / assistive technology side than on the side of the web
> server / web site. There are millions and millions of sites, but probably
> only hundreds or maybe thousands of user agents and assistive technology
> tools. Once a good user agent and/or piece of assistive technology is
> available to a user, lots of issues would go away. The only aspect web site
> developers (in this context at least) would have to adhere to is that the
> data / content they provide must be 'detectable', programmatically readable
> in a reasonably consistent fashion (this implies that certain JavaScript
> based app-like approaches might not work; it would definitely work for PDF
> files... ).
>
>
> Olaf
>
>
> > > >


--
Work hard. Have fun. Make history.

From: Andrew Kirkpatrick
Date: Tue, Aug 12 2014 5:43PM
Subject: Re: Links opening in new windows
← Previous message | Next message →

The WCAG WG discussed this issue on the call today and provided a response to Karl's comment. See the response at: http://lists.w3.org/Archives/Public/public-comments-wcag20/2014Aug/0010.html

Hope this helps,
AWK

From: Jared Smith
Date: Wed, Aug 13 2014 6:49PM
Subject: Re: Links opening in new windows
← Previous message | No next message

Andrew -

Thank you to you and the working group for considering this question.
It's clear it was thoroughly considered and well documented. I'm glad
to see such great progress being made on providing these needed
updates and clarifications. Assigning the advisory techniques to the
Predictable guideline instead being misaligned to a success criteria
allows it to inform the concept without muddying the waters and
resulting is misunderstanding of the success criteria.

Cheers,

Jared



On Tue, Aug 12, 2014 at 5:43 PM, Andrew Kirkpatrick < = EMAIL ADDRESS REMOVED = > wrote:
> The WCAG WG discussed this issue on the call today and provided a response to Karl's comment. See the response at: http://lists.w3.org/Archives/Public/public-comments-wcag20/2014Aug/0010.html
>
> Hope this helps,
> AWK
>
>