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
>
>
>