E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 9 (In chronological order)

From: Moore,Michael (Accessibility) (HHSC)
Date: Mon, May 16 2016 8:19AM
Subject: Why was software (user agents and authoring tools) left out of the recent SANPRM for the ADA by the DOJ?
No previous message | Next message →

Since there has been a lot of discussion of this apparent oversite I thought that I would make an attempt to explain.

The ADA covers three areas:

Title 1 Employment

Prohibits discrimination against people with disabilities in employment. Employers are not allowed to discriminate against a person who can perform the essential functions of a job because they have a disability. The employer must provide a "reasonable" accommodation for people with disabilities. Thus an employer would be expected to purchase accessible software needed to perform a job along with the assistive technology needed to use a computer in an office place. However, if none of the software that was available in the market place to perform a particular job function was accessible then the employer would not be obligated to develop their own.

Title 2 Public Services (This is the title covered by the SANPRM)

Prohibits discrimination against people with disabilities in the provision of public services. This means that information about the services, the application process, service delivery process, and any associated account management must be accessible to people with disabilities. The provision does not require fundamentally altering a service. The service provider is also protected from "undue burden" Much of the SANPRM at least on my first pass through appears to further define "undue burden" and fundamental alteration and does seem to place more responsibility on the agency providing the service to find and utilize accessible web based services when services are provided via the web.

Title 3 Public Accommodations and Services Operated by Private Entities

Prohibits discrimination against people with disabilities in private businesses that are open to the public. This one is where a lot of the action has been. The DOJ has interpreted the law to include on-line businesses and court decisions have backed them.

The problem is that the authoring tools, CMS/LMS systems, frameworks, script libraries and the rest of the stuff that is used to build services and put them on the web simply do not fall under the scope of the ADA. For open source project you could not even hold the project owners accountable as an employer. Yes Microsoft, Google, and Apple must make their workplace and public websites accessible but not necessarily their software...

Requiring that software, including authoring tools and plug-ins for websites be accessible will likely require additional action by congress. I will leave it to you to decide whether it is something that you would support and if so how it might actually be accomplished. The idea behind Section 508 and various state laws was at least partially to create commercial demand from federal and state agencies for accessible ICT (Information Communication Technology) products. Unfortunately, in many sectors no vendors are providing fully accessible products to so government agencies are forced to buy what is available.

Mike Moore
Accessibility Coordinator
Texas Health and Human Services Commission
Civil Rights Office
(512) 438-3431 (Office)

From: Brandon Keith Biggs
Date: Mon, May 16 2016 10:09AM
Subject: Re: Why was software (user agents and authoring tools) left out of the recent SANPRM for the ADA by the DOJ?
← Previous message | Next message →

Hello,
How this law should work in my oppinion is:
1. Government should not buy software if it is not fully accessible. (This
does not happen).
2. If a person is not able to use the software because of accessibility
problems, that is blatant discrimination. This is where the vendor
providing the software is liable because they provided a faulty product to
their customer.

Back to what should be done, has there been any kind of official
accessibility rating website? So authoring tools can have an accessibility
rating and see where they compare with other tools?
This would probably become a bone of contention for developers of open
source frameworks if they got a 1 out of 10 and other frameworks are around
9 or 10. That would allow people to select tools that are accessible.

Is there any kind of rating system for accessibility all across
dissibilities?
Thanks,


Brandon Keith Biggs <http://brandonkeithbiggs.com/>;

On Mon, May 16, 2016 at 7:19 AM, Moore,Michael (Accessibility) (HHSC) <
= EMAIL ADDRESS REMOVED = > wrote:

