E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 14 (In chronological order)

From: Bryan Garaventa
Date: Thu, Apr 19 2012 9:31PM
Subject: Do people actually want Automatic Accessibility within Web Technologies?
No previous message | Next message →

I'm curious about this.

When I say Automatic Accessibility, I'm referring to a combination of Universal Design (equally accessible for all) and Inclusive Design (integrated accessibility within mainstream applications). I adopted the term Automatic Accessibility because it's more descriptive and easier for people to understand who aren't already familiar with the terms Universal and Inclusive design.

So when I refer to Automatic Accessibility for web technologies, I'm talking about the incorporation of automatically accessible processes at the bedrock level of enterprise development. This way, new technologies can be built that include accessible features automatically, and everyone wins.

Is there something wrong with this idea?

From: Léonie Watson
Date: Fri, Apr 20 2012 12:57AM
Subject: Re: Do people actually want Automatic Accessibility within WebTechnologies?
← Previous message | Next message →

Bryan Garaventa wrote:
"When I say Automatic Accessibility, I'm referring to a combination of
Universal Design (equally accessible for all) and Inclusive Design
(integrated accessibility within mainstream applications)."

I have reservations about the possibility of universal design.
Without wanting to derail this conversation too far though, the answer for
me is yes. I'd certainly like to see more products/tools/whatever designed
to be accessible from the outset. The catch is accessible to whom?


Léonie.

From: Paul J. Adam
Date: Fri, Apr 20 2012 8:39AM
Subject: Re: Do people actually want Automatic Accessibility within Web Technologies?
← Previous message | Next message →

Everyone want's automatic accessibility, end users and developers. HTML & HTML5 with JavaScript & CSS are the only web technologies that provide universal design and have the ability to automatically be accessible as long as they are coded with W3C standards. Of course they are often not coded correctly so the accessibility is not quite automatic but HTML, JS, & CSS fit the definition of universal design since they work on all devices from feature phones to ebook readers to smart phones and beyond.

It's web technologies that do not work accessibly on all platforms and devices which support accessibility that are preventing automatic accessibility. E.g. Flash, PDF, MS Office Docs being the biggest barriers to automatic accessibility.

I'm sure people will disagree with my suggestions to avoid non-HTML web technologies but until they work on all accessible desktop platforms like Windows, OS X, and Linux and also work on the accessible smartphone platforms like iOS and (with many limitations) Android I will continue to suggest avoiding them if you want to achieve universal design & accessibility.


Paul J. Adam
Accessibility Evangelist
Deque Systems
= EMAIL ADDRESS REMOVED =
www.PaulJAdam.com
@pauljadam on Twitter

On Apr 19, 2012, at 10:31 PM, Bryan Garaventa wrote:

> I'm curious about this.
>
> When I say Automatic Accessibility, I'm referring to a combination of Universal Design (equally accessible for all) and Inclusive Design (integrated accessibility within mainstream applications). I adopted the term Automatic Accessibility because it's more descriptive and easier for people to understand who aren't already familiar with the terms Universal and Inclusive design.
>
> So when I refer to Automatic Accessibility for web technologies, I'm talking about the incorporation of automatically accessible processes at the bedrock level of enterprise development. This way, new technologies can be built that include accessible features automatically, and everyone wins.
>
> Is there something wrong with this idea?
> > >

From: John Foliot
Date: Fri, Apr 20 2012 10:23AM
Subject: Re: Do people actually want Automatic Accessibility within WebTechnologies?
← Previous message | Next message →

Bryan Garaventa
>
> When I say Automatic Accessibility, I'm referring to a combination of
> Universal Design (equally accessible for all) and Inclusive Design
> (integrated accessibility within mainstream applications). I adopted the
> term Automatic Accessibility because it's more descriptive and easier
> for people to understand who aren't already familiar with the terms
> Universal and Inclusive design.
>
> So when I refer to Automatic Accessibility for web technologies, I'm
> talking about the incorporation of automatically accessible processes at
> the bedrock level of enterprise development. This way, new technologies
> can be built that include accessible features automatically, and
> everyone wins.
>
> Is there something wrong with this idea?

Hi Bryan,

I have a few issues to consider.

Introducing yet another new term:

As you have already noted, we have "Universal Design", and we have
"Inclusive Design", and within the web-world we also have "Progressive
Enhancement" and "Graceful Degradation", and, and, and... introducing yet
another new idea/term into the lexicon adds yet another term to
learn/use/know, and I can hear the inevitable question now: "what's the
difference between Universal Design and Automatic Accessibility?"

"Universal Design Isn't" (and neither is Automatic):

