E-mail List Archives
Thread: Accessibility training and scanning solutions providers
Number of posts in this thread: 21 (In chronological order)
From: Bossley, Peter A.
Date: Wed, Dec 14 2016 10:35AM
Subject: Accessibility training and scanning solutions providers
No previous message | Next message →
Hello, WebAIM list,
OSU is currently evaluating two aspects of improving our accessibility compliance program.
First, we are looking at scanning and tracking solutions. Currently we are looking at offerings from Deque, SSB Bart Group, and Compliance Sherriff.
Second, we are looking for robust training on web accessibility, document accessibility, and native mobile app accessibility. Our evaluations on this front are planned to be Deque and SSB Bart Group.
I'm writing to ask the list if there are other solutions on either of these fronts that we should be looking at.
Keep in mind that we have a fairly large and decentralized campus environment, especially as it relates to websites. So a solution that won't scale efficiently is a showstopper for us.
Input or suggestions would be appreciated.
Best,
From: Lovely, Brian (CONT)
Date: Wed, Dec 14 2016 10:49AM
Subject: Re: Accessibility training and scanning solutions providers
← Previous message | Next message →
I'm not familiar with Compliance Sherriff, but it seems like you have it covered. At Capital One, we use solutions for Deque and SSB Bart Group as well. I would recommend that you create a specialized group tasked with accessibility testing and training, rather than relying on each department to be able to both self-administer and maintain a even level of compliance across all departments.
From: Lucy Greco
Date: Wed, Dec 14 2016 11:56AM
Subject: Re: Accessibility training and scanning solutions providers
← Previous message | Next message →
peter i think you have a good start to the list have you considered
Siteimprove if you write me off list i would like to calaberate on this
with you as we are about to start the same process thanks lucy
Lucia Greco
Web Accessibility Evangelist
IST - Architecture, Platforms, and Integration
University of California, Berkeley
(510) 289-6008 skype: lucia1-greco
http://webaccess.berkeley.edu
Follow me on twitter @accessaces
On Wed, Dec 14, 2016 at 9:35 AM, Bossley, Peter A. < = EMAIL ADDRESS REMOVED = >
wrote:
> Hello, WebAIM list,
> OSU is currently evaluating two aspects of improving our accessibility
> compliance program.
> First, we are looking at scanning and tracking solutions. Currently we are
> looking at offerings from Deque, SSB Bart Group, and Compliance Sherriff.
> Second, we are looking for robust training on web accessibility, document
> accessibility, and native mobile app accessibility. Our evaluations on this
> front are planned to be Deque and SSB Bart Group.
> I'm writing to ask the list if there are other solutions on either of
> these fronts that we should be looking at.
> Keep in mind that we have a fairly large and decentralized campus
> environment, especially as it relates to websites. So a solution that won't
> scale efficiently is a showstopper for us.
> Input or suggestions would be appreciated.
> Best,
>
>
>
> > > > >
From: Birkir R. Gunnarsson
Date: Wed, Dec 14 2016 12:11PM
Subject: Re: Accessibility training and scanning solutions providers
← Previous message | Next message →
I am wrapping up a very similar exercise for my employer.
I can't go into details other than saying our final candidates are
definitely not too far out of line with yours.
I can share a few of the evaluation criteria I used. An accessibility
testing platform needs to be:
* Accurate (automated testing should report the maximum number of real
issues but avoid reporting false positives, it takes too much time and
destroys the reliability of the platform).
* Flexible: You need a browser plug-in interface to run accessibility
scans on pages that are part of flows (e.g. that are displayed as a
result of filling in forms or logging in), or can perform scans after
selection an action on the page (that brings up a tab or a dialog).
Platforms that can only scan pages starting with a URL give you a very
incomplete picture for most web content.
* Test the DOM, not the html source (return 0 errors from testing
http://www.mothereffingtoolconfuser.com). This is almost a "needless
to say" requirement anymore, but there are still checkers out there
that only test the HTML source.
* Offer guidance for manual testing (this is not a must, but it helps
if the tool can guide your testers who do not have extensive
background in accessibility).
* Integrate with existing issue tracking systems (such as Jira, ALM,
Trac etc.). A strong selling point is an accessibility test platform
where results can be exported directly to the organization's issue
tracking system, no time wasted copying and pasting or manually
creating issues.
* Accessible: The dashboard and browser plugins need to be accessible.
This list is not exhaustive and does not fit everybody's needs, but
you may find it helpful to come up with such a list so you can compare
solutions.
In addition, I prefer it if the vendors have experts that participate
in standardization work, attend accessibility conferences and are
generally well known to be accessibility experts.
You may want to also consier Tenon as well. There is also Wave of
course, but who would know who they rae? *grin*
Cheers
-B
On 12/14/16, Lucy Greco < = EMAIL ADDRESS REMOVED = > wrote:
> peter i think you have a good start to the list have you considered
> Siteimprove if you write me off list i would like to calaberate on this
> with you as we are about to start the same process thanks lucy
>
> Lucia Greco
> Web Accessibility Evangelist
> IST - Architecture, Platforms, and Integration
> University of California, Berkeley
> (510) 289-6008 skype: lucia1-greco
> http://webaccess.berkeley.edu
> Follow me on twitter @accessaces
>
>
> On Wed, Dec 14, 2016 at 9:35 AM, Bossley, Peter A. < = EMAIL ADDRESS REMOVED = >
> wrote:
>
>> Hello, WebAIM list,
>> OSU is currently evaluating two aspects of improving our accessibility
>> compliance program.
>> First, we are looking at scanning and tracking solutions. Currently we are
>> looking at offerings from Deque, SSB Bart Group, and Compliance Sherriff.
>> Second, we are looking for robust training on web accessibility, document
>> accessibility, and native mobile app accessibility. Our evaluations on
>> this
>> front are planned to be Deque and SSB Bart Group.
>> I'm writing to ask the list if there are other solutions on either of
>> these fronts that we should be looking at.
>> Keep in mind that we have a fairly large and decentralized campus
>> environment, especially as it relates to websites. So a solution that
>> won't
>> scale efficiently is a showstopper for us.
>> Input or suggestions would be appreciated.
>> Best,
>>
>>
>>
>> >> >> >> >>
> > > > >
--
Work hard. Have fun. Make history.
From: Bossley, Peter A.
Date: Wed, Dec 14 2016 12:16PM
Subject: Re: Accessibility training and scanning solutions providers
← Previous message | Next message →
Siteimprove doesn't appear to actually test the DOM, so I bounced them off the list for that one alone.
From: Jordan Wilson
Date: Thu, Dec 15 2016 7:28AM
Subject: Re: Accessibility training and scanning solutions providers
← Previous message | Next message →
There's already a lot of great feedback here, I'll add a few that we found to be important/differentiators:
*The ability work both inside and outside of your firewall - if you have development or QA environments that are unavailable publicly.
*A library of support resources to research and understand the best practice remediation solution.
*If you're a large organization, a cost structure that supports multiple projects.
*Support for partners/agencies/vendors who may need to use your tools or see results when working on your projects.
*A strong and integrated page/browser level testing tool to support the spider
*The ability to communicate results on both a business and technical level
*Scale of the support team - were they going to be able to quickly assist w/ issues, validation testing, other a11y needs
*Separate but integrated mobile testing tools for native apps.
I'll also underline Birkir's point about guidance for manual testing - it really helps diversify your core testing team.
Many of these points became more important when we found our top choices were very, very similar at a technical level and the conversation changed away from can it do X, to how well will each solution integrate within our larger organization.
Jordan
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > on behalf of Birkir R. Gunnarsson < = EMAIL ADDRESS REMOVED = >
Sent: Wednesday, December 14, 2016 2:11 PM
To: WebAIM Discussion List
Subject: Re: [WebAIM] Accessibility training and scanning solutions providers
I am wrapping up a very similar exercise for my employer.
I can't go into details other than saying our final candidates are
definitely not too far out of line with yours.
I can share a few of the evaluation criteria I used. An accessibility
testing platform needs to be:
* Accurate (automated testing should report the maximum number of real
issues but avoid reporting false positives, it takes too much time and
destroys the reliability of the platform).
* Flexible: You need a browser plug-in interface to run accessibility
scans on pages that are part of flows (e.g. that are displayed as a
result of filling in forms or logging in), or can perform scans after
selection an action on the page (that brings up a tab or a dialog).
Platforms that can only scan pages starting with a URL give you a very
incomplete picture for most web content.
* Test the DOM, not the html source (return 0 errors from testing
http://www.mothereffingtoolconfuser.com). This is almost a "needless
to say" requirement anymore, but there are still checkers out there
that only test the HTML source.
* Offer guidance for manual testing (this is not a must, but it helps
if the tool can guide your testers who do not have extensive
background in accessibility).
* Integrate with existing issue tracking systems (such as Jira, ALM,
Trac etc.). A strong selling point is an accessibility test platform
where results can be exported directly to the organization's issue
tracking system, no time wasted copying and pasting or manually
creating issues.
* Accessible: The dashboard and browser plugins need to be accessible.
This list is not exhaustive and does not fit everybody's needs, but
you may find it helpful to come up with such a list so you can compare
solutions.
In addition, I prefer it if the vendors have experts that participate
in standardization work, attend accessibility conferences and are
generally well known to be accessibility experts.
You may want to also consier Tenon as well. There is also Wave of
course, but who would know who they rae? *grin*
Cheers
-B
On 12/14/16, Lucy Greco < = EMAIL ADDRESS REMOVED = > wrote:
> peter i think you have a good start to the list have you considered
> Siteimprove if you write me off list i would like to calaberate on this
> with you as we are about to start the same process thanks lucy
>
> Lucia Greco
> Web Accessibility Evangelist
> IST - Architecture, Platforms, and Integration
> University of California, Berkeley
> (510) 289-6008 skype: lucia1-greco
> http://webaccess.berkeley.edu
> Follow me on twitter @accessaces
>
>
> On Wed, Dec 14, 2016 at 9:35 AM, Bossley, Peter A. < = EMAIL ADDRESS REMOVED = >
> wrote:
>
>> Hello, WebAIM list,
>> OSU is currently evaluating two aspects of improving our accessibility
>> compliance program.
>> First, we are looking at scanning and tracking solutions. Currently we are
>> looking at offerings from Deque, SSB Bart Group, and Compliance Sherriff.
>> Second, we are looking for robust training on web accessibility, document
>> accessibility, and native mobile app accessibility. Our evaluations on
>> this
>> front are planned to be Deque and SSB Bart Group.
>> I'm writing to ask the list if there are other solutions on either of
>> these fronts that we should be looking at.
>> Keep in mind that we have a fairly large and decentralized campus
>> environment, especially as it relates to websites. So a solution that
>> won't
>> scale efficiently is a showstopper for us.
>> Input or suggestions would be appreciated.
>> Best,
>>
>>
>>
>> >> >> >> >>
> > > > >
--
Work hard. Have fun. Make history.
From: Tim Harshbarger
Date: Thu, Dec 15 2016 9:02AM
Subject: Re: Accessibility training and scanning solutions providers
← Previous message | Next message →
I cannot remember if anyone else mentioned this potential consideration--metrics.
If an organization is expending resources on anything, they are likely to want to measure what they are getting for that expenditure. You will likely want to be aware of what metrics you need to collect and get some idea of how each tool you are considering might assist with the process of gathering those metrics.
Thanks,
Tim
From: L Snider
Date: Thu, Dec 15 2016 9:04AM
Subject: Re: Accessibility training and scanning solutions providers
← Previous message | Next message →
Hi Birkir,
That was a great list, thanks! One question that came to mind when you
mentioned the DOM.
What would you say are the best online checkers that check the DOM and html
source?
Cheers
Lisa
On Wed, Dec 14, 2016 at 1:11 PM, Birkir R. Gunnarsson <
= EMAIL ADDRESS REMOVED = > wrote:
> * Test the DOM, not the html source (return 0 errors from testing
> http://www.mothereffingtoolconfuser.com). This is almost a "needless
> to say" requirement anymore, but there are still checkers out there
> that only test the HTML source.
>
> Cheers
> -B
>
>
From: Preast, Vanessa
Date: Thu, Dec 15 2016 9:35AM
Subject: Re: Accessibility training and scanning solutions providers
← Previous message | Next message →
Also, for those like myself who are not HTML experts...
How would I know whether the checker is using the DOM or the HTML source?
Thanks.
Vanessa
From: Sean Keegan
Date: Fri, Dec 16 2016 10:00AM
Subject: Re: Accessibility training and scanning solutions providers
← Previous message | Next message →
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 ADDRESS REMOVED = >
> To: WebAIM Discussion List < = EMAIL ADDRESS 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.
>
>
>
From: Birkir R. Gunnarsson
Date: Fri, Dec 16 2016 11:03AM
Subject: Re: Accessibility training and scanning solutions providers
← Previous message | Next message →
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 ADDRESS 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 ADDRESS REMOVED = >
>> To: WebAIM Discussion List < = EMAIL ADDRESS 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.
>>
>>
>>
> > > > >
--
Work hard. Have fun. Make history.
From: L Snider
Date: Sat, Dec 17 2016 11:37AM
Subject: Re: Accessibility training and scanning solutions providers
← Previous message | Next message →
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 ADDRESS 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 ADDRESS 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 ADDRESS REMOVED = >
> >> To: WebAIM Discussion List < = EMAIL ADDRESS 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.
> >>
> >>
> >>
> > > > > > > > > >
>
>
> --
> Work hard. Have fun. Make history.
> > > > >
From: Birkir R. Gunnarsson
Date: Sat, Dec 17 2016 12:42PM
Subject: Re: Accessibility training and scanning solutions providers
← Previous message | Next message →
Well, at the end of the day it is all about whether the user can have
an accessible experience (ideally not just accessible, but also
usable).
That all comes down to how the website is designed and only partially
down to how it is coded.
I think e.g. that dynamic forms are a very good user experience if
done corectly.
By dynamic I mean forms that show you information and fields based on
your selections.
Imagine a set of radiobuttons. For each radiobutton you choose you'd
get a different set of form fields.
A poorly static html page would show you all of the fields for all
choices. Even if this form were perfectly marked up for accessibility
it would be cumbersome and confusing to fill in.
A dynamic form that only displays the info you need to fill in as you
select a radiobutton provides amuch better user experience, but it
requires CSS/JavaScript to make it happen.
Basically, if people avoid unnecessarily using ARIA and JavaScript and
use the HTML element most appropriate for the purpose, I am happy.
HTmL does not have all the answers (dynamic forms, live regions, tab
and menu constructs, modal dialogs, auto complete searches cannot be
implemented with HTML alone, HTML5 is moving us closer but we're still
far off).
People who build custom elements as a rule always get themselves in
trouble, because they don't understand all the nuances and
complexities of assistive technologies. Even if they do, the browsers
and a.t. themselves do not always know how to interpret the markup.
But people who think of JavaScript/ARIA as inherently inaccessible an
evil, and believe the web should still be coded using HTmL only are
not providing the users with the best experience
It's all about the the situation, the content and the desired user experience.
On 12/17/16, L Snider < = EMAIL ADDRESS REMOVED = > wrote:
> 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 ADDRESS 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 ADDRESS 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 ADDRESS REMOVED = >
>> >> To: WebAIM Discussion List < = EMAIL ADDRESS 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.
>> >>
>> >>
>> >>
>> > >> > >> > >> > >> >
>>
>>
>> --
>> Work hard. Have fun. Make history.
>> >> >> >> >>
> > > > >
--
Work hard. Have fun. Make history.
From: JP Jamous
Date: Sat, Dec 17 2016 1:19PM
Subject: Re: Accessibility training and scanning solutions providers
← Previous message | Next message →
I second Birkir on this one. I deal on daily bases with old code dated back to 2005.
I butt heads with UX teams because they get their analytics and they have zero information about people with ATs. That is why I trying to make changes to ensure we have the best user experience on our site.
Being a software and web developer in the past, I don't rely much on automated checkers. I want to test drive that sucker myself and get the user experience. Even iOS and Android emulators I try to stay away from. I want the actual device and I want to be on a fully opened network rather behind a proxy firewall.
All of the above, I learned that they can block what the customer experiences during a session. I want to be in that person's shoe despite the disability and get a feel for what is happening. I then do the automated checking.
I know I am weird, but I want to achieve 2 things.
1. Is the site providing an accessible and positive user experience?
2. How can I prioritize my work and establish proper documentations for developers based on what I am experiencing so they can remedy the issues.
If I am still getting some issues in the automated checker but the performance is excellent, then move on JP. That's how I like to approach those tasks. Relying on a program to make sense out of a pot of old, new and sloppy coding can frustrate the best decision maker. Of course, the checker will fail too many things.
From: Birkir R. Gunnarsson
Date: Sat, Dec 17 2016 1:51PM
Subject: Re: Accessibility training and scanning solutions providers
← Previous message | Next message →
I don´t like checkers that automatically flag use of ARIA as a failure
and stop checking. I see this in quite a few checkers.
The checkers need to understand ARIA and check if ARIA is being used
according to spec (because correctly used ARIA can imporve the user
experience, and it is a fully valid coding technique according to a
W3C standard).
I am fine with checkers flagging a warning that HTML has an element
that can do the same, but it shouldn´t be flagged as an error.
On 12/17/16, JP Jamous < = EMAIL ADDRESS REMOVED = > wrote:
> I second Birkir on this one. I deal on daily bases with old code dated back
> to 2005.
>
> I butt heads with UX teams because they get their analytics and they have
> zero information about people with ATs. That is why I trying to make changes
> to ensure we have the best user experience on our site.
>
> Being a software and web developer in the past, I don't rely much on
> automated checkers. I want to test drive that sucker myself and get the user
> experience. Even iOS and Android emulators I try to stay away from. I want
> the actual device and I want to be on a fully opened network rather behind a
> proxy firewall.
>
> All of the above, I learned that they can block what the customer
> experiences during a session. I want to be in that person's shoe despite the
> disability and get a feel for what is happening. I then do the automated
> checking.
>
> I know I am weird, but I want to achieve 2 things.
>
> 1. Is the site providing an accessible and positive user experience?
> 2. How can I prioritize my work and establish proper documentations for
> developers based on what I am experiencing so they can remedy the issues.
>
> If I am still getting some issues in the automated checker but the
> performance is excellent, then move on JP. That's how I like to approach
> those tasks. Relying on a program to make sense out of a pot of old, new and
> sloppy coding can frustrate the best decision maker. Of course, the checker
> will fail too many things.
>
>
From: JP Jamous
Date: Sat, Dec 17 2016 3:28PM
Subject: Re: Accessibility training and scanning solutions providers
← Previous message | Next message →
Yeah and sometimes they flag elements with the same IDs when execution wise, those similar IDs would not cause an issue.
From: JP Jamous
Date: Sat, Dec 17 2016 3:47PM
Subject: Re: Accessibility training and scanning solutions providers
← Previous message | Next message →
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.
From: Lovely, Brian (CONT)
Date: Mon, Dec 19 2016 6:41AM
Subject: Re: Accessibility training and scanning solutions providers
← Previous message | Next message →
The only time I would pass non-unique IDs is if the page is responsive and there is (for instance) the same header ID for desktop and mobile view but one is always hidden. Otherwise, it's not just bad coding but it can interfere with constructing the DOM or the accessible DOM.
From: Birkir R. Gunnarsson
Date: Mon, Dec 19 2016 7:23AM
Subject: Re: Accessibility training and scanning solutions providers
← Previous message | Next message →
When I was with Deque I wrote a blog on why unique ID ttributes matter
(based on a real case working with a real client).
http://www.deque.com/blog/unique-id-attributes-matter/
On 12/19/16, Lovely, Brian (CONT) < = EMAIL ADDRESS REMOVED = > wrote:
> The only time I would pass non-unique IDs is if the page is responsive and
> there is (for instance) the same header ID for desktop and mobile view but
> one is always hidden. Otherwise, it's not just bad coding but it can
> interfere with constructing the DOM or the accessible DOM.
>
>
From: Lovely, Brian (CONT)
Date: Mon, Dec 19 2016 7:28AM
Subject: Re: Accessibility training and scanning solutions providers
← Previous message | Next message →
Thanks for this Birkir. After reading this blog post no one will pass non-unique IDs, not will they lend you their laptop! :)
From: Birkir R. Gunnarsson
Date: Mon, Dec 19 2016 8:00AM
Subject: Re: Accessibility training and scanning solutions providers
← Previous message | No next message
*grin*
On 12/19/16, Lovely, Brian (CONT) < = EMAIL ADDRESS REMOVED = > wrote:
> Thanks for this Birkir. After reading this blog post no one will pass
> non-unique IDs, not will they lend you their laptop! :)
>
>