Making it easier to build ARIA compliant content/tools

[ian Lloyd]

Hi everyone,

First proper post here, so please forgive any breach of 'etiquette' or
rules here! Hopefully I won't be shaming myself here by asking
anything too 'numpty'.

A brief history lesson (very brief): when I set up Accessify.com back
in 2003, it was mainly done as a way of pulling together a bunch of
tools that I'd built to help create accessible content. At that time,
much of the software available wasn't doing this, so I tried to do my
bit to help out. Many years later and some of those tools on the site
are no longer of quite so much use. However, with ARIA getting so much
more support it struck me that with all this discussion about it, for
the average developer on the street it's still not particularly easy
to quickly generate content. And this is where I'd like to offer some
help and maybe start churning out some new tools ...

I'm in the process of completely rebuilding accessify.com, including
some new tools, a general facelift, support for ARIA in the site
itself and some other bits and bobs. Should all be ready within a
month or so. I want to create some 'quickly make an AIRA-compliant
thing' type tools, but as I've not really used ARIA a huge amount
myself, I'm still not entirely sure what the most useful tools would
be. And that's where you folks come in.

If you like the idea and are happy for me to put something together
for accessify on this basis, please feed your ideas to me.

As an idea of the kind of thing I mean, here's a rough demo. I took
the simple slider example off the Paciello site and reverse engineered
it, created a form that allows you to choose your values, labels etc,
then at a press of a button it re-generates the necessary HTML/CSS/JS:

http://www.accessify.com/tools-and-wizards/aria-slider.html

It's unstyled, is lacking instructions but is just to give you an idea
of the kind of thing I'd like to do. So, what is it that's most sorely
needed?

I look forward to your ideas :-)

--
Ian Lloyd, Accessify.com

[David Bolter]

Hi Ian,

I'm intrigued with your slider builder. I feel that it might be a step
towards something quite useful... before I brain storm (or mindfork as
I call it)... What inspired you to create this builder? Which users
are you targeting for a tool like this?

Is anyone here aware of any existing DHTML GUI builders (perhaps like
this, or even WYSIWYG)? If so, we definitely need to make sure ARIA is
incorporated.

cheers,
David

[David Bolter]

Okay I just googled "dhtml gui builder" and got a lot of hits. What I
really care about is if there are any "popular' DHTML GUI builders?

cheers,
David

[ian Lloyd]

On 16 Oct 2008, at 02:49, David Bolter wrote:

> What inspired you to create this builder?

The same thing that inspired me to build tools like the accessible
form/table builder years, that being that the software out there
(DreamWeaver etc) didn't provide this out of the box, so the developer
would have to hand-code it and, potentially, make a bit of a hash-up
of it.

> Which users
> are you targeting for a tool like this?

Any developer who wants to do things the right way :)

Ian Lloyd (+me on twitter: lloydi | + me on AOL/Skype: uklloydi)
Mario Kart Friend Code: 0430-8470-8307

- - - - - - - - - - - - - - - - - - - - - - - - - -
The Ultimate HTML Reference: a hardcover HTML reference,
ideal for bashing standards numptys over the head with!
--> http://htmlreferencebook.com/
- - - - - - - - - - - - - - - - - - - - - - - - - -
Oi! Customise yer Mac browsers!
--> http://browserversionicons.com/
- - - - - - - - - - - - - - - - - - - - - - - - - -

[Aaron Leventhal]

Ian,

This is a good idea -- not just in order to use ARIA, but to help
developers use new widgets in the first place.

I would think there's a lot of value in having a GUI builder that helps
developers use Dojo, GWT, YUI or JQuery widgets. Since those have, or
are getting, accessibility support I'd use those. They're going to have
more more useful widgets since they're being built by a large general
community.

- Aaron

[ian Lloyd]

On 16 Oct 2008, at 09:15, Aaron Leventhal wrote:

> I would think there's a lot of value in having a GUI builder that
> helps
> developers use Dojo, GWT, YUI or JQuery widgets. Since those have, or
> are getting, accessibility support I'd use those. They're going to
> have
> more more useful widgets since they're being built by a large general
> community.

ideally, what I would like to do is the following:

1) Identify some typical widgets that could be used now and would work
well with ARIA attributes (like the slider example)
2) Build the tools that make building said widgets as easy as possible
3) Add in option for the ARIA attributes to be added in dynamically
via Scripting using a syntax of your choosing, e.g.

