Re: HTML Text Alternatives document question

On Thu, Sep 10, 2015 at 1:32 PM, jason@accessibleculture.org <
jason@accessibleculture.org> wrote:

> Inclusion in the glossary makes sense, but what definition would you use?
> The full, technical definition [7] is quite long. If a shorter, less
> complete definition is used, a link from the glossary entry to the full
> WCAG definition would still be in order, I think.
>

Makes sense.

On an unrelated question, why is there ongoing work in an editor’s draft of
> the note instead of in the editor’s draft of the HTML5.1 spec? If the alt
> attribute guidelines in the HTML5.1 spec already include earlier content
> from the working group note, I would expect to find the latest alt
> techniques in the latest editor’s draft of the HTML5.1 spec, especially
> since the latest published version of the alt techniques note [8] does not
> link to an editor’s draft, states that it is no longer being developed, and
> that it has been moved to the HTML5.1 spec.
>

Right.  This document is being developed by the HTML A11Y task force
basically as holding place for a cohesive set of changes that will be
proposed for the HTML 5.1 document.  We today requested that people review
the document.  It is at http://w3c.github.io/alt-techniques/ - feel free to
submit comments as issues against it's github repo.  Thanks!

>
> Jason
>
> [7]
> http://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html#uc-accessibility-support-head
> [8] http://www.w3.org/TR/html-alt-techniques/
>
>
>
> On 11/09/2015, at 4:00 am, Michiel Bijl <michiel@agosto.nl> wrote:
>
> +1
>
> —Michiel
>
> On 10 Sep 2015, at 15:18, Shane McCarron <shane@aptest.com> wrote:
>
> I think for the purposes of the text alternatives document, it might be
> good to just embed the definition in the local glossary (lifting it from
> WCAG).  Any objections?
>
> On Thu, Sep 10, 2015 at 4:38 AM, jason@accessibleculture.org <
> jason@accessibleculture.org> wrote:
>
>> I agree that the term is not widely used or understood. For what it’s
>> worth, it is used in some government contexts to establish what
>> technologies can or cannot be relied on to deliver accessible web content
>> according to those governments’ accessibility standards.
>>
>> In the Canadian government context, “accessibility supported”
>> technologies, and therefore technologies that can be relied on to deliver
>> an accessible experience are defined, in part, as those technologies for
>> which WCAG sufficient techniques exist [3].
>>
>> In Australia, the concept of accessibility support was used to address
>> the question of using PDF as a sole format [4]. Note that this position has
>> been modified slightly with the Australian Government’s more recent Digital
>> Service Standard [5], which still refers to the concept of accessibility
>> supported technologies.
>>
>> In New Zealand, we take a similar approach, and in effect, this again has
>> to do largely with the question of PDF and other non-HTML document formats
>> [6]. Whether the work that Adobe’s been doing to improve PDF accessibility
>> support for VoiceOver on Mac OS X will change our approach I cannot say
>> yet. There remain significant accessibility support issues on mobile
>> platforms. I can say that we are hopeful that EPUB3 will soon have
>> sufficient accessibility support across most platforms, user agents and
>> assistive technologies such that we can say it is a suitable single format
>> for packaged documents.
>>
>> While the concept of accessibility supported is not necessarily
>> transparent or easy to understand and explain, it can be useful for
>> establishing what technologies can or cannot be relied upon. That said, the
>> reliance of WCAG conformance on this same concept adds a degree of
>> complexity that can be difficult to address.
>>
>> For the figure and figcaption question, it would be useful to at least
>> link to the formal definition of "accessibility supported" in WCAG, if not
>> expand or replace it something along the lines of supported broadly by
>> user agents, including assistive technologies.
>>
>> Jason
>>
>> [3] See the refinement of WCAG 2.0 Conformance requirement 4 at
>> http://www.tbs-sct.gc.ca/pol/doc-eng.aspx?id=23601
>> [4]
>> http://webguide.gov.au/accessibility-usability/accessibility/pdf-accessibility/
>> [5] https://www.dto.gov.au/design-guides/guide/making-content-accessible
>> [6]
>> https://webtoolkit.govt.nz/guidance/design-and-development/accessibility-supported-technologies/
>>
>>
>> On 10/09/2015, at 8:46 pm, Léonie Watson <lwatson@paciellogroup.com>
>> wrote:
>>
>> *From:* ahby@aptest.com [mailto:ahby@aptest.com <ahby@aptest.com>] *On
>> Behalf Of *Shane McCarron
>> *Sent:* 10 September 2015 02:08
>>
>> "The text alternatives document [1] has a number of places where it says
>> "accessibility supported".  As in "Once figure and figcaption are
>> accessibility supported...".  Is this a term that we use a lot?  Is it well
>> defined / known?  It feels awkward to me and it isn't in the glossary.
>> Thoughts?"
>>
>> It's a term defined in WCAG [2]. That said, I don't think it's widely
>> used or widely understood for that matter.
>>
>> Léonie.
>> [1] https://w3c.github.io/alt-techniques/
>> [2]
>> http://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html#uc-accessibility-support-head
>>
>>
>> --
>> Senior accessibility engineer @PacielloGroup @LeonieWatson
>>
>>
>>
>>
>>
>>
>
>
> --
> Shane McCarron
> Managing Director, Applied Testing and Technology, Inc.
>
>
>
>


-- 
Shane McCarron
Managing Director, Applied Testing and Technology, Inc.