E-mail List Archives

Search E-mail List Archives for

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

From: Lynn Holdsworth
Date: Tue, Feb 10 2015 3:00AM
Subject: Where do single page applications fail WCAG2?
No previous message | Next message →

Hi all,

I'm looking at a single-page application which, when I press the Login
button, loads a whole new set of main content, essentially a new page,
without alerting screenreader users or moving the focus to somewhere
appropriate.

I understand what's wrong with this scenario and how to fix it, but I
can't find where it fails under WCAG2. Someone please tell me it does
fail!

I'd really appreciate any concrete info on which checkpoint(s) I
should fail this under.

Thanks as always, Lynn

From: Patrick H. Lauke
Date: Tue, Feb 10 2015 3:12AM
Subject: Re: Where do single page applications fail WCAG2?
← Previous message | Next message →

On 10/02/2015 10:00, Lynn Holdsworth wrote:
> I'm looking at a single-page application which, when I press the Login
> button, loads a whole new set of main content, essentially a new page,
> without alerting screenreader users or moving the focus to somewhere
> appropriate.
>
> I understand what's wrong with this scenario and how to fix it, but I
> can't find where it fails under WCAG2. Someone please tell me it does
> fail!
>
> I'd really appreciate any concrete info on which checkpoint(s) I
> should fail this under.

2.4.3. Focus Order would be a good start. Generally, if new content
appears and the focus is programmatically moved to it, screenreaders
will take it from there. If the focus isn't moved, or is reset/lost to
the start of the document, the order is inherently wrong/illogical.

