RE: HTML5 default implicit semantics

> I think the point was well made at the plenary session at TPAC that there are two aspects of Web technology: (1) tools such as APIs, Web Components, etc.,
> that allow application authors to create their own customized features, e.g., new widgets; and (2) pre-built features for authors to use in their applications
> and documents, for example HTML elements.
> The Web needs both, and we need to be able to make both accessible.

I agree with both 1 and 2, however I have doubts about 2.

It's true that we need fully customizable and provably accessible web components that people can simply plug into their projects and use however they wish.

This isn't a new concept however, and even when it is done, when provably accessible widgets are made, providing full control over visual styling, functionality, implementation, content in any language, and are freely given without any obligation of any kind, people still refuse to use them. I have seen this happen every day for years.

Here is a recent discussion this last week on WebAim that discusses the same topic, again, as we have had over and over again over the years, regarding the availability of accessible date pickers:
http://webaim.org/discussion/mail_thread?thread=7206


The thing is, I actually built the date picker I referenced in November 2011, 4 years ago; I presented this at UC Berkley in May 2012, and it has been keyboard and screen reader accessible since that time. I've lost track of the number of times that I've described how it works, where the roles are and how focus movement matches them, and what the nesting of the Application based roles do and how this improves accessibility and for which combinations of browsers and ATs. It never seems to matter though.

I think I understand what the problem is, it's competitive bias. If company A builds something, companies B and C won't use or endorse it. If company B builds something, companies A and C won't use or endorse it, and so on. The weird thing is how this seems to include open source software too.

My point is, we have the skills right now to build accessible software that works for millions of people, but competitive bias will always trump this, because Accessibility is a business.

I understand that this topic goes beyond what I am talking about, such as the future planning for ARIA 2.0 and the creation of integrated web components that tie into the platform APIs to maximize accessibility, and so on. This is great, and will someday blow the socks off of anything that we have the power to build accessibly right now.

There is one huge problem with this at the moment however, it doesn't exist yet. Not in any usable sense of the word so that developers can implement these successfully across billions of web pages accessibly right now.

I'm not saying that one way of doing something is the only way of doing it, but we do have an urgent need for an accessible widget archive that includes scalable, provably accessible widgets, that developers can actually utilize within their projects instead of having to reinvent the same wheels over and over again for everything.

Here are just two examples of why this is important, resulting from recent legislation:
http://www.deque.com/air-carrier-access-act-update/

and
http://www.technologydecisions.com.au/content/gov-tech-review/article/making-government-accessibility-accessible-618058756


These are just two, but there are more across all industries and sectors in recent years where the accessibility of specific ICT is a legal mandate with contractual and current deadlines to achieve.

So one of the projects we are working on is the APG 1.1 update, which is aimed at training developers to better understand how to implement dynamic interactive web components accessibly. This is also supposed to include vanilla JavaScript examples to demonstrate these. The problem here too, is that this approach requires all developers, not just those who want to, to have to reinvent all of the same wheels themselves. There are many developers who have the time and desire to do this, but to be blunt, there are also many others numbering in the millions who will have no time to do so, or who have no knowledge or ability to understand how accessibility works within ATs, or who aren't aware that these technologies exist, or who simply don't care enough to bother with doing this. I've seen examples of all of these repeatedly over the years.

So what would be incredibly helpful in the meantime, while work is being done on the totally awesome web components that don't work yet, is to also provide fully customizable, fully scalable, and provably accessible widgets that developers can actually utilize right now if they so desire to within their web technologies; thus meeting the need for legal mandates and unavoidable business deadlines that are requirements right now.

Moreover, it would be even more powerful to do so in such a way that all of these fully scalable accessible widgets would automatically be compatible with the most widely used JavaScript libraries and frameworks in use today, thus making it possible to maximize the target audience for these web components where this need can be met in the most simple and effective manner possible for anyone wishing to do so.

This would then achieve two critical requirements for the present time, (1) to provide comprehensive and accurate training materials to explain how to create accessible widget constructs manually using the APG, and (2) to provide fully scalable and provably accessible widget constructs that can be directly implemented as needed if such developers lack the time, knowledge, or desire to do all of this work themselves from scratch.

