- From: James Nurthen <james.nurthen@oracle.com>
- Date: Fri, 6 May 2016 10:16:47 -0700
- To: w3c-wai-gl@w3.org
- Message-ID: <7f16420f-1c80-d428-6e26-a73bde3ba574@oracle.com>
On 5/6/2016 1:21 AM, Patrick H. Lauke wrote:
> [Copying this to the WAI-GL list, as I think this is far more general
> / not directly related to only the mobile TF or even cognitive TF]
>
> I think WCAG currently lacks an SC that essentially says something
> along the lines of "When content/structure/functionality is changed
> dynamically (either automatically or as a result of a user
> interaction), ensure that this change is conveyed to the user"
> (probably single or double A).
>
> While what prompted me originally was the scenario of
>
> - a user flips their mobile/tablet device from landscape to portrait,
> and the overall page layout/structure/functionality changes (e.g. new
> UI elements are added/shown, components such as carousels turn into
> accordions, the overall view in a calendar flips from "today's
> schedule" to "this month's overview" or similar)
The device generally announces that orientation has changed. I'm not
convinced that the page author should have to respond to this. (more
details later)
>
> I'm actually thinking about something more broad and generic - not
> necessarily related to responsive designs per se, but also covering
> situations like:
>
> - a user changes some filtering options/controls at the top of a
> results/catalogue page, and (without reloading the page altogether)
> the list of items further down the page is dynamically updated;
> generally, we'd advise people to add an aria live region (usually
> hidden) that simply states "results listing updated (showing 10 of
> 50)" or similar, so that an AT user can get notification that another
> part of the page has changed (without an actual change in context)
I either advise an aria-controls relationship or a live region as you
suggest depending on the scenario for this kind of thing. In my opinion
the controls relationship advises (and provides a method of moving to in
a supported configuration). At a push I can see this being covered under
1.3.1
>
> - some content on the page is auto-updated - so not as a result of a
> user action, but based on other factors (e.g. a timer, a push
> notification coming from the server, etc)
Here we have to be very careful to avoid specifying something which
would annoy a user. Some updates should indeed be read - but some would
be really annoying if read automatically. This issue was the whole point
of aria-live="off" (provide a default live region which isn't read out,
that a screen reader user could customise in order to get the
information read when they want it read).
An example I use when teaching this is to imagine a page with sports
scores on it for all the games going on.
If it has 10 soccer games on it I think having live regions announcing
the scores as they change is very reasonable. If the games are 10
basketball games I don't think you would want those live regions.
>
> But yes, this would also cover - in the specific context of what we
> discussed - device orientation change, and a resulting change of
> layout which also fundamentally changes functionality/layout/structure.
I think this is the new normal as we push for responsive sites. You
change the orientation and the layout changes. So long as the device
communicates that the orientation has changed the user then needs to
explore the page in the new orientation using the normal methods.
Perhaps we could look at AT to communicate to the user that a media
query breakpoint changed and things may have moved around? I think this
would be much better solved at the AT/browser level than at the page level.
>
> 4.1.2 currently covers notifications/changes of state on a control
> itself (so that users get notified if, for instance, the interface
> component that the user is currently on changes in
> functionality/value/meaning), but WCAG doesn't - to my knowlede anyway
> - contain an SC about notifying users of changes elsewhere in the
> page...and this, particularly for dynamic sites, is arguably needed.
I agree that 4.1.2 doesn't cover this and nor should it IMO.
>
> The timing aspect of auto-updating content is covered/touched on in
> 2.2.2, but I don't believe it actually covers the *notification* of
> the auto-update itself, only having the ability to pause/stop/hide
> these auto-updates.
I agree 2.2.2 doesn't seem to cover this.
>
> But there is, I think, a gap here - no SC that specifically calls for
> users to be notified of fundamental/substantive changes to the current
> page.
I agree that there is a gap but we need to be really careful to avoid
people making pages too verbose. I would not want to see a SC which says
that all changes need to be announced. We would end up with people
putting a live region on a data table with paging controls which IMO is
useless.
>
> Sufficient technique wise, we'd probably be looking at (for
> HTML/JS/ARIA technologies) things like:
>
> - move the focus programmatically to the changed content - but be
> careful of not falling foul of 3.2.2 / change of context (and
> particularly if the user is likely to be in the middle of some other
> activity, such as working their way through filtering/refining search
> results, it would be inappropriate to yank their focus to the updated
> results, as they may not even have been done with their filtering)
>
> - notify the user with a hidden aria-live region (as described above),
> which would allow for a change notification without change of context
> / yanking the user away from their current activity/focus
To me the most serious thing which is missing is something you haven't
mentioned. In single page web applications, unless coded carefully,
nothing appears to happen frequently when doing something (pushing a
button, navigating to a new page etc.) Sometimes, simply shifting focus
to the new content, fixes this but sometimes a live region announcement
is needed. I frequently have trouble using WCAG to justify this but
obviously it is needed for an application to be accessible.
Regards,
James
>
> Thoughts?
>
> P
>
> On 06/05/2016 01:43, David MacDonald wrote:
>> I agree... it is a good point in a responsive world where sections get
>> dropped off ... do you have some proposed language?
>>
>> I'm wondering what type of mechanism we might propose to notify a user
>> of what is gone from a page and how to get it back...
>>
>> The Cognitive team have looked at simplifying interfaces dropping off
>> content that is not central to the point of the page, that might be
>> pertinent to this success criteria
>>
>> They proposed an attribute "@aria-importance": {"high"}
>> This might be an area we would want to stay in close contact with them
>> about...
>>
>> Cheers,
>> David MacDonald
>>
>> *Can**Adapt**Solutions Inc.*
>>
>> Tel: 613.235.4902
>>
>> LinkedIn
>> <http://www.linkedin.com/in/davidmacdonald100>
>>
>> twitter.com/davidmacd <http://twitter.com/davidmacd>
>>
>> GitHub <https://github.com/DavidMacDonald>
>>
>> www.Can-Adapt.com <http://www.can-adapt.com/>
>>
>> / Adapting the web to *all* users/
>>
>> / Including those with disabilities/
>>
>> If you are not the intended recipient, please review our privacy policy
>> <http://www.davidmacd.com/disclaimer.html>
>>
>> On Thu, May 5, 2016 at 7:42 PM, Patrick H. Lauke <redux@splintered.co.uk
>> <mailto:redux@splintered.co.uk>> wrote:
>>
>> On 05/05/2016 17:50, David MacDonald wrote:
>>
>> Added to WIKI
>>
>> https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Proposed_revision_of_3.4.1
>>
>>
>> I was going to comment on the line about "Changes in orientation
>> must be programmatically exposed", but I see that in the latest edit
>> on the wiki that has been removed. Just to say I approve of this,
>> partially because it's usually the domain of the OS/AT to announce
>> an orientation change.
>>
>> I *can* see that in certain situations it would be useful to
>> announce to the user if something changed in the current page/view
>> as a result of an orientation change (e.g. a completely different
>> layout is introduced with more/less navigation options,
>> functionalities, etc), but this is probably something that falls
>> under the need to have a more generic "if parts of the page change,
>> this change should be announced to the user" SC (which, at least for
>> interface components, is probably covered by 4.1.2, but not for
>> non-user-interface cases.
>>
>> For this latter part, is it worth proposing/thinking about another
>> SC (which is, once again, not really "mobile" specific)?
>>
>>
>> P
>> --
>> Patrick H. Lauke
>>
>> www.splintered.co.uk <http://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
>>
>>
>>
>
>
--
Regards, James
Oracle <http://www.oracle.com>
James Nurthen | Principal Engineer, Accessibility
Phone: +1 650 506 6781 <tel:+1%20650%20506%206781> | Mobile: +1 415 987
1918 <tel:+1%20415%20987%201918> | Video: james.nurthen@oracle.com
<sip:james.nurthen@oracle.com>
Oracle Corporate Architecture
500 Oracle Parkway | Redwood Cty, CA 94065
Green Oracle <http://www.oracle.com/commitment> Oracle is committed to
developing practices and products that help protect the environment
Received on Friday, 6 May 2016 17:19:44 UTC