ARIA support is broken in the last several nightly builds of FF3?

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

ARIA support is broken in the last several nightly builds of FF3?

Victor Tsaran
Hi,
I have noticed that in the last several nightly builds of FF3
ARIA-marked tab controls or buttons are no longer recognized as such.
Anyone else noticed this behavior?
Victor
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: ARIA support is broken in the last several nightly builds of FF3?

Aaron Leventhal-3
Victor, please file a bug with a testcase: bugzilla.mozilla.org. The
data of the regression would be helpful.

- Aaron

Victor Tsaran wrote:
> Hi,
> I have noticed that in the last several nightly builds of FF3
> ARIA-marked tab controls or buttons are no longer recognized as such.
> Anyone else noticed this behavior?
> Victor
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: ARIA support is broken in the last several nightly builds of FF3?

Aaron Leventhal-3
Bug filed:
https://bugzilla.mozilla.org/show_bug.cgi?id=401107

- Aron

Aaron Leventhal wrote:

> Victor, please file a bug with a testcase: bugzilla.mozilla.org. The
> data of the regression would be helpful.
>
> - Aaron
>
> Victor Tsaran wrote:
>> Hi,
>> I have noticed that in the last several nightly builds of FF3
>> ARIA-marked tab controls or buttons are no longer recognized as such.
>> Anyone else noticed this behavior?
>> Victor
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: ARIA support is broken in the last several nightly builds of FF3?

Aaron Leventhal-3
In reply to this post by Victor Tsaran
Victor,

This is intentional behavior. We sent out a message to related
newsgroups and known ARIA implementors that we're changing how we
process ARIA markup and that developers would need to change their code.

It's the result of our fix for
https://bugzilla.mozilla.org/show_bug.cgi?id=397100

Basicall, we're working to process markup is stated here:
http://simon.html5.org/specs/aria-proposal

This means we won't allow the role attribute to be namespaced in HTML
anymore. It won't be recognized. It will also still work in Firefox 2 if
you just use |role| in no namespace on an HTML element.

The problem is lines in HTML such as:
setAttrNS(elmAccessible, NS_XHTML2, "role", "wairole:" + sClass);

You can now just use the role attribute directly on the element. Or, if
you still want to set the role attribute in JS, then it can just do:
element.setAttribute("role", "wairole:" + sClass);

Just don't put the role attribute in a namespace in HTML anymore.

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

Re: ARIA support is broken in the last several nightly builds of FF3?

earl johnson
Hi Aaron;

Is this fix just for Firefox [FF] 3 or is it being backported to
FF1 &/or FF2?

Earl

Aaron Leventhal wrote:

> Victor,
>
> This is intentional behavior. We sent out a message to related
> newsgroups and known ARIA implementors that we're changing how we
> process ARIA markup and that developers would need to change their code.
>
> It's the result of our fix for
> https://bugzilla.mozilla.org/show_bug.cgi?id=397100
>
> Basicall, we're working to process markup is stated here:
> http://simon.html5.org/specs/aria-proposal
>
> This means we won't allow the role attribute to be namespaced in HTML
> anymore. It won't be recognized. It will also still work in Firefox 2 if
> you just use |role| in no namespace on an HTML element.
>
> The problem is lines in HTML such as:
> setAttrNS(elmAccessible, NS_XHTML2, "role", "wairole:" + sClass);
>
> You can now just use the role attribute directly on the element. Or, if
> you still want to set the role attribute in JS, then it can just do:
> element.setAttribute("role", "wairole:" + sClass);
>
> Just don't put the role attribute in a namespace in HTML anymore.
>
> - 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: ARIA support is broken in the last several nightly builds of FF3?

Aaron Leventhal-3
The role attribute already worked in no namespace Firefox 2. The
difference is Firefox 3 is more restrictive about that, so we're not
planning to backport the restriction that role cannot be in a namespace
for HTML elements.

As far as allowing ARIA attributes to be hyphenated, and not in a
namespace, I'm not currently planning to backport that.

- Aaron

Earl Johnson wrote:

> Hi Aaron;
>
> Is this fix just for Firefox [FF] 3 or is it being backported to FF1
> &/or FF2?
>
> Earl
>
> Aaron Leventhal wrote:
>
>> Victor,
>>
>> This is intentional behavior. We sent out a message to related
>> newsgroups and known ARIA implementors that we're changing how we
>> process ARIA markup and that developers would need to change their code.
>>
>> It's the result of our fix for
>> https://bugzilla.mozilla.org/show_bug.cgi?id=397100
>>
>> Basicall, we're working to process markup is stated here:
>> http://simon.html5.org/specs/aria-proposal
>>
>> This means we won't allow the role attribute to be namespaced in HTML
>> anymore. It won't be recognized. It will also still work in Firefox 2
>> if you just use |role| in no namespace on an HTML element.
>>
>> The problem is lines in HTML such as:
>> setAttrNS(elmAccessible, NS_XHTML2, "role", "wairole:" + sClass);
>>
>> You can now just use the role attribute directly on the element. Or,
>> if you still want to set the role attribute in JS, then it can just do:
>> element.setAttribute("role", "wairole:" + sClass);
>>
>> Just don't put the role attribute in a namespace in HTML anymore.
>>
>> - 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: ARIA support is broken in the last several nightly builds of FF3?

Jon Gunderson
In reply to this post by Victor Tsaran
Aaron,

Is this change in implementation for content delivered for both "text/html" and "application/xhtml+html"?

Jon


---- Original message ----

>Date: Thu, 25 Oct 2007 14:01:36 -0400
>From: Aaron Leventhal <[hidden email]>  
>Subject: Re: ARIA support is broken in the last several nightly builds of FF3?  
>To: [hidden email]
>
>Victor,
>
>This is intentional behavior. We sent out a message to related
>newsgroups and known ARIA implementors that we're changing how we
>process ARIA markup and that developers would need to change their code.
>
>It's the result of our fix for
>https://bugzilla.mozilla.org/show_bug.cgi?id=397100
>
>Basicall, we're working to process markup is stated here:
>http://simon.html5.org/specs/aria-proposal
>
>This means we won't allow the role attribute to be namespaced in HTML
>anymore. It won't be recognized. It will also still work in Firefox 2 if
>you just use |role| in no namespace on an HTML element.
>
>The problem is lines in HTML such as:
>setAttrNS(elmAccessible, NS_XHTML2, "role", "wairole:" + sClass);
>
>You can now just use the role attribute directly on the element. Or, if
>you still want to set the role attribute in JS, then it can just do:
>element.setAttribute("role", "wairole:" + sClass);
>
>Just don't put the role attribute in a namespace in HTML anymore.
>
>- Aaron
>_______________________________________________
>dev-accessibility mailing list
>[hidden email]
>https://lists.mozilla.org/listinfo/dev-accessibility
Jon Gunderson, Ph.D.
Coordinator of Assistive Communication and Information Technology (DRES)

WWW: http://www.cita.uiuc.edu/
WWW: https://netfiles.uiuc.edu/jongund/www/


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

Re: ARIA support is broken in the last several nightly builds of FF3?

Aaron Leventhal-3
In reply to this post by Victor Tsaran
Jon Gunderson wrote:
> Is this change in implementation for content delivered for both "text/html" and "application/xhtml+html"?

Yes, for both.

- Aaron


>
> Jon
>
>
> ---- Original message ----
>> Date: Thu, 25 Oct 2007 14:01:36 -0400
>> From: Aaron Leventhal <[hidden email]>  
>> Subject: Re: ARIA support is broken in the last several nightly builds of FF3?  
>> To: [hidden email]
>>
>> Victor,
>>
>> This is intentional behavior. We sent out a message to related
>> newsgroups and known ARIA implementors that we're changing how we
>> process ARIA markup and that developers would need to change their code.
>>
>> It's the result of our fix for
>> https://bugzilla.mozilla.org/show_bug.cgi?id=397100
>>
>> Basicall, we're working to process markup is stated here:
>> http://simon.html5.org/specs/aria-proposal
>>
>> This means we won't allow the role attribute to be namespaced in HTML
>> anymore. It won't be recognized. It will also still work in Firefox 2 if
>> you just use |role| in no namespace on an HTML element.
>>
>> The problem is lines in HTML such as:
>> setAttrNS(elmAccessible, NS_XHTML2, "role", "wairole:" + sClass);
>>
>> You can now just use the role attribute directly on the element. Or, if
>> you still want to set the role attribute in JS, then it can just do:
>> element.setAttribute("role", "wairole:" + sClass);
>>
>> Just don't put the role attribute in a namespace in HTML anymore.
>>
>> - Aaron
>> _______________________________________________
>> dev-accessibility mailing list
>> [hidden email]
>> https://lists.mozilla.org/listinfo/dev-accessibility
> Jon Gunderson, Ph.D.
> Coordinator of Assistive Communication and Information Technology (DRES)
>
> WWW: http://www.cita.uiuc.edu/
> WWW: https://netfiles.uiuc.edu/jongund/www/
>
>
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: ARIA support is broken in the last several nightly builds of FF3?

Aaron Leventhal-3
In reply to this post by Victor Tsaran
I should add that it hasn't been necessary to put the role attribute in
a namespace application/xhtml+html since at lest Firefox 2, so it would
surprise me if anyone needed to change content there.

- Aaron

Aaron Leventhal wrote:

> Jon Gunderson wrote:
>> Is this change in implementation for content delivered for both
>> "text/html" and "application/xhtml+html"?
>
> Yes, for both.
>
> - Aaron
>
>
>>
>> Jon
>>
>>
>> ---- Original message ----
>>> Date: Thu, 25 Oct 2007 14:01:36 -0400
>>> From: Aaron Leventhal <[hidden email]>  Subject: Re: ARIA
>>> support is broken in the last several nightly builds of FF3?  To:
>>> [hidden email]
>>>
>>> Victor,
>>>
>>> This is intentional behavior. We sent out a message to related
>>> newsgroups and known ARIA implementors that we're changing how we
>>> process ARIA markup and that developers would need to change their code.
>>>
>>> It's the result of our fix for
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=397100
>>>
>>> Basicall, we're working to process markup is stated here:
>>> http://simon.html5.org/specs/aria-proposal
>>>
>>> This means we won't allow the role attribute to be namespaced in HTML
>>> anymore. It won't be recognized. It will also still work in Firefox 2
>>> if you just use |role| in no namespace on an HTML element.
>>>
>>> The problem is lines in HTML such as:
>>> setAttrNS(elmAccessible, NS_XHTML2, "role", "wairole:" + sClass);
>>>
>>> You can now just use the role attribute directly on the element. Or,
>>> if you still want to set the role attribute in JS, then it can just do:
>>> element.setAttribute("role", "wairole:" + sClass);
>>>
>>> Just don't put the role attribute in a namespace in HTML anymore.
>>>
>>> - Aaron
>>> _______________________________________________
>>> dev-accessibility mailing list
>>> [hidden email]
>>> https://lists.mozilla.org/listinfo/dev-accessibility
>> Jon Gunderson, Ph.D.
>> Coordinator of Assistive Communication and Information Technology (DRES)
>>
>> WWW: http://www.cita.uiuc.edu/
>> WWW: https://netfiles.uiuc.edu/jongund/www/
>>
>>
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: ARIA support is broken in the last several nightly builds of FF3?

Hans Hillen-2
In reply to this post by Victor Tsaran
Hi Aaron,

I've noticed that when I switch to this non-namespaced approach my table elements that have roles applied to them now
have a MSAA description of 'Description: layout table: Has role attribute, and role is table' in the FF3 nightly. This
is also being announced by the screen readers. Some example where this is happening are my tab and button controls
(unfortunately Yahoo Mail relies heavily on Layout tables), but this occurs even in situations where the use of a table
is perfectly legit, for example a table marked up as a grid.

Another thing I noticed is that in FF2 and ff3 a lot of the ARIA roles are either exposed erratically or not at all when
using this approach, even though they worked fine with the namespaces. For example: my tab controls used to show up in
MSAA as a role of 'page tab' and a name matching whatever the tab's title was. Now it mostly has an empty name value and
a role of 'table'(as I said, the tabs are created trough tables).

I guess part of this has to do with the complexity of Yahoo mail, but I was wondering if there are any known additional
constraints for using the non-namespaced approach: anything that would cause the browser to stop correctly exposing the
role info? SHould I file this as a bug? Also, I am interested to know whether other people trying this approach have
experienced similar effects.

