E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 22 (In chronological order)

From: Sean Keegan
Date: Sun, Mar 29 2015 11:16AM
Subject: Name, Role, Value and Labels or Instructions techniques...
No previous message | Next message →

Hello all,

I am reviewing a web application that has many form fields that are using
the title attribute. To add to this, there is on-screen text for nearly all
the form fields but the <label> tag is not used consistently. It appears
that the title attribute was used initially to provide supplemental
information and then became more of a support for screen-readers.

I considered this is a fail under 4.1.2 (Name, Role, Value) and 3.3.2
(Labels and Instructions). It was pointed out to me that the technique H65
allows for the title attribute for form fields and this satisfies the
"programmatically determined" requirement as well as provides the relevant
instructions. I say shenanigans as the second part of the H65 technique
uses the phrase "when the label element cannot be used."

Any thoughts/comments from those all-knowing in the ways of WCAG?

(I know there are other limitations to the use of the title attribute for
form controls, but the discussion is centering on the WCAG 2.0 language and
aforementioned technique)

Take care,
Sean

From: Patrick H. Lauke
Date: Sun, Mar 29 2015 11:26AM
Subject: Re: Name, Role, Value and Labels or Instructions techniques...
← Previous message | Next message →

On 29/03/2015 18:16, Sean Keegan wrote:
> Any thoughts/comments from those all-knowing in the ways of WCAG?

To me, the important question with WCAG 2.0 is always: does it pass the
success criterion? Yes, they may not be using actual <label> elements,
but does their current markup still provide a name to those controls? As
the title attribute forms part of the accessible name calculation
http://www.w3.org/TR/wai-aria/roles#namecalculation_header I'd say this
does pass the SC (keeping in mind that techniques are only informative,
while the actual WCAG 2.0 SC are normative).

P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: Birkir R. Gunnarsson
Date: Sun, Mar 29 2015 11:28AM
Subject: Re: Name, Role, Value and Labels or Instructions techniques...
← Previous message | Next message →

This is not a fail under 4.1.2, because the title attribute is a valid
way to determine the accessible name according to the accessible name
calculation algorithm
http://www.w3.org/TR/wai-aria/roles#namecalculation
(if link does not take you directly to that section, it is section 5.2.7).
It is the last fallback for determining the accessible name, but it is
a valid option.
If it always 100% matches/communicates all the same information as the
visible text label, I would have a hard time calling it under 3.3.2 or
1.3.1. But if the on-screen text provides any additional info, such as
format of input, input restrictions, or any other useful info not
duplicated in title, 3.3.2 can be used.
I would always call a best practice problem under 1.3.1 because
visible text should be associated with having on-screen instructions
that are not connected with the form field.
Duplicating label in the title attribute for a form field is risky
because on-screen instructions can often be changed or updated and
people may forget to make the corresponding change to the title
attribute.
There are two ways to associated on-screen label with form field.
Explicit/implicit labeling using the label tag (explicit with a
for="id" association, implicit if form field and text are both wrapped
in a single label tag.
This has the advantage that mouse users can click anywhere on the
label to get focus into the form field.
The other is aria-labelledby conection from form field to the id of
the label text container.

Cheers



On 3/29/15, Sean Keegan < = EMAIL ADDRESS REMOVED = > wrote:
> Hello all,
>
> I am reviewing a web application that has many form fields that are using
> the title attribute. To add to this, there is on-screen text for nearly all
> the form fields but the <label> tag is not used consistently. It appears
> that the title attribute was used initially to provide supplemental
> information and then became more of a support for screen-readers.
>
> I considered this is a fail under 4.1.2 (Name, Role, Value) and 3.3.2
> (Labels and Instructions). It was pointed out to me that the technique H65
> allows for the title attribute for form fields and this satisfies the
> "programmatically determined" requirement as well as provides the relevant
> instructions. I say shenanigans as the second part of the H65 technique
> uses the phrase "when the label element cannot be used."
>
> Any thoughts/comments from those all-knowing in the ways of WCAG?
>
> (I know there are other limitations to the use of the title attribute for
> form controls, but the discussion is centering on the WCAG 2.0 language and
> aforementioned technique)
>
> Take care,
> Sean
> > > > >


--
Work hard. Have fun. Make history.

From: John Foliot
Date: Sun, Mar 29 2015 11:44AM
Subject: Re: Name, Role, Value and Labels or Instructions techniques...
← Previous message | Next message →

Sean Keegan wrote:

> Hello all,
>
> I am reviewing a web application that has many form fields that are
> using the title attribute. To add to this, there is on-screen text for
> nearly all the form fields but the <label> tag is not used
> consistently. It appears that the title attribute was used initially to
> provide supplemental information and then became more of a support for
> screen-readers.
>
> I considered this is a fail under 4.1.2 (Name, Role, Value) and 3.3.2
> (Labels and Instructions). It was pointed out to me that the technique
> H65 allows for the title attribute for form fields and this satisfies
> the "programmatically determined" requirement as well as provides the
> relevant instructions. I say shenanigans as the second part of the H65
> technique uses the phrase "when the label element cannot be used."
>
> Any thoughts/comments from those all-knowing in the ways of WCAG?


For me, the primary question to answer is - is the form usable by those users
requiring AT/screen readers? According to the "HTML to Platform Accessibility
APIs Implementation Guide" (currently still a draft, but accurate
non-the-less), using @title to provide an Accessible Name to a form input is
acceptable, as the algorithm calls for the following:

1. Use aria-labelledby
2. Otherwise use aria-label
3. Otherwise use the associated label element
4. Otherwise use the placeholder attribute
5. Otherwise use the title attribute
6. If none of the above yield a usable text string there is no accessible
name

(source:
http://www.w3.org/TR/html-aapi/#accessible-name-and-description-calculation)

Therefore, if each of the form inputs @title value serves as a useful
accessible name then it meets the practical requirement that drives the spirit
of WCAG. Further, basic testing confirms that this "works" with screen readers
today. Question: do the @title values "mirror" the on-screen text (exactly
and/or close-enough?). (Note, the algorithm also calls for 'processing' those
instructions in order, so for example if the form input has @placeholder text
present, the Accessibility API's are supposed to expose that value *before*
the value of @title - yes, this is a problem for cognition and low vision
deficits, but as far as the AAPI is concern, it isn't, it's a text value that
'labels' the input.)

If however you are mandated for a strict conformance to WCAG, then per your
reading I would issue, at a minimum, a warning that using the <label> element
is the "better" way of providing an accessible name (label) to form inputs.
However, using @title is not technically "wrong" and does work today.

This "predicament" reminds me of the old saying (regarding marriage) "You can
be right, or you can be married."

HTH

JF

From: Bryan Garaventa
Date: Sun, Mar 29 2015 2:23PM
Subject: Re: Name, Role, Value and Labels or Instructions techniques...
← Previous message | Next message →

Regarding the naming calculation, there are still issues with how this breaks down, as is being discussed at:
http://lists.w3.org/Archives/Public/public-pfwg/2015Mar/0155.html
Which is probably good for others to be aware of.

From: Sean Keegan
Date: Sun, Mar 29 2015 3:06PM
Subject: Re: Name, Role, Value and Labels or Instructions techniques...
← Previous message | Next message →

> Yes, they may not be using actual <label> elements, but does
> their current markup still provide a name to those controls?

Good question and I realized that I neglected to include an example of what
I was encountering. Here is one sample in which label is not used:

a) The on-screen text says "Social Security Number" and under that text
input field there is a sample as to how the social security number should
be formatted (###-##-####).

b) The title attribute in the input field says, "Please enter your number
in the described format. To change this information after completing the
application, please check under the Settings. If you do not include this
information, you will not be able to submit for financial aid."

Because there was such a disassociation between the on-screen text and
@title, I believed this would be a 3.3.2 issue as well as 4.1.2. I should
have also reviewed 1.3.1 (thanks, Birkir, I completely bypassed that one).

So, there is @title, it just is not equating to the on-screen text, thus I
saw this as failing 4.1.2. I agree that @title could be used, but to be
conformant it would need to have the social security number and formatting
information - yes?

Admittedly, I have a slight bias towards using <label> for form fields as
this provides options for someone using speech-recognition, so I need to
get over my issues with @title when it's used properly.

Thanks all for the reference to the accessible name calculation - that's a
great help.

Take care,
Sean

From: Birkir R. Gunnarsson
Date: Sun, Mar 29 2015 7:00PM
Subject: Re: Name, Role, Value and Labels or Instructions techniques...
← Previous message | Next message →

Based on this I would call a 3.3.2 for sure.
There are formatting instructions which need to be associated with the
form field, either using label, aria-describedby, title or
placeholder.
I would also call the fact that the title equivalent for screen
readers does not mention 'social security' number , just 'number', if
you copied this wor d for word.
I would finally include the 1.3.1 best practice mention. There is no
reason why the visible label present on screen is not associated with
the input field to ensure that the same information is presented to
all users.
I would not call 4.1.2, at a glance, because the field has an
accessible name, albeit an inaccurate one.




On 3/29/15, Sean Keegan < = EMAIL ADDRESS REMOVED = > wrote:
>> Yes, they may not be using actual <label> elements, but does
>> their current markup still provide a name to those controls?
>
> Good question and I realized that I neglected to include an example of what
> I was encountering. Here is one sample in which label is not used:
>
> a) The on-screen text says "Social Security Number" and under that text
> input field there is a sample as to how the social security number should
> be formatted (###-##-####).
>
> b) The title attribute in the input field says, "Please enter your number
> in the described format. To change this information after completing the
> application, please check under the Settings. If you do not include this
> information, you will not be able to submit for financial aid."
>
> Because there was such a disassociation between the on-screen text and
> @title, I believed this would be a 3.3.2 issue as well as 4.1.2. I should
> have also reviewed 1.3.1 (thanks, Birkir, I completely bypassed that one).
>
> So, there is @title, it just is not equating to the on-screen text, thus I
> saw this as failing 4.1.2. I agree that @title could be used, but to be
> conformant it would need to have the social security number and formatting
> information - yes?
>
> Admittedly, I have a slight bias towards using <label> for form fields as
> this provides options for someone using speech-recognition, so I need to
> get over my issues with @title when it's used properly.
>
> Thanks all for the reference to the accessible name calculation - that's a
> great help.
>
> Take care,
> Sean
> > > > >


--
Work hard. Have fun. Make history.

From: Gunderson, Jon R
Date: Mon, Mar 30 2015 8:38AM
Subject: Re: Name, Role, Value and Labels or Instructions techniques...
← Previous message | Next message →

Sean,

In terms of the ARIA specification and I believe the HTML5.1 specification, the TITLE attribute will be part of the accessible name calculation, usually as a last resort if no other means is available.

I feel the way you do, that when there are other "better" ways to do something (e.g. LABEL element) they should be used, but alias WCAG 2.0 is not about the "best" way, it is about "some" way to meet the accessibility requirement.

Jon

From: _mallory
Date: Tue, Mar 31 2015 2:01AM
Subject: Re: Name, Role, Value and Labels or Instructions techniques...
← Previous message | Next message →

On Mon, Mar 30, 2015 at 02:38:05PM +0000, Gunderson, Jon R wrote:
> Sean,
>
> In terms of the ARIA specification and I believe the HTML5.1 specification, the TITLE attribute will be part of the accessible name calculation, usually as a last resort if no other means is available.
>
> I feel the way you do, that when there are other "better" ways to do something (e.g. LABEL element) they should be used, but alias WCAG 2.0 is not about the "best" way, it is about "some" way to meet the accessibility requirement.
>

This whole thread makes no sense to me. If titles are inaccessible
to keyboard and speech-to-text users, how can this count as
"accessible"? Because a *screen reader* can access it?

I understand not everyone has the criteria of "must be generally
accessible" and instead need to meet specific WCAG requirements,
but I thought the whole point of WCAG was to help people build
things that worked, for *people*.

extremely horribly confused,
_mallory

From: Patrick H. Lauke
Date: Tue, Mar 31 2015 2:39AM
Subject: Re: Name, Role, Value and Labels or Instructions techniques...
← Previous message | Next message →

On 31/03/2015 09:01, _mallory wrote:
> This whole thread makes no sense to me. If titles are inaccessible
> to keyboard and speech-to-text users, how can this count as
> "accessible"? Because a *screen reader* can access it?

As per the OP, there is text visible in the page that acts as labels.
Just that it's not associated using <label>, and the controls instead
have a title attribute.

> I understand not everyone has the criteria of "must be generally
> accessible" and instead need to meet specific WCAG requirements,
> but I thought the whole point of WCAG was to help people build
> things that worked, for *people*.

But remember that one SC can pass while still not offering a solution
for everybody. Those excluded by the specific way an SC has been passed
will likely be vindicated by another SC failing.

So, assuming that there was no other text that acts as visual label for
a moment, but just title, this would pass 4.1.2 but fail 3.3.2.

P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: Ryan E. Benson
Date: Tue, Mar 31 2015 5:41AM
Subject: Re: Name, Role, Value and Labels or Instructions techniques...
← Previous message | Next message →

>As per the OP, there is text visible in the page that acts as labels. Just
that it's not associated using <label>, and the controls instead have a
title attribute.

Patrick, I am pretty sure Mallory is asking in general, *not* /this/ exact
situation. Frankly I have the same feelings as her. One of the things about
WCAG is it was supposed to be AT gnostic. It isn't now, sadly, in my eyes.
By saying @title is equivalent to label, we can have a form without any
text shown and it wouldn't flag any errors if all the needed text is in
@title. Now this would be poor UX, but I am showing how it could be done,
if somebody wanted a "clean design." As keyborder, personally I rely on the
labels for radios and checkboxes, since the default size is sometimes hard
for me to target.

--
Ryan E. Benson

On Tue, Mar 31, 2015 at 4:39 AM, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = >
wrote:

> On 31/03/2015 09:01, _mallory wrote:
>
>> This whole thread makes no sense to me. If titles are inaccessible
>> to keyboard and speech-to-text users, how can this count as
>> "accessible"? Because a *screen reader* can access it?
>>
>
> As per the OP, there is text visible in the page that acts as labels. Just
> that it's not associated using <label>, and the controls instead have a
> title attribute.
>
> I understand not everyone has the criteria of "must be generally
>> accessible" and instead need to meet specific WCAG requirements,
>> but I thought the whole point of WCAG was to help people build
>> things that worked, for *people*.
>>
>
> But remember that one SC can pass while still not offering a solution for
> everybody. Those excluded by the specific way an SC has been passed will
> likely be vindicated by another SC failing.
>
> So, assuming that there was no other text that acts as visual label for a
> moment, but just title, this would pass 4.1.2 but fail 3.3.2.
>
> P
> --
> Patrick H. Lauke
>
> www.splintered.co.uk | https://github.com/patrickhlauke
> http://flickr.com/photos/redux/ | http://redux.deviantart.com
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
> > > > >

From: Patrick H. Lauke
Date: Tue, Mar 31 2015 6:02AM
Subject: Re: Name, Role, Value and Labels or Instructions techniques...
← Previous message | Next message →

On 31/03/2015 12:41, Ryan E. Benson wrote:
> Patrick, I am pretty sure Mallory is asking in general, *not* /this/ exact
> situation. Frankly I have the same feelings as her. One of the things about
> WCAG is it was supposed to be AT gnostic. It isn't now, sadly, in my eyes.
> By saying @title is equivalent to label, we can have a form without any
> text shown and it wouldn't flag any errors if all the needed text is in
> @title.

We are not saying that @title is equivalent to label, we are saying that
@title provides a programmatically associated name that gets exposed to
AT in the same way that label does. It passes SC 4.1.2, which is
specifically concerned about programmatically exposed name, role and value.

As already noted, *just* having @title and no visible text that labels a
form control would pass 4.1.2, *but* it will fail SC 3.3.2. So the end
result is still that it would overall not comply with WCAG 2.0.

Again, not every SC addresses all forms of ability/disability. 4.1.2 is
almost exclusively aimed at AT support, for instance. What matters is
that there are enough complementary SCs that cover similar problems from
the different ability/disability/AT/non-AT viewpoints to ensure that
overall, something that doesn't work for a particular type of user
doesn't slip through the overall WCAG 2.0 assessment.

P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: Patrick H. Lauke
Date: Tue, Mar 31 2015 6:03AM
Subject: Re: Name, Role, Value and Labels or Instructions techniques...
← Previous message | Next message →

On 31/03/2015 12:41, Ryan E. Benson wrote:
> By saying @title is equivalent to label, we can have a form without any
> text shown and it wouldn't flag any errors if all the needed text is in
> @title.

To be clear: it wouldn't flag errors under 4.1.2, but it most definitely
would fail 3.3.2. So end result: it's not WCAG 2.0 compliant.

P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: Ryan E. Benson
Date: Tue, Mar 31 2015 6:22AM
Subject: Re: Name, Role, Value and Labels or Instructions techniques...
← Previous message | Next message →

>We are not saying that @title is equivalent to label, we are saying that
@title provides a programmatically associated name that gets exposed to AT
in the same way that label does.

But it is still considered equivalent, although not the preferred method. I
point to the W3C doc and list provided earlier in this thread.

>It passes SC 4.1.2, which is specifically concerned about programmatically
exposed name, role and value.

So with the new document, 4.1.2 and 3.3.2 success criterion, in a way,
contradict each other. Part of me ask why list something that can be done.
but really should not be done?

--
Ryan E. Benson

On Tue, Mar 31, 2015 at 8:02 AM, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = >
wrote:

> On 31/03/2015 12:41, Ryan E. Benson wrote:
>
>> Patrick, I am pretty sure Mallory is asking in general, *not* /this/ exact
>> situation. Frankly I have the same feelings as her. One of the things
>> about
>> WCAG is it was supposed to be AT gnostic. It isn't now, sadly, in my eyes.
>> By saying @title is equivalent to label, we can have a form without any
>> text shown and it wouldn't flag any errors if all the needed text is in
>> @title.
>>
>
> We are not saying that @title is equivalent to label, we are saying that
> @title provides a programmatically associated name that gets exposed to AT
> in the same way that label does. It passes SC 4.1.2, which is specifically
> concerned about programmatically exposed name, role and value.
>
> As already noted, *just* having @title and no visible text that labels a
> form control would pass 4.1.2, *but* it will fail SC 3.3.2. So the end
> result is still that it would overall not comply with WCAG 2.0.
>
> Again, not every SC addresses all forms of ability/disability. 4.1.2 is
> almost exclusively aimed at AT support, for instance. What matters is that
> there are enough complementary SCs that cover similar problems from the
> different ability/disability/AT/non-AT viewpoints to ensure that overall,
> something that doesn't work for a particular type of user doesn't slip
> through the overall WCAG 2.0 assessment.
>
>
> P
> --
> Patrick H. Lauke
>
> www.splintered.co.uk | https://github.com/patrickhlauke
> http://flickr.com/photos/redux/ | http://redux.deviantart.com
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
> > > > >

From: Patrick H. Lauke
Date: Tue, Mar 31 2015 6:27AM
Subject: Re: Name, Role, Value and Labels or Instructions techniques...
← Previous message | Next message →

On 31/03/2015 13:22, Ryan E. Benson wrote:
>> We are not saying that @title is equivalent to label, we are saying that
> @title provides a programmatically associated name that gets exposed to AT
> in the same way that label does.
>
> But it is still considered equivalent, although not the preferred method. I
> point to the W3C doc and list provided earlier in this thread.

"Preferred" is irrelevant, in my view. What counts with success criteria
is: does it pass the criterion or doesn't it pass the criterion.

>> It passes SC 4.1.2, which is specifically concerned about programmatically
> exposed name, role and value.
>
> So with the new document, 4.1.2 and 3.3.2 success criterion, in a way,
> contradict each other. Part of me ask why list something that can be done.
> but really should not be done?

They are not contradictory. First of all, they refer to different
aspects (one is concerned about the programmatically associated
name,role,state, the other about having clear labelling). And, as noted,
they are not contradictory because the following passes both 4.1.2 and
3.3.2 (you can then argue about whether one is "preferred" or "best
practice", but that argument is irrelevant in determining whether
something passes or fails SCs in my opinion):

<span>Username</span>
<input type="text" title="Username" ... >

(the @title satisfies 4.1.2, the preceding visible text in the <span>
satisfies 3.3.2)

P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: Léonie Watson
Date: Tue, Mar 31 2015 6:47AM
Subject: Re: Name, Role, Value and Labels or Instructions techniques...
← Previous message | Next message →

" So with the new document, 4.1.2 and 3.3.2 success criterion, in a way, contradict each other. Part of me ask why list something that can be done.
but really should not be done?"

I don't think they do contradict each other do they? 4.2.2 requires that a thing has an accessible name, 3.2.2 requires that it has a visible label. You can meet both in one go using the <label> element, or you can meet them separately using the title attribute and a different visual label. It's just different ways to get to the same outcome.


Léonie.
--
@LeonieWatson Tink.UK Carpe diem

From: Patrick H. Lauke
Date: Tue, Mar 31 2015 7:31AM
Subject: Re: Name, Role, Value and Labels or Instructions techniques...
← Previous message | Next message →

On 31/03/2015 14:18, Moore,Michael (DARS) wrote:
> I am not sure that using a title when a visible label is present
> (Technique H65) actually meets all of the requirements for labeling
> non text content (form controls). (4.1.2, 3.3.2, and 1.1.1)

Why?

> It
> certainly has the potential to cause confusion if the title and the
> label do not match.

Of course, anything that's done wrong can cause confusion.

> Technique H65 description: "The objective of this technique is to use
> the title attribute to label form controls when the visual design
> cannot accommodate the label (for example, if there is no text on the
> screen that can be identified as a label) or where it might be
> confusing to display a label. User agents, including assistive
> technology, can speak the title attribute."
>
> Since a visible label is present and is clear using the title instead
> of the label does not fulfil the use case for the technique.

Keep in mind that techniques are informative (and some of them aren't
particularly good/well worded), while only the SCs in WCAG 2.0 are
normative.

> Additionally marking up the label using something other than the
> label element may potentially violate 4.1.1 Using the markup language
> to spec. (Technique G192).

4.1.1 itself is only concerned with "elements have complete start and
end tags, elements are nested according to their specifications,
elements do not contain duplicate attributes, and any IDs are unique".

G192 goes further and demands full validation. But...you can't violate a
technique, as techniques are only informative. So full validation is not
required to pass WCAG 2.0. Also, HTML does not *mandate* that <label>
must be used, so arguably even not using <label> does not contravene the
HTML spec.

As we're looking around for other WCAG 2.0 SCs that may stick, 1.3.1
Info and Relationships may be a good one...you *could* argue that not
using <label> and having those labels correctly associated with their
form controls violates 1.3.1 - though, if the controls were to use
@title (or @aria-label, or even @placeholder), correctly - albeit
redundantly - to convey the exact same text, you could also argue that
the end result is the same.

P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: Moore,Michael (DARS)
Date: Tue, Mar 31 2015 7:18AM
Subject: Re: Name, Role, Value and Labels or Instructions techniques...
← Previous message | Next message →

From: Ryan E. Benson
Date: Tue, Mar 31 2015 6:41PM
Subject: Re: Name, Role, Value and Labels or Instructions techniques...
← Previous message | Next message →

>It's just different ways to get to the same outcome.

except when the scope is expanded to people not using screen readers, such
as my need for needing larger targets at times.

--
Ryan E. Benson

On Tue, Mar 31, 2015 at 8:47 AM, Léonie Watson < = EMAIL ADDRESS REMOVED = > wrote:

> " So with the new document, 4.1.2 and 3.3.2 success criterion, in a way,
> contradict each other. Part of me ask why list something that can be done.
> but really should not be done?"
>
> I don't think they do contradict each other do they? 4.2.2 requires that a
> thing has an accessible name, 3.2.2 requires that it has a visible label.
> You can meet both in one go using the <label> element, or you can meet them
> separately using the title attribute and a different visual label. It's
> just different ways to get to the same outcome.
>
>
> Léonie.
> --
> @LeonieWatson Tink.UK Carpe diem
>
>
> > > > >

From: Birkir R. Gunnarsson
Date: Wed, Apr 01 2015 1:10AM
Subject: Re: Name, Role, Value and Labels or Instructions techniques...
← Previous message | Next message →

It is a fact that WCAG definitely has a little bit of screen reader bias.
Well, that is only part of the story. The other part is that browser
vendors should have done a better job making keyboard only navigation
accessible, such as options or displaying title attributes onFocus as
well as onHover
Users with dexterity impairments should be able to click on the target
of aria-labelledby )which at that point is the programmatically
associated label for a form control) to move focus into the associated
input field or checks the associated radiobutton.
browsers should enable users to configure the default color and
appearance of placeholder text so that they can make placeholder color
contrast sufficient when necessary,
color contrast requirements should definitely be an A vs. a AA violation
..and so on.
screen reader users have the luxury of applications that take full
benfit of WCAG compliance. Sadly other groups of disabilities may not
have that luxury because they do not rely solely on assistive
technology to make webpages fully work for them.
This is a process, and hopefully we can move it forward, both in terms
of current browsers and other applications taking more advantage of
accessible mark-up, as well as keeping future improvements to our
standards in mind.
I think WCAG compliance offers a lot more accessibl scenarios than we
)the tech world= currently offer, which makes the future exciting.
-B



On 3/31/15, Ryan E. Benson < = EMAIL ADDRESS REMOVED = > wrote:
>>It's just different ways to get to the same outcome.
>
> except when the scope is expanded to people not using screen readers, such
> as my need for needing larger targets at times.
>
> --
> Ryan E. Benson
>
> On Tue, Mar 31, 2015 at 8:47 AM, Léonie Watson < = EMAIL ADDRESS REMOVED = > wrote:
>
>> " So with the new document, 4.1.2 and 3.3.2 success criterion, in a way,
>> contradict each other. Part of me ask why list something that can be done.
>> but really should not be done?"
>>
>> I don't think they do contradict each other do they? 4.2.2 requires that a
>> thing has an accessible name, 3.2.2 requires that it has a visible label.
>> You can meet both in one go using the <label> element, or you can meet
>> them
>> separately using the title attribute and a different visual label. It's
>> just different ways to get to the same outcome.
>>
>>
>> Léonie.
>> --
>> @LeonieWatson Tink.UK Carpe diem
>>
>>
>> >> >> >> >>
> > > > >


--
Work hard. Have fun. Make history.

From: Cliff Tyllick
Date: Tue, Apr 07 2015 10:50AM
Subject: Re: Name, Role, Value and Labels or Instructions techniques...
← Previous message | Next message →

Birkir said (in part):
> color contrast requirements should definitely be an A vs. a AA violation

Cliff responds:
Actually, I don't see why the systematic assignment of colors used for text and other meaningful content isn't a Level A guideline. Without that, we cannot ensure that all people with color- or contrast-sensitive deficits in vision will be able to make the content perceivable.

No one palette works for everyone in every situation. No one threshold value affords usable levels of contrast to every user. But giving the user control—systematic and, therefore, predictable control—over the site's or application's palette does ensure that the content can be perceivable to everyone.

Cliff Tyllick



Sent from my iPhone
Although its spellcheck often saves me, all goofs in sent messages are its fault.

> On Apr 1, 2015, at 2:10 AM, Birkir R. Gunnarsson < = EMAIL ADDRESS REMOVED = > wrote:
>
> It is a fact that WCAG definitely has a little bit of screen reader bias.
> Well, that is only part of the story. The other part is that browser
> vendors should have done a better job making keyboard only navigation
> accessible, such as options or displaying title attributes onFocus as
> well as onHover
> Users with dexterity impairments should be able to click on the target
> of aria-labelledby )which at that point is the programmatically
> associated label for a form control) to move focus into the associated
> input field or checks the associated radiobutton.
> browsers should enable users to configure the default color and
> appearance of placeholder text so that they can make placeholder color
> contrast sufficient when necessary,
> color contrast requirements should definitely be an A vs. a AA violation
> ..and so on.
> screen reader users have the luxury of applications that take full
> benfit of WCAG compliance. Sadly other groups of disabilities may not
> have that luxury because they do not rely solely on assistive
> technology to make webpages fully work for them.
> This is a process, and hopefully we can move it forward, both in terms
> of current browsers and other applications taking more advantage of
> accessible mark-up, as well as keeping future improvements to our
> standards in mind.
> I think WCAG compliance offers a lot more accessibl scenarios than we
> )the tech world= currently offer, which makes the future exciting.
> -B
>
>
>
> On 3/31/15, Ryan E. Benson < = EMAIL ADDRESS REMOVED = > wrote:
>>> It's just different ways to get to the same outcome.
>>
>> except when the scope is expanded to people not using screen readers, such
>> as my need for needing larger targets at times.
>>
>> --
>> Ryan E. Benson
>>
>>> On Tue, Mar 31, 2015 at 8:47 AM, Léonie Watson < = EMAIL ADDRESS REMOVED = > wrote:
>>>
>>> " So with the new document, 4.1.2 and 3.3.2 success criterion, in a way,
>>> contradict each other. Part of me ask why list something that can be done.
>>> but really should not be done?"
>>>
>>> I don't think they do contradict each other do they? 4.2.2 requires that a
>>> thing has an accessible name, 3.2.2 requires that it has a visible label.
>>> You can meet both in one go using the <label> element, or you can meet
>>> them
>>> separately using the title attribute and a different visual label. It's
>>> just different ways to get to the same outcome.
>>>
>>>
>>> Léonie.
>>> --
>>> @LeonieWatson Tink.UK Carpe diem
>>>
>>>
>>> >>> >>> >>> >>>
>> >> >> >> >>
>
>
> --
> Work hard. Have fun. Make history.
> > > >

From: Sailesh Panchang
Date: Tue, Apr 07 2015 12:29PM
Subject: Re: Name, Role, Value and Labels or Instructions techniques...
← Previous message | No next message

>>I feel the way you do, that when there are other "better" ways to do something (e.g. >>LABEL element) they should be used, but alias WCAG 2.0 is not about the "best" >>way, it is about "some" way to meet the accessibility requirement.
Sailesh: The technique documentation takes the trouble to recommend
different practices for different situations.
By following the recommended techniques one is able to achieve the
best possible outcome from an accessibility perspective.
When visible label is present, using implicit/explicit labelling to
associate the label text with the control helps a wider group of
users.
No ARIA is needed. Nor does one have to rely on multiple methods to
meet the needs of different user groups nor does one have to duplicate
label text in different attributes to meet different SC.
As accessibility consultants it is our duty to suggest the most
suitable technique to clients / developers and point out the
deficiencies from an accessibility perspective of using just any
technique in the book.
Disregard instructional info or data formats for the present but let
us focus on the basic label: Most will agree that when a title is
used to serve as a label when visible label is present, it is seldom
identical. This creates a disconnect between what one sees and what is
announced as the control's name to SR users. And of course it is more
work for coders even if it is 100% identical.
Thanks,
Sailesh


On 4/7/15, Cliff Tyllick < = EMAIL ADDRESS REMOVED = > wrote:
> Birkir said (in part):
>> color contrast requirements should definitely be an A vs. a AA violation
>
> Cliff responds:
> Actually, I don't see why the systematic assignment of colors used for text
> and other meaningful content isn't a Level A guideline. Without that, we
> cannot ensure that all people with color- or contrast-sensitive deficits in
> vision will be able to make the content perceivable.
>
> No one palette works for everyone in every situation. No one threshold value
> affords usable levels of contrast to every user. But giving the user
> control—systematic and, therefore, predictable control—over the site's or
> application's palette does ensure that the content can be perceivable to
> everyone.
>
> Cliff Tyllick
>
>
>
> Sent from my iPhone
> Although its spellcheck often saves me, all goofs in sent messages are its
> fault.
>
>> On Apr 1, 2015, at 2:10 AM, Birkir R. Gunnarsson
>> < = EMAIL ADDRESS REMOVED = > wrote:
>>
>> It is a fact that WCAG definitely has a little bit of screen reader bias.
>> Well, that is only part of the story. The other part is that browser
>> vendors should have done a better job making keyboard only navigation
>> accessible, such as options or displaying title attributes onFocus as
>> well as onHover
>> Users with dexterity impairments should be able to click on the target
>> of aria-labelledby )which at that point is the programmatically
>> associated label for a form control) to move focus into the associated
>> input field or checks the associated radiobutton.
>> browsers should enable users to configure the default color and
>> appearance of placeholder text so that they can make placeholder color
>> contrast sufficient when necessary,
>> color contrast requirements should definitely be an A vs. a AA violation
>> ..and so on.
>> screen reader users have the luxury of applications that take full
>> benfit of WCAG compliance. Sadly other groups of disabilities may not
>> have that luxury because they do not rely solely on assistive
>> technology to make webpages fully work for them.
>> This is a process, and hopefully we can move it forward, both in terms
>> of current browsers and other applications taking more advantage of
>> accessible mark-up, as well as keeping future improvements to our
>> standards in mind.
>> I think WCAG compliance offers a lot more accessibl scenarios than we
>> )the tech world= currently offer, which makes the future exciting.
>> -B
>>
>>
>>
>> On 3/31/15, Ryan E. Benson < = EMAIL ADDRESS REMOVED = > wrote:
>>>> It's just different ways to get to the same outcome.
>>>
>>> except when the scope is expanded to people not using screen readers,
>>> such
>>> as my need for needing larger targets at times.
>>>
>>> --
>>> Ryan E. Benson
>>>
>>>> On Tue, Mar 31, 2015 at 8:47 AM, Léonie Watson < = EMAIL ADDRESS REMOVED = > wrote:
>>>>
>>>> " So with the new document, 4.1.2 and 3.3.2 success criterion, in a way,
>>>> contradict each other. Part of me ask why list something that can be
>>>> done.
>>>> but really should not be done?"
>>>>
>>>> I don't think they do contradict each other do they? 4.2.2 requires that
>>>> a
>>>> thing has an accessible name, 3.2.2 requires that it has a visible
>>>> label.
>>>> You can meet both in one go using the <label> element, or you can meet
>>>> them
>>>> separately using the title attribute and a different visual label. It's
>>>> just different ways to get to the same outcome.
>>>>
>>>>
>>>> Léonie.
>>>> --
>>>> @LeonieWatson Tink.UK Carpe diem
>>>>
>>>>
>>>> >>>> >>>> >>>> >>>>
>>> >>> >>> >>> >>>
>>
>>
>> --
>> Work hard. Have fun. Make history.
>> >> >> >> > > > > >