Re: suggestion for ARIA 2.0

Hi Lisa,

We are trying to lock down ARIA 1.1 so we are not quite looking at ARIA 2.0 right now, but I want to capture your thoughts. I created a WIKI for potential approaches to ARIA 2.0:

https://www.w3.org/WAI/ARIA/wiki/ARIA_2.0_Potential_Directions <https://www.w3.org/WAI/ARIA/wiki/ARIA_2.0_Potential_Directions>

Please capture your thoughts around patterns (which are like we discussed in COGA) there for now. JSON would be a better route than XML in the browser crowd. 

We also need to pull in Dominic Mazzoni’s issues from the old PF wiki and determine what is relevant. Whatever we do we need to synch up with Cynthia’s effort in WICG. 

Rich


> On Feb 4, 2016, at 9:50 PM, lisa.seeman <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");
> loadpatterns("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
> 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 15:09:53 UTC