Depending on the specifics, 4.1.2 Name, Role, Value may also play a part
here (to make sure controls expose their correct role, alerts/dialogs
are correctly identified, 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: Lynn Holdsworth
Date: Tue, Feb 10 2015 3:38AM
Subject: Re: Where do single page applications fail WCAG2?
← Previous message | Next message →

Thanks Patrick.

I did think about 4.1.2, but wondered if I might be trying to shoehorn
a square peg into a round hole.

And as for focus order, the focus seems to go to the first link in the
document, which is where it would go if a whole new page were loaded,
so I'm not sure I can fault them on that.

What I really want to fail them on is something around AT not being
alerted to the fact that new content has loaded. JAWS for one isn't
always great at refreshing its off-screen model, and in this case it
tells me that I'm still on the Login button, which doesn't exist in
the newly loaded view.

Best, Lynn

On 10/02/2015, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = > wrote:
> On 10/02/2015 10:00, Lynn Holdsworth wrote:
>> I'm looking at a single-page application which, when I press the Login
>> button, loads a whole new set of main content, essentially a new page,
>> without alerting screenreader users or moving the focus to somewhere
>> appropriate.
>>
>> I understand what's wrong with this scenario and how to fix it, but I
>> can't find where it fails under WCAG2. Someone please tell me it does
>> fail!
>>
>> I'd really appreciate any concrete info on which checkpoint(s) I
>> should fail this under.
>
> 2.4.3. Focus Order would be a good start. Generally, if new content
> appears and the focus is programmatically moved to it, screenreaders
> will take it from there. If the focus isn't moved, or is reset/lost to
> the start of the document, the order is inherently wrong/illogical.
>
> Depending on the specifics, 4.1.2 Name, Role, Value may also play a part
> here (to make sure controls expose their correct role, alerts/dialogs
> are correctly identified, 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: Patrick H. Lauke
Date: Tue, Feb 10 2015 4:27AM
Subject: Re: Where do single page applications fail WCAG2?
← Previous message | Next message →

On 10/02/2015 10:38, Lynn Holdsworth wrote:
> And as for focus order, the focus seems to go to the first link in the
> document, which is where it would go if a whole new page were loaded,
> so I'm not sure I can fault them on that.
>
> What I really want to fail them on is something around AT not being
> alerted to the fact that new content has loaded. JAWS for one isn't
> always great at refreshing its off-screen model, and in this case it
> tells me that I'm still on the Login button, which doesn't exist in
> the newly loaded view.

This sounds more like the focus is actually lost, rather than being
programmatically set to the newly shown content. A subsequent TAB would
then go to the first link in the document, purely because the browser
actually lost it and reset it to the start of the document.

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: Lynn Holdsworth
Date: Tue, Feb 10 2015 5:40AM
Subject: Re: Where do single page applications fail WCAG2?
← Previous message | Next message →

Hi Patrick,

> This sounds more like the focus is actually lost, rather than being programmatically set to the newly shown content.

But is it? If we're mimicking a new page load, which is surely what
SPA's are doing, shouldn't the focus behave in the same way as it
would if we'd reached a new page?

I wish I knew what event causes screenreaders to read new pages and
not significant amounts of new content. Then perhaps we could fire off
that event.

Thanks for all your input - it's given me a lot of food for thought. I
guess I'll fail this issue under focus order, but it doesn't feel like
a great fit to me.

Best, Lynn

On 10/02/2015, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = > wrote:
> On 10/02/2015 10:38, Lynn Holdsworth wrote:
>> And as for focus order, the focus seems to go to the first link in the
>> document, which is where it would go if a whole new page were loaded,
>> so I'm not sure I can fault them on that.
>>
>> What I really want to fail them on is something around AT not being
>> alerted to the fact that new content has loaded. JAWS for one isn't
>> always great at refreshing its off-screen model, and in this case it
>> tells me that I'm still on the Login button, which doesn't exist in
>> the newly loaded view.
>
> This sounds more like the focus is actually lost, rather than being
> programmatically set to the newly shown content. A subsequent TAB would
> then go to the first link in the document, purely because the browser
> actually lost it and reset it to the start of the document.
>
> 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: Bim Egan
Date: Tue, Feb 10 2015 5:44AM
Subject: Re: Where do single page applications fail WCAG2?
← Previous message | Next message →

You're right Patrick,
It does sound as though focus has been lost. It's a common problem in
single page applications, along with the fact that there's no change in
page title unless JavaScript has been used to update it.

But I see Lynn's problem, loss of focus or context comes under WCAG2 SC
3.2.2 On Input, which says that it covers a change of setting for a form
control, but does not cover the activation of a link or button. [1]

Single page applications can be made accessible, but can they be deemed to
fail WCAG2 at Level AA or even Level A? They should, as the loss of focus
and page title problems are extremely disorientating for blind people. But
if the overall page has a title and the focus is lost on activating a
button, what does it fail on?

Bim
[1]
http://www.w3.org/TR/UNDERSTANDING-WCAG20/consistent-behavior-unpredictable-
change.html

From: Patrick H. Lauke
Date: Tue, Feb 10 2015 6:05AM
Subject: Re: Where do single page applications fail WCAG2?
← Previous message | Next message →

On 10/02/2015 12:40, Lynn Holdsworth wrote:
> Hi Patrick,
>
>> This sounds more like the focus is actually lost, rather than being programmatically set to the newly shown content.
>
> But is it? If we're mimicking a new page load, which is surely what
> SPA's are doing, shouldn't the focus behave in the same way as it
> would if we'd reached a new page?

When a completely new page loads, browsers notify screenreaders (that a
page load is in progress, when it's finished, etc) and then the browser
itself explicitly resets the focus. In your case, the focus isn't
reset...it just sits in limbo (after what was originally focused was
hidden/removed from the page's DOM/accessibility tree). So it *does*
need to be explicitly moved - to the start of the document, if that's
the most sensible place for it, but still programmatically.

> I wish I knew what event causes screenreaders to read new pages and
> not significant amounts of new content. Then perhaps we could fire off
> that event.

There is no relevant event that can be fired, I'm afraid. But the above
will do the job.

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: Lynn Holdsworth
Date: Tue, Feb 10 2015 6:16AM
Subject: Re: Where do single page applications fail WCAG2?
← Previous message | Next message →

Thanks Patrick. I've written a few SPA's, and all I did was change the
page title and drop focus on the H1 heading. That's what I was
planning to advise these guys to do, but I just wasn't sure where (or
even whether) to fail this one. I'll probably fail it under 3.2.2, and
probably also 2.4.3.

Best, Lynn

On 10/02/2015, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = > wrote:
> On 10/02/2015 12:40, Lynn Holdsworth wrote:
>> Hi Patrick,
>>
>>> This sounds more like the focus is actually lost, rather than being
>>> programmatically set to the newly shown content.
>>
>> But is it? If we're mimicking a new page load, which is surely what
>> SPA's are doing, shouldn't the focus behave in the same way as it
>> would if we'd reached a new page?
>
> When a completely new page loads, browsers notify screenreaders (that a
> page load is in progress, when it's finished, etc) and then the browser
> itself explicitly resets the focus. In your case, the focus isn't
> reset...it just sits in limbo (after what was originally focused was
> hidden/removed from the page's DOM/accessibility tree). So it *does*
> need to be explicitly moved - to the start of the document, if that's
> the most sensible place for it, but still programmatically.
>
>> I wish I knew what event causes screenreaders to read new pages and
>> not significant amounts of new content. Then perhaps we could fire off
>> that event.
>
> There is no relevant event that can be fired, I'm afraid. But the above
> will do the job.
>
> 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: Patrick H. Lauke
Date: Tue, Feb 10 2015 6:17AM
Subject: Re: Where do single page applications fail WCAG2?
← Previous message | Next message →

On 10/02/2015 12:44, Bim Egan wrote:
> You're right Patrick,
> It does sound as though focus has been lost. It's a common problem in
> single page applications, along with the fact that there's no change in
> page title unless JavaScript has been used to update it.
>
> But I see Lynn's problem, loss of focus or context comes under WCAG2 SC
> 3.2.2 On Input, which says that it covers a change of setting for a form
> control, but does not cover the activation of a link or button. [1]
>
> Single page applications can be made accessible, but can they be deemed to
> fail WCAG2 at Level AA or even Level A? They should, as the loss of focus
> and page title problems are extremely disorientating for blind people. But
> if the overall page has a title and the focus is lost on activating a
> button, what does it fail on?

Indeed, this is one of the situations where WCAG 2 - for all its good
intentions - has a serious gap, requiring sometimes creative
reinterpretation of what an SC covers beyond the letter of the spec. I'd
roughly justify failing something like the above for 2.4.3 Focus Order
by making the argument that if focus is lost due to programmatic
changes, that breaks the navigation sequence/order completely and then
relies on the user agents to error-correct by resetting focus back to
the start of the document on the next interaction. It could also be
argued that it breaks 1.3.2 Meaningful Sequence, for the same reason.

But I admit that this could be argued to be my own private interpretation.

Maybe what we need, more than anything, are a few updated failure
examples (and some additional prose in the "Understanding..."
documentation) for 2.4.3/1.3.2 that cover this sort of scenario?

Failing that, the above can pass WCAG 2 but still be inaccessible in
real terms...which yes, can be a problem if a site owner/developer is
merely interested in a pass/fail box-ticking exercise. Happens less with
WCAG 2 than with WCAG 1, but still...

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: Birkir R. Gunnarsson
Date: Tue, Feb 10 2015 6:40AM
Subject: Re: Where do single page applications fail WCAG2?
← Previous message | Next message →

If an entirely new page loads, you could fail it based on 2.4.2, page
title, a bit of a stretch honestly, but fair I would say.
You could use role="alert" or an aria-live region" on an identifying
part of the new content, such as its heading, to notify user that new
content was loaded .. this works if AJAX creates the new content and
injects it into the page, does not work if the whole page is reloaded.
My question is .. it sounds like the new content is added to the page,
because the focus still remains on the "log in" button, meaning that
said button is still on the page ..
Does the refresh happen so that the new content is loaded, in content
order, before the button (at top of page) or after it?
Cheers


On 2/10/15, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = > wrote:
> On 10/02/2015 12:44, Bim Egan wrote:
>> You're right Patrick,
>> It does sound as though focus has been lost. It's a common problem in
>> single page applications, along with the fact that there's no change in
>> page title unless JavaScript has been used to update it.
>>
>> But I see Lynn's problem, loss of focus or context comes under WCAG2 SC
>> 3.2.2 On Input, which says that it covers a change of setting for a form
>> control, but does not cover the activation of a link or button. [1]
>>
>> Single page applications can be made accessible, but can they be deemed
>> to
>> fail WCAG2 at Level AA or even Level A? They should, as the loss of
>> focus
>> and page title problems are extremely disorientating for blind people.
>> But
>> if the overall page has a title and the focus is lost on activating a
>> button, what does it fail on?
>
> Indeed, this is one of the situations where WCAG 2 - for all its good
> intentions - has a serious gap, requiring sometimes creative
> reinterpretation of what an SC covers beyond the letter of the spec. I'd
> roughly justify failing something like the above for 2.4.3 Focus Order
> by making the argument that if focus is lost due to programmatic
> changes, that breaks the navigation sequence/order completely and then
> relies on the user agents to error-correct by resetting focus back to
> the start of the document on the next interaction. It could also be
> argued that it breaks 1.3.2 Meaningful Sequence, for the same reason.
>
> But I admit that this could be argued to be my own private interpretation.
>
> Maybe what we need, more than anything, are a few updated failure
> examples (and some additional prose in the "Understanding..."
> documentation) for 2.4.3/1.3.2 that cover this sort of scenario?
>
> Failing that, the above can pass WCAG 2 but still be inaccessible in
> real terms...which yes, can be a problem if a site owner/developer is
> merely interested in a pass/fail box-ticking exercise. Happens less with
> WCAG 2 than with WCAG 1, but still...
>
> 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
> > > >


--
Work hard. Have fun. Make history.

From: _mallory
Date: Tue, Feb 10 2015 7:09AM
Subject: Re: Where do single page applications fail WCAG2?
← Previous message | Next message →

On Tue, Feb 10, 2015 at 01:17:04PM +0000, Patrick H. Lauke wrote:
> Indeed, this is one of the situations where WCAG 2 - for all its
> good intentions - has a serious gap, requiring sometimes creative
> reinterpretation of what an SC covers beyond the letter of the spec.
> I'd roughly justify failing something like the above for 2.4.3 Focus
> Order by making the argument that if focus is lost due to
> programmatic changes, that breaks the navigation sequence/order
> completely and then relies on the user agents to error-correct by
> resetting focus back to the start of the document on the next
> interaction. It could also be argued that it breaks 1.3.2 Meaningful
> Sequence, for the same reason.

Or, it's a bit the opposite of "don't pull the context out from under
users when they don't expect it". In this case, they expect a change of
context when there appears (to the user) not to be.
_mallory

From: Shawn Henry
Date: Tue, Feb 10 2015 7:12AM
Subject: Re: Where do single page applications fail WCAG2?
← Previous message | Next message →

Patrick H. Lauke wrote: Maybe what we need, more than anything, are a few updated failure examples (and some additional prose in the "Understanding..." documentation) for 2.4.3/1.3.2 that cover this sort of scenario?

Suggestions always welcome! See Instructions for Commenting on WCAG 2.0 Documents at <http://www.w3.org/WAI/WCAG20/comments/>;

~Shawn
<http://www.w3.org/People/Shawn/>;


Full thread:

On 2/10/2015 7:17 AM, Patrick H. Lauke wrote:
> On 10/02/2015 12:44, Bim Egan wrote:
>> You're right Patrick,
>> It does sound as though focus has been lost. It's a common problem in
>> single page applications, along with the fact that there's no change in
>> page title unless JavaScript has been used to update it.
>>
>> But I see Lynn's problem, loss of focus or context comes under WCAG2 SC
>> 3.2.2 On Input, which says that it covers a change of setting for a form
>> control, but does not cover the activation of a link or button. [1]
>>
>> Single page applications can be made accessible, but can they be deemed to
>> fail WCAG2 at Level AA or even Level A? They should, as the loss of focus
>> and page title problems are extremely disorientating for blind people. But
>> if the overall page has a title and the focus is lost on activating a
>> button, what does it fail on?
>
> Indeed, this is one of the situations where WCAG 2 - for all its good intentions - has a serious gap, requiring sometimes creative reinterpretation of what an SC covers beyond the letter of the spec. I'd roughly justify failing something like the above for 2.4.3 Focus Order by making the argument that if focus is lost due to programmatic changes, that breaks the navigation sequence/order completely and then relies on the user agents to error-correct by resetting focus back to the start of the document on the next interaction. It could also be argued that it breaks 1.3.2 Meaningful Sequence, for the same reason.
>
> But I admit that this could be argued to be my own private interpretation.
>
> Maybe what we need, more than anything, are a few updated failure examples (and some additional prose in the "Understanding..." documentation) for 2.4.3/1.3.2 that cover this sort of scenario?
>
> Failing that, the above can pass WCAG 2 but still be inaccessible in real terms...which yes, can be a problem if a site owner/developer is merely interested in a pass/fail box-ticking exercise. Happens less with WCAG 2 than with WCAG 1, but still...
>
> P

From: Jonathan Avila
Date: Tue, Feb 10 2015 10:58AM
Subject: Re: Where do single page applications fail WCAG2?
← Previous message | Next message →

> I wish I knew what event causes screenreaders to read new pages and not significant amounts of new content. Then perhaps we could fire off that event.

Normally screen readers look for the document's loaded event and probably check the document readyState property.

Jonathan

--
Jonathan Avila
Chief Accessibility Officer
SSB BART Group
= EMAIL ADDRESS REMOVED =

703-637-8957 (o)
Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter

From: Lynn Holdsworth
Date: Tue, Feb 10 2015 12:36PM
Subject: Re: Where do single page applications fail WCAG2?
← Previous message | No next message

Thanks Jonathan - that's what I feared as these cant be changed programmatically.



On 10 Feb 2015, at 17:58, Jonathan Avila < = EMAIL ADDRESS REMOVED = > wrote:

>> I wish I knew what event causes screenreaders to read new pages and not significant amounts of new content. Then perhaps we could fire off that event.
>
> Normally screen readers look for the document's loaded event and probably check the document readyState property.
>
> Jonathan
>
> --
> Jonathan Avila
> Chief Accessibility Officer
> SSB BART Group
> = EMAIL ADDRESS REMOVED =
>
> 703-637-8957 (o)
> Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter
>
>