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

Hi Jemma,

Thank you so much for the information! Yes, I've heard about it.

I also added the data for Japanese screen readers to our working document
at:
https://docs.google.com/document/d/1XxzwsgWZSDh2EDqTag-nYfrqAT3b6Glpu8DGbVpTd9M/edit#heading=h.mn1h3f8yhtvv

Best regards,
Makoto


2022年9月22日(木) 0:26 Ku, JaEun Jemma <jku@uic.edu>:

> 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
>
>
>
> 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>:
>
> 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
>
>
>
>
>
>
>
> On Aug 31, 2022, at 6:54 AM, Jonathan Avila <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
>
>
>
>