Add ARIA attributes using:

* Standard JavaScript syntax ('setAttribute("role","navigation"))
* jQuery syntax ('$("#whataver").attr("role","navigation"))
* dojo

etc etc

The last bit is the easy part; for me steps 1 and 2 are the hard
parts. If you folks can make a few suggestions for step 1, I can think
about step 2.

In addition, once the tools are done, i fully intend to screen cast
how the tools work and tie that up with an exmple of how the widget is
used (for that second part it may simply be enough to refer to an
existing ARIA example screencast).

[ian Lloyd]

On 16 Oct 2008, at 18:59, David Bolter wrote:

> Just quick jump in:

>
>> * jQuery syntax ('$("#whataver").attr("role","navigation"))
>

> You're safer to do $("#foo").ariaRole("role","navigation"));
>
>> * dojo
>
> dijit.setWaiRole(node, "navigation");

Ah, thanks for that. I only know jQuery, so I'd have to seek advice on
tho others when the time comes. But first I need to build a tool or
two ;-)

[David Bolter]

Hi Ian

Yes I don't mean to get ahead of things. BTW I was too fast on my
original reply, let me correct myself:

> > You're safer to do $("#foo").ariaRole("role","navigation"));

Should be:
$("#foo").ariaRole("navigation");

cheers,
David

[Aaron Leventhal]

> ideally, what I would like to do is the following:
>
> 1) Identify some typical widgets that could be used now and would work
> well with ARIA attributes (like the slider example)
> 2) Build the tools that make building said widgets as easy as possible
> 3) Add in option for the ARIA attributes to be added in dynamically
> via Scripting using a syntax of your choosing, e.g.
>

Do you mean build new widgets or just using the ones that come with
Dojo, GWT, YUI etc.
If you use the pre-built widgets they already add ARIA, so no need for
#3 above.
Also the pre-built widgets already exist and are more likely to be
robust for real software -- e.g. able to handle no CSS, no JS or a high
contrast theme, etc.

- Aaron

[ian Lloyd]

On 16 Oct 2008, at 20:40, Aaron Leventhal wrote:

> Do you mean build new widgets or just using the ones that come with
> Dojo, GWT, YUI etc.

I'm beginning to wonder whether I've fundamentally misunderstood
things here ;-)

Let's imagine that we're not dealing with any particular JS
library ... my understanding is that if someone creates a widget of
some kind using standard JavaScript, as it stands it will not useful/
understood by assistive tech. Only once the various ARIA attributes
are written in (either as HTML attributes or added via JavaScript) is
the widget understood by the assistive tech. I'm I right so far?

Now, for a developer to start using ARIA, they have to understand how
it works, where to apply the attributes etc etc and know what widgets
are understood, such as a slider. While these types of controls may
already be defined, many developers won;t know what these are.

So what I'm trying to do is not suggest/introduce new types of
widgets, but rather provide a way that a developer can say "I need to
use a slider ... how do I build one so that it works well, is keyboard
navigable, accessible and all that jazz without having to immerse
myself in some new discipline"? If they have to do the former, many
people will just say 'stuff that' and do it the quick way that they
know how.

So, what I'm after is some guidance about what tools would be good to
provide to allow people to do that, not suggesting new widgets, just
trying to work out a way of making it easy/easier for people to create
these widgets ... and then (re-introducing the JS side of things) to
add in any necessary JS hooks to plug the gaps.

If I'm misunderstanding how this works - and that's certainly possible
as I've not been actively involved in ARIA to date - then accept my
apologies. But if I've clarified what I'm trying to do with this note,
great :-)

[Aaron Leventhal]

On 10/16/2008 9:59 PM, ian Lloyd wrote:
> On 16 Oct 2008, at 20:40, Aaron Leventhal wrote:
>
>
>> Do you mean build new widgets or just using the ones that come with
>> Dojo, GWT, YUI etc.
>>
>
> I'm beginning to wonder whether I've fundamentally misunderstood
> things here ;-)
>

I don't think so. You seem to understand ARIA. It can definitely be used
directly by developers. I need a better way to explain what I'm trying
to say.

