Re: Question regarding browser-specific issues

Hi all,

Thanks for your comments and suggestions. That helped to establish that a number browser-specific accessibility issues do exist, especially in the area of contrasts. I appreciate that attempts have been made in the past and that new initiatives and consolidated guidelines by the W3C may eventually fix the issues. 

However, as I understand it, the situation leaves us with a principle problem when it comes to compliance. As a website owner, you are responsible for the contents that show up in users' browsers and for the decisions that have been made regarding technology, design, third-party content etc. 

Best practice is usually to use technology in accordance with its purpose, intentions and specification, and to rely as much as possible on standard components. When doing exactly that, we find that many websites fail different success criteria relating to  contrast (selected text, text in focus, focus indicator, ...) when rendered by browsers currently used by 80%+ of users (Chrome, Safari, Edge).

The result is that a very large proportion of websites will fail on contrast when presented in the browsers used by most users.

Advising website owners on compliance, that currently seems to leave us with (at least) two options:

1. Blame it on the browsers and advise users to select a compliant browser. From a formal point of view, this will likely address the compliance issue but the websites will still have accessibility issues. Furthermore, browsers with lesser uptake and better contrast support may introduce all sorts of other issues, accessibility and otherwise.

2. Advise clients to customize styling and/or develop bespoke components. This may address the particular accessibility issue, but is a move away from the best practice advise of using standard components and may introduce all sorts of other accessibility issues. Furthermore, it does not seem to be the most cost-efficient way of addressing the issues. 

IMHO, a much better way would be for Google, Apple and Microsoft to make those slight modifications to their internal stylesheets. If we could only find someone with the right contacts at the right level ...

Your thoughts and suggestions would be welcome. 

Venligst/Kind regards
 
Lars
----
Lars Ballieu Christensen 
Rådgiver/Adviser, Ph.D., M.Sc., Sensus ApS
Specialister i tilgængelighed/Accessibility Consultants 
Tel: +45 48 22 10 03 – Mobil: +45 40 32 68 23 - Skype: Ballieu
Mail: lbc@sensus.dk – Web: https://www.sensus.dk 
 
Vi arbejder for et tilgængeligt og rummeligt informationssamfund
Working for an accessible and inclusive information society

 

On 18/02/2021, 05.07, "Janina Sajka" <janina@rednote.net> wrote:

    In the past WAI attempted to address this with separate specifications
    WCAG for content, ATAG for authoring, UAAG for user agents.

    The current AGWG Charter rolls this all into WCAG 3, though the recently
    published FPWD doesn't reflect this expectation yet.

    I propose a good starting point for Silver, something I have raised and
    will raise again, would be low hanging fruit. My top suggestions:

    * Auto-playing audio. There's no reason a browser can't block
    * that.

    * Constraints on flashing can also be mitigated by user agents. I
    * would far rather depend on a user agent for such prophylaxis
    * than on the good behavior of content creators.

    May I note that flashing is life threatening to many who are sensitive
    to flashing. I think it's unique in that sense among WCAG SC.

    Best,

    Janina

    Patrick H. Lauke writes:
    > On 17/02/2021 23:21, Brooks Newton wrote:
    > > There will be no appetite if you haven't taken the first step in making
    > > it a possibility, which is to include all parties to the user experience
    > > in the master plan framework for accessibility. The W3C, or any other
    > > standards body for that matter, lacks the direct capacity to compel
    > > content authors to adjust their sites, apps, etc. to follow WCAG rules.
    > > So how did it work it out that WCAG only speaks to content authors, and
    > > not the other parties to the user experience?
    > 
    > Again, I'd refer you to UAAG and ATAG and the work that WAI has attempted in
    > the past at getting browser devs, AT devs, etc around the table. Sure, it
    > might be worth another shot, but let's not make it sound like this hasn't
    > actually been attempted before...
    > 
    > P
    > -- 
    > Patrick H. Lauke
    > 
    > https://www.splintered.co.uk/ | https://github.com/patrickhlauke
    > https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
    > twitter: @patrick_h_lauke | skype: patrick_h_lauke

    -- 

    Janina Sajka
    https://linkedin.com/in/jsajka

    Linux Foundation Fellow
    Executive Chair, Accessibility Workgroup: http://a11y.org

    The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
    Co-Chair, Accessible Platform Architectures http://www.w3.org/wai/apa

Received on Thursday, 18 February 2021 11:55:56 UTC