WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Accessibility training and scanning solutions providers

for

From: JP Jamous
Date: Dec 17, 2016 3:47PM

Lisa,

My 2 cents is that this conversion between the HTML markup and the DOM translation can be impacted by so many factors. Let me give you an example.

I was coding once and wrote a CSS class to take 25% of a page and make the background a certain color because the background of the page was all white. There was no issue with the markup and even W3 validation give me the green light to go with it.

I loaded Firefox and the view was exactly as I wanted it. I loaded IE 9 and my wife was, "Umm, not the whole 25% is the color you specified." I thought my wife had too much to drink, because we had a large time difference and it was night time where she was. I kept trying and trying, but to no avail. Percentage was interpreted by IE differently from Firefox and Chrome.

So as you see, even the best markup can get screwed up by the browser agent. The same applies to the AT agent. Why does JAWS read the fieldset legend whenever a radio button is selected, but NVDA and VoiceOver do not do that. The mark up is the same. However, FS thought it would be best to keep repeating the legend whenever a new radio button obtained focus.

With the above in mind, how do you find the sweet sport? A checker would read the markup or the DOM and give you the green light. However, when you put it to the test it breaks with JAWS.

Personally, I get annoyed when the legend is read over and over. It is a waste of my precious time and the verbose output makes me forget what the radio buttons before the one I am on stated. I hope AT manufacturers provide a way to switch those on and off in the user settings.

All of those frustrations above are a result of how HTML started and the war between Microsoft and Netscape. I don't know if you recall that in the late 90's. I was starting in this field and witnessed the battle. That battle never stopped.

If you switch to desktop development, you would notice that the coding is more standardized than HTML. Eventually Windows is reading the binary file and loading it in memory.

Of course, the difference in interpreting the markup creates a competitive advantage for those manufacturers. That is why they won't change it. The Burdon fall on developers and WCAG evaluators. That is why we have to evaluate on a general level rather than a specific one. If we get specific, we start leaning towards level AAA and a big mess would be started.

-----Original Message-----
From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On Behalf Of L Snider
Sent: Saturday, December 17, 2016 12:37 PM
To: WebAIM Discussion List < <EMAIL REMOVED> >
Subject: Re: [WebAIM] Accessibility training and scanning solutions providers

Hi Birkir,

What has been your experience if the DOM passes, but the HTML has been a mess, in terms of user testing? I have seen people do what you suggested, basically layer over the html, but I always wondered how people found it in terms of accessibility, and not just a checker saying it is okay. If that makes sense?

For me, I want the DOM and HTML to be accessible, as much as possible. but I found others I have met in the past few years don't always share that view-and they rely on the DOM to fix the issues, when if they just worked on the HTML...well you can see where I am going with this!

Cheers

Lisa



On Fri, Dec 16, 2016 at 12:03 PM, Birkir R. Gunnarsson < <EMAIL REMOVED> > wrote:

> Karl Groves set up the provocatively named but brilliant
> http://www.mothereffingtoolconfuser.com
> This is a webpage whose HTML source code has a number of accessibility
> issues, all of which are fixed with JQuery that runs on page load.
> So the HTML source has a bunch of issues, the DOM should have 0.
> If a tool reports a bunch of errors on this page, either it tested the
> HTML source, or there is something happening with JavaScript not
> running (I have seen it happen when trying to test this page from
> behind a corporate firewall).
> But if the tool reports 0 errors, it is testing the DOM.
> I had a SiteImprove tech guy test this page for me (in SiteImprove you
> cannot test a random page yourself,only the domain you have access
> to). He said it returned 0 errors, Based on that info they test the
> DOM.
>
> -B
>
>
> On 12/16/16, Sean Keegan < <EMAIL REMOVED> > wrote:
> > Hi Peter,
> >
> > Have you verified with SiteImprove that the tool does not check the DOM?
> I
> > raised this question with two different technical people at
> > SiteImprove several months ago and both said the tool is evaluating
> > the DOM, not the source code.
> >
> > Take care,
> > Sean
> >
> >
> >
> >> ---------- Forwarded message ----------
> >> From: "Bossley, Peter A." < <EMAIL REMOVED> >
> >> To: WebAIM Discussion List < <EMAIL REMOVED> >
> >> Cc:
> >> Date: Wed, 14 Dec 2016 19:16:11 +0000
> >> Subject: Re: [WebAIM] Accessibility training and scanning solutions
> >> providers Siteimprove doesn't appear to actually test the DOM, so I
> >> bounced them
> off
> >> the list for that one alone.
> >>
> >>
> >>
> > > > > > archives at http://webaim.org/discussion/archives
> > > >
>
>
> --
> Work hard. Have fun. Make history.
> > > archives at http://webaim.org/discussion/archives
> >