Basically, my suggestion is that for *most* developers who want the kind
of things that ARIA allows, it's better to just use widgets that someone
else already created. Since the JavaScript developer is effectively
implementing the widget, instead of the browser doing it, things can get
mighty complex. For example, a tree view has a lot of nuance. If you
type a letter/number/punctuation character, the focus should move to the
first visible tree item. If you type several of these characters, it
should match to the first two characters.Pressing left arrow collapses a
tree item, but if it's already collapsed or there are no children, the
focus should move to the parent. I could go on about the details of tree
views. Then you have all the cross-browser complexity and the issues
with high contrast modes, and perhaps the desire to degrade gracefully
so that older screen readers see it as nested lists of links.

When you consider the amount of work to create a full widget set, it
becomes clear that developers need to collaborate on a few really good
widget sets, and add ARIA to those. I would not recommend that every
developer go and develop their own JavaScript widgets (even without the
complexity of keyboard navigation support and ARIA). Just getting the
cross-browser bits correct is a good enough reason to pool resources and
efforts.

So I guess what I'm saying is that I love the idea of your tool, and
wonder whether it makes sense to do this as a mainstream designer tool
for an existing set of JavaScript widgets, rather than developing new
ones. It's not that you couldn't provide authors with new widgets, but
in my opinion, its more economical and more likely to be maintained if
you pool resources with another widget development effort. You could
even allow the author the choice of which kind of widget they want (GWT,
JQuery, Dojo, YUI, etc.).

- Aaron

[ian Lloyd]

On 20 Oct 2008, at 09:07, Aaron Leventhal wrote:

> Basically, my suggestion is that for *most* developers who want the
> kind
> of things that ARIA allows, it's better to just use widgets that
> someone
> else already created. Since the JavaScript developer is effectively
> implementing the widget, instead of the browser doing it, things can
> get

> mighty complex. ... I could go on about the details of tree

> views. Then you have all the cross-browser complexity and the issues
> with high contrast modes, and perhaps the desire to degrade gracefully
> so that older screen readers see it as nested lists of links.
>
> When you consider the amount of work to create a full widget set, it
> becomes clear that developers need to collaborate on a few really good
> widget sets, and add ARIA to those. I would not recommend that every
> developer go and develop their own JavaScript widgets (even without
> the
> complexity of keyboard navigation support and ARIA). Just getting the
> cross-browser bits correct is a good enough reason to pool resources
> and
> efforts.

OK, no probs. I think that part of the problem is that I'm not ever
going to find the time to really immerse myself in the nuts and bolts
of ARIA as some of the people on this list. My thought was that if
there was a way to make it easier for developers to implement/add ARIA
functionality with existing HTML patterns (rather than widgets/tags
that may not make any sense in HTML4 etc), then that might be worth a
go.

I'll keep my ear to the ground, perhaps I'll get a bright idea for a
time-saver or two in future.

[Scott González]

Hey Ian,

I don't want to discourage you from providing some Accessify tools for
ARIA, but I'm not sure I see the usefulness here. The types of
widgets that you'd be creating will almost certainly require some
customized scripting to interact with, which means that devs can't go
to Accessify and produce some static content to drop into their site.
Also, if the widgets require interaction, then you'll be producing an
API for the widgets, which would essentially make you a competitor of
the libraries you're talking about supporting.

If, on the other hand, you're going to generate markup that the
libraries' existing widgets work with, then you don't need to know
anything about ARIA to do that. I'd like to think that the libraries'
documentation and examples are good enough to make the content
generation straight-forward enough that an external tool wouldn't be
necessary. Again, I'm not trying to be negative, just trying to
figure out who the audience would actually be and what problem the
tool would solve (that would be better than any of the existing JS
libraries).

Also, you talked about the lack of existing popular tools that provide
good accessibility support. The bright side is that Dreamweaver CS4
has support for jQuery UI, which will have full ARIA support soon.
This is obviously only a fraction of devs that would benefit from more
tools that provide accessibility, but it's a good start.

On Oct 15, 8:08 pm, ian Lloyd <lloydiwombat...@gmail.com> wrote:

[Aaron Leventhal]

Hi Ian,

Any new thoughts on making ARIA easier for developers? We've been
attempting to make codetalks.org a great place for developers, but it
needs more content and appeal. I'm looking at the page
http://accessify.com/tools-and-wizards/accessibility-tools/aria/ and
thinking, now that he's done with his redesign, maybe Ian is chomping at
the bit to work on more content on ARIA? :)

BTW I love the new design of accessify.com.

- Aaron

