WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Name, Role, Value and Labels or Instructions techniques...

for

From: Sailesh Panchang
Date: Apr 7, 2015 12:29PM

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