> Since there has been a lot of discussion of this apparent oversite I
> thought that I would make an attempt to explain.
>
> The ADA covers three areas:
>
> Title 1 Employment
>
> Prohibits discrimination against people with disabilities in employment.
> Employers are not allowed to discriminate against a person who can perform
> the essential functions of a job because they have a disability. The
> employer must provide a "reasonable" accommodation for people with
> disabilities. Thus an employer would be expected to purchase accessible
> software needed to perform a job along with the assistive technology needed
> to use a computer in an office place. However, if none of the software that
> was available in the market place to perform a particular job function was
> accessible then the employer would not be obligated to develop their own.
>
> Title 2 Public Services (This is the title covered by the SANPRM)
>
> Prohibits discrimination against people with disabilities in the provision
> of public services. This means that information about the services, the
> application process, service delivery process, and any associated account
> management must be accessible to people with disabilities. The provision
> does not require fundamentally altering a service. The service provider is
> also protected from "undue burden" Much of the SANPRM at least on my first
> pass through appears to further define "undue burden" and fundamental
> alteration and does seem to place more responsibility on the agency
> providing the service to find and utilize accessible web based services
> when services are provided via the web.
>
> Title 3 Public Accommodations and Services Operated by Private Entities
>
> Prohibits discrimination against people with disabilities in private
> businesses that are open to the public. This one is where a lot of the
> action has been. The DOJ has interpreted the law to include on-line
> businesses and court decisions have backed them.
>
> The problem is that the authoring tools, CMS/LMS systems, frameworks,
> script libraries and the rest of the stuff that is used to build services
> and put them on the web simply do not fall under the scope of the ADA. For
> open source project you could not even hold the project owners accountable
> as an employer. Yes Microsoft, Google, and Apple must make their workplace
> and public websites accessible but not necessarily their software...
>
> Requiring that software, including authoring tools and plug-ins for
> websites be accessible will likely require additional action by congress. I
> will leave it to you to decide whether it is something that you would
> support and if so how it might actually be accomplished. The idea behind
> Section 508 and various state laws was at least partially to create
> commercial demand from federal and state agencies for accessible ICT
> (Information Communication Technology) products. Unfortunately, in many
> sectors no vendors are providing fully accessible products to so government
> agencies are forced to buy what is available.
>
> Mike Moore
> Accessibility Coordinator
> Texas Health and Human Services Commission
> Civil Rights Office
> (512) 438-3431 (Office)
>
> > > > >

From: Chagnon | PubCom
Date: Mon, May 16 2016 1:00PM
Subject: Re: Why was software (user agents and authoring tools) left out of the recent SANPRM for the ADA by the DOJ?
← Previous message | Next message →

Great comments, Keith.
#1) The US federal government is required to purchase only computer software and hardware that is fully accessible to people using assistive technologies.

You're right, our federal government agencies don't follow the current law!

And our software companies aren't meeting the law, either. Example: how many people on this list consider the "read aloud" utility in Adobe Acrobat a functional, sufficient screen reader? How about the screen reader built into Windows?

With websites, they all are based on the HTML coding, regardless of which authoring tool is used to create the code. So even if the software authoring tool doesn't make a fully accessible website, it can still be hand-coded into compliance with any text editor, even NotePad. It's time-consuming, yes, but at least it's doable.

But that's not the case with documents. We're stuck with whatever we can create with Microsoft and Adobe software tools, especially when governments, educational institutions, and corporations are making the documents.

Think about the billions of government documents created every day.

How easy is it to make each Word, PowerPoint, or Excel document accessible? And InDesign layouts...let's not even discuss the code mess when a PDF is exported from an InDesign layout file, and the amount of money it takes to remediate it into accessibility. The discussion will make every taxpayer sick.

Shouldn't the millions of mere mortals (also known as government employees and contractors) be able to do this without purchasing thousands of dollars worth of software just to fix the documents, or spend hours...even days, making one document fully compliant? Or spend gazillions of dollars outsourcing the accessibility portion to contactors? (FYI, I'm in the middle of bidding on such a job right now.)

And what about the AT that doesn't do the full job for its users?

Or the AT user who doesn't take the time to read the user manual or control the AT?

Going back to the question of the original post: "Why was software (user agents and authoring tools) left out of the recent SANPRM for the ADA by the DOJ?"

Maybe DOJ doesn't fully understand the extend of the problem. I doubt they fully comprehend all the stakeholders' parts in the situation and how they each point fingers at the other, or claim that it will cost billions for them to retrofit their software. Such an undue burden...especially on the CEOs and stockholders.

Since DOJ takes it marching orders from the White House, maybe the current administration doesn't fully understand the problem. Given the presidential directives/recommendations/advisory letters/whatever you want to call them during the past couple of years, I'm thinking that this could be a root cause of the problem.

Maybe the lobbyists for these multi-billion-dollar companies did their job and put some muscle on DOJ.

Just my 2 cents worth as I sit inside the Washington DC Beltway. I'm just as baffled from my insider seat as you are!

—Bevi Chagnon