I'm not speaking hypothetically either, I've already built a framework that does this, which automatically normalizes provably accessible scalable widget constructs equally across jQuery, Dojo, and MooTools.
E.G
jQuery: https://github.com/accdc/tsg

Dojo: https://github.com/accdc/tsg-dojo

MooTools: https://github.com/accdc/tsg-mootools


All three of these archives use the same accessible widget  modules, they simply normalize the module functionality by automatically tying into each of these libraries and frameworks to prevent code bloat and to maximize the target audience potential for each user base.

To put this into perspective, the present day usage statistics for these libraries and frameworks is available at:
http://w3techs.com/technologies/overview/javascript_library/all

Which monitors the top ten million domains in the world as a subset of the 876 million websites that currently exist around the world.

At 66.9%, jQuery usage accounts for approximately 6,690,000 domains.

At 3.8%, MooTools accounts for approximately 3,800,000 domains.

At 0.1%, Dojo accounts for approximately 100,000 domains.

This means that, out of the top ten million domains in the world, the potential target audience for the AccDC widget framework is approximately 70.8%, or 7,080,000 domains, where provably accessible widget constructs such as these can be implemented today.

Moreover, such a framework also has the capacity to be expanded, which I've already done twice with MooTools and Dojo. For example I could do the same for Prototype, thus adding another 2.2% to this equation, increasing the potential target audience by another 2,200,000 domains for the same provably accessible widget constructs.

As noted, this only refers to the top ten million domains, as opposed to the 876 million websites that actually exist around the world. Reference: 
http://news.netcraft.com/archives/2015/01/15/january-2015-web-server-survey.html


My point is that this capability already exists right now, and actually has existed for several years without anybody seeing the value in it.

If we were to work together on this, instead of compartmentalizing Accessibility as we have been doing for years, we could easily make this available to hundreds of millions of present day developers around the world in a matter of months, where we could build on what I've already built, re-style and prettify what needs  doing, add widgets where they are missing for ARIA 1.1, and turn this into a truly world changing collection of accessible widgets that can bridge the gap of present day web technologies until we have better available technologies in the years to come.

This combined with the APG for those who truly wish to learn, I think will make a huge difference.

As I did last year, I again offer these projects to the W3C for this purpose if anybody is interested in helping me achieve this.

Sincerely,
Bryan Garaventa


-----Original Message-----
From: Cynthia Shelly [mailto:cyns@microsoft.com] 
Sent: Friday, November 06, 2015 1:55 PM
To: White, Jason J <jjwhite@ets.org>; John Foliot <john.foliot@deque.com>
Cc: lwatson@paciellogroup.com; Steve Lee <steve@opendirective.com>; public-cognitive-a11y-tf <public-cognitive-a11y-tf@w3.org>; W3C WAI Protocols & Formats <public-pfwg@w3.org>
Subject: RE: HTML5 default implicit semantics

+1 to both Jason and Leonie

-----Original Message-----
From: White, Jason J [mailto:jjwhite@ets.org] 
Sent: Friday, November 6, 2015 1:23 PM
To: John Foliot <john.foliot@deque.com>
Cc: lwatson@paciellogroup.com; Steve Lee <steve@opendirective.com>; public-cognitive-a11y-tf <public-cognitive-a11y-tf@w3.org>; W3C WAI Protocols & Formats <public-pfwg@w3.org>
Subject: Re: HTML5 default implicit semantics


> On Nov 6, 2015, at 13:31, John Foliot <john.foliot@deque.com> wrote:
>
> Léonie Watson [mailto:lwatson@paciellogroup.com] wrote:
>>
>> When ARIA first came into existence we thought it was temporary. 
>> We've come a long way since then and ARIA is clearly here to stay. 
>> Perhaps this means we're at a good point to reevaluate the overall strategy and roadmap for ARIA?
>
> +1 to that.

I think the point was well made at the plenary session at TPAC that there are two aspects of Web technology: (1) tools such as APIs, Web Components, etc., that allow application authors to create their own customized features, e.g., new widgets; and (2) pre-built features for authors to use in their applications and documents, for example HTML elements.

The Web needs both, and we need to be able to make both accessible.


________________________________

This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited.


Thank you for your compliance.

________________________________

Received on Sunday, 8 November 2015 22:57:20 UTC