Relationship of ARIA to HTML 4 & 5

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Relationship of ARIA to HTML 4 & 5

Aaron Leventhal-3
I would love to get feedback on the FAQ here:
http://developer.mozilla.org/en/docs/ARIA:_Accessible_Rich_Internet_Applications/Relationship_to_HTML_FAQ

It includes suggestions for easing the way ARIA can be used within HTML. It also
explains the goals of ARIA in a way that addresses many of the concerns I've
heard from leaders in the WHATWG/HTML5 community.

- Aaron
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: Relationship of ARIA to HTML 4 & 5

Gez Lemon
Hi Aaron,

On Sep 4, 4:50 pm, Aaron Leventhal <[hidden email]> wrote:
> I would love to get feedback on the FAQ here:http://developer.mozilla.org/en/docs/ARIA:_Accessible_Rich_Internet_A...

It's very good, but I have a few questions (probably not what you're
looking for, but to help aid my understanding).

There are a few references to building widgets using semantically
neutral elements, such as div and span. I can understand that's
advisable when there isn't an existing element close to what we're
describing, but is it unacceptable to use elements that are
semantically close to the widget's purpose when they exist and are
appropriate for the task? For example, using input type="image" might
be useful in circumstances where a simple widget is required to be in
the browser's tab order, without having to set a tabindex on a div or
span. The input type can then have a regular label with an explicit
association containing a property that is announced to screen readers.
The elements can still use ARIA properties to add extended meaning,
but there are times when using input type="image" or using a button
element, etc. might be more appropriate than semantically neutral
elements. Do ARIA widgets have to be built using semantically neutral
elements?

Using "aria-" as a prefix for ARIA attribute names seems like a good
idea where existing attribute names might clash with concepts from
ARIA, but would it cause a problem if some of the attributes were used
natively in HTML5 where existing attributes don't exist, could be
dropped, or their meaning changed in HTML5, without the prefix? For
example, HTLM5 could drop the longdesc attribute and replace it with
describedby, which could then be used as a generic attribute to
provide a longer descriptions for any object, not just images. The
"for" attribute for labels and the "headers" attribute for table cells
could be replaced by the labelledby attribute.

Best regards,

Gez



_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: Relationship of ARIA to HTML 4 & 5

David Bolter
Hi Gez,

Gez wrote:

> Hi Aaron,
>
> On Sep 4, 4:50 pm, Aaron Leventhal <[hidden email]> wrote:
>  
>> I would love to get feedback on the FAQ here:http://developer.mozilla.org/en/docs/ARIA:_Accessible_Rich_Internet_A...
>>    
>
> It's very good, but I have a few questions (probably not what you're
> looking for, but to help aid my understanding).
>
> There are a few references to building widgets using semantically
> neutral elements, such as div and span. I can understand that's
> advisable when there isn't an existing element close to what we're
> describing, but is it unacceptable to use elements that are
> semantically close to the widget's purpose when they exist and are
> appropriate for the task? For example, using input type="image" might
> be useful in circumstances where a simple widget is required to be in
> the browser's tab order, without having to set a tabindex on a div or
> span. The input type can then have a regular label with an explicit
> association containing a property that is announced to screen readers.
> The elements can still use ARIA properties to add extended meaning,
> but there are times when using input type="image" or using a button
> element, etc. might be more appropriate than semantically neutral
> elements. Do ARIA widgets have to be built using semantically neutral
> elements?
>  

I like your idea of using input with type="image", but I think one
desirable aspect of div and span is the kind of elements they can
contain. ARIA widgets are sometimes rather complex, requiring a subtree
of elements. I'm not sure off hand what is allowable inside input tags.

The other thing about input elements is that they can be difficult to
style, although hopefully that won't always be the case.

> Using "aria-" as a prefix for ARIA attribute names seems like a good
> idea where existing attribute names might clash with concepts from
> ARIA, but would it cause a problem if some of the attributes were used
> natively in HTML5 where existing attributes don't exist, could be
> dropped, or their meaning changed in HTML5, without the prefix? For
> example, HTLM5 could drop the longdesc attribute and replace it with
> describedby, which could then be used as a generic attribute to
> provide a longer descriptions for any object, not just images. The
> "for" attribute for labels and the "headers" attribute for table cells
> could be replaced by the labelledby attribute.
>
>  

I don't see any problem with this :)

cheers,
David
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: Relationship of ARIA to HTML 4 & 5

Aaron Leventhal-3
In reply to this post by Gez Lemon
I'll fix the article so that it doesn't just talk about div/span. Those are the
most common, but not the only elements that are used. Technically any rendered
element can be used.

There's no issue with clashes, in that ARIA is an override -- it trumps the
native markup. Does that answer the question or am I not understanding it?

- Aaron

_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: Relationship of ARIA to HTML 4 & 5

mozilla accessibility
In reply to this post by Aaron Leventhal-3
Aaron, this is excellent.

A couple small points:

1. Maybe a paragraph of background on what exactly name spaces are and how
they     relate to HTML. How does a namespace differ from a prefix?
You wrote:
>Ian Hixie has suggested using "aria-" as a prefix for ARIA attribute names
>used in text/html
>, which would circumvent the dependency on namespaces (and hacky
>initialization scripts). This is still under discussion.


2. Perhaps a bit more on what XBL is and how it might be easier to use (or
not) than aria?


This is a very clear description of Aria, its purpose, and why it is
necessary. I'm gunna circulate it to web accessibility folks at MIT.

Thanx Aaron.
-- Rich Caloggero, WGBH NCAM

----- Original Message -----
From: "Aaron Leventhal" <[hidden email]>
Newsgroups: mozilla.dev.accessibility
To: <[hidden email]>
Sent: Tuesday, September 04, 2007 11:50 AM
Subject: Relationship of ARIA to HTML 4 & 5


I would love to get feedback on the FAQ here:
http://developer.mozilla.org/en/docs/ARIA:_Accessible_Rich_Internet_Applications/Relationship_to_HTML_FAQ

It includes suggestions for easing the way ARIA can be used within HTML. It
also
explains the goals of ARIA in a way that addresses many of the concerns I've
heard from leaders in the WHATWG/HTML5 community.

- Aaron
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility

_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: Relationship of ARIA to HTML 4 & 5

Al Gilman
In reply to this post by Aaron Leventhal-3
At 1:38 PM -0400 6 09 2007, Aaron Leventhal wrote:
>I'll fix the article so that it doesn't just talk about div/span.
>Those are the
>most common, but not the only elements that are used. Technically any rendered
>element can be used.
>
>There's no issue with clashes, in that ARIA is an override -- it trumps the
>native markup. Does that answer the question or am I not understanding it?

I would want to moderate that explanation a bit.

In terms of author usage, we prefer that authors use HTML to the hilt.
I forget which widget it is, but there is at least one widget where DoJo
just uses HTML+CSS because it does the job.  No script, no ARIA.

Further, there are issues with clashes even if ARIA says "I rule."  It means
that ARIA-aware user agents and ARIA-unaware user agents will present
different user experiences in ways the author didn't expect.  This may
be a necessary growing pain, but it's still a pain.

So far as I understand, there are only a few places where ARIA markup
actually removes functionality from HTML markup:

<table role='presenatation'>

<any labelledby='wxyz' title='foo'>
<span role='header' id='wxyz'>bar</span>
</any>

.. and not a lot more.

I think that in answering this question, we need to start with "Of course,
we are for using HTML+CSS without script for those things that they can
do."

It's not just that we prefer ARIA semantics to be native in HTML5 markup.

We prefer the semantics native in HTML4, too; what ARIA supports
is very largely functionality that HTML4+CSS2.1 cannot deliver.

Al

>- Aaron
>
>_______________________________________________
>dev-accessibility mailing list
>[hidden email]
>https://lists.mozilla.org/listinfo/dev-accessibility

_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: Relationship of ARIA to HTML 4 & 5

Gez Lemon
In reply to this post by Aaron Leventhal-3
Hello,

Many thanks to everyone that answered my previous questions.

On Sep 6, 5:04 pm, David Bolter wrote:
> I'm not sure off hand what is allowable inside
> input tags.

The input element is empty, so nothing can be placed inside it. Many
of the roles defined by ARIA wouldn't be appropriate for an input
element, but it's just an example of an element that could be used in
certain circumstances, such as a control for a tri-state checkbox, the
thumb for a slider control, and so on.

> The other thing about input elements is that they
> can be difficult to style, although hopefully that
> won't always be the case.

Yes, that's true. Using <input type="checkbox" .../> would be
difficult to reuse for a tri-state checkbox, but an input type of
image doesn't have a default style in graphical user agents, and
instead uses the image specified by the src attribute to draw the
control. Other elements, such as li and button, are easily re-styled.
As you point out, other widgets can't be defined at all in HTML; in
this scenario, it makes sense to revert to semantically neutral
elements.

On Sep 6, 7:12 pm, Al Gilman wrote:
> It's not just that we prefer ARIA semantics to be
> native in HTML5 markup.
>
> We prefer the semantics native in HTML4, too; what
> ARIA supports is very largely functionality that
> HTML4+CSS2.1 cannot deliver.

That makes sense, but I was questioning whether HTML5 should support
properties natively from ARIA that HTML4 doesn't. The longdesc
attribute can be used to provide a URI for a detailed description of
complex images, but there isn't an equivalent attribute for other non-
text objects in HTML4; the describedby attribute from ARIA provides
that functionality. The labelledby property also provides a generic
means of providing a label for elements without having specific markup
constructs, such as the 'for' attribute with the label element, and
the 'headers' attribute to markup irregular heading cells in data
tables. Would it be a problem if HTML5 supported these attributes
natively, when HTML4 doesn't?

Thanks,

Gez

_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: Relationship of ARIA to HTML 4 & 5

