Updated the Infusion Browser support chart

Thu Dec 24 15:29:57 UTC 2009

I've been doing some more thinking about that a11y testing stuff that Armin brought up a while ago.  (Sorry that this is so late coming.)

Maybe what we could do is to make test plans based on wcag 2.0. 

I gather from being part of a conversation with Jan, the other day, that wcag 2.0 will be legislated in some manner.

What I'm imaging we could do, is to indicate what level (A, AA, or AAA) each component complies with in it's base configuration, or is possible to achieve. 

For example the video player is capable of display captions, but it is up to the integrator to supply them.

Here are a couple critiques of wcag 2.0 (they are both from 2006 though)
http://www.alistapart.com/articles/tohellwithwcag2
http://www.webcredible.co.uk/user-friendly-resources/web-accessibility/wcag-guidelines-20.shtml

We are still faced with an issue of what AT's to test with. In looking at the builder, we found that putting the text of a button inside of a span, caused the button to only announce "Button" in NVDA. However, if you changed to focus mode, it did read it properly. This leads me to believe that to some degree AT's are essentially broken, or at least not fully functional at the moment. 

It seems to me that wcag 2.0 will allow us to say, for example, if the aria semantics are correct, then we are compliant whether or not the AT's actually work properly. I'm not quite sure this is correct and it is a poor approach at best. However, it will prevent us from getting into a situation where we are making vain attempts at implementing concessions for a variety of AT's.

So here is my suggestion.

1) Make test plans based on wcag 2.0 and aim to have every component ship with defaults which are at least AA and include options which ensure integrators can achieve at least AA compliance.

2) Indicate some how, which level of compliance each component meets

3) At this point, assume that proper development techniques will yield AT support (with exceptions listed below)

4) Continue testing keyboard a11y in A-grade browsers

5) Pick a few screen reader configurations to test in. While I don't think we should herald this as we do our A-grade support. As a convenience we should indicate something like "screen reader testing for release x.y.z was done using the following screen readers..."

Thanks
Justin
On 2009-11-03, at 8:34 PM, Armin Krauss wrote:

> Hello,
> 
> thanks for the good discussion. I did not know that we tested with Linux and I am happy to
> hear. I fully understand the reason for the A-Grade browsers to have focus on a selected
> set of platforms. I don't want to change this considering the enormous time commitment to
> do the release testing.
> 
> Maybe we can create a B-Grade browser list. The purpose of this list would be to direct
> testing that goes beyond the core that we have to cover. This would help to give people, which
> want to do extra testing, some guidance of what we see as desirable.
> This could be Firefox on Ubuntu or in the future Opera (since it looks like Opera might drop
> out of Yahoo's browser listing).
> 
> Any thoughts on this "alternative" list? We could also give some information on screen readers
> we want to cover. Since we always talk about accessibility it is from my point of view important
> to integrate testing with tools like screen readers into our QA cycles. This might not be done for
> each release but on an ongoing basis. To do so we might want to create a A-Grade listing for
> assistance technology.
> 
> Armin 
> 
> 
> On Tue, Nov 3, 2009 at 16:47, Colin Clark <colinbdclark at gmail.com> wrote:
> On this particular issue, I'm with Justin.
> 
> The purpose of the A-Grade chart is to outline a feasible set of platforms on which we can test most thoroughly. It's not about excluding some platforms--our goal is to enable use across a wide variety of platforms and browsers. With limited QA resources, we use the A-Grade list to help us focus. But we're always happy to receive test results from users on all platforms, and we do our best to fix issues on non-A-Grade browsers where possible.
> 
> It's pretty useful to read Yahoo!'s perspective on graded browser support:
> 
> http://developer.yahoo.com/yui/articles/gbs/
> 
> As Justin says, several of our developers do use Linux on a regular basis, and Joan was kind enough to submit QA results for it. If you're interested in helping out with Linux testing, please feel very welcome and encouraged to do so. The A-Grade chart will continue to allow us to focus on a baseline of testing and support that our users can rely on for every release.
> 
> Colin
> 
> 
> On 3-Nov-09, at 4:00 PM, Justin Obara wrote:
> 
> Hello,
> 
> Thanks for your keen interest in testing and how it affects all of our users.
> 
> I suppose I should start by saying that the browser support chart doesn't prevent testing on any other configuration, but is instead the base for what must be covered.
> 
> You may or may not have noticed that we did testing on linux in the last release of Infusion (1.1.2).
> 
> That being said, we have tried to stay inline with the Yahoo A-grade browser support. It provides us with a "standard" configuration to follow, which does allow our browser support decisions to be more transparent.
> 
> I'd be interested in knowing more about what you and others in the community think about this.
> 
> Thanks
> Justin
> 
> On 2009-11-03, at 3:22 PM, Alison Benjamin wrote:
> 
> I think incorporating testing with Ubuntu in our QA cycles would be a
> good thing and I would be happy to help.
> 
> Alison
> 
> 
> 
> 
> On Tue, Nov 3, 2009 at 2:55 PM, Armin Krauss <mackrauss at googlemail.com> wrote:
> Hello Justin,
> 
> I understand that we have to concentrate on some browsers in order to be
> able to get
> our releases tested in an acceptable time. However, I would argue for adding
> testing
> on Ubuntu with the newest Firefox. This does not have a huge market share,
> but we
> could use this platform to test with the Orca screen reader as well. Testing
> more often
> with Orca, VoiceOver and Jaws would allow use to cover accessibility issues
> better.
> 
> Including the most popular Desktop Linux distribution with one of the most
> popular
> browsers would help us to make sure Fluid passes the regular test cycle on
> this
> platform. If you then start tests with Orca and with disabled users you do
> not run
> into errors that could have be caught during the regular test cycle.
> 
> I was planning to meet with Alison and Jamon in order to set up our laptop
> for dual boot
> and virtual machines that allow use to easily work and test on the Ubuntu
> platform. Maybe
> we could also have one instance of a Ubuntu running on a VM so that everyone
> has
> access via VNC and does not need to maintain an installation.
> 
> Any comments and thoughts are more than welcome to get a discussion started.
> 
> Armin
> 
> 
> 
> On Mon, Nov 2, 2009 at 14:09, Justin Obara <obara.justin at gmail.com> wrote:
> 
> Hello,
> I have just updated the browser support chart for Infusion to match
> Yahoo's latest A-grade browser chart.
> http://wiki.fluidproject.org/display/fluid/Browser+Support+Chart
> 
> Below is the list of changes posted on the YUI blog.
> http://yuiblog.com/blog/2009/10/16/gbs-update-2009q4/
> 
> With this update, Mac OS 10.4 Tiger drops from the A-Grade testing matrix
> (replaced with Mac OS 10.6 Snow Leopard) and the testing surface is reduced
> to 12 browsers on 4 OS platforms (down from 14 browsers on 4 platforms).
> Specific changes include:
> 
> Initiated A-Grade support for Firefox 3.5.† on Mac OS 10.6.†
> Initiated A-Grade support for Opera 10.0.† on Windows XP
> Discontinued A-Grade support for Firefox 3.0.† on Mac OS 10.5.†
> Discontinued A-Grade support for Firefox 3.5.† on Mac OS 10.5.†
> Discontinued A-Grade support for Safari 3.2.† on Mac OS 10.4.†
> Discontinued A-Grade support for Opera 9.6.† on Windows XP
> 
> Thanks
> Justin
> _______________________________________________________
> fluid-work mailing list - fluid-work at fluidproject.org
> To unsubscribe, change settings or access archives,
> see http://fluidproject.org/mailman/listinfo/fluid-work
> 
> 
> 
> _______________________________________________________
> fluid-work mailing list - fluid-work at fluidproject.org
> To unsubscribe, change settings or access archives,
> see http://fluidproject.org/mailman/listinfo/fluid-work
> 
> 
> 
> _______________________________________________________
> fluid-work mailing list - fluid-work at fluidproject.org
> To unsubscribe, change settings or access archives,
> see http://fluidproject.org/mailman/listinfo/fluid-work
> 
> ---
> Colin Clark
> Technical Lead, Fluid Project
> http://fluidproject.org
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20091224/b5f4d7ab/attachment.htm>