346122 - (fox3vpat) Add VPAT for Firefox 3, including appropriate information updates

Status: RESOLVED FIXED

(www.mozilla.org :: General, defect)

Description

[Aaron Leventhal]

In this bug we will track VPAT changes (positive and negative) for Firefox 3. Please add any changes you know of from the base VPAT at http://www.mozilla.com/firefox/vpat.html

First, we know that remote XUL is no longer broken.
Also, automatic refreshes can be blocked now, would be nice to find a place to insert that (perhaps where it talks about timed content).

- We will need a VPAT for Linux (hopefully, if we get far enough with screen reader support)
- We may want to have a VPAT for OS X if Hakan Waara's project for VoiceOver support is successful
- We may want to mention XForms accessibility on each VPAT, depending on how far we get with that project.
- If full page zoom becomes a reality we will want to mention that.

Comment 1

[Reed Loden [:reed]]

Please remember to update the QA contact when you change components, as many of us watch it specifically.

Comment 2

[Marco Zehe (:MarcoZ)]

Notes based on current observations/bug fixes:

1. Section 1194.21: Under (a), regarding adding an RSS feed as a live bookmark: This has become keyboard accessible. Select the "Subscribe to this page" item from the Bookmarks menu, a new page comes up containing the RSS feed and a combobox at tthe top that allows to choose how to bookmark the feed. The workaround is no longer necessary.

2. Under (c), it says "The caret is not visible in a read-only text field. However, the selection is visible, so the read-only field can be used to select text using shift+arrow/home/end." Question: This has been fixed recently, has it not? The caret should now be visible in readonly text fields.

3. Under (d), add info about IAccessible2 making it clear that text that traditionally was only readable via an offscreen model, is now fully accessible via APIs.

4. As Aaron said, for (f) RemoteXUL is now supported.

5. In table for section 1194.25: (b) says: "When a timed response is required, the user shall be alerted and given sufficient time to indicate more time is required." We may need to revise our answer of "not applicable" in the case where the information bar/password manager prompts appear. These are timed, and as far as I know, there is no way for users to currently prolongue the timeout.

Comment 3

[Mike Shaver (:shaver emeritus)]

Do we ever time-out the infobars?  I thought they were always removed by user action (including navigating to another page).

Comment 4

[John Slater]

I'd like to get this page updated to the new Mozilla.com look & feel (ideally before launch, although I'm not 100% sure that's possible). 

Can someone give me a clean doc with all the revised content in it? That would make it a pretty easy update...let me know what the best process for that is.

Thanks!

Comment 5

[Mike Beltzner [:beltzner, not reading bugmail]]

