Adding Korean screen reader data - Formerly Re: Accessibility Support - 4th option

I would also like to chime in with the importance of considering non-English speaking countries and other countries which try to adopt and use WCAG.

According to Makoto’s “accessibility supported” subgroup presentation<https://docs.google.com/presentation/d/1Oo7A6B44guvYaBkaFSBVaeSW1qCAglReaYqxSSsksNw/edit#slide=id.g146bfd02d17_0_66>, slide #11, there is a big difference in the functional level of screen readers in Japan.


     *   PC-Talker had more than 80% market share in Japan.
     *   It is only available for Japanese language, made by Japanese AT vendor.
     *   The support for HTML/ARIA is less than JAWS/NVDA

I also found the similar information regarding Korea. According to the survey, Korean screen reader is used 85.2% among 331 screen reader users.

The screen readers used in Korea(desktop only) - data by Korean Blind Union<http://www.kbuwel.or.kr/> in 2020
(Total of 331 screen readers were surveyed.)


  1.  Sense reader(Korean screen reader created by Korean AT vendor) – 282 people use – 85.2%
  2.  Jaws – 2 people use – 0.6%
  3.  NVDA – 14 people use – 4.2%
  4.  Narrator – 4 people use -1.2%
  5.  Voiceover – 25 people use – 7.6%
  6.  Others – 4 people use – 1.2%

Best,

JaEun Jemma Ku, Ph.D.
Director of IT Accessibility
Co-editor of W3C ARIA Authoring Practice Guide<https://www.w3.org/WAI/ARIA/apg/>
W3C Advisory Committee Representative

Office for Access and Equity <https://oae.uic.edu/> and Technology Solutions<https://it.uic.edu/>
University of Illinois Chicago<https://www.uic.edu/>
Email: jku@uic.edu<mailto:jku@uic.edu>

Pronouns: she/her/hers

From: Makoto Ueki <makoto.ueki@gmail.com>
Date: Thursday, September 1, 2022 11:04 PM
To: w3c-waI-gl@w3. org <w3c-wai-gl@w3.org>, Jonathan Avila <jon.avila@levelaccess.com>
Subject: Re: Accessibility Support - 4th option
Thanks so much, Jon. We'll discuss the 4th option at our subgroup meeting next week.

My concern is that it means WCAG will accept the situation where an AT doesn't work with a documented technique in a country, even if users of the AT can't access and use the content in reality. WCAG is the international guidelines and also used in other countries than English speaking countries. I think we need to care about different situations in different countries. That was one of the issues "accessibility-supported" concept tried to solve.

On the other hand, it could reduce burden on content author's side. We should discuss the 4th option carefully.

Best regards,
Makoto

2022年9月1日(木) 0:09 Gregg Vanderheiden <gregg@vanderheiden.us<mailto:gregg@vanderheiden.us>>:
Hmmm interesting

I agree with the sentiment but there is a hole in it re implementation.

Not sure that "standard documented platform and specification techniques"  is defined.
Is this a list?  Or up to each person to determine?
If you mean "one of the techniques documented in WCAG Techniques document"  - that is clear.
If you mean a technique documented in an accessibility standard - that would be clear - and is deterministic

Best is to keep it limited to documented techniques.
We have/had a form even where a company with a new technologies could submit potential techniques for consideration.
But as AWK pointed out — the key is that we don’t document techniques ourselves that are not accessibility supported.  by the way — the requirement for technology support - has been an incentive to companies with new technologies to work with AT vendors to achieve support.

Best

G

Gregg Vanderheiden
gregg@vanderheiden.us<mailto:gregg@vanderheiden.us>




On Aug 31, 2022, at 6:54 AM, Jonathan Avila <jon.avila@levelaccess.com<mailto:jon.avila@levelaccess.com>> wrote:

I’d like to propose to the group that we consider a 4th option to the 3 options outlined by the Accessibility Supported group which is discussing handling accessibility support in WCAG 3.0.

An option to consider is

  *   Allow authors to use standard documented platform and specification techniques without having to validate accessibility support

     *   For example, use of alt text on images, ARIA according to the specification, HTML attributes used according to the specification and align with documentation such as HTML API Mappings 1.0, etc.
     *   When non-standard methods are used then those methods would need to be accessiblity supported
This allows organizations to use standard documented known methods without having to worry about compatibility while at the same time allowing for flexibility to use other things as long as they work with a combination of user agents, assistive technologies, etc.  This is somewhat how things work today from a de facto standpoint.

For example, you could use autocomplete values to communicate input purpose without having to test for accessibility support.  But if you wanted to use another method such as metadata that was not documented by the specification then you would have to show it is accessiblity supported.

The challenge with this approach is who determines which platform or specification level documentation is allowed and how new specification features are adopted by assistive technology.  For example, HTML could add a new feature that is not yet supported by assistive technology.

Best Regards,

Jonathan