Re: CSS in Accessibility Name Computation (Was: a11y-outline available for Firefox)

+1 Stefan,

I've been lurking on this thread for a bit now. Personally, I've always
worked under the presumption that when it comes to modifying an element,
that the modifier that is closest to that element took precedence (ref: CSS
Cascade model). That being said, I would then argue that the @id attribute
of the input - which programmatically links to an onscreen string of text -
is the 'closer' of the two modifiers, as it is part of the element and thus
should be the default behavior.

More importantly however, I agree with Bryan & Stefan that we need a
'standard' here, whichever behavior is deemed 'correct'.

JF

On Sat, Feb 10, 2018 at 1:21 PM, Schnabel, Stefan <stefan.schnabel@sap.com>
wrote:

> My 2 cents here:
>
> You can argument that explicit declaration is always stronger than a code
> clamp (reference camp) or that closure wins (environment camp). Not sure
> what is the better approach but I agree that we need a standard here. Also
> I can imagine similar cases with other elements instead of input.
>
> Regards Stefan
>
> Von meinem iPad gesendet
>
> > Am 09.02.2018 um 21:02 schrieb Bryan Garaventa <
> bryan.garaventa@levelaccess.com>:
> >
> > Hi,
> > In case it's unclear why I'm asking about this, I just ran the following
> quick test.
> >
> > The following markup:
> >
> > <label>
> > This is
> > <input id="lbl" />
> > </label>
> > <label for="lbl">a test.</label>
> >
> > Results in the following Name property value in FF and Chrome.
> >
> > Firefox: "a test.This is"
> >
> > Chrome: "This is a test."
> >
> > These are two fundamentally different interpretations. Which is correct,
> or are both incorrect, and if so, what is correct?
> >
> > So I just need to know which one we can all agree is correct for us to
> go forward.
> >
> > Thanks,
> > Bryan
> >
> >
> > Bryan Garaventa
> > Accessibility Fellow
> > Level Access, Inc.
> > Bryan.Garaventa@LevelAccess.com
> > 415.624.2709 (o)
> > www.LevelAccess.com
> >
> > -----Original Message-----
> > From: Bryan Garaventa [mailto:bryan.garaventa@levelaccess.com]
> > Sent: Friday, February 09, 2018 9:41 AM
> > To: Schnabel, Stefan <stefan.schnabel@sap.com>; Tobias Bengfort <
> tobias.bengfort@posteo.de>; jcraig@apple.com; Matthew King <mck@fb.com>;
> ARIA Working Group <public-aria@w3.org>
> > Cc: Aaron Leventhal <aleventhal@google.com>; Alexander Surkov <
> asurkov@mozilla.com>; Marco Zehe <marco.zehe@gmail.com>; David Bolter <
> david.bolter@gmail.com>; Dominic Mazzoni <dmazzoni@google.com>; Joseph
> Scheuhammer <clown@alum.mit.edu>; Michael Cooper <cooper@w3.org>; Tess
> O'Connor <hober@apple.com>; Joanmarie Diggs (jdiggs@igalia.com) <
> jdiggs@igalia.com>
> > Subject: RE: CSS in Accessibility Name Computation (Was: a11y-outline
> available for Firefox)
> >
> > Hi,
> > Yes indeed, the algorithm already does this. What about the following
> markup instead?
> >
> > <label>
> > This is
> > <input id="lbl" />
> > </label>
> > <label for="lbl">is a test.</label>
> >
> > Basically what I need to know is, should only one be included or both,
> no matter where the explicit label is located in the DOM, above or below.
> >
> > Thanks,
> > Bryan
> >
> >
> > Bryan Garaventa
> > Accessibility Fellow
> > Level Access, Inc.
> > Bryan.Garaventa@LevelAccess.com
> > 415.624.2709 (o)
> > www.LevelAccess.com
> >
> > -----Original Message-----
> > From: Schnabel, Stefan [mailto:stefan.schnabel@sap.com]
> > Sent: Friday, February 09, 2018 12:23 AM
> > To: Bryan Garaventa <bryan.garaventa@levelaccess.com>; Tobias Bengfort <
> tobias.bengfort@posteo.de>; jcraig@apple.com; Matthew King <mck@fb.com>;
> ARIA Working Group <public-aria@w3.org>
> > Cc: Aaron Leventhal <aleventhal@google.com>; Alexander Surkov <
> asurkov@mozilla.com>; Marco Zehe <marco.zehe@gmail.com>; David Bolter <
> david.bolter@gmail.com>; Dominic Mazzoni <dmazzoni@google.com>; Joseph
> Scheuhammer <clown@alum.mit.edu>; Michael Cooper <cooper@w3.org>; Tess
> O'Connor <hober@apple.com>; Joanmarie Diggs (jdiggs@igalia.com) <
> jdiggs@igalia.com>
> > Subject: RE: CSS in Accessibility Name Computation (Was: a11y-outline
> available for Firefox)
> >
> > Bryan,
> >
> > <label>
> > This is
> > <input id="lbl" />
> > <label for="lbl">is a test.</label>
> > </label>
> >
> > https://html5.validator.nu/ says for your example:
> >
> >    Error: The element label must not appear as a descendant of the label
> element.
> >    From line 10, column 1; to line 10, column 17
> >    ="lbl" />↩<label for="lbl">is a t
> >
> > Shouldn't the discussion of edge cases be based on valid HTML5?
> >
> > - Stefan
> >
> > -----Original Message-----
> > From: Bryan Garaventa [mailto:bryan.garaventa@levelaccess.com]
> > Sent: Friday, February 9, 2018 8:57 AM
> > To: Tobias Bengfort <tobias.bengfort@posteo.de>; jcraig@apple.com;
> Matthew King <mck@fb.com>; ARIA Working Group <public-aria@w3.org>
> > Cc: Aaron Leventhal <aleventhal@google.com>; Alexander Surkov <
> asurkov@mozilla.com>; Marco Zehe <marco.zehe@gmail.com>; David Bolter <
> david.bolter@gmail.com>; Dominic Mazzoni <dmazzoni@google.com>; Joseph
> Scheuhammer <clown@alum.mit.edu>; Michael Cooper <cooper@w3.org>; Tess
> O'Connor <hober@apple.com>; Joanmarie Diggs (jdiggs@igalia.com) <
> jdiggs@igalia.com>
> > Subject: RE: CSS in Accessibility Name Computation (Was: a11y-outline
> available for Firefox)
> >
> > Hi,
> > No problem.
> >
> > I'm confused though, can you tell me what you would expect the label to
> be with the following markup?
> >
> > <label>
> > This is
> > <input id="lbl" />
> > <label for="lbl">is a test.</label>
> > </label>
> >
> >
> > Bryan Garaventa
> > Accessibility Fellow
> > Level Access, Inc.
> > Bryan.Garaventa@LevelAccess.com
> > 415.624.2709 (o)
> > www.LevelAccess.com
> >
> > -----Original Message-----
> > From: Tobias Bengfort [mailto:tobias.bengfort@posteo.de]
> > Sent: Thursday, February 08, 2018 10:52 PM
> > To: Bryan Garaventa <bryan.garaventa@levelaccess.com>; jcraig@apple.com;
> Matthew King <mck@fb.com>; ARIA Working Group <public-aria@w3.org>
> > Cc: Aaron Leventhal <aleventhal@google.com>; Alexander Surkov <
> asurkov@mozilla.com>; Marco Zehe <marco.zehe@gmail.com>; David Bolter <
> david.bolter@gmail.com>; Dominic Mazzoni <dmazzoni@google.com>; Joseph
> Scheuhammer <clown@alum.mit.edu>; Michael Cooper <cooper@w3.org>; Tess
> O'Connor <hober@apple.com>; Joanmarie Diggs (jdiggs@igalia.com) <
> jdiggs@igalia.com>
> > Subject: Re: CSS in Accessibility Name Computation (Was: a11y-outline
> available for Firefox)
> >
> > Thanks Bryan for all the work! I have just one quick remark:
> >
> >> On 09/02/18 01:54, Bryan Garaventa wrote:
> >> 3. Logic for handling nested label elements has been added, in which
> >> an implicit label element surrounds a form field that also includes an
> >> explicit form field reference somewhere else. There appears to be no
> >> standard in the naming computation to address this, so I set this to
> >> compute the explicit label and ignore the implicit one in such cases.
> >> This seems logical to me, but if everybody wants this to be handled
> >> differently it can be changed.
> >
> > I think the standard is actually clear about this: All labels should be
> included in the name. A labelable element is associated with a label
> element if:
> >
> > - the label element has a `for` attribute that matches the control's `id`
> > - the label element does not have a `for` attribute and the labelable
> element is the first labelable descendant of that label.
> >
> > This means that there can be more than one label for a labelable
> element. These labels should be processed in source order.
> >
> > Source: https://www.w3.org/TR/html52/sec-forms.html#the-label-element
> >
> > thanks
> > tobias
>



-- 
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
john.foliot@deque.com

Advancing the mission of digital accessibility and inclusion