(In reply to comment #3)
> Do we ever time-out the infobars?  I thought they were always removed by user
> action (including navigating to another page).

In all cases except the password manager, this is the case.

For the password manager infobar, any page navigation after 30s will result in the infobar being removed. (This was to allow for login-redirect-fu.)

Comment 6

[Mike Shaver (:shaver emeritus)]

(In reply to comment #5)
> (In reply to comment #3)
> > Do we ever time-out the infobars?  I thought they were always removed by user
> > action (including navigating to another page).
> 
> In all cases except the password manager, this is the case.
> 
> For the password manager infobar, any page navigation after 30s will result in
> the infobar being removed. (This was to allow for login-redirect-fu.)

Are you saying that the pwmgr infobar will go away on its own, or that even user interaction isn't always enough to send it away?  If there's no timeout that _dismisses_ it, rather than just making it dismissable, then I don't think there's an a11y issue here.

Comment 7

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #6)
> Are you saying that the pwmgr infobar will go away on its own

Yes, it will go away on it's own, triggered by a pageload, if 20 seconds have elapsed (though it will ignore the first pageload no matter what, to allow for login sequences that redirect).

Comment 8

[Mike Shaver (:shaver emeritus)]

Ah, so if the site reloads itself on a longish timer, it could go away without user action.  Hrm.

Comment 9

[Aaron Leventhal]

I should not have linked to the VPAT for 1.5. The starting point for the new VPAT should be the VPAT for Firefox 2.0: http://www.mozilla.com/en-US/firefox/vpat-2.html
FWIW it's a bit confusing that the base vpat URL goes to an old one. I'd rather have that redirect to the most current VPAT.

Marco, readonly caret works again. Hooray!

We should also brag about new a11y features:
1. Full page zoom supported (text zoom still possible by using View -> Zoom -> Zoom Text Only)
2. Users can report inaccessible websites via Help -> Report a broken website (for problem type choose Disability access). Statistics and info on the inaccessible websites can be found at reporter.mozilla.org (Note to us: from looking at the reports it would appear many people still think that this means the website wouldn't come up).
3. In appropriate places in the VPAT, I would list any extensions helpful to people with disabilities. Obviously we can't list them all, but talk to accessfirefox.com, since they know some of them.
4. Under (f) we mention DHTML, but we should also explicitly say that we have industry-leading support WAI-ARIA, for DHTML, AJAX and Web 2.0 accessibility. We can link to the spec in-progress. We really need to brag more about this somehow.
5. In the key nav special features section of (a) I would describe the Awesomebar as a great way to use the keyboard to quickly navigate to previously visited websites
6. As far as timeouts go, one good piece of news is that under Tools -> Options -> Advanced -> Gerneral there is a new checkbox "Warn me when websites try to reload or redirect the page". It's probably a poorly named pref. Not only does it warn you, it asks for permission. So users are notified and can stop it or allow it.

Comment 10

[Mike Beltzner [:beltzner, not reading bugmail]]

Marco, still on this / eta?

Comment 11

[Marco Zehe (:MarcoZ)]

I'd need help with editing the relevant parts. It's not a wiki page. Other than that, I went through it again yesterday and didn't find any extra items other than what's in the comments of this bug.

Comment 12

[Marco Zehe (:MarcoZ)]

Attachment: First cut at edVPAT for Firefox 3

1. Addressed Aaron's and my comments as applicable.
2. Changed instances of Firefox 2 to 3.
3. Changed operating system statements.

Comment 13

[Marco Zehe (:MarcoZ)]

Forgot to mention: Changed the text-zoom part to full page zoom, and added information that a text-only zoom is optionally available.

Also I was unsure about the automatic refresh blocking, didn't feel comfortable with putting it in "timed content" since that's not really what that section talks about.

Comment 14

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 324404 [details]
First cut at edVPAT for Firefox 3

This is fantastic.

Steven: is the HTML ok for being dropped into the existing template?

Comment 15

[Steven Garrity [:sgarrity]]

(In reply to comment #14)
> Steven: is the HTML ok for being dropped into the existing template?

Yup. I've updated the styles for the page in r15688. All that is needed is to include the new CSS file in the header. I can add that once the new page is committed.

Comment 16

[Steven Garrity [:sgarrity]]

Is this going to live at en-US/firefox/vpat-3.html ? Want me to commit it?

Comment 17

[Marco Zehe (:MarcoZ)]

Steven, yes, can you commit the page that's attached to this bug? This is the copy we'd want. Thanks!

Comment 18

[Aaron Leventhal]

Can we make the base vpat URL always point to the current release's VPAT?

Comment 19

[Steven Garrity [:sgarrity]]

(In reply to comment #17)
> Steven, yes, can you commit the page that's attached to this bug? This is the
> copy we'd want. Thanks!

Sending        en-US/firefox/vpat-2.html
Adding         en-US/firefox/vpat-3.html
Sending        style/tignish/firefox-vpat.css
Transmitting file data ...
Committed revision 15696.

(In reply to comment #18)
> Can we make the base vpat URL always point to the current release's VPAT?

We can probably do that. Right now we have three files:
vpat.html (v1.5)
vpat-2.html (v2)
vpat-3.html (v3)

How should the URLs be handled? We could move the 1.5 version to vpat-1.5.html, and move v3 to vpat.html, and just rotate the files when the next version comes out. Does that work?

Comment 20

[Aaron Leventhal]

That plan would work fine thanks.

Comment 21

[Steven Garrity [:sgarrity]]

(In reply to comment #20)
> That plan would work fine thanks.

Done in r15710.

Are we ready to mark this as FIXED?

Comment 22

[Mike Beltzner [:beltzner, not reading bugmail]]

Actually, since the VPATs are version specific, can we keep the filenames versioned that way? So rename the vpat.html one to vpat-1.5.html?

We can establish a redirect so that vpat.html goes to the correct version.

Comment 23

[Mike Beltzner [:beltzner, not reading bugmail]]

Actually, the more that I think about it, that would be a new bug. Marking this one FIXED.

Tracking the issue from comment 22 in bug 439472

Comment 24

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1527381