On 10/16/2008 9:59 PM, ian Lloyd wrote:

[ian Lloyd]

On 16 Jan 2009, at 13:48, Aaron Leventhal wrote:

> Hi Ian,
>
> Any new thoughts on making ARIA easier for developers? We've been
> attempting to make codetalks.org a great place for developers, but it
> needs more content and appeal. I'm looking at the page
> http://accessify.com/tools-and-wizards/accessibility-tools/aria/and
> thinking, now that he's done with his redesign, maybe Ian is
> chomping at
> the bit to work on more content on ARIA? :)

I'd love to help however I can, but I will confess that since joining
this group I've been somewhat overwhelmed by the level of the
discussion and don't really know where to get a foothold. It probably
doesn't help that I only have one screen reader at my disposal at the
moment (Jaws 10 40 minute mode!) running as a virtual machine on the
Mac, so I feel a bit in the dark.

In essence, I've not contributed because I don't want to come across
like an eejit!

But I'd still like to help if I can, and putting together tools that
make it easy for people to implement ARIA features is one thing that I
can do; I just might need to get some direction.

For example, there's this tool: http://is.gd/g6RN (video explanation
here: http://accessify.com/screencasts/quick-page-accessibility-tester/)

One of the things it does is try to make a guess about navigation
areas and prompts the user to add in ARIA attributes. I'm sure there
are things like this I could do.

Why not drop me a line off-list with an idea or two for me to have a
crack at. I *still* don't have an awful lot of time, so I never commit
to doing anything lest I let others down. Family, home life, marriage
and sanity first, web second! Perhaps between the two of us I could
come up with a tool that your ARIA folks would really find handy?

> BTW I love the new design of accessify.com.

Thanks - I certainly think it's better, but I'm no Bryan Veloso!

Ian Lloyd
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

- - - - -

** The perfect HTML/CSS book for beginners is now in its second
edition **
** FIND OUT MORE at http://beginningwebdesign.com/ **
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

- - - - -

On Twitter/Flickr you can call me 'lloydi', on AOL Instant Messenger
I'm 'uklloydi'

[Aaron Leventhal]

Hi Ian,

I don't think anyone's going to be able to help the general effort
unless they are using it. Why not implement the ARIA landmarks on your site?

It's the simplest part to do, requiring no scripting, and already works
with JAWS in both Firefox and IE. On Linux, it works with Orca & Firefox.
A nice enhancement to accessibility of your site.

That will give you some flavor and hopefully get you hooked.

- Aaron

[ian Lloyd]

On 19 Jan 2009, at 14:09, Aaron Leventhal wrote:

> Why not implement the ARIA landmarks on your site?

I already did, but added it in unobtrusively with scripting (jQuery)
rather than placing the attributes in the HTML directly (to avoid the
validation issues).

function addAriaAttributes()
{
//landmark roles
$("#searcharea form, #blog_search").attr("role","search");
$(".storycontent, #commentlist li").attr("role","article");
$("#logo").attr("role","banner");
$("#skippies, #primarynavigation, #categories_list,
#archive_footer").attr("role","navigation");
$("#about-site-links").attr("role","contentinfo");
//required fields
//$("#author, #url").attr("aria-required","true");
}
addAriaAttributes();

That's still OK to do it that way, right?

[Aaron Leventhal]

I think it's just avoiding the issue, but it's okay by me.

Why is required commented out? Using required and invalid would be
great. In fact, do you have any fields where you can use a role="alert"
if a user doesn't enter data correctly? It gives instant feedback, which
is better than submitting the form and having to come back through the
page a 2nd time.

- Aaron

[ian Lloyd]

On 19 Jan 2009, at 15:53, Aaron Leventhal wrote:

> I think it's just avoiding the issue, but it's okay by me.

Not sure how it's avoiding the issue? I wanted to include these and
took the lead from Gez's article on Opera dev (http://dev.opera.com/articles/view/introduction-to-wai-aria/
), but I guess that's still not as 'immediate' as putting it directly
into the markup.

But still, they are there :-)

http://is.gd/guKE
http://is.gd/guKK

That'd be the next stop for me I guess. Perhaps an HTML5 make-over
would be good :-)

> Why is required commented out? Using required and invalid would be
> great. In fact, do you have any fields where you can use a
> role="alert"
> if a user doesn't enter data correctly? It gives instant feedback,
> which
> is better than submitting the form and having to come back through the
> page a 2nd time.

