E-mail List Archives
Re: FW: web site for testing
From: Jared Smith
Date: Feb 15, 2013 8:53AM
- Next message: Chagnon | PubCom: "Re: PDF Remediation Tools"
- Previous message: Tim Harshbarger: "Re: Checking color contrast, keyboard focus and webpage look/ARIA as a blind user"
- Next message in Thread: None
- Previous message in Thread: Birkir R. Gunnarsson: "Re: web site for testing"
- View all messages in this Thread
On Fri, Feb 15, 2013 at 8:31 AM, Wyant, Jay wrote:
> Given that each browser creates its own DOM, does it then stand to reason that one should test tools using multiple browsers?
Our testing has shown that as browsers become more standards
compliant, the minor discrepancies between various browser DOM
structures have negligible impact on accessibility testing (so long as
the site and/or scripting isn't doing browser-specific manipulations).
> For example, you can use the WAVE's Firefox plug-in, but should you also run the web version in other browsers to see if the results are different?
The web version of WAVE still evaluates the content based on a
Firefox-generated DOM produced on our servers. However, we are in the
process of porting the backend engine to Webkit and have found that
there are no notable differences in results, which proves this point.
> And if the results are indeed different, then can you isolate whether accessibility failure is the fault of the browser, the DOM, or the site?
Speaking for WAVE, the server version does not currently process
scripting on the pages that are analyzed due to security issues, so
this will often result in differences between the toolbar and the
server version of WAVE for scripted pages. For pages that don't
utilize scripting, the results should be identical between both tools
regardless of which browser you use to view the web-based version.
Even if there were differences between browsers, I wonder if this is
of great concern to developers. If you follow the rules, it's the
browsers responsibility to produce an accessible result.
I think the key here is that different tools take different approaches
to evaluation. Use several of them and consider their strengths and
weaknesses. When you're dealing with scripted content, there are cases
where some tools may miss or misrepresent accessibility issues if they
don't evaluate the DOM (though these tools do give a good
representation of what users who have scripting disabled will
experience).
Jared
- Next message: Chagnon | PubCom: "Re: PDF Remediation Tools"
- Previous message: Tim Harshbarger: "Re: Checking color contrast, keyboard focus and webpage look/ARIA as a blind user"
- Next message in Thread: None
- Previous message in Thread: Birkir R. Gunnarsson: "Re: web site for testing"
- View all messages in this Thread