Regards,

Hans



Aaron Leventhal wrote:

> I should add that it hasn't been necessary to put the role attribute in
> a namespace application/xhtml+html since at lest Firefox 2, so it would
> surprise me if anyone needed to change content there.
>
> - Aaron
>
> Aaron Leventhal wrote:
>> Jon Gunderson wrote:
>>> Is this change in implementation for content delivered for both
>>> "text/html" and "application/xhtml+html"?
>>
>> Yes, for both.
>>
>> - Aaron
>>
>>
>>>
>>> Jon
>>>
>>>
>>> ---- Original message ----
>>>> Date: Thu, 25 Oct 2007 14:01:36 -0400
>>>> From: Aaron Leventhal <[hidden email]>  Subject: Re:
>>>> ARIA support is broken in the last several nightly builds of FF3?  
>>>> To: [hidden email]
>>>>
>>>> Victor,
>>>>
>>>> This is intentional behavior. We sent out a message to related
>>>> newsgroups and known ARIA implementors that we're changing how we
>>>> process ARIA markup and that developers would need to change their
>>>> code.
>>>>
>>>> It's the result of our fix for
>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=397100
>>>>
>>>> Basicall, we're working to process markup is stated here:
>>>> http://simon.html5.org/specs/aria-proposal
>>>>
>>>> This means we won't allow the role attribute to be namespaced in
>>>> HTML anymore. It won't be recognized. It will also still work in
>>>> Firefox 2 if you just use |role| in no namespace on an HTML element.
>>>>
>>>> The problem is lines in HTML such as:
>>>> setAttrNS(elmAccessible, NS_XHTML2, "role", "wairole:" + sClass);
>>>>
>>>> You can now just use the role attribute directly on the element. Or,
>>>> if you still want to set the role attribute in JS, then it can just do:
>>>> element.setAttribute("role", "wairole:" + sClass);
>>>>
>>>> Just don't put the role attribute in a namespace in HTML anymore.
>>>>
>>>> - Aaron
>>>> _______________________________________________
>>>> dev-accessibility mailing list
>>>> [hidden email]
>>>> https://lists.mozilla.org/listinfo/dev-accessibility
>>> Jon Gunderson, Ph.D.
>>> Coordinator of Assistive Communication and Information Technology (DRES)
>>>
>>> WWW: http://www.cita.uiuc.edu/
>>> WWW: https://netfiles.uiuc.edu/jongund/www/
>>>
>>>
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: ARIA support is broken in the last several nightly builds of FF3?

Aaron Leventhal-3
Hans,

The thing about the tables must be a bug -- please file it in
bugzilla.mozilla.org.

As far as the other issue, the new approach will only work in Firefox 2
if you put "wairole:" as the prefix to the role value. Could that be the
issue? Otherwise I don't know what would make it erratic. You'll have to
supply a testcase that doesn't work, and attach it to a bug.

We haven't heard anything about either of these bugs, so please file
them as soon as possible.

BTW, are you building your own Firefox or using nightly builds from ftp?

- Aaron



Hans Hillen wrote:

> Hi Aaron,
>
> I've noticed that when I switch to this non-namespaced approach my table
> elements that have roles applied to them now have a MSAA description of
> 'Description: layout table: Has role attribute, and role is table' in
> the FF3 nightly. This is also being announced by the screen readers.
> Some example where this is happening are my tab and button controls
> (unfortunately Yahoo Mail relies heavily on Layout tables), but this
> occurs even in situations where the use of a table is perfectly legit,
> for example a table marked up as a grid.
>
> Another thing I noticed is that in FF2 and ff3 a lot of the ARIA roles
> are either exposed erratically or not at all when using this approach,
> even though they worked fine with the namespaces. For example: my tab
> controls used to show up in MSAA as a role of 'page tab' and a name
> matching whatever the tab's title was. Now it mostly has an empty name
> value and a role of 'table'(as I said, the tabs are created trough tables).
>
> I guess part of this has to do with the complexity of Yahoo mail, but I
> was wondering if there are any known additional constraints for using
> the non-namespaced approach: anything that would cause the browser to
> stop correctly exposing the role info? SHould I file this as a bug?
> Also, I am interested to know whether other people trying this approach
> have experienced similar effects.
>
> Regards,
>
> Hans
>
>
>
> Aaron Leventhal wrote:
>> I should add that it hasn't been necessary to put the role attribute
>> in a namespace application/xhtml+html since at lest Firefox 2, so it
>> would surprise me if anyone needed to change content there.
>>
>> - Aaron
>>
>> Aaron Leventhal wrote:
>>> Jon Gunderson wrote:
>>>> Is this change in implementation for content delivered for both
>>>> "text/html" and "application/xhtml+html"?
>>>
>>> Yes, for both.
>>>
>>> - Aaron
>>>
>>>
>>>>
>>>> Jon
>>>>
>>>>
>>>> ---- Original message ----
>>>>> Date: Thu, 25 Oct 2007 14:01:36 -0400
>>>>> From: Aaron Leventhal <[hidden email]>  Subject: Re:
>>>>> ARIA support is broken in the last several nightly builds of FF3?  
>>>>> To: [hidden email]
>>>>>
>>>>> Victor,
>>>>>
>>>>> This is intentional behavior. We sent out a message to related
>>>>> newsgroups and known ARIA implementors that we're changing how we
>>>>> process ARIA markup and that developers would need to change their
>>>>> code.
>>>>>
>>>>> It's the result of our fix for
>>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=397100
>>>>>
>>>>> Basicall, we're working to process markup is stated here:
>>>>> http://simon.html5.org/specs/aria-proposal
>>>>>
>>>>> This means we won't allow the role attribute to be namespaced in
>>>>> HTML anymore. It won't be recognized. It will also still work in
>>>>> Firefox 2 if you just use |role| in no namespace on an HTML element.
>>>>>
>>>>> The problem is lines in HTML such as:
>>>>> setAttrNS(elmAccessible, NS_XHTML2, "role", "wairole:" + sClass);
>>>>>
>>>>> You can now just use the role attribute directly on the element.
>>>>> Or, if you still want to set the role attribute in JS, then it can
>>>>> just do:
>>>>> element.setAttribute("role", "wairole:" + sClass);
>>>>>
>>>>> Just don't put the role attribute in a namespace in HTML anymore.
>>>>>
>>>>> - Aaron
>>>>> _______________________________________________
>>>>> dev-accessibility mailing list
>>>>> [hidden email]
>>>>> https://lists.mozilla.org/listinfo/dev-accessibility
>>>> Jon Gunderson, Ph.D.
>>>> Coordinator of Assistive Communication and Information Technology
>>>> (DRES)
>>>>
>>>> WWW: http://www.cita.uiuc.edu/
>>>> WWW: https://netfiles.uiuc.edu/jongund/www/
>>>>
>>>>
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: ARIA support is broken in the last several nightly builds of FF3?

Aaron Leventhal-3
In reply to this post by Hans Hillen-2
Actually I've already filed a bug for the extra decsriptions on table.
That was for debugging our heuristic for determining whether a table is
layout or data, and we can remove that now.

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

Re: ARIA support is broken in the last several nightly builds of FF3?

Hans Hillen-2
In reply to this post by Aaron Leventhal-3
Alright, will file it.

Yes, I know about the wairole constraint. I realize better testcases are needed , so I'll try to isolate the issue. At
this point I can however say that as far as the DOM is concerned the roles are successfully applied. For example, in
firebug they show up correctly. I've been using the nightly FTP builds. Should I be building myself instead?

Hans



Aaron Leventhal wrote:

