Re: Question regarding browser-specific issues

I appreciate this discussion and value the input that everyone has brought
to the table.

Here's a quick outline of what I've stated below in this most recent post:


   - There are many more problems with lagging software accessibility
   support, than just browsers rendering low contrast page components.
   - Content authors need more and better native HTML markup, for example,
   to make modern ways of presenting web content accessible to people with
   disabilities.
   - The relevant layers in the software stack need to commit to supporting
   accessible markup in consistent, predictable and usable ways.
   - Design systems and frameworks need to follow the accessibility rules
   provided by standards bodies.
   - We need a thoughtful, ongoing transfer of ownership of appropriate
   digital accessibility issues away from content authors to wares
   manufacturers.
   - Instead of relying on a 6 year old set of specifications for user
   agents and authoring tools, we need a single integrated accessibility
   standard that reflects the true relationships between standards bodies,
   wares manufacturers, content authors and users.
   - The single source of digital accessibility guidance should ensure that
   properly marked up content is interoperable across the software stack,
   across platforms and across disability types.


In my personal opinion as a consultant to content authors, the fundamental
problems we have with making digital content accessible today go well
beyond contrast issues associated with browser rendered content.  For
example, we don't have enough tools in our markup toolbox to account for
the many and varied content constructs we see out in the wild.  Content
owners/authors depend upon a constant stream of improvements to
standards-based technologies (HTML, CSS, etc.) to accommodate these new
design patterns and components that pop-up and come into vogue.  The markup
we have to account for the innovations in interfaces, for example, is
severely lacking.  It is lacking in its scope and depth, and maybe more
importantly, in its adoption and adherence by wares manufacturers.  I can't
emphasize this last point enough.

Even if we had all of the enhanced native markup, etc. to account for these
new interface components, we need for all of the players in the software
stack to commit to supporting the new technologies in a way that supports
accessible user experiences.  Without that commitment, we are left to teach
developers and other digital production line workers to use theoretically
accessible approaches that won't work in practice.  It is a monumental
waste of precious business resources (not to mention credibility of our
cause) to send production teams on wild goose chases to achieve theoretical
compliance under the WCAG technical standard, but not achieve
performance-proven accessibility across software, platforms and
disabilities.  Want to get better buy-in from organizations around the
world who are trying to make their sites and apps accessible?  Give them
the accessible markup and and provide lessons on authoring practices they
need to accommodate their content.  But, make absolutely sure at the same
time that the software stack people with disabilities use to view a page,
fill out a form, etc. will support those code-level accommodations.  There
needs to be a single integrated standard that accounts for all of the
players in the user experience model.

When wares companies and standards bodies put all of the burden on content
authors to make their products accessible, it makes it exceedingly complex
and difficult for production teams to create accessible products that work
for real people with real disabilities. It also makes it difficult for end
users, because each content author organization has to custom script
interfaces that go much beyond the simple web some of us remember from the
previous century.  As a user, you have to ask yourself questions like "What
keyboard shortcuts do I have to use on this gizmo?" because no one has
created a standard that is broadly supported. Accessibility used to be
pretty easy to teach and to put into practice.  It isn't easy to teach or
practice at all now.  A large part of that problem is directly related to
non-native controls and new-fangled content constructs that have been
pushed by big tech.  This is the same big tech that has a significant
amount of control of whether or not accessible improvements to HTML and
other other technologies get baked into subsequent versions of those
technology specifications.

The UAAG and ATAG specifications haven't been touched in 5 years, right?
That's an eternity in the technology sphere.  And, those standards are not
nearly as comprehensive as the WCAG benchmark is.  In other words,
following the UAAG and ATAG standards as they are currently drafted will
not provide the necessary level of support required to maintain the
integrity of the accessible user experience.  From my recollection, work on
the UAAG and ATAG standards came to halt right about the time big tech
began introducing and evangelizing their own design systems and
frameworks.  These fancy new content templates by themselves introduced a
whole host of accessibility problems for consumers (content authors) and to
end users with disabilities.   As a web content accessibility auditor, I
can tell you that a significant portion of the errors I've logged over the
past 6 years or so have been from a number of big companies introducing
their custom design systems/frameworks without carefully coordinating their
products to fit within the WCAG rules that existed well in advance.  I have
no doubt that others in my profession have experienced the same
frustration.  Lack of supporting standards and a lack of consistent
adherence by all parties in the user experience is good for business, if
you are an accessibility consultant.  But, it's not so good if you are a
person with a disability who just wants to be able to use the web/mobile
app in a consistent, predictable, usable, productive, and self-reliant way.

Brooks Newton



>
>
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Virus-free.
www.avg.com
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>