From: Brooks Newton
Date: Mon, May 16 2016 1:18PM
Subject: Re: Why was software (user agents and authoring tools) left out of the recent SANPRM for the ADA by the DOJ?
← Previous message | Next message →

Hi Mike,

Thanks for your breakdown of Title I, Title II and Title III of the ADA.

Obligatory disclaimer: I'm not a lawyer. Please hire a licensed attorney if you plan on taking action in the Web accessibility sphere that requires legal counsel.

Upon reflection, here's my opinion based on your post.

If the ADA has no "teeth," when it comes to enforcing the accessibility of software integral to the accessibility of the Web browsing experience, then we should loudly reject a change in the ADA, which would obligate site content owners to bear the full weight and responsibility of ensuring the accessibility of Web content. As I've mentioned in my previous posts, it is impossible for content owners and their production teams to make their Web content accessible without careful coordination with operating systems, user agents and assistive technology. It is dangerous and fool hearted exercise to pass federal civil rights law that unfairly targets online digital content owners who have not in any way shape or form been given the requisite support they need to post their content online accessibly.

I happen to be well-versed in the finer points of the Communications and Video Accessibility Act (CVAA), a set of landmark regulations, which unlike the ADA SANPRM, actually serves as the law of the land for qualifying content and services at the present time.

Granted, parts the CVAA strengthen the idea that software manufacturers should not hinder or block the "pass through" of accessible accommodations, such as the requirements for qualifying closed caption content video content. However, the Advanced Communication Services (ACS) provisions of the Act also makes the same mistake that ADA Title II SANPRM seems to be making in its preliminary form by largely excluding software manufacturers from culpability when accessibility is not achieved in online communications. Setting the enormous burden for digital accessibility squarely onto the backs of Web content owners, when mostly unregulated software fails to do its part in delivering an accessible experience, is beyond unfair - it is just plain bad public policy .

Let me provide a purely hypothetical CVAA case in point to underscore the shaky state of how the U.S. currently regulates online accessibility under the Act:

Company XX&Y, a telecommunications company, hosts an online real-time chat support forum for mobile handsets on its public Web servers. Because of the nature of this chat service (Web-based real-time or near real-time electronic messaging services), it falls under the obligations established by the ACS provision in the CVAA. The thoughtful owners of Company XX&Y have mandated that the chat forum developers build-out the near real-time text communication tool so that it works in conjunction with a couple of major browsers and an industry leading screen reader program to provide access to visually impaired users. The chat developers do their jobs coding the chat site well, they dutifully test their code with key browsers and the leading screen reader program and achieve accessible results.

Company XX&Y launches the chat service and everything is A-OK, for a while. Through no fault of their own, Company XX&Y receives a complaint from a member of the public, who is blind, stating that the support chat forum isn't accessible using a browser and the assistive technology XX&Y originally developed for and tested with. Upon further research, Company XX&Y learns that the screen reader software manufacturer, who operates under no CVAA regulations or obligations, released a new version of their software which has bug that fails to make accessible the features and functions that have been carefully coded by accessibility-friendly developers in the online support chat tool. Much like the ADA Title II SANPRM, the CVAA provides no safe harbor for ACS Web site owners who have exercised due diligence in developing and testing accessible content before launch. ACS site owners are required to know when something in the accessible software chain (OS/UA/AT) breaks, and are under the obligation to make their site work natively, without the help of assistive technology software. Failure to do so can burden the ACS Web site owner with FCC fines that may total $100,000 per day, up to a million dollars per violation. Again, all of the burden in this scenario is carried by the content owner / ACS owner, without any culpability built into the law for other necessary participants in the ACS Web experience game, third party software manufactures. Seem fair? Not by a longshot. The stakes are very high folks. And the rules are very biased in favor of software manufacturers.

Note: The CVAA mandates that in order for chat forum, an ACS by definition of the CVAA, to be compliant with the law, it must achieve a performance objective of actually being accessible to members of defined disabilities groups, including blind users. Technical compliance with a published standard, such as WCAG 2.0, is specifically prohibited as a "safe harbor" for ACS manufactures. In other words, saying you are compliant because you coded your chat forum software according to WCAG 2.0 AA specs, won't cut it alone, in terms of proving compliance with the law.

