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

Re: suggestion for ARIA 2.0

From: Ian Pouncey <w3c@ipouncey.co.uk>
Date: Fri, 5 Feb 2016 13:39:18 +0000
Message-ID: <CAKaroWxRoF0zfQ4OcvWdUJHoR7oUs6J7Hibt4+tEVK9wAY1ioQ@mail.gmail.com>
To: "lisa.seeman" <lisa.seeman@zoho.com>, public-aria@w3.org
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.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 13:47:06 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:58:20 UTC