WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Links opening in new windows - 3.2.2

for

From: Jared Smith
Date: Aug 5, 2014 2:40PM

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