- From: Joshue O Connor <joshue.oconnor@ncbi.ie>
- Date: Thu, 12 Jul 2012 12:20:54 +0100
- 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