Mike and others on this list: You will be hard pressed to find another individual who believes more fervently in the concept of codifying accessibility responsibilities into law than I do. We've tried the voluntary scheme, and it has failed over the past 20 years to deliver equal access in the realm of online communications. I want a law in place that will protect folks who live with disabilities, providing them with a fighting chance to make full and complete use of the Web. However, I am not in favor of passing a new set of regulations that are not up to the challenge of fairly defining, balancing and enforcing obligations on the part of all the active players in the online accessible experience loop. I'm not a lawyer, so I'm not capable on my own of agreeing with your statement that operating systems, user agents, assistive technology, or authoring tools, frameworks and content management systems fall outside the scope of the ADA. If these entities do in fact fall outside of the scope of the ADA, then let's all agree find a better legal framework to ensure the accessibility of online content. And let's make sure that the Department of Justice gets the word that we, the experts, think the SANPRM fails to capture the entire list of culpable participants in the online accessibility sphere.

If you have not read the ADA Title II SANPRM recently announced by the U.S. Department of Justice, please take some time to peruse the document. It is approximately 40 pages of printed material, more if you expand the type to something readable! Here's the link, which was first published to this list by Sarah Bourne (thanks Sarah!): https://www.federalregister.gov/articles/2016/05/09/2016-10464/nondiscrimination-on-the-basis-of-disability-accessibility-of-web-information-and-services-of-state

This week I'll be posting my thoughts of parts of the SANPRM I can add value to as a participant in this forum. Thank you WebAIM for making this type of enlightened discourse possible.

Thanks,

Brooks Newton

From: Bryan Garaventa
Date: Mon, May 16 2016 1:24PM
Subject: Re: Why was software (user agents and authoring tools) left out of the recent SANPRM for the ADA by the DOJ?
← Previous message | Next message →

" Back to what should be done, has there been any kind of official accessibility rating website? So authoring tools can have an accessibility rating and see where they compare with other tools?"

Not that I'm aware of, but yes, having an index of open source projects and their accessibility ratings would indeed be useful.

Bryan Garaventa
Accessibility Fellow
SSB BART Group, Inc.
= EMAIL ADDRESS REMOVED =
415.624.2709 (o)
www.SSBBartGroup.com

From: Jonathan Avila
Date: Mon, May 16 2016 1:43PM
Subject: Re: Why was software (user agents and authoring tools)left out of the recent SANPRM for the ADA by the DOJ?
← Previous message | Next message →

> . Much like the ADA Title II SANPRM, the CVAA provides no safe harbor for ACS Web site owners who have exercised due diligence in developing and testing accessible content before launch. ACS site owners are required to know when something in the accessible software chain (OS/UA/AT) breaks, and are under the obligation to make their site work natively, without the help of assistive technology software.

CVAA allows for compliance with the ACS requirements by providing support for third party nominal cost assistive technology. So as long as a nominal-cost AT was available to support use by each of the functional performance criteria then the service provider is under no obligation to make it work with other/all assistive technologies. If the technology they were relying on for access is no longer available then yes they would need to find another way for the service to be functionally accessible. The FCC hinted in their report and order that following the WCAG 2 A and AA guidelines would likely allow a provider to meet the obligations -- but as you point out it's not required and it's not a given -- but likely a good case for the provider to argue.

Jonathan

Jonathan Avila
Chief Accessibility Officer
SSB BART Group
= EMAIL ADDRESS REMOVED =
703.637.8957 (Office)
Visit us online: Website | Twitter | Facebook | Linkedin | Blog
Check out our Digital Accessibility Webinars!

From: Brooks Newton
Date: Tue, May 17 2016 12:59PM
Subject: Re: Why was software (user agents and authoring tools) left out of the recent SANPRM for the ADA by the DOJ?
← Previous message | Next message →

Jonathan,

Based on your comment, I think it is important to further emphasize one of the primary differences between the CVAA and other Web accessibility regulations. The CVAA uses a set of performance objectives to measure compliance for Advanced Communication Systems (ACS), not a technical standard, such as WCAG 2.0. I didn't get that distinction from your latest post. What I got from your post is that WCAG 2.0 Level A or AA compliance will likely get an organization out of trouble based on a user complaint. I've got to say, that is not at all the way I understand it. I also want to clarify another critical point about the CVAA. The law assumes that qualifying ACS, such as online chat and other Web-based messaging systems, should be natively accessible. Yep, that is right, natively accessible without the aid of additional software, such as help from third party assistive technology. As you rightly pointed out, ACS manufacturers can rely on low-cost software to assist the ACS in meeting its performance objectives, but the chat room site owner, for example, is responsible for making sure the third party AT always supports the accessibility of the ACS. The moment the AT stops supporting the accessibility of the ACS, the ACS owner is on the hook for either providing access through another low-cost software solution, or they must magically invent a native means of meeting the performance objectives in the CVAA.