> Hans,
>
> The thing about the tables must be a bug -- please file it in
> bugzilla.mozilla.org.
>
> As far as the other issue, the new approach will only work in Firefox 2
> if you put "wairole:" as the prefix to the role value. Could that be the
> issue? Otherwise I don't know what would make it erratic. You'll have to
> supply a testcase that doesn't work, and attach it to a bug.
>
> We haven't heard anything about either of these bugs, so please file
> them as soon as possible.
>
> BTW, are you building your own Firefox or using nightly builds from ftp?
>
> - Aaron
>
>
>
> Hans Hillen wrote:
>> Hi Aaron,
>>
>> I've noticed that when I switch to this non-namespaced approach my
>> table elements that have roles applied to them now have a MSAA
>> description of 'Description: layout table: Has role attribute, and
>> role is table' in the FF3 nightly. This is also being announced by the
>> screen readers. Some example where this is happening are my tab and
>> button controls (unfortunately Yahoo Mail relies heavily on Layout
>> tables), but this occurs even in situations where the use of a table
>> is perfectly legit, for example a table marked up as a grid.
>>
>> Another thing I noticed is that in FF2 and ff3 a lot of the ARIA roles
>> are either exposed erratically or not at all when using this approach,
>> even though they worked fine with the namespaces. For example: my tab
>> controls used to show up in MSAA as a role of 'page tab' and a name
>> matching whatever the tab's title was. Now it mostly has an empty name
>> value and a role of 'table'(as I said, the tabs are created trough
>> tables).
>>
>> I guess part of this has to do with the complexity of Yahoo mail, but
>> I was wondering if there are any known additional constraints for
>> using the non-namespaced approach: anything that would cause the
>> browser to stop correctly exposing the role info? SHould I file this
>> as a bug? Also, I am interested to know whether other people trying
>> this approach have experienced similar effects.
>>
>> Regards,
>>
>> Hans
>>
>>
>>
>> Aaron Leventhal wrote:
>>> I should add that it hasn't been necessary to put the role attribute
>>> in a namespace application/xhtml+html since at lest Firefox 2, so it
>>> would surprise me if anyone needed to change content there.
>>>
>>> - Aaron
>>>
>>> Aaron Leventhal wrote:
>>>> Jon Gunderson wrote:
>>>>> Is this change in implementation for content delivered for both
>>>>> "text/html" and "application/xhtml+html"?
>>>>
>>>> Yes, for both.
>>>>
>>>> - Aaron
>>>>
>>>>
>>>>>
>>>>> Jon
>>>>>
>>>>>
>>>>> ---- Original message ----
>>>>>> Date: Thu, 25 Oct 2007 14:01:36 -0400
>>>>>> From: Aaron Leventhal <[hidden email]>  Subject: Re:
>>>>>> ARIA support is broken in the last several nightly builds of FF3?  
>>>>>> To: [hidden email]
>>>>>>
>>>>>> Victor,
>>>>>>
>>>>>> This is intentional behavior. We sent out a message to related
>>>>>> newsgroups and known ARIA implementors that we're changing how we
>>>>>> process ARIA markup and that developers would need to change their
>>>>>> code.
>>>>>>
>>>>>> It's the result of our fix for
>>>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=397100
>>>>>>
>>>>>> Basicall, we're working to process markup is stated here:
>>>>>> http://simon.html5.org/specs/aria-proposal
>>>>>>
>>>>>> This means we won't allow the role attribute to be namespaced in
>>>>>> HTML anymore. It won't be recognized. It will also still work in
>>>>>> Firefox 2 if you just use |role| in no namespace on an HTML element.
>>>>>>
>>>>>> The problem is lines in HTML such as:
>>>>>> setAttrNS(elmAccessible, NS_XHTML2, "role", "wairole:" + sClass);
>>>>>>
>>>>>> You can now just use the role attribute directly on the element.
>>>>>> Or, if you still want to set the role attribute in JS, then it can
>>>>>> just do:
>>>>>> element.setAttribute("role", "wairole:" + sClass);
>>>>>>
>>>>>> Just don't put the role attribute in a namespace in HTML anymore.
>>>>>>
>>>>>> - Aaron
>>>>>> _______________________________________________
>>>>>> dev-accessibility mailing list
>>>>>> [hidden email]
>>>>>> https://lists.mozilla.org/listinfo/dev-accessibility
>>>>> Jon Gunderson, Ph.D.
>>>>> Coordinator of Assistive Communication and Information Technology
>>>>> (DRES)
>>>>>
>>>>> WWW: http://www.cita.uiuc.edu/
>>>>> WWW: https://netfiles.uiuc.edu/jongund/www/
>>>>>
>>>>>
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: ARIA support is broken in the last several nightly builds of FF3?

Aaron Leventhal-3
Hi Hans -- no, don't build your own. Use the nightlies.

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