Test environment: Windows XP, Firefox 2 (Bon Echo) build 20060801, Microsoft Inspect Objects Optional: screen reader (JAWS or Window-Eyes) Description: There are many accessibility issues in the Page Info dialog. Page Info has several notebook tabs (General, Forms, Links, Media, and Security). Accessibility issues are listed below for each tab. To open the Page Info dialog: 1. Press Alt+T to open tools menu. 2. Press "i" to open Page Info. 3. Press Ctrl+Tab to move from one info tab to another. To see MSAA properties, start Inspect Objects. To hear screen reader output, start JAWS or Window-Eyes GENERAL TAB 1. No scroll bars for window, if the window is sized very small. 2. In the top section, the "Referring URL" item not part of tab ring. (Its value = "Not specified", but two items later, the "Expires" item also has a value of "Not specified", yet it is in the tab ring. Note: If you are running a screen reader, it will not read the items that are not in the tab ring, so a blind user does not know they even exist. 3. In "Meta" section, the LIST/TABLE header is not keyboard accessible. The "table column selector" icon in the right corner of the header cannot be accessed by any keystroke, so the pulldown list that it generates is not keyboard accessible. A screen reader user, or keyboard-only user, will not be able to use this function. 4. There is no way to scroll right/left in the content field, in the case where the text in the field is wider than the available width of the window. There is also no way to resize the columns with the keyboard, to allow the user to view data that might not fit in the available width. A keyboard-only user cannot see all of the data in columns that have text overflow. 5. The information is visually presented as a table, but the implemented as a list (Inspect Objects shows MSAA Role = list item, and MSAA Name = the entire contents of the line of data. The screen reader reads the entire line, but does not differentiate between the data in each column. The screen reader user does not know when the "Name" ends and the "Content" begins. FORMS TAB 1. All of the same list/table issues as listed above in GENERAL section. 2. Items listed under 'Unnamed Forms" are not in the tab ring (Encoding and Target). The screen reader will not easily read those items unless you can tab to them. LINKS TAB 1. All of the same list/table issues as above. MEDIA TAB 1. All of the same list/table issues as above. 2. In the middle section, not all of the items are in the tab ring, if they are not specified or empty. The screen reader user is not aware of their existence. SECURITY TAB 1. None of the information is in the tab ring... this is not completely necessary, but it would make it much easier for a screen reader to announce the information. Currently, the only easy way for a screen reader to announce this page is to press the "read entire window" key, which gives more information that the user wants. - For example, In the case where no security is used, the top part of this page says "Web Site Identity Not Verified", and the bottom has a heading saying "Connection Not Encrypted", with a paragraph of text beneath. If the phrase "Web Site Identity Not Verified" and "Connection Not Encrypted" were part of the tab ring, and the paragraph text in the bottom section were contained in a read-only text box, also in the tab ring, the user could tab to each field and read it all easily with a screen reader. - In the case where a secure web page is viewed, the Security info page looks similar, but with a paragraph of extra text in the top section, and a "View" button. The only elements in the tab ring are the "View" button, and the "Security" tab itself. Very little useful information is available to the screen reader without forcing the user to read the entire window, or search for information using more advanced screen reader functions. Expected results: 1. In most cases, all of the information required by the end user should be part of the tab ring. 2. Columns that can be sized using a mouse should be sizeable with the keyboard also. 3. The "table column selector" icon should be accessible via the keyboard. 4. Because a sighted user can easily understand which information is found in which column, the same information should be available to the screen reader user. (Which portion of a line in each list/table is associated with which column header.)

There's a summer of code project related to making this window simpler and more usable: http://mozilla.queze.net/soc.html It could potentially be a great help with the accessibility of this dialog.

CC'ing beltzner since he's Florian's mentor.

(In reply to comment #0) > 2. Columns that can be sized using a mouse should be sizeable with the > keyboard also. > 3. The "table column selector" icon should be accessible via the keyboard. > 4. Because a sighted user can easily understand which information is found in > which column, the same information should be available to the screen reader > user. (Which portion of a line in each list/table is associated with which > column header.) > Is this a page info issue or a tree accessibility issue? Is there somewhere else a tree on which the column headers and the column picker are accessible via the keyboard?

Florian, you're right. If you use a tree view the accessibility should be fine. We'll take care of remaining tree issues in separate bug. I mainly wanted to CC you to let you know that your redesign is a big opportunity to make things simpler/better for users with disabilities as well.

Looking at this a bit closer. > > 2. Columns that can be sized using a mouse should be sizeable with the > > keyboard also. There is no standard way to do that. I suppose we'd need to make them tabbable. That would be annoying in something like mail, but perhaps okay in this dialog. However, that's inconsistent. Need ideas here. Context menu? > > 3. The "table column selector" icon should be accessible via the keyboard. There is no standard way to do that. I suppose we'd need to it also tabbable or put options in the context menu. > > 4. Because a sighted user can easily understand which information is found in > > which column, the same information should be available to the screen reader > > user. (Which portion of a line in each list/table is associated with which > > column header.) That will be addressed eventually by accessibility API work, so ignore that for now. So we should make sure there is a separate bug on tree view keyboard issues, but realize the page info dialog is special in that there is no main menu bar. So normally you'd have View -> Sort by to help out, but here you don't.

Is this bug still valid? The Page Info dialog looks quite different from what is described here. So this bug may have resolved itself overtime. Any comments?

The new page info screen superceded this.