Re: CfC: Checkbox and Radio button labels and 1.3.1

John,

Thanks so much for the clarification.

The key is the <p> element. And the aria-label or title string must be
identical to the on-screen text. I won't recommend this technique, but
I understood that this could also meet the SC 1.3.1.

Thanks again for your time.

- Makoto


2015-12-09 2:22 GMT+09:00 John Foliot <john.foliot@deque.com>:
> Makoto UEKI - Infoaxia, Inc. [mailto:makoto.ueki@gmail.com] wrote:
>
>>
>
>> > via aria-label or title attribute
>
>> >  <p><input type=“checkbox” aria-label="Please send me a ton of email">
>
>> > Please send me a ton of email</p>
>
>> >
>
>> > AND:
>
>> >
>
>> > <p><input type=“checkbox” title="Please send me a ton of email">
>
>> > Please send me a ton of email</p>
>
>>
>
>> Have the working group reached the consensus that using aria-label or
>> title
>
>> attribute passes SC 1.3.1?
>
>
>
> I believe the answer is yes - both of those examples would meet the Success
> Criteria today.
>
>
>
>
>
>> As I commented on the github, the visible label text itself is not
>
>> programmatically determined even if those attributes provide the
>> accessible
>
>> name.
>
>>
>
>> SC 1.3.1 reads "Information, structure, and relationships conveyed through
>
>> presentation". In this case, the requirement of the SC would be to make
>> the
>
>> visible label text programmatically determinable as the label for the
>> checkbox.
>
>
>
> Actually, no, not exactly. From "Understanding SC 1.3.1"
> (http://www.w3.org/TR/UNDERSTANDING-WCAG20/content-structure-separation-programmatic.html):
>
>
>
> KEY TERMS:
>
>
>
>                Presentation:     rendering of the content in a form to be
> perceived by users
>
>
>
>                Programmatically determined (programmatically determinable):
> determined by software from author-supplied data provided in a way that
> different user agents, including assistive technologies, can extract and
> present this information to users in different modalities
>
>                   * Example 1: Determined in a markup language from elements
> and attributes that are accessed directly by commonly available assistive
> technology.
>
>                   * Example 2: Determined from technology-specific data
> structures in a non-markup language and exposed to assistive technology via
> an accessibility API that is supported by commonly available assistive
> technology.
>
>
>
>                Relationships:     meaningful associations between distinct
> pieces of content
>
>
>
>                Structure:
>
>                     *  The way the parts of a Web page are organized in
> relation to each other; and
>
>                     *  The way a collection of Web pages is organized
>
>
>
> *********************
>
>
>
> Taking the requirements individually:
>
>
>
>      <p><input type=“checkbox” aria-label="Please send me a ton of
> email">Please send me a ton of email</p>
>
>
>
> Information:
>
>                * There is a form input of TYPE: checkbox. Visually rendered
> as a box on screen, and announced to the screen reader via the AAPI.
>
>                * The checkbox, when selected, allows the user to submit the
> following: "Please send me a ton of email".
>                               * The non-sighted screen-reader user knows
> this because of the Accessible Name applied to the form input.
>
>                               * The sighted user knows this because the
> checkbox and onscreen "label" suggest this due to visual proximity.
>
>
>
> Structure:
>
> * The input is contained inside of the paragraph element, thus the text and
> the input are related - programmatically associated - as children of the
> paragraph. While this is hardly a Best Practices example, screen readers
> *can* determine individual paragraphs, and so the requirement is met.
>
>
>
> Not mentioned, but perhaps relevant here, is that due to the fact that the
> screen reader goes into "Forms Mode" [sic] querying the paragraph and page
> structure becomes significantly more difficult, as the end user needs to
> switch between the physical and virtual cursor. This is a *usability*
> problem however (and a significant one), but not an actual access /
> accessibility problem as the end user *can* determine what is required to
> complete the form when an accessible name is applied to the input.
>
> NOTE: Somebody did mention that perhaps if the aria-label or @title string
> was not identical to the on-screen text (in the paragraph - or grouping
> element) then *THAT* would be a Failure, and I agree. It's the fact that the
> label text string and the visible text string are identical which gives it
> the information equivalent, and the fact that both the onscreen text and the
> form input are contained within one grouping element (<P>) that allows it to
> claim conformance to SC 1.3.1.
>
>
>
>
>
> Relationship (conveyed through presentation):
>
> * BECAUSE the aria-label content, and the visual on-screen content is
> identical, the label provides the equivalent user experience - all users
> (sighted and non-sighted) are provided with the required information: this
> checkbox will submit "Please send me a ton of email". The relationship
> between the two ‘things’ (a form input and on-screen text) is created
> because they are both children of the same parent <p> element.
>
>
>
>
>
> JF



-- 
--
<以下、署名>

株式会社インフォアクシア
植木 真
<ueki@infoaxia.co.jp>

104-0054 東京都中央区勝どき1丁目13-6 プラザタワー勝どき 3011
TEL：03-5547-5777 FAX：03-5547-5778
http://www.infoaxia.co.jp/
https://www.facebook.com/weba11y.jp

Received on Tuesday, 8 December 2015 17:34:08 UTC