Long story short, Congress chose to put ACS owners on the hook bigtime, and severely limited support from software to make the Web-based communication tools accessible to people with disabilities. That's pretty hardcore, and frankly, flies in the face of what most of us in the digital accessibility industry know about the role of operating systems, user agents and assistive technology: they are integral to the accessible online experience for many people. I'm bringing up the CVAA because it is the last major piece of federal digital accessibility legislation passed by the U.S. Congress, and will likely have some level of influence on how legislation / regulation on the horizon will lean, such as the Title II and Title III ADA updates.

Here's some text from the CVAA Sections 716 and 717 Report and Order, dated October 7, 2011 - I think this is the document you were referring to in your post.

From Section 213 of the Report and Order: Background. Section 716(e)(1)(D) of the Act provides that the Commission "shall . . . not mandate technical standards, except that the Commission may adopt technical standards as a safe harbor for such compliance if necessary to facilitate the manufacturers' and service providers' compliance" with the accessibility and compatibility requirements in Section 716.583.

From Section 214: ... In light of the concerns raised in the record, the Commission proposed not to adopt any technical standards as safe harbors, and sought comment on its proposal.

Here's a link to relevant CVAA Report and Order pdf file for those who want to read the document directly: https://apps.fcc.gov/edocs_public/attachmatch/FCC-11-151A1.pdf#page’

Anybody else in the know want to comment? What am I missing here? I'm completely open to varying perspectives on this and all issues.

Thanks,

Brooks Newton

From: Jonathan Avila
Date: Wed, May 18 2016 12:03PM
Subject: Re: Why was software (user agents and authoring tools)left out of the recent SANPRM for the ADA by the DOJ?
← Previous message | Next message →

Brooks wrote:

> The CVAA uses a set of performance objectives to measure compliance for Advanced Communication Systems (ACS), not a technical standard, such as WCAG 2.0. I didn't get that distinction from your latest post.

To clarify I did not say or mean to imply that WCAG guidelines were included in the ACS requirements -- In my post I mentioned the functional performance objectives and then said this about web based serviced providers The FCC hinted in their report and order that following the WCAG 2 A and AA guidelines would likely allow a provider to meet the obligations -- but as you point out it's not required and it's not a given -- but likely a good case for the provider to argue."

The functional performance objectives of 47 CFR 14.21 are the criteria that must be used (when achievable) to measure compliance the requirements -- and I agree, congress did not give the FCC the authority to make technical requirements and yes there is no safe harbor by using WCAG 2. Having said that though, the FCC acknowledges the following in paragraph 85 of the report and order

