Firefox 14 is in aurora channel and 5 June it's becoming a beta. We did a bunch of improvements and changes in accessibility support.
ARIA
ARIA role="note" is mapped into IA2_ROLE_NOTE role. ARIA role="form" is mapped to IA2_ROLE_FORM / ATK_ROLE_FORM role. Also xml-roles:note and xml-roles:form object attributes are exposed respectively.
ARIA aria-describedby attribute used on HTML image element and pointing to HTML a element makes the image accessible to expose showlongdesc action. This action opens an URL provided by @href attribute on HTML a element in a new window. Take a look at example:
<a id="a" href="http://www.mozilla.org">a link</a>
<img aria-describedby="a" src="mozlizzard.png">
HTML
HTML section element accessible has IA2_ROLE_SECTION / ATK_ROLE_SECTION role and exposes xml-roles:region object attribute what makes it similar to ARIA role="region".
HTML sup and sub elements are exposed as text-position text attribute. Say you have:
ARIA
ARIA role="note" is mapped into IA2_ROLE_NOTE role. ARIA role="form" is mapped to IA2_ROLE_FORM / ATK_ROLE_FORM role. Also xml-roles:note and xml-roles:form object attributes are exposed respectively.
ARIA aria-describedby attribute used on HTML image element and pointing to HTML a element makes the image accessible to expose showlongdesc action. This action opens an URL provided by @href attribute on HTML a element in a new window. Take a look at example:
<a id="a" href="http://www.mozilla.org">a link</a>
<img aria-describedby="a" src="mozlizzard.png">
HTML
HTML section element accessible has IA2_ROLE_SECTION / ATK_ROLE_SECTION role and exposes xml-roles:region object attribute what makes it similar to ARIA role="region".
HTML sup and sub elements are exposed as text-position text attribute. Say you have:
<div>x<sub>i</sub><sup>2</sup></div>
which looks like xi2. In this case you get default text attributes at range (0, 1) for HTML div accessible, text-position:sub at (1, 2) range and text-position:super at (2, 3) range.HTML button having aria-pressed="true" attribute has IA2_ROLE_TOGGLE_BUTTON / ATK_ROLE_TOGGLE_BUTTON role.
States
Editable text fields always expose IA2_STATE_EDITABLE / ATK_STATE_EDITABLE state not depending on whether text field is readonly or disabled.
Undertemined HTML progress element and ARIA role="progressbar" expose STATE_SYSTEM_INDETERMINATE / ATK_STATE_INDETERMINATE state. Here are examples of indeterminate progressmeters:
<progress></progress>
<div aria="progressbar"></div>
Correctness and consistence
Image map accessible tree is properly updated when image map is changed. So whenever you add or remove HTML area element to/from related HTML map or change @name attribute on HTML map the image map accessible picks up the changes.
XUL listbox accessible tree is updated correctly when list items are inserted or removed. The issue affected on Thuderbird UI and Firefox profile manager dialog. I'm happy that finally this problem was fixed.
event-from-input:true object attribute is exposed on event target accessible if it's a child of the focused editable area. In general this is not correct but it's a good approximation to desired behavior. So for example, if value of the focused editable area is changed by script then we still report event-from-input:true and that's wrong of course.
We report the value of tag object attribute in lowercase always. We do that for consistence with other markup languages like XUL, XHTML or SVG. Also tag object attribute is not exposed when it's not applicable, for example, it's not used anymore for bullet accessible of list item. These changes shouldn't introduce problems for ATs but you should be aware of them just in case.
In MSAA/IAccessible2 layer when accessible is defunct then any method called on it returns CO_E_OBJECTNOTCONNECTED now.
XPCOM interfaces
nsIAccessible::innerHTML attribute was removed. It dupes the HTML element interface capabilities so it doesn't make sense to maintain accessibility version of it.
XUL/XBL
ARIA relation attributes used on XBL bound element are allowed to point to XBL anonymous content. You can do:
<bindings xmlns="http://www.mozilla.org/xbl">
<binding id="custombutton">
<content aria-labelledby="button.label" role="button">
<label xmlns="http://www.w3.org/1999/xhtml" anonid="button.label">
anon label
</label>
</content>
</binding>
</bindings>
<div id="button" style="-moz-binding: url('#custombutton');"></div>
In this case the button accessible picks up the name from anonymous label element.
My personal feeling is that this change for aria-describedby is a band-aid for longdesc. There is nothing here that would give mainstream developers motivation to create a second page and use it. Normally I am supportive of everything the Mozilla accessibility team does but not this one.
ReplyDeleteIn implementation we followed the discussion at http://lists.w3.org/Archives/Public/public-html/2011Apr/0515.html. Personally I don't have strong opinion whether aria-describedby should provide longdesc semantics or not.
DeleteI'm not sure what's the best way to proceed this case. What would you recommend?
Btw, Steve has a use case for this behavior.
DeleteI have had discussions on this with David Bolter, Dominic Mazzoni, and Silvia Pfeifer. What we came to agreement on was that we should have an attribute that takes a URL. We were designing on aria-describedat. When provided, the user agent would provide a visual indicator of its choice. I suggested a an icon with the letter i at the upper right corner of the the element being rendered to indicate that more information was available. We also agreed that author ought to be able to redefine the look of the indicator using a style sheet. Upon either a key command, gesture, etc. (depends on the browser) the user agent would either bring up a menu of choices to choose from (the context menu) that would include a menu item that said "more information" or automatically generate a new window with the content. Once the new window was activated the user agent needs to provide a vehicle (say the escape key) to bring the user back to the place in the original document where they left off.
ReplyDeleteThis provides real mainstream value add to all users without the need to provide a separate anchor element. Point of sale systems, informational kiosks (museum or library), would be able to make use of this.
It should be up to the browser to define how the availability of additional information gets rendered, how the information is accessed and how the user returns back to the original document. This is very important. I think the thoughts were that the ARIA spec. people were trying to dictate this functionality in the browser and we are not. In fact, doing so would not make sense.
Heya i’m for the first time here. I found this board and I find It truly useful & it helped me out much. I hope to give something back and aid others like you aided me.
ReplyDeletemachine learning consulting companies