Re: Re: suggestion for ARIA 2.0

Hi Ian

The idea would be to make the linking to a ARIA pattern library simple and standardized. It should be supported by the browser but even before then, we can load the behaviors via a script and have support for the use.


The point is to enable the advantage of a pattern based solution without loss of flexibility that ARIA now has. It solves the issue of bad implementations, and the need for rigorous debugging that ARIA now has, but does not lock us in to pretending that we know what developers will do next.

BTW Another useful direction could be to add context, such as the coga extension is suggesting. 

All the best

Lisa Seeman

Athena ICT Accessibility Projects 
LinkedIn, Twitter





---- On Fri, 05 Feb 2016 15:39:18 +0200 Ian Pouncey <w3c@ipouncey.co.uk> wrote ---- 

Other than a mapping syntax for ARIA, which has been (informally, not formally as far as I know) suggested before using CSS without much support for the idea, this doesn’t add anything new. There is nothing special about ARIA attributes, as demonstrated by the pseudocode which uses the same approach to add styles and event handlers. Adding attributes and events is not what's difficult, we can already do that quite easily with JavaScript, so the only benefits would be encapsulation and reusability.

 

It looks like a job for web components to me.


I don't see how any approach to ARIA 2.0 would make new UI patterns inherently inaccessible, or how defining a new standard for adding attributes and event handlers to the DOM would fix the problem even if that were the case. Could you expand on this please?


Ian.



On 5 February 2016 at 03:50, 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.jsOR if it is fully standardized, implementing the mapping can be left to the browser All the best

Lisa Seeman

Athena ICT Accessibility Projects
LinkedIn, Twitter

Received on Sunday, 7 February 2016 11:44:58 UTC