No idea why I commented that out, I think it was because while I was
developing I didn't spot any validation taking place and commented it
out temporarily. I'll take another look.

[Steven Faulkner]

Hi Ian I had a look at your landmark role use on Accessify, I couldn't
find a role="main". any reason why you have not used it?
also the role="article" is no longer a landmark (in the spec) although
JAWS 10 recognizes it as a landmark.

regards
steve

2009/1/19 ian Lloyd <lloydiw...@gmail.com>:

--
with regards

Steve Faulkner
Technical Director - TPG Europe
Director - Web Accessibility Tools Consortium

www.paciellogroup.com | www.wat-c.org
Web Accessibility Toolbar -
http://www.paciellogroup.com/resources/wat-ie-about.html

[Rich Schwerdtfeger]

At 09:02 AM 1/21/2009, you wrote:

>Hi Ian I had a look at your landmark role use on Accessify, I couldn't
>find a role="main". any reason why you have not used it?
>also the role="article" is no longer a landmark (in the spec) although
>JAWS 10 recognizes it as a landmark.

Article was never a landmark articles are part of discussion
sequences say in blog comments and it is derived from an element in
HTML 5. So, it is not a navigational landmark although an AT could
certainly add keys to follow those roles. So, rather than treat them
as landmark regions they are just semantically tagged sections of
your web page.

Rich

__________________________________________________
Rich Schwerdtfeger
Round Rock, Texas, USA

[ian Lloyd]

On 21 Jan 2009, at 15:02, Steven Faulkner wrote:

> Hi Ian I had a look at your landmark role use on Accessify, I couldn't
> find a role="main". any reason why you have not used it?

Nah ... no reason in particular that I can remember, so I'll take
another look at this :-)

> also the role="article" is no longer a landmark (in the spec) although
> JAWS 10 recognizes it as a landmark.

What should I replace this with? Or has it been dropped entirely? I
pretty much took all the landmark role titles and descriptions from
the Opera dev article. Is that article now out of date? Or has it been
updated since I read it?

[Gez Lemon]

Hi Ian,

2009/1/28 ian Lloyd <lloydiw...@gmail.com>:

> On 21 Jan 2009, at 15:02, Steven Faulkner wrote:
>> also the role="article" is no longer a landmark (in the spec) although
>> JAWS 10 recognizes it as a landmark.
>
> What should I replace this with? Or has it been dropped entirely? I
> pretty much took all the landmark role titles and descriptions from
> the Opera dev article. Is that article now out of date? Or has it been
> updated since I read it?

That role is out of date, but the rest of the article is still valid.
One of the problems writing about ARIA is that the specification is
still being developed, so things change. The public draft still lists
the article role, but you can see what landmark roles are available
from the WAI ARIA best practices editor's draft [1]. You could use the
main landmark role instead of article, as the article is the main
content.

[1] http://www.w3.org/WAI/PF/aria-practices/#kbd_layout_landmark_XHTML

Cheers,

Gez

--
_____________________________
Supplement your vitamins
http://juicystudio.com

[ian Lloyd]

On 28 Jan 2009, at 00:33, Gez Lemon wrote:

> That role is out of date, but the rest of the article is still valid.

Thanks for clarifying.

> One of the problems writing about ARIA is that the specification is
> still being developed, so things change.

Sure, understood, and what I added in terms of attributes reflects
that snapshot in time. I'll update these attributes soon (added to the
list of odds'n'sods that need a tweak).

[Gez Lemon]

Hi Ian,

>> One of the problems writing about ARIA is that the specification is
>> still being developed, so things change.
>
> Sure, understood, and what I added in terms of attributes reflects
> that snapshot in time. I'll update these attributes soon (added to the
> list of odds'n'sods that need a tweak).

I'm with you - I removed the role article from Juicy Studio.

[sch...@austin.rr.com]

We are moving to last call for February - at least that is the plan. So, the churn will subside.

Rich
--
Richard Schwerdfeger
Round Rock, TX USA

[sch...@austin.rr.com]

[sch...@austin.rr.com]

To reduce the churn look at the editors draft of the aria specification and the BPG:

http://www.w3.org/wai/pf/aria
http://www.w3.org/wai/pf/aria-practices

--
Richard Schwerdfeger
Round Rock, TX USA