By which I mean that even the concept of Universal Design (and
Inclusive Design as well) suffers from what I consider the "Long Tail"
problem (http://en.wikipedia.org/wiki/Long_Tail) - that the universality of
Universal Design has itself some limitations, and at some point, to be
really inclusive, we need to also consider Accommodation strategies. It has
been my observation (and concern) that increasingly - and notably within the
web world - this basic fact is becoming lost in the rush to embrace
"Universal Design" (and the presumption of what you are calling Automatic
Accessibility). I see this a lot in my exchanges and work at the W3C with
HTML5, where a significant portion of a certain working group believe that
Universal Design principles will solve *all* accessibility issues (because,
you know, they tested it with VoiceOver...)

The bottom line is that to achieve the real end-goal (access for
<del>all</del> <ins>most of</ins> of our users) requires attention, thought,
and occasionally some extra effort; and while I whole-heartedly embrace the
concept of Universal Design and Inclusive Design, it is with the caveat that
those principles alone do not equal success. My fear is that if we
introduce a loaded term like "Automatic" it somehow suggests that the end
authors don't have to contribute to the heavy lifting, which I believe we
all know to be false.

Me, I will continue to use the term Universal Design, which is already a
common term in the Design world, and teach that while Universal Design as a
design principle is beneficial to all users in subtle and not-so-subtle
ways, I will also continue to teach at the same time that it gets us 80% or
better towards our ultimate goal, but that it has its limitations, and
should not be thought of as the panacea to absolve authors/creators from
thinking through what they are creating.

My $0.02, because you asked...

JF

From: Bryan Garaventa
Date: Fri, Apr 20 2012 10:26AM
Subject: Re: Do people actually want Automatic Accessibility withinWebTechnologies?
← Previous message | Next message →

That would mean both screen reader and keyboard only users, including voice
only activation (using keyboard nav commands), which is where the highest
percentage of accessibility issues reside, and these can be solved
programmatically.

Devs still need to do the rest like color contrast and sizing for low vision
and color blind users, which can be accomplished through CSS.

The reason why I ask, is that I've brought this concept up to approximately
6000 Accessibility Professionals around the world, and received positive
feedback from about 10, not counting WebAim.

That appears to be 0.17% in favor, and 99.83% against?

----- Original Message -----
From: "Léonie Watson" < = EMAIL ADDRESS REMOVED = >
To: "'WebAIM Discussion List'" < = EMAIL ADDRESS REMOVED = >
Sent: Thursday, April 19, 2012 11:57 PM
Subject: Re: [WebAIM] Do people actually want Automatic Accessibility
withinWebTechnologies?


Bryan Garaventa wrote:
"When I say Automatic Accessibility, I'm referring to a combination of
Universal Design (equally accessible for all) and Inclusive Design
(integrated accessibility within mainstream applications)."

I have reservations about the possibility of universal design.
Without wanting to derail this conversation too far though, the answer for
me is yes. I'd certainly like to see more products/tools/whatever designed
to be accessible from the outset. The catch is accessible to whom?


Léonie.

From: Bryan Garaventa
Date: Fri, Apr 20 2012 10:31AM
Subject: Re: Do people actually want Automatic Accessibility withinWeb Technologies?
← Previous message | Next message →

It is possible to make web technologies automatically accessible, that's why
I built AccDC, to provide a baseline for this functionality.
Life is full of adventures.


----- Original Message -----
From: "Paul J. Adam" < = EMAIL ADDRESS REMOVED = >
To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
Sent: Friday, April 20, 2012 7:39 AM
Subject: Re: [WebAIM] Do people actually want Automatic Accessibility
withinWeb Technologies?


> Everyone want's automatic accessibility, end users and developers. HTML &
> HTML5 with JavaScript & CSS are the only web technologies that provide
> universal design and have the ability to automatically be accessible as
> long as they are coded with W3C standards. Of course they are often not
> coded correctly so the accessibility is not quite automatic but HTML, JS,
> & CSS fit the definition of universal design since they work on all
> devices from feature phones to ebook readers to smart phones and beyond.
>
> It's web technologies that do not work accessibly on all platforms and
> devices which support accessibility that are preventing automatic
> accessibility. E.g. Flash, PDF, MS Office Docs being the biggest barriers
> to automatic accessibility.
>
> I'm sure people will disagree with my suggestions to avoid non-HTML web
> technologies but until they work on all accessible desktop platforms like
> Windows, OS X, and Linux and also work on the accessible smartphone
> platforms like iOS and (with many limitations) Android I will continue to
> suggest avoiding them if you want to achieve universal design &
> accessibility.
>
>
> Paul J. Adam
> Accessibility Evangelist
> Deque Systems
> = EMAIL ADDRESS REMOVED =
> www.PaulJAdam.com
> @pauljadam on Twitter
>
> On Apr 19, 2012, at 10:31 PM, Bryan Garaventa wrote:
>
>> I'm curious about this.
>>
>> When I say Automatic Accessibility, I'm referring to a combination of
>> Universal Design (equally accessible for all) and Inclusive Design
>> (integrated accessibility within mainstream applications). I adopted the
>> term Automatic Accessibility because it's more descriptive and easier for
>> people to understand who aren't already familiar with the terms Universal
>> and Inclusive design.
>>
>> So when I refer to Automatic Accessibility for web technologies, I'm
>> talking about the incorporation of automatically accessible processes at
>> the bedrock level of enterprise development. This way, new technologies
>> can be built that include accessible features automatically, and everyone
>> wins.
>>
>> Is there something wrong with this idea?
>> >> >> >
> > >

From: John Foliot
Date: Fri, Apr 20 2012 11:19AM
Subject: Re: Do people actually want Automatic Accessibility within Web Technologies?
← Previous message | Next message →

Paul J. Adam wrote:
> Everyone want's automatic accessibility, end users and developers.

...and as blues great Albert Collins wrote, "...everybody wants to go to
heaven, nobody wants to die."


> HTML
> & HTML5 with JavaScript & CSS are the only web technologies that provide
> universal design and have the ability to automatically be accessible as
> long as they are coded with W3C standards.

You see, this is exactly the type of problem I am talking about. I can take
HTML/HTML5 + JavaScript + CSS and create a fully conformant yet totally
inaccessible piece of garbage with little effort, and we've been able to do
so for years now. This is one of the reasons why WCAG dropped the
requirement for code validation, because we now know that validation alone
does not equal accessible.


> Of course they are often not
> coded correctly so the accessibility is not quite automatic but HTML,
> JS, & CSS fit the definition of universal design since they work on all
> devices from feature phones to ebook readers to smart phones and beyond.

It's not the devices, but rather the user-agent combinations
(browsers/software) and the content created for those combinations of
hardware and software tools that is key. Every piece of the chain is
critical, and to somehow suggest that using some magical tokens (HTML5,
JavaScript and CSS) will "automatically" give you Universal or Automatic
Access is simply false, and serves to further illustrate my overarching
concern.

When used correctly, Daisy and ePub (both non W3C technologies) can produce
accessible content for many if not most users, including sighted and
mobility impaired users. Content creators need to *THINK* about what they
are trying to achieve, rather than look at every problem as a nail, because
they have HTML/JS/CSS hammers...


> It's web technologies that do not work accessibly on all platforms and
> devices which support accessibility that are preventing automatic
> accessibility. E.g. Flash, PDF, MS Office Docs being the biggest
> barriers to automatic accessibility.

Yes, yes, big bad Adobe and Microsoft (who can't seem to get accessibility
right on the Mac platform - ever consider maybe it's not *their* fault?).

I want to remind everyone that any tool, when misused, can cause pain or
harm. Flash itself is not inaccessible, it is inaccessible content created
by under-educated developers that introduces inaccessibility. Yet, when it
comes to the "most accessible" option for providing videos on the web today,
it's not HTML5 that comes to the rescue, but rather Flash-based video
players, which can and do support closed captions, descriptive audio and
other accessibility accommodations. The current crop of HTML5 browsers that
are supporting the HTML5 <video> tag cannot even provide native support for
captions today, and descriptive audio is far down the line to come. (And
before anyone wants to chime in about lack of Flash support on iOS, go
complain to Apple, not to me, as it was Apple who chose not to support a
specific type of technology, thus impacting all of their users negatively.
So much for "Universality" huh?)

PDF itself isn't inaccessible, once again it is poorly created content that
is the root of problems. A well constructed PDF form (for example) can be
quite accessible to both sighted and non-sighted users, and due to some
formatting constructs that you can employ within PDF there may be instances
when using a PDF form is in fact the best choice for the task at hand.

What's the expression? "Guns don't kill people, People kill people..."


>
> I'm sure people will disagree with my suggestions to avoid non-HTML web
> technologies but until they work on all accessible desktop platforms
> like Windows, OS X, and Linux and also work on the accessible smartphone
> platforms like iOS and (with many limitations) Android I will continue
> to suggest avoiding them if you want to achieve universal design &
> accessibility.

I disagree with your simplistic assertions that using a specific set of
technologies will "automatically" get you to accessible - it simply won't.

JF

From: Bryan Garaventa
Date: Fri, Apr 20 2012 11:22AM
Subject: Re: Do people actually want Automatic Accessibility withinWebTechnologies?
← Previous message | Next message →

Thanks, I agree, I'm not recommending another term, this is simply one I use
myself when I'm trying to explain the concept to others. I've found that
most people who aren't familiar with programming or accessibility, have no
idea what universal and inclusive design is, and they find it confusing.

I agree that heavy lifting is often necessary for the development of truly
accessible applications, however it is possible to automate the
accessibility of baseline processes within a framework designed for that
purpose, so that new web technologies and current ones can tap into the same
functionality.

This provides a programmatic standard that can be used as a development
platform, a framework where encapsulated widgets can be created and
distributed as scalable automatically accessible user interface components,
and a learning aid for the education of new developers at the same time.


----- Original Message -----
From: "John Foliot" < = EMAIL ADDRESS REMOVED = >
To: "'WebAIM Discussion List'" < = EMAIL ADDRESS REMOVED = >
Sent: Friday, April 20, 2012 9:23 AM
Subject: Re: [WebAIM] Do people actually want Automatic Accessibility
withinWeb Technologies?


> Bryan Garaventa
>>
>> When I say Automatic Accessibility, I'm referring to a combination of
>> Universal Design (equally accessible for all) and Inclusive Design
>> (integrated accessibility within mainstream applications). I adopted the
>> term Automatic Accessibility because it's more descriptive and easier
>> for people to understand who aren't already familiar with the terms
>> Universal and Inclusive design.
>>
>> So when I refer to Automatic Accessibility for web technologies, I'm
>> talking about the incorporation of automatically accessible processes at
>> the bedrock level of enterprise development. This way, new technologies
>> can be built that include accessible features automatically, and
>> everyone wins.
>>
>> Is there something wrong with this idea?
>
> Hi Bryan,
>
> I have a few issues to consider.
>
> Introducing yet another new term:
>
> As you have already noted, we have "Universal Design", and we have
> "Inclusive Design", and within the web-world we also have "Progressive
> Enhancement" and "Graceful Degradation", and, and, and... introducing yet
> another new idea/term into the lexicon adds yet another term to
> learn/use/know, and I can hear the inevitable question now: "what's the
> difference between Universal Design and Automatic Accessibility?"
>
> "Universal Design Isn't" (and neither is Automatic):
>
> By which I mean that even the concept of Universal Design (and
> Inclusive Design as well) suffers from what I consider the "Long Tail"
> problem (http://en.wikipedia.org/wiki/Long_Tail) - that the universality
> of
> Universal Design has itself some limitations, and at some point, to be
> really inclusive, we need to also consider Accommodation strategies. It
> has
> been my observation (and concern) that increasingly - and notably within
> the
> web world - this basic fact is becoming lost in the rush to embrace
> "Universal Design" (and the presumption of what you are calling Automatic
> Accessibility). I see this a lot in my exchanges and work at the W3C with
> HTML5, where a significant portion of a certain working group believe that
> Universal Design principles will solve *all* accessibility issues
> (because,
> you know, they tested it with VoiceOver...)
>
> The bottom line is that to achieve the real end-goal (access for
> <del>all</del> <ins>most of</ins> of our users) requires attention,
> thought,
> and occasionally some extra effort; and while I whole-heartedly embrace
> the
> concept of Universal Design and Inclusive Design, it is with the caveat
> that
> those principles alone do not equal success. My fear is that if we
> introduce a loaded term like "Automatic" it somehow suggests that the end
> authors don't have to contribute to the heavy lifting, which I believe we
> all know to be false.
>
> Me, I will continue to use the term Universal Design, which is already a
> common term in the Design world, and teach that while Universal Design as
> a
> design principle is beneficial to all users in subtle and not-so-subtle
> ways, I will also continue to teach at the same time that it gets us 80%
> or
> better towards our ultimate goal, but that it has its limitations, and
> should not be thought of as the panacea to absolve authors/creators from
> thinking through what they are creating.
>
> My $0.02, because you asked...
>
> JF
>
>
>
>
> > >

From: Elle
Date: Fri, Apr 20 2012 12:18PM
Subject: Re: Do people actually want Automatic Accessibility within Web Technologies?
← Previous message | Next message →

*I disagree with your simplistic assertions that using a specific set
of technologies
will "automatically" get you to accessible - it simply won't.*
*
*
If we could just remove the human element from all of this, I think we'd
all get more hours of sleep.

John, I really could not agree more with your comments. As much as I wish
for a universally standardized, codified, and tidy online world of
accessible content using all the "best" technologies, and believe me I wish
for it often in my job, we will never reach that goal where individual and
unique user need no longer influences web accessibility. And, I shall
posit, we shouldn't aim for this. The web, at its best, is a very
interactive and fluid environment, changed and shaped by its users. Just
as user experience is highly personal and individual, so is web
accessibility. I will continue to strive to codify what I can, based on
the commonalities found in users' feedback and standards laid out by W3C,
but I won't pretend that we'll ever sanitize the web of the pesky
exceptions to the rule, who are in fact, people.


Respectfully,
Elle

From: Paul J. Adam
Date: Fri, Apr 20 2012 1:19PM
Subject: Re: Do people actually want Automatic Accessibility within Web Technologies?
← Previous message | Next message →

Other OS X software applications are VoiceOver accessible so it is possible for Adobe & Microsoft to do the same. Adobe blogged in 2010 that they planed to "utilize the OSX accessibility API support, resulting in the ability to access to Flash content using VoiceOver" (http://blogs.adobe.com/accessibility/2010/03/flash_player_and_flex_support.html) but they said at CSUN that Flash will never be accessible on the Mac so I'd say you can safely avoid it.

If other companies like Google can make apps like Chrome accessible on the Mac then I doubt it's Apple's fault that Reader, Flash, or Office are not accessible.

ePub is mostly XHTML underneath so easy to make accessible.

No one thinks that HTML automatically comes accessible with no work. My point is that if you follow W3C standards-based, semantic coding practices then the accessibility is included and universal design is automatic. You can follow the accessibility standards for creating PDF, Flash, & Office docs but they still will never be universally accessible on all devices that support accessibility.

Accessibility does not come for free and is not automatic but no matter how much work you put into non-HTML based technologies they'll never be accessible on all the platforms which support accessibility.

The other pro with using HTML is that you don't need to purchase expensive software to make it accessible and there's plenty of free training on the web to teach you how to do it.

Paul J. Adam
Accessibility Evangelist
Deque Systems
= EMAIL ADDRESS REMOVED =
www.PaulJAdam.com
@pauljadam on Twitter

On Apr 20, 2012, at 12:19 PM, John Foliot wrote:

> Paul J. Adam wrote:
>> Everyone want's automatic accessibility, end users and developers.
>
> ...and as blues great Albert Collins wrote, "...everybody wants to go to
> heaven, nobody wants to die."
>
>
>> HTML
>> & HTML5 with JavaScript & CSS are the only web technologies that provide
>> universal design and have the ability to automatically be accessible as
>> long as they are coded with W3C standards.
>
> You see, this is exactly the type of problem I am talking about. I can take
> HTML/HTML5 + JavaScript + CSS and create a fully conformant yet totally
> inaccessible piece of garbage with little effort, and we've been able to do
> so for years now. This is one of the reasons why WCAG dropped the
> requirement for code validation, because we now know that validation alone
> does not equal accessible.
>
>
>> Of course they are often not
>> coded correctly so the accessibility is not quite automatic but HTML,
>> JS, & CSS fit the definition of universal design since they work on all
>> devices from feature phones to ebook readers to smart phones and beyond.
>
> It's not the devices, but rather the user-agent combinations
> (browsers/software) and the content created for those combinations of
> hardware and software tools that is key. Every piece of the chain is
> critical, and to somehow suggest that using some magical tokens (HTML5,
> JavaScript and CSS) will "automatically" give you Universal or Automatic
> Access is simply false, and serves to further illustrate my overarching
> concern.
>
> When used correctly, Daisy and ePub (both non W3C technologies) can produce
> accessible content for many if not most users, including sighted and
> mobility impaired users. Content creators need to *THINK* about what they
> are trying to achieve, rather than look at every problem as a nail, because
> they have HTML/JS/CSS hammers...
>
>
>> It's web technologies that do not work accessibly on all platforms and
>> devices which support accessibility that are preventing automatic
>> accessibility. E.g. Flash, PDF, MS Office Docs being the biggest
>> barriers to automatic accessibility.
>
> Yes, yes, big bad Adobe and Microsoft (who can't seem to get accessibility
> right on the Mac platform - ever consider maybe it's not *their* fault?).
>
> I want to remind everyone that any tool, when misused, can cause pain or
> harm. Flash itself is not inaccessible, it is inaccessible content created
> by under-educated developers that introduces inaccessibility. Yet, when it
> comes to the "most accessible" option for providing videos on the web today,
> it's not HTML5 that comes to the rescue, but rather Flash-based video
> players, which can and do support closed captions, descriptive audio and
> other accessibility accommodations. The current crop of HTML5 browsers that
> are supporting the HTML5 <video> tag cannot even provide native support for
> captions today, and descriptive audio is far down the line to come. (And
> before anyone wants to chime in about lack of Flash support on iOS, go
> complain to Apple, not to me, as it was Apple who chose not to support a
> specific type of technology, thus impacting all of their users negatively.
> So much for "Universality" huh?)
>
> PDF itself isn't inaccessible, once again it is poorly created content that
> is the root of problems. A well constructed PDF form (for example) can be
> quite accessible to both sighted and non-sighted users, and due to some
> formatting constructs that you can employ within PDF there may be instances
> when using a PDF form is in fact the best choice for the task at hand.
>
> What's the expression? "Guns don't kill people, People kill people..."
>
>
>>
>> I'm sure people will disagree with my suggestions to avoid non-HTML web
>> technologies but until they work on all accessible desktop platforms
>> like Windows, OS X, and Linux and also work on the accessible smartphone
>> platforms like iOS and (with many limitations) Android I will continue
>> to suggest avoiding them if you want to achieve universal design &
>> accessibility.
>
> I disagree with your simplistic assertions that using a specific set of
> technologies will "automatically" get you to accessible - it simply won't.
>
> JF
>
>
> > >

From: John Foliot
Date: Fri, Apr 20 2012 1:34PM
Subject: Re: Do people actually want Automatic Accessibility within Web Technologies?
← Previous message | Next message →

Bryan Garaventa wrote:
>
> Thanks, I agree, I'm not recommending another term, this is simply one I
> use myself when I'm trying to explain the concept to others.

LOL, then you *are* introducing a new term, at least to the "others" you are
explaining to...


> I've found that
> most people who aren't familiar with programming or accessibility, have
> no idea what universal and inclusive design is, and they find it
> confusing.

I'm not really sure what the net gain is from explaining one new term -
Automatic Accessibility - versus explaining another new term - Universal
Design - especially when at least the second term is more widely used. And I
*really* have an issue with the notion of "automatic" - it smacks too much
of "click this button and your accessibility woes will go away" - but maybe
that's just me.

If you *really* need a new term, I'd personally be way more comfortable with
"Embedded Accessibility", which based on the balance of your response is
equally true, but less "magical": we can embed systems and processes, that
*when used correctly* facilitate accessibility without a lot of manual
manipulation. This is absolutely true, and a laudable goal to pursue. (This
is actually the truest definition of Universal Design - a design that
facilitates accessibility when used properly)


> I agree that heavy lifting is often necessary for the development of
> truly
> accessible applications, however it is possible to automate the
> accessibility of baseline processes within a framework designed for that
> purpose, so that new web technologies and current ones can tap into the
> same functionality.

Ah, OK, so something along the lines of "moving to a CMS, where most authors
can't mess with the backend code, gets us greater gains in accessibility
overall" - ya, I can agree to that. But it still means that I need to teach
the content authors to not open the shiny new, accessibility friendly CMS,
and type something like "click on the red button on the right".

Or perhaps something along the lines of the Captioning System we developed
when I was at Stanford, where the end user "fed in" their video, and we
programmatically did some 'behind the curtain magic' and returned
web-friendly videos PLUS time-stamped caption files, copy and paste code,
and a Flash-based player that combined all the stuff we generated into a web
page that then rendered closed-caption videos. The content creators had no
idea what we were doing behind the scenes, but we established a work-flow
that simply generated captioned videos as an end-state, which was the net
win of the project.


>
> This provides a programmatic standard that can be used as a development
> platform, a framework where encapsulated widgets can be created and
> distributed as scalable automatically accessible user interface
> components,
> and a learning aid for the education of new developers at the same time.

At a very high level, at the enterprise, this makes enormous sense, and in
fact moving to these frameworks benefits more than just accessibility.
However, moving to them allows us, as accessibility practitioners, to
achieve gains at a much more scalable and high-level perspective than going
after "Dreamweaver built" web-pages, which we all know is a thankless and
never-ending task.

JF

From: Bryan Garaventa
Date: Fri, Apr 20 2012 2:54PM
Subject: Re: Do people actually want Automatic Accessibility withinWeb Technologies?
← Previous message | Next message →

I understand that all technologies are different, and all have their own
methodologies for making them work correctly, and not all of them will work
together as well as they should. However, everything has to start somewhere,
and there is value in establishing a reliable baseline.
For example there are accessibility APIs for Flash, Windows, iOS, and so on
at the platform level already which people already use for this purpose.

Since there are infinite ways to combine HTML/XHTML, JS, and CSS however,
this medium is far more challenging, since there are also infinite ways to
get them wrong.

What I'm hearing from these threads is basically, it's too big, it's
impossible, forget it.

What I know from experience however, is that it can be tackled by starting
in one place and moving onward, that it's definitely possible, and that it
shouldn't be forgotten.

The reason I know this, is because I already built an API that acts as a
baseline to make complex processes automatically accessible. I've been
working on it for three years now, and it works. It's called AccDC, and it
fully powers the dynamic website at
http://whatsock.com/

When I referred to fully encapsulated scalable and automatically accessible
user interface components, I was not speaking hypothetically. They are in
the download section, and they are as automatically accessible as it is
currently possible to be given recent advancements in browser/AT
combinations and ARIA.

Technology grows and we all have to adapt. This is also true for Assistive
Technology and platform combinations as well.

The first step for any true advancement is to establish a baseline from
which to work, otherwise there is nothing and we are going nowhere.



----- Original Message -----
From: "John Foliot" < = EMAIL ADDRESS REMOVED = >
To: "'WebAIM Discussion List'" < = EMAIL ADDRESS REMOVED = >
Sent: Friday, April 20, 2012 12:34 PM
Subject: Re: [WebAIM] Do people actually want Automatic Accessibility
withinWeb Technologies?


> Bryan Garaventa wrote:
>>
>> Thanks, I agree, I'm not recommending another term, this is simply one I
>> use myself when I'm trying to explain the concept to others.
>
> LOL, then you *are* introducing a new term, at least to the "others" you
> are
> explaining to...
>
>
>> I've found that
>> most people who aren't familiar with programming or accessibility, have
>> no idea what universal and inclusive design is, and they find it
>> confusing.
>
> I'm not really sure what the net gain is from explaining one new term -
> Automatic Accessibility - versus explaining another new term - Universal
> Design - especially when at least the second term is more widely used. And
> I
> *really* have an issue with the notion of "automatic" - it smacks too much
> of "click this button and your accessibility woes will go away" - but
> maybe
> that's just me.
>
> If you *really* need a new term, I'd personally be way more comfortable
> with
> "Embedded Accessibility", which based on the balance of your response is
> equally true, but less "magical": we can embed systems and processes, that
> *when used correctly* facilitate accessibility without a lot of manual
> manipulation. This is absolutely true, and a laudable goal to pursue.
> (This
> is actually the truest definition of Universal Design - a design that
> facilitates accessibility when used properly)
>
>
>> I agree that heavy lifting is often necessary for the development of
>> truly
>> accessible applications, however it is possible to automate the
>> accessibility of baseline processes within a framework designed for that
>> purpose, so that new web technologies and current ones can tap into the
>> same functionality.
>
> Ah, OK, so something along the lines of "moving to a CMS, where most
> authors
> can't mess with the backend code, gets us greater gains in accessibility
> overall" - ya, I can agree to that. But it still means that I need to
> teach
> the content authors to not open the shiny new, accessibility friendly CMS,
> and type something like "click on the red button on the right".
>
> Or perhaps something along the lines of the Captioning System we developed
> when I was at Stanford, where the end user "fed in" their video, and we
> programmatically did some 'behind the curtain magic' and returned
> web-friendly videos PLUS time-stamped caption files, copy and paste code,
> and a Flash-based player that combined all the stuff we generated into a
> web
> page that then rendered closed-caption videos. The content creators had no
> idea what we were doing behind the scenes, but we established a work-flow
> that simply generated captioned videos as an end-state, which was the net
> win of the project.
>
>
>>
>> This provides a programmatic standard that can be used as a development
>> platform, a framework where encapsulated widgets can be created and
>> distributed as scalable automatically accessible user interface
>> components,
>> and a learning aid for the education of new developers at the same time.
>
> At a very high level, at the enterprise, this makes enormous sense, and in
> fact moving to these frameworks benefits more than just accessibility.
> However, moving to them allows us, as accessibility practitioners, to
> achieve gains at a much more scalable and high-level perspective than
> going
> after "Dreamweaver built" web-pages, which we all know is a thankless and
> never-ending task.
>
> JF
>
> > >

From: Bryan Garaventa
Date: Sun, Apr 22 2012 5:13PM
Subject: Re: Do people actually want Automatic AccessibilitywithinWeb Technologies?
← Previous message | Next message →

Hi,
I've been going back and forth with John Foliot off-list, and he had some
awesome questions that I wished to share. He's been pivotal in helping me to
frame and explain the concepts of AccDC in a more comprehensive manner,
which admittedly is not something I'm very good at at times. So thanks a
million John, you rock!
In addition to pasting the questions/answers below, I've already added these
to the FAQ section at
http://www.kickstarter.com/projects/bgaraventa/accdc-the-accelerated-dynamic-content-api?ref=email

Q/A

What do you mean by Automatic Accessibility? There can't be a magic
accessibility button, that's impossible.

No, you're absolutely right, there is no such thing as a magic button to
automate accessibility.

Simply put, AccDC is an accessibility API for the web, which can also be
used to build powerful dynamic applications using JavaScript.

The framework allows developers to build encapsulated user interface
components in such a way, that accessibility is built in and can be
redistributed with the components themselves, so that accessibility can
propagate across various web technologies simply by the study and use of
these components. This is why the encapsulated object model of AccDC is so
important.

Also, as the use and knowledge of such components becomes more widespread,
developers will pick up on the techniques and concepts that are used in the
construction of these components, and begin to build their own in the same
manner. This is why I'm trying to raise the funds to write the book, so that
I can outline these concepts in a clear and concise manner, so the
construction of such components will be as accessible as possible for
everyone.

Are you talking about 100% accessibility?

No, of course not, accessibility will never be a 100% proposition because of
the various technologies and disability types involved. However, we can
certainly raise the bar as high as possible, which will have a positive
impact on the lives of millions.

How close is this to a Mixin?

As defined at
http://en.wikipedia.org/wiki/Mixin

The answer is sort of similar, but not really.

The concept for a Mixin is basically like this,
you have object1, and object2 with extra stuff in it,
then you merge object2 into object1 so that now object1 has the extra stuff
as well.
The drawback to this concept, is that, if there are pre-existing
accessibility issues within object1 to begin with, those issues will still
exist even after object2 is merged into it.

AccDC is more of a wholesale solution, where an enclosed object is provided
as a plug-and-play component.
Here is a simple example, which I've already implemented before.

There is an AccDC Object declaration, which is a block of code that loads
automatically when AccDC starts up.
The ID for this AccDC Object is 'tooltip', and is designed to display an
accessible tooltip message that is automatically announced to screen reader
users when displayed.
So, after it loads into AccDC, it's ready to be used like so within a click
event handler:

// Set the triggering element so that the tooltip will appear next to it
visually.
$A.reg.tooltip.triggerObj = this;
// Set the tooltip text that will be displayed.
$A.reg.tooltip.source = 'You must enter a valid email address to continue
with registration.';
// Now open the tooltip.
$A.reg.tooltip.open();

And that's it. All of the other stuff like event handlers enabling keyboard
accessibility, automatic announcement for screen reader users, mouseOver and
mouseOut functionality and so on, are already built into the tooltip object;
so all you have to do to use it, is to plug the tooltip object into any
application using AccDC, set a few parameters and open it, and it just
works.

Plus, and this is really cool, you can change the nature of the object on
the fly as well, while preserving the same level of accessibility. For
example, take the tooltip example above, where you can do the following from
within a click handler as well:

// Set the triggering element so that the tooltip will appear next to it
visually.
$A.reg.tooltip.triggerObj = this;
// Change the autopositioning so that the message appears to the left of the
triggering element instead.
$A.reg.tooltip.autoPosition = 7;
// Change the class name to apply a different styling to the tooltip.
$A.reg.tooltip.className = 'decorated tooltip';
// Set the tooltip text that will be displayed.
$A.reg.tooltip.source = 'You must enter a valid email address to continue
with registration.';
// Now open the tooltip.
$A.reg.tooltip.open();

Or, you could even change the nature of the tooltip AccDC Object into a
popup like so from within the same click handler, by loading the desired
popup content from an external HTML file. This would also preserve the same
level of accessibility.

// Set the triggering element so that the tooltip will appear next to it
visually.
$A.reg.tooltip.triggerObj = this;
// Change the role of the object from a tooltip to that of a popup.
$A.reg.tooltip.role = 'Popup';
// Change the rendering mode from 0 to 1, which will pull content from an
external file.
$A.reg.tooltip.mode = 1;
// Set the external file path, and point to a particular message using its
ID attribute.
$A.reg.tooltip.source = 'files/popupList.html #message1';
// Now open the converted popup.
$A.reg.tooltip.open();

Plus you can use nested and linked AccDC Objects to build complex components
like tab controls, dialogs, dropdown menus, carousels, wizards, or any other
user interface component you can think of.

Is this like a Polyfill? Or like Modernizr?

As defined at
http://remysharp.com/2010/10/08/what-is-a-polyfill/
and
http://modernizr.com/

A polyfill does fit the analogy, but not in the same way as it's commonly
understood.

The purpose of a polyfill is to patch up browser inconsistencies. For
instance, say you can do something on IE but you can't do it the same way in
Firefox, so you use a polyfill solution to make it possible to use the same
script so that it works in both IE and Firefox at the same time. jQuery
works like this, where you can use the same jQuery commands to perform an
action that is equally compatible in both IE and Firefox.

AccDC does the same thing, so you can create component objects that render
successfully across browsers and platforms, such as in IE and Firefox,
Safari on the Mac and iOS devices, etc. So, in this way, it does offer the
same functionality as a conventional polyfill.

Modernizr is a more specific form of polyfill, where Modernizr can be used
to run cross-browser compatible processes, and is designed to be plugged
into other technologies for this purpose, which is awesome!

Think of it this way, a polyfill is designed to bridge the gaps between the
browsers and platforms so the same applications will work on all of those
systems equally well, but this doesn't include accessibility.

AccDC does both at the same time, so that content is rendered in a
consistently accessible manner that is cross-browser compatible. AccDC does
this by updating the Document Object Model in ways that are proven to be
most accessible for keyboard and screen reader users, and includes a
framework for adding additional accessibility related information to every
AccDC Object so that accessibility is an integral part of every component.

So basically, AccDC is a polyfill for accessibility.

Is the concept of AccDC more similar to Modernizr, or jQuery?

There are more similarities with the way that jQuery works, at least on the
backend. When I first wrote AccDC in 2009, it was a jQuery plugin. This
limited its versatility however, since it couldn't be directly integrated
into other systems that didn't also use jQuery, and I didn't want the system
to be reliant on a constantly changing system. So I rewrote all of the API
functionality to use cross-browser functions based on the X library at
cross-browser.com, and kept some of the other open source components like
the event handling system, and then I rewrote everything else and removed
all redundant processes to make AccDC work faster. This is why the AJAX
functionality is similar to that of jQuery's, though nothing else is.

Would integrating AccDC into a larger package also see expanded benefits?

Yes! You can plug AccDC into larger packages to enhance the functionality of
those software systems. For example, you can plug AccDC into frameworks or
libraries like YUI and jQuery, to enhance functionality.

This works because AccDC is a closed system, meaning that it won't conflict
with anything else that's running at the same time. Another framework can
then generate AccDC Objects and use them within their own framework on the
fly, or customized user interface components that utilize AccDC can be
created and redistributed. Then you can have the combined functionality of
the framework or library and AccDC at the same time.

Also, AccDC can be used by itself, so you don't have to include it within
any other framework for it to work, so it is very versatile.

----- Original Message -----
From: "Bryan Garaventa" < = EMAIL ADDRESS REMOVED = >
To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
Sent: Friday, April 20, 2012 1:54 PM
Subject: Re: [WebAIM] Do people actually want Automatic
AccessibilitywithinWeb Technologies?


>I understand that all technologies are different, and all have their own
> methodologies for making them work correctly, and not all of them will
> work
> together as well as they should. However, everything has to start
> somewhere,
> and there is value in establishing a reliable baseline.
> For example there are accessibility APIs for Flash, Windows, iOS, and so
> on
> at the platform level already which people already use for this purpose.
>
> Since there are infinite ways to combine HTML/XHTML, JS, and CSS however,
> this medium is far more challenging, since there are also infinite ways to
> get them wrong.
>
> What I'm hearing from these threads is basically, it's too big, it's
> impossible, forget it.
>
> What I know from experience however, is that it can be tackled by starting
> in one place and moving onward, that it's definitely possible, and that it
> shouldn't be forgotten.
>
> The reason I know this, is because I already built an API that acts as a
> baseline to make complex processes automatically accessible. I've been
> working on it for three years now, and it works. It's called AccDC, and it
> fully powers the dynamic website at
> http://whatsock.com/
>
> When I referred to fully encapsulated scalable and automatically
> accessible
> user interface components, I was not speaking hypothetically. They are in
> the download section, and they are as automatically accessible as it is
> currently possible to be given recent advancements in browser/AT
> combinations and ARIA.
>
> Technology grows and we all have to adapt. This is also true for Assistive
> Technology and platform combinations as well.
>
> The first step for any true advancement is to establish a baseline from
> which to work, otherwise there is nothing and we are going nowhere.
>
>
>
> ----- Original Message -----
> From: "John Foliot" < = EMAIL ADDRESS REMOVED = >
> To: "'WebAIM Discussion List'" < = EMAIL ADDRESS REMOVED = >
> Sent: Friday, April 20, 2012 12:34 PM
> Subject: Re: [WebAIM] Do people actually want Automatic Accessibility
> withinWeb Technologies?
>
>
>> Bryan Garaventa wrote:
>>>
>>> Thanks, I agree, I'm not recommending another term, this is simply one I
>>> use myself when I'm trying to explain the concept to others.
>>
>> LOL, then you *are* introducing a new term, at least to the "others" you
>> are
>> explaining to...
>>
>>
>>> I've found that
>>> most people who aren't familiar with programming or accessibility, have
>>> no idea what universal and inclusive design is, and they find it
>>> confusing.
>>
>> I'm not really sure what the net gain is from explaining one new term -
>> Automatic Accessibility - versus explaining another new term - Universal
>> Design - especially when at least the second term is more widely used.
>> And
>> I
>> *really* have an issue with the notion of "automatic" - it smacks too
>> much
>> of "click this button and your accessibility woes will go away" - but
>> maybe
>> that's just me.
>>
>> If you *really* need a new term, I'd personally be way more comfortable
>> with
>> "Embedded Accessibility", which based on the balance of your response is
>> equally true, but less "magical": we can embed systems and processes,
>> that
>> *when used correctly* facilitate accessibility without a lot of manual
>> manipulation. This is absolutely true, and a laudable goal to pursue.
>> (This
>> is actually the truest definition of Universal Design - a design that
>> facilitates accessibility when used properly)
>>
>>
>>> I agree that heavy lifting is often necessary for the development of
>>> truly
>>> accessible applications, however it is possible to automate the
>>> accessibility of baseline processes within a framework designed for that
>>> purpose, so that new web technologies and current ones can tap into the
>>> same functionality.
>>
>> Ah, OK, so something along the lines of "moving to a CMS, where most
>> authors
>> can't mess with the backend code, gets us greater gains in accessibility
>> overall" - ya, I can agree to that. But it still means that I need to
>> teach
>> the content authors to not open the shiny new, accessibility friendly
>> CMS,
>> and type something like "click on the red button on the right".
>>
>> Or perhaps something along the lines of the Captioning System we
>> developed
>> when I was at Stanford, where the end user "fed in" their video, and we
>> programmatically did some 'behind the curtain magic' and returned
>> web-friendly videos PLUS time-stamped caption files, copy and paste code,
>> and a Flash-based player that combined all the stuff we generated into a
>> web
>> page that then rendered closed-caption videos. The content creators had
>> no
>> idea what we were doing behind the scenes, but we established a work-flow
>> that simply generated captioned videos as an end-state, which was the net
>> win of the project.
>>
>>
>>>
>>> This provides a programmatic standard that can be used as a development
>>> platform, a framework where encapsulated widgets can be created and
>>> distributed as scalable automatically accessible user interface
>>> components,
>>> and a learning aid for the education of new developers at the same time.
>>
>> At a very high level, at the enterprise, this makes enormous sense, and
>> in
>> fact moving to these frameworks benefits more than just accessibility.
>> However, moving to them allows us, as accessibility practitioners, to
>> achieve gains at a much more scalable and high-level perspective than
>> going
>> after "Dreamweaver built" web-pages, which we all know is a thankless and
>> never-ending task.
>>
>> JF
>>
>> >> >> >
> > >

From: Birkir R. Gunnarsson
Date: Sun, Apr 22 2012 5:36PM
Subject: Re: Do people actually want Automatic AccessibilitywithinWeb Technologies?
← Previous message | No next message

Bryan

You've been doing some awesome work for sure.
I suggest you put this in a separate new thread with a more
descriptive subject such as (my accessibility library, please consider
funding it" or something.
(though you may want to run that by the list admin of course).
I think, from looking at implementing ARIA controls from scratch this
weekend, that a library like this could make a huge difference for
accessibility. Creating an accessible tab control from scratch is not
a trivial task, not even for a JQuery programmer with eperience. It is
very doable, sure, but to write all the associated event and keyboard
handling and testing it is not something you can do in a few hours,
and adding accessibility for mainstream developers has to be as easy
as possible. Of course it supplements other very valuable efforts,
such as trying to get better accessibility built into JQuery
components, but having a readily available open source framework for
generating accessible AJAX controls without having to take care of all
the underlying details, will both promote accessibility and
consistency in things like keyboard navigation of custom widgets.
I will most certainly pledge to this myself, and I suggest, besides
posting it to this list in its own thread, posting it to any W3C
working groups or lists you may be aware of and do more aggressive
tweeting to get the word out and get discussions going.
Good luck.
-B

On 4/22/12, Bryan Garaventa < = EMAIL ADDRESS REMOVED = > wrote:
> Hi,
> I've been going back and forth with John Foliot off-list, and he had some
> awesome questions that I wished to share. He's been pivotal in helping me to
> frame and explain the concepts of AccDC in a more comprehensive manner,
> which admittedly is not something I'm very good at at times. So thanks a
> million John, you rock!
> In addition to pasting the questions/answers below, I've already added these
> to the FAQ section at
> http://www.kickstarter.com/projects/bgaraventa/accdc-the-accelerated-dynamic-content-api?ref=email
>
> Q/A
>
> What do you mean by Automatic Accessibility? There can't be a magic
> accessibility button, that's impossible.
>
> No, you're absolutely right, there is no such thing as a magic button to
> automate accessibility.
>
> Simply put, AccDC is an accessibility API for the web, which can also be
> used to build powerful dynamic applications using JavaScript.
>
> The framework allows developers to build encapsulated user interface
> components in such a way, that accessibility is built in and can be
> redistributed with the components themselves, so that accessibility can
> propagate across various web technologies simply by the study and use of
> these components. This is why the encapsulated object model of AccDC is so
> important.
>
> Also, as the use and knowledge of such components becomes more widespread,
> developers will pick up on the techniques and concepts that are used in the
> construction of these components, and begin to build their own in the same
> manner. This is why I'm trying to raise the funds to write the book, so that
> I can outline these concepts in a clear and concise manner, so the
> construction of such components will be as accessible as possible for
> everyone.
>
> Are you talking about 100% accessibility?
>
> No, of course not, accessibility will never be a 100% proposition because of
> the various technologies and disability types involved. However, we can
> certainly raise the bar as high as possible, which will have a positive
> impact on the lives of millions.
>
> How close is this to a Mixin?
>
> As defined at
> http://en.wikipedia.org/wiki/Mixin
>
> The answer is sort of similar, but not really.
>
> The concept for a Mixin is basically like this,
> you have object1, and object2 with extra stuff in it,
> then you merge object2 into object1 so that now object1 has the extra stuff
> as well.
> The drawback to this concept, is that, if there are pre-existing
> accessibility issues within object1 to begin with, those issues will still
> exist even after object2 is merged into it.
>
> AccDC is more of a wholesale solution, where an enclosed object is provided
> as a plug-and-play component.
> Here is a simple example, which I've already implemented before.
>
> There is an AccDC Object declaration, which is a block of code that loads
> automatically when AccDC starts up.
> The ID for this AccDC Object is 'tooltip', and is designed to display an
> accessible tooltip message that is automatically announced to screen reader
> users when displayed.
> So, after it loads into AccDC, it's ready to be used like so within a click
> event handler:
>
> // Set the triggering element so that the tooltip will appear next to it
> visually.
> $A.reg.tooltip.triggerObj = this;
> // Set the tooltip text that will be displayed.
> $A.reg.tooltip.source = 'You must enter a valid email address to continue
> with registration.';
> // Now open the tooltip.
> $A.reg.tooltip.open();
>
> And that's it. All of the other stuff like event handlers enabling keyboard
> accessibility, automatic announcement for screen reader users, mouseOver and
> mouseOut functionality and so on, are already built into the tooltip object;
> so all you have to do to use it, is to plug the tooltip object into any
> application using AccDC, set a few parameters and open it, and it just
> works.
>
> Plus, and this is really cool, you can change the nature of the object on
> the fly as well, while preserving the same level of accessibility. For
> example, take the tooltip example above, where you can do the following from
> within a click handler as well:
>
> // Set the triggering element so that the tooltip will appear next to it
> visually.
> $A.reg.tooltip.triggerObj = this;
> // Change the autopositioning so that the message appears to the left of the
> triggering element instead.
> $A.reg.tooltip.autoPosition = 7;
> // Change the class name to apply a different styling to the tooltip.
> $A.reg.tooltip.className = 'decorated tooltip';
> // Set the tooltip text that will be displayed.
> $A.reg.tooltip.source = 'You must enter a valid email address to continue
> with registration.';
> // Now open the tooltip.
> $A.reg.tooltip.open();
>
> Or, you could even change the nature of the tooltip AccDC Object into a
> popup like so from within the same click handler, by loading the desired
> popup content from an external HTML file. This would also preserve the same
> level of accessibility.
>
> // Set the triggering element so that the tooltip will appear next to it
> visually.
> $A.reg.tooltip.triggerObj = this;
> // Change the role of the object from a tooltip to that of a popup.
> $A.reg.tooltip.role = 'Popup';
> // Change the rendering mode from 0 to 1, which will pull content from an
> external file.
> $A.reg.tooltip.mode = 1;
> // Set the external file path, and point to a particular message using its
> ID attribute.
> $A.reg.tooltip.source = 'files/popupList.html #message1';
> // Now open the converted popup.
> $A.reg.tooltip.open();
>
> Plus you can use nested and linked AccDC Objects to build complex components
> like tab controls, dialogs, dropdown menus, carousels, wizards, or any other
> user interface component you can think of.
>
> Is this like a Polyfill? Or like Modernizr?
>
> As defined at
> http://remysharp.com/2010/10/08/what-is-a-polyfill/
> and
> http://modernizr.com/
>
> A polyfill does fit the analogy, but not in the same way as it's commonly
> understood.
>
> The purpose of a polyfill is to patch up browser inconsistencies. For
> instance, say you can do something on IE but you can't do it the same way in
> Firefox, so you use a polyfill solution to make it possible to use the same
> script so that it works in both IE and Firefox at the same time. jQuery
> works like this, where you can use the same jQuery commands to perform an
> action that is equally compatible in both IE and Firefox.
>
> AccDC does the same thing, so you can create component objects that render
> successfully across browsers and platforms, such as in IE and Firefox,
> Safari on the Mac and iOS devices, etc. So, in this way, it does offer the
> same functionality as a conventional polyfill.
>
> Modernizr is a more specific form of polyfill, where Modernizr can be used
> to run cross-browser compatible processes, and is designed to be plugged
> into other technologies for this purpose, which is awesome!
>
> Think of it this way, a polyfill is designed to bridge the gaps between the
> browsers and platforms so the same applications will work on all of those
> systems equally well, but this doesn't include accessibility.
>
> AccDC does both at the same time, so that content is rendered in a
> consistently accessible manner that is cross-browser compatible. AccDC does
> this by updating the Document Object Model in ways that are proven to be
> most accessible for keyboard and screen reader users, and includes a
> framework for adding additional accessibility related information to every
> AccDC Object so that accessibility is an integral part of every component.
>
> So basically, AccDC is a polyfill for accessibility.
>
> Is the concept of AccDC more similar to Modernizr, or jQuery?
>
> There are more similarities with the way that jQuery works, at least on the
> backend. When I first wrote AccDC in 2009, it was a jQuery plugin. This
> limited its versatility however, since it couldn't be directly integrated
> into other systems that didn't also use jQuery, and I didn't want the system
> to be reliant on a constantly changing system. So I rewrote all of the API
> functionality to use cross-browser functions based on the X library at
> cross-browser.com, and kept some of the other open source components like
> the event handling system, and then I rewrote everything else and removed
> all redundant processes to make AccDC work faster. This is why the AJAX
> functionality is similar to that of jQuery's, though nothing else is.
>
> Would integrating AccDC into a larger package also see expanded benefits?
>
> Yes! You can plug AccDC into larger packages to enhance the functionality of
> those software systems. For example, you can plug AccDC into frameworks or
> libraries like YUI and jQuery, to enhance functionality.
>
> This works because AccDC is a closed system, meaning that it won't conflict
> with anything else that's running at the same time. Another framework can
> then generate AccDC Objects and use them within their own framework on the
> fly, or customized user interface components that utilize AccDC can be
> created and redistributed. Then you can have the combined functionality of
> the framework or library and AccDC at the same time.
>
> Also, AccDC can be used by itself, so you don't have to include it within
> any other framework for it to work, so it is very versatile.
>
> ----- Original Message -----
> From: "Bryan Garaventa" < = EMAIL ADDRESS REMOVED = >
> To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
> Sent: Friday, April 20, 2012 1:54 PM
> Subject: Re: [WebAIM] Do people actually want Automatic
> AccessibilitywithinWeb Technologies?
>
>
>>I understand that all technologies are different, and all have their own
>> methodologies for making them work correctly, and not all of them will
>> work
>> together as well as they should. However, everything has to start
>> somewhere,
>> and there is value in establishing a reliable baseline.
>> For example there are accessibility APIs for Flash, Windows, iOS, and so
>> on
>> at the platform level already which people already use for this purpose.
>>
>> Since there are infinite ways to combine HTML/XHTML, JS, and CSS however,
>> this medium is far more challenging, since there are also infinite ways to
>> get them wrong.
>>
>> What I'm hearing from these threads is basically, it's too big, it's
>> impossible, forget it.
>>
>> What I know from experience however, is that it can be tackled by starting
>> in one place and moving onward, that it's definitely possible, and that it
>> shouldn't be forgotten.
>>
>> The reason I know this, is because I already built an API that acts as a
>> baseline to make complex processes automatically accessible. I've been
>> working on it for three years now, and it works. It's called AccDC, and it
>> fully powers the dynamic website at
>> http://whatsock.com/
>>
>> When I referred to fully encapsulated scalable and automatically
>> accessible
>> user interface components, I was not speaking hypothetically. They are in
>> the download section, and they are as automatically accessible as it is
>> currently possible to be given recent advancements in browser/AT
>> combinations and ARIA.
>>
>> Technology grows and we all have to adapt. This is also true for Assistive
>> Technology and platform combinations as well.
>>
>> The first step for any true advancement is to establish a baseline from
>> which to work, otherwise there is nothing and we are going nowhere.
>>
>>
>>
>> ----- Original Message -----
>> From: "John Foliot" < = EMAIL ADDRESS REMOVED = >
>> To: "'WebAIM Discussion List'" < = EMAIL ADDRESS REMOVED = >
>> Sent: Friday, April 20, 2012 12:34 PM
>> Subject: Re: [WebAIM] Do people actually want Automatic Accessibility
>> withinWeb Technologies?
>>
>>
>>> Bryan Garaventa wrote:
>>>>
>>>> Thanks, I agree, I'm not recommending another term, this is simply one I
>>>> use myself when I'm trying to explain the concept to others.
>>>
>>> LOL, then you *are* introducing a new term, at least to the "others" you
>>> are
>>> explaining to...
>>>
>>>
>>>> I've found that
>>>> most people who aren't familiar with programming or accessibility, have
>>>> no idea what universal and inclusive design is, and they find it
>>>> confusing.
>>>
>>> I'm not really sure what the net gain is from explaining one new term -
>>> Automatic Accessibility - versus explaining another new term - Universal
>>> Design - especially when at least the second term is more widely used.
>>> And
>>> I
>>> *really* have an issue with the notion of "automatic" - it smacks too
>>> much
>>> of "click this button and your accessibility woes will go away" - but
>>> maybe
>>> that's just me.
>>>
>>> If you *really* need a new term, I'd personally be way more comfortable
>>> with
>>> "Embedded Accessibility", which based on the balance of your response is
>>> equally true, but less "magical": we can embed systems and processes,
>>> that
>>> *when used correctly* facilitate accessibility without a lot of manual
>>> manipulation. This is absolutely true, and a laudable goal to pursue.
>>> (This
>>> is actually the truest definition of Universal Design - a design that
>>> facilitates accessibility when used properly)
>>>
>>>
>>>> I agree that heavy lifting is often necessary for the development of
>>>> truly
>>>> accessible applications, however it is possible to automate the
>>>> accessibility of baseline processes within a framework designed for that
>>>> purpose, so that new web technologies and current ones can tap into the
>>>> same functionality.
>>>
>>> Ah, OK, so something along the lines of "moving to a CMS, where most
>>> authors
>>> can't mess with the backend code, gets us greater gains in accessibility
>>> overall" - ya, I can agree to that. But it still means that I need to
>>> teach
>>> the content authors to not open the shiny new, accessibility friendly
>>> CMS,
>>> and type something like "click on the red button on the right".
>>>
>>> Or perhaps something along the lines of the Captioning System we
>>> developed
>>> when I was at Stanford, where the end user "fed in" their video, and we
>>> programmatically did some 'behind the curtain magic' and returned
>>> web-friendly videos PLUS time-stamped caption files, copy and paste code,
>>> and a Flash-based player that combined all the stuff we generated into a
>>> web
>>> page that then rendered closed-caption videos. The content creators had
>>> no
>>> idea what we were doing behind the scenes, but we established a work-flow
>>> that simply generated captioned videos as an end-state, which was the net
>>> win of the project.
>>>
>>>
>>>>
>>>> This provides a programmatic standard that can be used as a development
>>>> platform, a framework where encapsulated widgets can be created and
>>>> distributed as scalable automatically accessible user interface
>>>> components,
>>>> and a learning aid for the education of new developers at the same time.
>>>
>>> At a very high level, at the enterprise, this makes enormous sense, and
>>> in
>>> fact moving to these frameworks benefits more than just accessibility.
>>> However, moving to them allows us, as accessibility practitioners, to
>>> achieve gains at a much more scalable and high-level perspective than
>>> going
>>> after "Dreamweaver built" web-pages, which we all know is a thankless and
>>> never-ending task.
>>>
>>> JF
>>>
>>> >>> >>> >>
>> >> >> >
> > > >