Known IE8 beta2 ARIA bugs

From CodeTalks

IE top ARIA bugs

Issue # Markup Description Testcase(s) Severity
high/med/low
1 role="alert" Alerts not spoken, because MSAA event EVENT_SYSTEM_ALERT is not fired for alert object when it appears http://test.cita.uiuc.edu/aria/alert/alert1.php
type the number to guess and press ENTER. 		High
2 role="treeitem" Tree view position and state changes (closed/opened) not reported in screen readers. Also, too many tree items read as user navigates. In general, seems flaky.

UIUC example: http://codetalks.org/source/widgets/tree/tree3.html Older Mozilla.org example: http://codetalks.org/source/widgets/tree/tree.html

High
3 role="tooltip" Two problems:
  1. EVENT_SHOW is being fired twice -- it should only be fired once. The first time is for an invisible tooltip. A page may insert a node and then make it visible, so the browser needs to do some event coalescing to avoid redundant events.
  2. The tooltip has the FOCUSABLE state and it shouldn't
http://test.cita.uiuc.edu/aria/tooltip/tooltip1.php Low (probably causes some ATs to speak tooltip twice)
4 role="button" aria-pressed="false"/"true" aria-pressed on a button doesn't cause it to be announced as a toggle button http://test.cita.uiuc.edu/aria/toolbar/toolbar2.php
navigate the toolbar and try to press any of the buttons. 		Med
5 role="button" aria-haspopup="true" aria-haspopup on a button doesn't cause it to be announced as a menu button http://developer.yahoo.com/yui/examples/button/button-ariaplugin_clean.html
"reply" and "move to" are buttons with context menus. It's on odd case, but like aria-pressed, the aria-haspopup attribute can affect the role when it's on a button. The MSAA role needs to be ROLE_SYSTEM_BUTTONMENU. This should happen even if this property is used on an HTML button (as opposed to an ARIA button). 		Low/Medium
6 role="presentation" role="presentation" does no remove objects from the accessible hierarchy. http://codetalks.org/source/simple/presentation.html High
7 <table role="*" /> Any time a role other than "grid" is used on a table, it should cause the inner table structure not be be exposed, this allowing the <table> to be treated by screen reader as either:
  1. only for layout in the role="presentation" or role=landmark-role case
  2. a widget in the role=widget-role case, e.g. <table role="menu">
http://codetalks.org/source/simple/tables-with-roles.html Medium
8 role="img" Tiled images using role="img" create many images in the virtual buffer of screen readers. The img role has "Children Presentational: true" and the children should not be exposed. http://codetalks.org/source/widgets/img/tiled.html Low
9 aria-activedescendant Does activedescendant work? (I'm concerned because it was misspelled in their docs, with an "e" at the end). Does it affect the FOCUSABLE state? I can't even get our activedescendant listbox testcase to work. http://codetalks.org/source/widgets/listbox/listbox.html High
10 aria-selected="false"/"true" aria-selected should set selectable state, if present and not "" or "undefined" http://codetalks.org/source/simple/selected.html High
11 role="menubar" etc. ARIA menubars don't work, because the following events are never fired: EVENT_SYSTEM_MENU_START/MENUPOPUP_START/MENUPOPUP_END/MENU_END. The implementor's guide provides an algorithm for firing these events.

http://developer.yahoo.com/yui/examples/menu/menuwaiaria_source.html http://codetalks.org/source/widgets/grid/grid.html

High
12 element.style.visibility="collapse"; element.insertNode; element.removeNode; etc. Live changes: no show/hide events unless for visibility: collapse changes and DOM node insertions or removals (they are being fired for display:none toggles and visibility: hidden toggles). http://codetalks.org/source/live/framechange.html High
13 element.style.display = foo; element.style.visibility="collapse"; element.insertNode; element.removeNode; etc. Missing event-from-user-input object attribute necessary for automatic determination of what to do with changes caused by the user.

This object attribute is not in the spec, but is really useful for helping screen readers guess at the right thing to do for the majority of dynamic pages that do not use live region markup. It is defined in the implementor's guide section on live changes.

http://codetalks.org/source/live/framechange.html Medium
14 aria-live, aria-relevant, aria-atomic along with

element.style.display = foo; element.style.visibility="collapse"; element.insertNode; element.removeNode; etc.

Missing container-foo object attributes necessary for processing.

The live region object attributes are defined in the implementor's guide section on live changes.

Anything from http://codetalks.org/source/live/ where aria properties are used (most of the testcases there). High
15 aria-labelledby Accessible name should be "slider control 1" or "slider control 2", not the same as the value. Also affects dojo dialogs which uses labelledby to indicate the dialog title http://test.cita.uiuc.edu/aria/slider

http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/tests/test_Dialog.html

Medium
16 aria-label Accessible name should use aria-label and it should override even aria-labelledby. Right now aria-label is completely ignored. http://codetalks.org/source/enhanced-html-forms/label.html High
17 aria-describedby Accessible name should use aria-label and it should override even aria-labelledby. Right now aria-describedby is completely ignored. http://codetalks.org/source/enhanced-html-forms/describedby.html High
18 role="dialog" The "dialog" role doesn't work in IE 8 RC 1 using JAWS and Window-Eyes. Here is an example of the YUI Dialog using ARIA in FF3 + JAWS:

Notice how when the "First Name" field is focused, JAWS announces "Personal Information Dialog". Using the same example in IE8, JAWS simply announces the label of the "First Name" field: Movie: http://public.yahoo.com/~kloots/aria/dialog-ie8+jaws.mov

High
19 role="menuitem" In IE 8 (RC1), each time a menuitem receives focus JAWS reads the text label of the menuitem followed by "submenu". Seem like IE 8 is assuming every menuitem in a submenu has a submenu. Here is a movie illustrating the bug:

This is likely a bug in IE 8, since JAWS doesn't do this in Firefox as illustrated in this movie:

High

To do

  1. investigate some of them more and add details and test case links.
  2. go through set of testcases page and find issues, then add to this list
  3. go through implementor's guide and look for issues to test in IE
  4. go through Firefox ARIA bug list and look for issues to test in IE (http://wiki.codetalks.org/wiki/index.php/Known_Firefox3.1_beta2_ARIA_bugs)
  5. make sure each issue has a corresponding testcase
  6. set severity levels
  7. share with Microsoft
Retrieved from "http://wiki.codetalks.org/wiki/index.php/Known_IE8_beta2_ARIA_bugs"