W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > July to September 2012

Re: activating behaviours

From: Joshue O Connor <joshue.oconnor@ncbi.ie>
Date: Thu, 12 Jul 2012 12:20:54 +0100
Message-ID: <4FFEB316.3030702@ncbi.ie>
To: w3b@chaals.com
CC: "w3c-wai-ig.w3.org" <w3c-wai-ig@w3.org>, Steven Faulkner <faulkner.steve@gmail.com>
Great thread.

This is a really complex issue that is exacerbated by the sheer 
multitude of devices and user needs.

There have been some really good take aways for me from this discussion.

1) Determining a single way of activating a behaviour that is not native 
to a control is potentially bad in terms of its impact on the user 
experience. Also adding activation behaviours to input controls that 
perform other functions in some browsing environments is also 
potentially problematic.

2) This may sometimes however need to be done due to the nature of 
custom controls and widgets that (for whatever reason) need to have 
activation behaviours added. Usually because of lack of support for a 
native control (HTML5 anyone?)  being one of them - or in order to 
support some advanced customisation or widget behaviour.

3) The ghettoization of ARIA solely into A11y APIs is severely limiting 
the scope of the language and its potential benefit to other user groups 
who are not AT users. FWIW, we struggle with this last issue in the WCAG 
HTML5/ARIA techniques TF -  as we are trying to come up with ARIA use 
cases for non AT users. At the moment they really are limited to 
'helping to make stuff more keyboard accessible' but have advanced 
little beyond adding a tabindex (which has nothing to do with ARIA anyway).

What was very interesting to me was some degree of polarization between 
Chaals' and Steves' views. FWIW, it seems that someone closer to the 
browser side and au fait with browser implementation (Chaals) may have a 
very different perspective on what needs to be done to develop platform 
agnostic/independent UIs when compared with what someone closer to the 
dev/author side - with expertise in developing accessible RIAs (Steve) - 
may say about creating accessible content. And then also we have Ramón 
saying "But what should I do now!"

I think Ramon represents the majority of devs who need to know how to 
practically steer a course between the two perspectives. For example, 
how can you successfully anticipate interaction models for every 
possible device? You can't really, I guess only to about 60% level of 
confidence +/- a standard deviation of a browser or two..

IMO, the current practical options are to in _some_ cases to define them 
as loosely as possible letting the browser do the work (as Chaals seems 
to be saying) but for me these cases do get rather fuzzy unless we do 
advanced content negotiation or feature detection to serve content with 
stronger activation behaviours where needed. I would tend toward 
defining activation behaviours in a tighter way (with some explicit 
keybindings) until I found out something was broken then I would work a 
way to do content negotiation for that platform and serve it something 
their users can work with.

Anyway, my 2 cents and great to see such an informed and considered 
discussion :-)

Josh




Follow us on Facebook: https://www.facebook.com/ncbiworkingforpeoplewithsightloss
Follow us on Twitter: www.twitter.com/ncbi_sightloss

Check-out NCBI's Mícheál Ó Muircheartaigh appeal on the following link. 
http://youtu.be/25P2tiuCi0U

********************************************************************
National Council for the Blind of Ireland (NCBI) is a company 
limited by guarantee (registered in Ireland No. 26293) .
Our registered office is at Whitworth Road, Drumcondra, Dublin 9.
NCBI is also a registered Charity (chy4626). 

NOTICE: The information contained in this email and any attachments 
is confidential and may be privileged.  If you are not the intended 
recipient you should not use, disclose, distribute or copy any of 
the content of it or of any attachment; you are requested to notify 
the sender immediately of your receipt of the email and then to 
delete it and any attachments from your system.

NCBI endeavours to ensure that emails and any attachments generated 
by its staff are free from viruses or other contaminants.  However, 
it cannot accept any responsibility for any such which are 
transmitted.  We therefore recommend you scan all attachments.

Please note that the statements and views expressed in this email 
and any attachments are those of the author and do not necessarily 
represent the views of NCBI


********************************************************************
Received on Thursday, 12 July 2012 11:21:48 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:13:30 UTC