Bugzilla – Full Text Bug Listing
| Summary: | Web Accessibility checklist fails checkpoint 9: Two internal frames say "Untitled" in HomePageReader | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Lee Anne Kowalski <kowalskilee> | ||||
| Component: | User Assistance | Assignee: | Platform-Help-Inbox <platform-help-inbox> | ||||
| Status: | RESOLVED DUPLICATE | QA Contact: | |||||
| Severity: | critical | ||||||
| Priority: | P3 | ||||||
| Version: | 2.1.1 | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Windows 2000 | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Lee Anne Kowalski
All frames have titles. I am marking the bug as duplicate of bug 37423. It is a Home Page Reader problem. The navigation views contains view frames and one hidden IFRAME used for loading other frames during synchronization. The HTML code is as follows: <iframe frameborder="0" style="visibility:hidden" tabindex="-1" name="temp" id="temp" title="Ignore this temp frame, it only contains other frames."></iframe> The toolbar contains hidden IFrame used to execute live (active) help actions. The HTML code is as follows: <iframe name="liveHelpFrame" title="Ignore this liveHelpFrame frame, it only contains other frames." style="visibility:hidden" tabindex="-1" frameborder="no" width="0" height="0" scrolling="no"> </iframe> Check point 9: "Provide a title for each FRAME element and frame page ,Provide an accessible source for each frame" Answer: 1. Both frames have NAME and TITLE attributes, so the frames that contain the hidden frames are completely accessible. 2. The frames are used for implementations of certain DHTML actions and have no content to be accessed by a user. In fact they have no content and no SRC attribute set, so there is no inaccessible content in them. The fact that there is no content and no source is additionally emphasized by: - both frames are hidden, not visible in UI. - tab index is set to -1, so user cannot navigate to these frames using keyboard. - the title says to ignore these frames Hence, We are accessible. The frames are internal to implementation and cannot be got rid of. We added all possible accessibility features to these frames. Users that do not use special tools, or use good tools have no chance of being confused by these frames. Jaws has no problem with these frames, only Home Page Reader has. It should report the title correctly, honor visibility:hidden and tabindex=-1. The bugs are in Home Page reader and I am not sure they will ever be fixed, as Home Page Reader in not even supported on Windows XP. *** This bug has been marked as a duplicate of 37423 *** What's curious to me is that HomePage Reader reports some of the internal frames with titles, but just not two particular ones. Is it that it's only those 2 that have the hidden attribute, while the other internal frames are visible? See the attachment which is the list of frames when I load the information in HomePage Reader. It shows 6 internal frames listed, but 2 of the 6 say "Untitled" (#11 and #8), while the others show titles. The internal frames that are listed as "Untitled" and the other ones that have specific titles listed. Are those the two hidden ones, while the other ones are visible? I can go to the Accessibility Center and ask them to clarify in the checklist regarding the tool. However, I need to understand why there seems to be a difference in the treatment of one type of internal frame vs the other, so I can articulate an intelligent case to them. Created attachment 6494 [details]
screen capture of Home Page Reader Frames listing window on Information Center
Other frames are hidden or visible depending on the user actions, so they do not have attribute style="visibility:hidden" but have visibility controlled from JavaScript by code like: iframes[i].className = "hidden"; iframes[i].style.visibility="hidden"; So the two frames are not the only hidden ones. Jaws does not report frames that are hidden (correct), but HPR does. For example after launching content view is shown, and search results view is not (it is hidden). So in addition to reporting two frames as "Untitled: blank", HPR shows "Search Results" frame and second "Toolbar" frame, which are hidden and should not be reported. But, the main problem #1 of HPR is that it simply ignores TITLE attribute of the FRAME or IFRAME element. When it ignores title of our two frames that do not have any source, it has nothing tho show, so it reports "Untitled: blank". For our frames titled "Search Results View Toolbar"(usually hidden) and "Contents View Toolbar"(usually visible), HPR reports both of them, and shows the name as "Toolbar". This is clearly wrong. Who ever defines frameset and uses TITLE attribute on the frames has knowledge how many frames there are. The documents displayed inside frames have no knowledge of each other, any many can share the same document title. In HTML document title has nothing to do with frame title. HPR should not use those. Another example to illustrated the problem: The frame #1 we defined and gave it a title "Banner". HPR reports the frame title as "IBM Websphere .....". It is clear that HPR displays document titles instead of frame titles. I suggest to treat HPR as a tool to aid identifying problems. It is not a tool to pass or fail standard compliance. |