"As is the case with manufacturers, providers of ACS are responsible for ensuring the accessibility of the underlying components of the service, to the extent that doing so is achievable. For example, a provider of a web-based e-mail service could meet its obligations by ensuring its services are coded to web accessibility standards (such as the Web Content Accessibility Guidelines (WCAG)177), if achievable." (https://apps.fcc.gov/edocs_public/attachmatch/FCC-11-151A1.txt paragraph 85)

Brooks wrote
> The law assumes that qualifying ACS, such as online chat and other Web-based messaging systems, should be natively accessible. Yep, that is right, natively accessible without the aid of additional software, such as help from third party assistive technology.

The ACS report and order states in paragraph 4
"The Report and Order requires manufacturers and service providers subject to Section 716 to comply with the requirements of Section 716 either by building accessibility features into their equipment or service or by relying on third party applications or other accessibility solutions."

Thus, there is industry flexibility to allow service providers to rely on accessibility features and nominal cost assistive technology. For example, in theory a service provider could rely on a style sheet plug-in to improve the contrast of a site or rely on an accessibility feature of a browser such as high contrast mode as long as it was nominal cost and was supported for the life time of the product/service or a replacement was made available. While I would like to see accessibility built into a product or service the ACS requirements allow for flexibility. One common example that is allowed by the current ACS requirements and even the and the separate WCAG is to rely on the browser to provide resize of text up to 200% without assistive technology. That is sites do not need to natively provide text sizing controls or even relative font sizes as long as the text can resized without loss of content or functionality up to 200% with browser zoom.

Best Regards,

Jonathan

Jonathan Avila
Chief Accessibility Officer
SSB BART Group
= EMAIL ADDRESS REMOVED =
703.637.8957 (Office)
Visit us online: Website | Twitter | Facebook | Linkedin | Blog
Check out our Digital Accessibility Webinars!

From: Brooks Newton
Date: Thu, May 19 2016 12:38PM
Subject: Re: Why was software (user agents and authoring tools) left out of the recent SANPRM for the ADA by the DOJ?
← Previous message | No next message

Hi Jonathan,

I think we are on the same sheet here. It makes perfect sense to move any and all responsibilities for accessibility from site owners to software, if and when the software can handle the responsibility consistently and effectively. Why depend on individual site owners and their production staff to do these things accessibly, when the tasks can be handled in a centralized, standardized accessible fashion through the operating system, user agent and/or assistive technology. I just re-read the UAAG 2.0 this week, which is available at https://www.w3.org/TR/UAAG20/ . This is a brilliantly crafted document, which assigns several accessibility tasks to the user agent that have previously been the responsibility of site owners / developers. Features the UAAG recommends as built-in functionality of browsers include things like form submission confirmation, a mechanism to avoid keyboard traps, capacity to zoom page content (as you mentioned), as well as other features such as user agent settings that disable media that plays automatically on page load. UAAG 2.0 also recommends that user agents provide some functionality that has previously been relegated to assistive technology, such as the capacity to traverse content via structural markup. If I've gotten this wrong W3C folks, please advise. I agree with Sharron Rush's earlier post that policymakers need to consider incorporating parts of the UAAG and ATAG into our laws and regulations. Good call, Sharron. I'm going to re-read ATAG 2.0 this weekend. https://www.w3.org/TR/ATAG20/

All of the user agent features I mentioned earlier complement or even replace requirements that have previously been in the content owner's bucket of accessibility responsibilities. That's cool by me. Let the software do what it does best. I'm sure this kind innovation through automation is a welcome source of support that content owners, designers and developers need. Just as we as accessibility practitioners should encourage a shift from hand review to machine review for issues that software handles accurately on a consistent basis, so to should we be accepting and encouraging of centralized software handling some of the heavy lifting that had previously been relegated to meticulous and fallible custom coding by site developers.

If we are in fact going to rely upon user agents and other forms of software to take over some of the accessibility responsibilities that we have long served up on site owners plates, then we need some type of formal assurance that the software manufacturers recognize this shift and accept the responsibility. In my opinion, that means there needs to be a shared legal responsibility between content owners and the software that allows the Web work for all of us. It's time we consider regulating some of the critical accessibility functions we are asking software to handle. This will free up developers to focus on accessibility responsibilities that software alone cannot yet handle. It will also give site owners the assurance that their money spent on accessibility fixes/features won't be wasted because the software isn't holding up its end of the bargain. Any content owners out there agree? Have I angered OS/UA/AT software developers past the point of return? What are your thoughts and concerns?

Last note in this post: I think my favorite Success Criterion in UAAG 2.0 is S.C. 4.1.2, Expose Accessible Properties - Here's the UAAG reference for this Success Criteria - https://www.w3.org/TR/2015/NOTE-UAAG20-Reference-20151215/#sc_412

If we could put browser manufacturers on the hook for honoring accessibility markup consistently, it would go a long way in giving site owners, designers and developers the support they need to build-out our online future accessibly. At the present, an awful lot of well-intentioned WAI-ARIA code goes unrecognized or improperly rendered by user agents, and is thus worthless in making advanced content accessible now. Actually, it is worse than worthless. If we were all honest with ourselves and with our clients, we would recommend presenting certain content in a simplified, old school HTML way instead of encouraging site owners to use newfangled, sporadically supported WAI-ARIA markup instead. How nice will it be when all of our elegant, cleanly coded recommended accessibility fixes actually work? In other words, I seriously look forward to a time when site content has a real chance to meet performance objectives versus achieving mere compliance with a technical standard...compliance that in no way guarantees actual access to users who live with disabilities that impact Web / mobile browsing. Holding software accountable for some of the accessibility responsibilities will take us a long way toward the goal of actual versus theoretical accessibility.

Over and Out,

Brooks Newton