Steve Lee-3
In reply to this post by mozilla accessibility
On 06/09/07, Rich Caloggero <[hidden email]> wrote:
> 1. Maybe a paragraph of background on what exactly name spaces are and how
> they     relate to HTML. How does a namespace differ from a prefix?

I once found James Clark's explanation a useful introduction to the
concepts though he does introduce his own syntax in order to explain.

http://www.jclark.com/xml/xmlns.htm

--
Steve Lee
--
Open Source Assistive Technology Software
PowerTalk - your presentations can speak for themselves
www.fullmeasure.co.uk
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: Relationship of ARIA to HTML 4 & 5

mozilla accessibility
In reply to this post by Aaron Leventhal-3
Jez wrote:
>Yes, that's true. Using <input type="checkbox" .../> would be
>difficult to reuse for a tri-state checkbox, but an input type of
>image doesn't have a default style in graphical user agents, and
>instead uses the image specified by the src attribute to draw the
>control. Other elements, such as li and button, are easily re-styled.

However, the screen reader will see input type=image as a button; how could
you get a tri-state checkbox (or any sort of specialized behavior) out of
this arrangement without specific ARIA roles and states and the proper MSAA
or other accessibility layer code behind it to tell the screen reader what's
really going on?

-- Rich

"Gez" <[hidden email]> wrote in message
news:[hidden email]...

> Hello,
>
> Many thanks to everyone that answered my previous questions.
>
> On Sep 6, 5:04 pm, David Bolter wrote:
>> I'm not sure off hand what is allowable inside
>> input tags.
>
> The input element is empty, so nothing can be placed inside it. Many
> of the roles defined by ARIA wouldn't be appropriate for an input
> element, but it's just an example of an element that could be used in
> certain circumstances, such as a control for a tri-state checkbox, the
> thumb for a slider control, and so on.
>
>> The other thing about input elements is that they
>> can be difficult to style, although hopefully that
>> won't always be the case.
>
> Yes, that's true. Using <input type="checkbox" .../> would be
> difficult to reuse for a tri-state checkbox, but an input type of
> image doesn't have a default style in graphical user agents, and
> instead uses the image specified by the src attribute to draw the
> control. Other elements, such as li and button, are easily re-styled.
> As you point out, other widgets can't be defined at all in HTML; in
> this scenario, it makes sense to revert to semantically neutral
> elements.
>
> On Sep 6, 7:12 pm, Al Gilman wrote:
>> It's not just that we prefer ARIA semantics to be
>> native in HTML5 markup.
>>
>> We prefer the semantics native in HTML4, too; what
>> ARIA supports is very largely functionality that
>> HTML4+CSS2.1 cannot deliver.
>
> That makes sense, but I was questioning whether HTML5 should support
> properties natively from ARIA that HTML4 doesn't. The longdesc
> attribute can be used to provide a URI for a detailed description of
> complex images, but there isn't an equivalent attribute for other non-
> text objects in HTML4; the describedby attribute from ARIA provides
> that functionality. The labelledby property also provides a generic
> means of providing a label for elements without having specific markup
> constructs, such as the 'for' attribute with the label element, and
> the 'headers' attribute to markup irregular heading cells in data
> tables. Would it be a problem if HTML5 supported these attributes
> natively, when HTML4 doesn't?
>
> Thanks,
>
> Gez
>
> _______________________________________________
> dev-accessibility mailing list
>     > https://lists.mozilla.org/listinfo/dev-accessibility
>

_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: Relationship of ARIA to HTML 4 & 5

Victor Tsaran
In reply to this post by Aaron Leventhal-3
Hi Aaron,
Sorry for coming in so late on this discussion. Just wanted to tell you
that it is an excellent FAQ not only for ARIA/HTML5-related issues, but
also as a quick-to-look-at intor to ARIA itself.
I will definitely be circling this around the company.,
Thanks a lot for all you do.
Victor

Aaron Leventhal wrote:
> I would love to get feedback on the FAQ here:
> http://developer.mozilla.org/en/docs/ARIA:_Accessible_Rich_Internet_Applications/Relationship_to_HTML_FAQ 
>
>
> It includes suggestions for easing the way ARIA can be used within HTML.
> It also explains the goals of ARIA in a way that addresses many of the
> concerns I've heard from leaders in the WHATWG/HTML5 community.
>
> - Aaron
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: Relationship of ARIA to HTML 4 & 5

Gez Lemon
In reply to this post by Aaron Leventhal-3
Hi Rich,

Rich Caloggero wrote:
> However, the screen reader will see input type=image as a button; how could
> you get a tri-state checkbox (or any sort of specialized behavior) out of
> this arrangement without specific ARIA roles and states and the proper MSAA
> or other accessibility layer code behind it to tell the screen reader what's
> really going on?

I wasn't suggesting not using ARIA role and state information. I was
asking whether it would be okay to use input type="image" and add ARIA
role and state information to that element in certain situations.

Gez

_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility