E-mail List Archives

Search E-mail List Archives for

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.

-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Bossley, Peter A.
Sent: Wednesday, December 14, 2016 12:35 PM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: [WebAIM] Accessibility training and scanning solutions providers

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,



The information contained in this e-mail is confidential and/or proprietary to Capital One and/or its affiliates and may only be used solely in performance of work or services for Capital One. The information transmitted herewith is intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer.

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.


-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Lucy Greco
Sent: Wednesday, December 14, 2016 1:56 PM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Accessibility training and scanning solutions providers

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: 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

-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jordan Wilson
Sent: Thursday, December 15, 2016 8:29 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Accessibility training and scanning solutions providers

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: 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

-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of L Snider
Sent: Thursday, December 15, 2016 10:04 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Accessibility training and scanning solutions providers

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: 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.

-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Birkir R. Gunnarsson
Sent: Saturday, December 17, 2016 1:43 PM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Accessibility training and scanning solutions providers

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.
>> >>
>> >>
>> >>
>> > >> > >> > archives at http://webaim.org/discussion/archives
>> > >> >
>>
>>
>> --
>> Work hard. Have fun. Make history.
>> >> >> archives at http://webaim.org/discussion/archives
>> >>
> > > archives at http://webaim.org/discussion/archives
> >


--
Work hard. Have fun. Make history.

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.
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Birkir R. Gunnarsson
> Sent: Saturday, December 17, 2016 1:43 PM
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Subject: Re: [WebAIM] Accessibility training and scanning solutions
> providers
>
> 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.
>>> >>
>>> >>
>>> >>
>>> > >>> > >>> > archives at http://webaim.org/discussion/archives
>>> > >>> >
>>>
>>>
>>> --
>>> Work hard. Have fun. Make history.
>>> >>> >>> archives at http://webaim.org/discussion/archives
>>> >>>
>> >> >> archives at http://webaim.org/discussion/archives
>> >>
>
>
> --
> Work hard. Have fun. Make history.
> > > http://webaim.org/discussion/archives
> >
> > > > >


--
Work hard. Have fun. Make history.

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.

-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Birkir R. Gunnarsson
Sent: Saturday, December 17, 2016 2:51 PM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Accessibility training and scanning solutions providers

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.
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf Of Birkir R. Gunnarsson
> Sent: Saturday, December 17, 2016 1:43 PM
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Subject: Re: [WebAIM] Accessibility training and scanning solutions
> providers
>
> 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.
>>> >>
>>> >>
>>> >>
>>> > >>> > >>> > archives at http://webaim.org/discussion/archives
>>> > >>> >
>>>
>>>
>>> --
>>> Work hard. Have fun. Make history.
>>> >>> >>> archives at http://webaim.org/discussion/archives
>>> >>>
>> >> >> archives at http://webaim.org/discussion/archives
>> >>
>
>
> --
> Work hard. Have fun. Make history.
> > > archives at http://webaim.org/discussion/archives
> >
> > > archives at http://webaim.org/discussion/archives
> >


--
Work hard. Have fun. Make history.

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.

-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of L Snider
Sent: Saturday, December 17, 2016 12:37 PM
To: WebAIM Discussion List < = EMAIL ADDRESS 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 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.
> >>
> >>
> >>
> > > > > > archives at http://webaim.org/discussion/archives
> > > >
>
>
> --
> Work hard. Have fun. Make history.
> > > archives at http://webaim.org/discussion/archives
> >

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.

-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of JP Jamous
Sent: Saturday, December 17, 2016 5:29 PM
To: 'WebAIM Discussion List' < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Accessibility training and scanning solutions providers

Yeah and sometimes they flag elements with the same IDs when execution wise, those similar IDs would not cause an issue.

-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Birkir R. Gunnarsson
Sent: Saturday, December 17, 2016 2:51 PM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Accessibility training and scanning solutions providers

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.
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf Of Birkir R. Gunnarsson
> Sent: Saturday, December 17, 2016 1:43 PM
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Subject: Re: [WebAIM] Accessibility training and scanning solutions
> providers
>
> 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.
>>> >>
>>> >>
>>> >>
>>> > >>> > >>> > archives at http://webaim.org/discussion/archives
>>> > >>> >
>>>
>>>
>>> --
>>> Work hard. Have fun. Make history.
>>> >>> >>> archives at http://webaim.org/discussion/archives
>>> >>>
>> >> >> archives at http://webaim.org/discussion/archives
>> >>
>
>
> --
> Work hard. Have fun. Make history.
> > > archives at http://webaim.org/discussion/archives
> >
> > > archives at http://webaim.org/discussion/archives
> >


--
Work hard. Have fun. Make history.
The information contained in this e-mail is confidential and/or proprietary to Capital One and/or its affiliates and may only be used solely in performance of work or services for Capital One. The information transmitted herewith is intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer.

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.
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of JP Jamous
> Sent: Saturday, December 17, 2016 5:29 PM
> To: 'WebAIM Discussion List' < = EMAIL ADDRESS REMOVED = >
> Subject: Re: [WebAIM] Accessibility training and scanning solutions
> providers
>
> Yeah and sometimes they flag elements with the same IDs when execution wise,
> those similar IDs would not cause an issue.
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Birkir R. Gunnarsson
> Sent: Saturday, December 17, 2016 2:51 PM
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Subject: Re: [WebAIM] Accessibility training and scanning solutions
> providers
>
> 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.
>>
>> -----Original Message-----
>> From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On
>> Behalf Of Birkir R. Gunnarsson
>> Sent: Saturday, December 17, 2016 1:43 PM
>> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
>> Subject: Re: [WebAIM] Accessibility training and scanning solutions
>> providers
>>
>> 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.
>>>> >>
>>>> >>
>>>> >>
>>>> > >>>> > >>>> > archives at http://webaim.org/discussion/archives
>>>> > >>>> >
>>>>
>>>>
>>>> --
>>>> Work hard. Have fun. Make history.
>>>> >>>> >>>> archives at http://webaim.org/discussion/archives
>>>> >>>>
>>> >>> >>> archives at http://webaim.org/discussion/archives
>>> >>>
>>
>>
>> --
>> Work hard. Have fun. Make history.
>> >> >> archives at http://webaim.org/discussion/archives
>> >>
>> >> >> archives at http://webaim.org/discussion/archives
>> >>
>
>
> --
> Work hard. Have fun. Make history.
> > > http://webaim.org/discussion/archives
> >
> > > http://webaim.org/discussion/archives
> > >
> The information contained in this e-mail is confidential and/or proprietary
> to Capital One and/or its affiliates and may only be used solely in
> performance of work or services for Capital One. The information transmitted
> herewith is intended only for use by the individual or entity to which it is
> addressed. If the reader of this message is not the intended recipient, you
> are hereby notified that any review, retransmission, dissemination,
> distribution, copying or other use of, or taking of any action in reliance
> upon this information is strictly prohibited. If you have received this
> communication in error, please contact the sender and delete the material
> from your computer.
> > > > >


--
Work hard. Have fun. Make history.

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! :)

-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Birkir R. Gunnarsson
Sent: Monday, December 19, 2016 9:23 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Accessibility training and scanning solutions providers

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.
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf Of JP Jamous
> Sent: Saturday, December 17, 2016 5:29 PM
> To: 'WebAIM Discussion List' < = EMAIL ADDRESS REMOVED = >
> Subject: Re: [WebAIM] Accessibility training and scanning solutions
> providers
>
> Yeah and sometimes they flag elements with the same IDs when execution
> wise, those similar IDs would not cause an issue.
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf Of Birkir R. Gunnarsson
> Sent: Saturday, December 17, 2016 2:51 PM
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Subject: Re: [WebAIM] Accessibility training and scanning solutions
> providers
>
> 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.
>>
>> -----Original Message-----
>> From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On
>> Behalf Of Birkir R. Gunnarsson
>> Sent: Saturday, December 17, 2016 1:43 PM
>> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
>> Subject: Re: [WebAIM] Accessibility training and scanning solutions
>> providers
>>
>> 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.
>>>> >>
>>>> >>
>>>> >>
>>>> > >>>> > >>>> > archives at http://webaim.org/discussion/archives
>>>> > >>>> >
>>>>
>>>>
>>>> --
>>>> Work hard. Have fun. Make history.
>>>> >>>> >>>> archives at http://webaim.org/discussion/archives
>>>> >>>>
>>> >>> >>> archives at http://webaim.org/discussion/archives
>>> >>>
>>
>>
>> --
>> Work hard. Have fun. Make history.
>> >> >> archives at http://webaim.org/discussion/archives
>> >>
>> >> >> archives at http://webaim.org/discussion/archives
>> >>
>
>
> --
> Work hard. Have fun. Make history.
> > > archives at http://webaim.org/discussion/archives
> >
> > > archives at http://webaim.org/discussion/archives
> > >
> The information contained in this e-mail is confidential and/or
> proprietary to Capital One and/or its affiliates and may only be used
> solely in performance of work or services for Capital One. The
> information transmitted herewith is intended only for use by the
> individual or entity to which it is addressed. If the reader of this
> message is not the intended recipient, you are hereby notified that
> any review, retransmission, dissemination, distribution, copying or
> other use of, or taking of any action in reliance upon this
> information is strictly prohibited. If you have received this
> communication in error, please contact the sender and delete the material from your computer.
> > > archives at http://webaim.org/discussion/archives
> >


--
Work hard. Have fun. Make history.
The information contained in this e-mail is confidential and/or proprietary to Capital One and/or its affiliates and may only be used solely in performance of work or services for Capital One. The information transmitted herewith is intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer.

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! :)
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Birkir R. Gunnarsson
> Sent: Monday, December 19, 2016 9:23 AM
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Subject: Re: [WebAIM] Accessibility training and scanning solutions
> providers
>
> 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.
>>
>> -----Original Message-----
>> From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On
>> Behalf Of JP Jamous
>> Sent: Saturday, December 17, 2016 5:29 PM
>> To: 'WebAIM Discussion List' < = EMAIL ADDRESS REMOVED = >
>> Subject: Re: [WebAIM] Accessibility training and scanning solutions
>> providers
>>
>> Yeah and sometimes they flag elements with the same IDs when execution
>> wise, those similar IDs would not cause an issue.
>>
>> -----Original Message-----
>> From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On
>> Behalf Of Birkir R. Gunnarsson
>> Sent: Saturday, December 17, 2016 2:51 PM
>> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
>> Subject: Re: [WebAIM] Accessibility training and scanning solutions
>> providers
>>
>> 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.
>>>
>>> -----Original Message-----
>>> From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On
>>> Behalf Of Birkir R. Gunnarsson
>>> Sent: Saturday, December 17, 2016 1:43 PM
>>> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
>>> Subject: Re: [WebAIM] Accessibility training and scanning solutions
>>> providers
>>>
>>> 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.
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> > >>>>> > >>>>> > archives at http://webaim.org/discussion/archives
>>>>> > >>>>> >
>>>>>
>>>>>
>>>>> --
>>>>> Work hard. Have fun. Make history.
>>>>> >>>>> >>>>> archives at http://webaim.org/discussion/archives
>>>>> >>>>>
>>>> >>>> >>>> archives at http://webaim.org/discussion/archives
>>>> >>>>
>>>
>>>
>>> --
>>> Work hard. Have fun. Make history.
>>> >>> >>> archives at http://webaim.org/discussion/archives
>>> >>>
>>> >>> >>> archives at http://webaim.org/discussion/archives
>>> >>>
>>
>>
>> --
>> Work hard. Have fun. Make history.
>> >> >> archives at http://webaim.org/discussion/archives
>> >>
>> >> >> archives at http://webaim.org/discussion/archives
>> >> >>
>> The information contained in this e-mail is confidential and/or
>> proprietary to Capital One and/or its affiliates and may only be used
>> solely in performance of work or services for Capital One. The
>> information transmitted herewith is intended only for use by the
>> individual or entity to which it is addressed. If the reader of this
>> message is not the intended recipient, you are hereby notified that
>> any review, retransmission, dissemination, distribution, copying or
>> other use of, or taking of any action in reliance upon this
>> information is strictly prohibited. If you have received this
>> communication in error, please contact the sender and delete the material
>> from your computer.
>> >> >> archives at http://webaim.org/discussion/archives
>> >>
>
>
> --
> Work hard. Have fun. Make history.
> > > http://webaim.org/discussion/archives
> > >
> The information contained in this e-mail is confidential and/or proprietary
> to Capital One and/or its affiliates and may only be used solely in
> performance of work or services for Capital One. The information transmitted
> herewith is intended only for use by the individual or entity to which it is
> addressed. If the reader of this message is not the intended recipient, you
> are hereby notified that any review, retransmission, dissemination,
> distribution, copying or other use of, or taking of any action in reliance
> upon this information is strictly prohibited. If you have received this
> communication in error, please contact the sender and delete the material
> from your computer.
> > > > >


--
Work hard. Have fun. Make history.