W3C home > Mailing lists > Public > public-aria@w3.org > February 2016

Re: suggestion for ARIA 2.0

From: Michiel Bijl <michiel@agosto.nl>
Date: Fri, 5 Feb 2016 08:03:16 +0100
Cc: public-aria@w3.org
Message-Id: <1630A184-3988-49C4-AA33-A6197A7B5B34@agosto.nl>
To: "lisa.seeman" <lisa.seeman@zoho.com>
Are suggesting the WG write plug-ins for all the different design patterns?


> On 05 Feb 2016, at 04:50, lisa.seeman <lisa.seeman@zoho.com <mailto:lisa.seeman@zoho.com>> wrote:
> Hi Folks
> I have a suggestion for ARIA 2.0
> It will solve the dichotomy between flexibility (such as in aria 1.0 and 1.1 has) and easy of use.
> There was a suggestions that 2.0 should be based on patterns. But that would lock in the UI to what is happening today. It would make it harder to use ARIA when new interface components are developed (like the touch screen with hamburger menu) and these would remain inaccessible until we develop and publish new syntax.
> My suggestion is to introduce mappings. (A bit like what we are working of for personlization). The author would to specify a conforment JSON (or xml/ rdf etc) file that defines initial states and properties and the behaviors on events. The author would only have to set the roles and relationships that are not implied by the DOM - And remember to include the right behaviors files.
> This would make developing via ARIA  BY FAR the most flexible and extendable and easy (for the final author)way to go.
> for example
> 1. Main HTML (much less complex - no tabindex or states)
> <body>
> <ul  role="tablist <>">     <li  role="tab <>" >Prices</li>
>     <li role="tab <>" >Features </li>     </ul>   <div id="panel1 <>"  role="aria-tabpanel <>" >
>   <h3 >Prices</h3> </div>
> <div id="panel2 <>".....
> </body> 
> 2. We can allow users to include the pattern in the head.
> (in this example we import a script that does the work BUT we could also standardize this and use a simple include in html for the JSON)
> <head>
> <script>
> $(document).ready(function(){
> $.getScript("http://w3.org/tr/importingroles.js <http://w3.org/tr/importingroles.js>");
> loadpatterns("http://w3.org/tr/sampleariapatterns.json <http://w3.org/tr/sampleariapatterns.json>", JSON); 
> //loadpatterns will be a function in importingroles that parses the specified json or other accepted formatted file
> }); 
> </script>
> </head>
>  3.This is  some phudocode for the pattern (the libary owner would write this) could look (in part) something like
> (BTW if json does not support this we can stick with xml)
> "role-aria-tab":first: {
> "@aria-controls ": "aria-tabpanel":first.
> "@tabindex": "0",
> "@aria-hidden": "false",
> "css": "visibility:visible;size:2em; border: 5px solid",
> "onclick": "<script>$("li[role='tab']").attr("aria-selected","false"); //deselect all the tabs 
>  	$(this).attr("aria-selected","true");  // select this tab
> 	var tabpanid= $(this).attr("aria-controls"); //find out what tab panel this tab controls  
>    var tabpan = $("#"+tabpanid);  
> 	$("div[role='tabpanel']").attr("aria-hidden","true"); //hide all the panels 
>  tabpan.attr("aria-hidden","false"); // show our panel",</script>",
> ..
>       } 
> 4. An imported script that Glues it all together could be like the by Ayelet at https://github.com/ayelet-seeman/coga.personalisation/blob/Script-Options/personalisation.1.0.js <https://github.com/ayelet-seeman/coga.personalisation/blob/Script-Options/personalisation.1.0.js>
> OR if it is fully standardized, implementing the mapping can be left to the browser 
> All the best
> Lisa Seeman
> Athena ICT Accessibility Projects  <http://accessibility.athena-ict.com/>
> LinkedIn <http://il.linkedin.com/in/lisaseeman/>, Twitter <https://twitter.com/SeemanLisa>

Received on Friday, 5 February 2016 07:03:45 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:23:19 UTC