E-mail List Archives
Thread: WebAIM-Forum Digest, Vol 166, Issue 17
Number of posts in this thread: 3 (In chronological order)
From: Minnery, Bob (EDU)
Date: Thu, Jan 17 2019 12:11PM
Subject: WebAIM-Forum Digest, Vol 166, Issue 17
No previous message | Next message →
This is above my skill set.
Can you walk me through this process?
How do you do this on your phone?
Where do you enter the script below?
. You have to add a bookmark to your browser then use the following
bookmarklets:
To increase the font size:
javascript:var
p=document.getElementsByTagName('*');for(i=0;i<p.length;i++){if(p[i].style.fontSize){var
s=parseInt(p[i].style.fontSize.replace("px",""));}else{var
s=12;}s+=2;p[i].style.fontSize=s+"px"}
Go Bold'n
bob Minnery
Manager
Alternative Educational Resources Ontario
W. Ross Macdonald School for the Visually Impaired and Deafblind
350 Brant Ave. Brantford On.,
N3T 3J9
= EMAIL ADDRESS REMOVED =
http://alternativeresources.ca
1-519-759-2522 ext.288
519-865-2772
-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of = EMAIL ADDRESS REMOVED =
Sent: January-17-19 2:00 PM
To: = EMAIL ADDRESS REMOVED =
Subject: WebAIM-Forum Digest, Vol 166, Issue 17
Send WebAIM-Forum mailing list submissions to
= EMAIL ADDRESS REMOVED =
To subscribe or unsubscribe via the World Wide Web, visit
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flist.webaim.org%2Fmailman%2Flistinfo%2Fwebaim-forum&data=02%7C01%7Cbob.minnery%40ontario.ca%7C24e9416ef9474648c33908d67caeaab3%7Ccddc1229ac2a4b97b78a0e5cacb5865c%7C0%7C1%7C636833486962759906&sdata=b8DCqIc5EBl5oFp8lh7tOURnnB1WLK1ox6gWib1Wu5U%3D&reserved=0
or, via email, send a message with subject or body 'help' to
= EMAIL ADDRESS REMOVED =
You can reach the person managing the list at
= EMAIL ADDRESS REMOVED =
When replying, please edit your Subject line so it is more specific than "Re: Contents of WebAIM-Forum digest..."
From: Peter Shikli
Date: Thu, Jan 31 2019 1:27PM
Subject: Re: WebAIM-Forum Digest, Vol 166, Issue 27
← Previous message | Next message →
Message 12 to 14 seem to have been cropped from this email posting. Please send.
Cheers,
Peter Shikli
----------------------------------------
From: = EMAIL ADDRESS REMOVED =
Sent: 1/31/19 11:00 AM
To: = EMAIL ADDRESS REMOVED =
Subject: WebAIM-Forum Digest, Vol 166, Issue 27
Send WebAIM-Forum mailing list submissions to
= EMAIL ADDRESS REMOVED =
To subscribe or unsubscribe via the World Wide Web, visit
http://list.webaim.org/mailman/listinfo/webaim-forum
or, via email, send a message with subject or body 'help' to
= EMAIL ADDRESS REMOVED =
You can reach the person managing the list at
= EMAIL ADDRESS REMOVED =
When replying, please edit your Subject line so it is more specific
than "Re: Contents of WebAIM-Forum digest..."
Today's Topics:
1. Beyonc?'s website in class-action lawsuit ( = EMAIL ADDRESS REMOVED = )
2. Using required attribute with a star mark VS Marking as
optional (Ramakrishnan Subramanian)
3. Re: Using required attribute with a star mark VS Marking as
optional (Graham Armfield)
4. Re: Native or web? (Mohith BP)
5. Re: Using required attribute with a star mark VS Marking as
optional (Isabel Holdsworth)
6. Re: Accessible, flexible select box (Isabel Holdsworth)
7. Re: Accessible, flexible select box (Isabel Holdsworth)
8. Re: Accessible, flexible select box ( = EMAIL ADDRESS REMOVED = )
9. Colour contrast and blue light filters (Pat Reynolds)
10. Re: Colour contrast and blue light filters (Patrick H. Lauke)
11. Re: Accessible, flexible select box (Isabel Holdsworth)
12. Re: Using required attribute with a star mark VS Marking as
optional (Birkir R. Gunnarsson)
13. Re: Colour contrast and blue light filters (Jonathan Avila)
14. Accessibility UI developers needed in CA, US (Jeevan Reddy)
----------------------------------------------------------------------
Message: 1
Date: Wed, 30 Jan 2019 16:24:45 -0500
From:
To: "'WebAIM Discussion List'"
Subject: [WebAIM] Beyonc?'s website in class-action lawsuit
Message-ID: <013001d4b8e2$391600d0$ab420270$@pubcom.com>
Content-Type: text/plain;charset="iso-8859-1"
Didn?t see this posted on the list.
Beyonc??s website cited for lack of accessibility.
News story is here:
https://musically.com/2019/01/07/beyonces-company-sued-over-the-accessibilit
y-of-her-website/
? ? ?
Bevi Chagnon, founder/CEO |
? ? ?
PubCom: Technologists for Accessible Design + Publishing
consulting ? training ? development ? design ? sec. 508 services
Upcoming classes at www.PubCom.com/ www.pubcom.com/classes=""> classes
? ? ?
------------------------------
Message: 2
Date: Thu, 31 Jan 2019 11:58:10 +0530
From: Ramakrishnan Subramanian
To: = EMAIL ADDRESS REMOVED =
Subject: [WebAIM] Using required attribute with a star mark VS Marking
as optional
Message-ID:
Content-Type: text/plain; charset="UTF-8"
Hi Team,
I would like to listen to your opinion on the following:
Marking the mandatory fields with the ?star mark and required
attribute? VS marking as ?optional? for the optional fields.
We know that the ideal recommendation for a form is to mark the
mandatory fields with the ?star mark? and with the ?required
attribute?. But, Instead of that, when the other practice is followed,
what are the pros and cons? And whether this practice is considered
WCAG compliant?
--
Thanks and Regards
Ramakrishnan
------------------------------
Message: 3
Date: Thu, 31 Jan 2019 08:14:50 +0000
From: Graham Armfield
To: WebAIM Discussion List
Subject: Re: [WebAIM] Using required attribute with a star mark VS
Marking as optional
Message-ID:
Content-Type: text/plain; charset="UTF-8"
Hi Ramakrishnan,
My own view is that it doesn't matter which way you do it as long as users
know what's going on.
The 'convention' of indicating required fields with a * goes back at least
to the early 2000s when I started building web things professionally. As
far as I am aware all screen readers announce the asterisk (*) as 'Star'
when in a page in English, but best to include it in the element
though. And it's also a good idea to have a message at the top of the form
that reads "Required data is marked with *" or similar.
Lately, probably as a result of the onset of greater scrutiny around
privacy, online forms are asking only for the data they really need. So the
tendency is much more that most input fields are required. So the reverse
approach of saying "All data fields are required, unless indicated." at the
top of the form seems much more common now.
Using the 'required' attribute does mean that screen readers announce the
field as required. However, I'm not a big fan of the default error messages
generated by browsers. In Firefox the "Please fill out this field" message
(and screen reader announcement) is just not specific enough - especially
if there are multiple required fields that have not been completed.
So I favour the use of aria-required="true" on the inputs, and some more
robust client-side validation that generates more meaningful error
messages, and also adds aria-invalid="true" to the input element if errors
are detected.
The challenge comes around radio button groups where the error might be
that the user hasn't selected one of the options, rather than the
individual options themselves. Is aria-required appropriate there I wonder?
Maybe a required message in the ?
Regards
Graham Armfield
coolfields.co.uk www.coolfields.co.uk/="">
M:07905 590026
T: 01483 856613
@coolfields
------------------------------
Message: 4
Date: Thu, 31 Jan 2019 14:27:57 +0530
From: Mohith BP
To: WebAIM Discussion List
Subject: Re: [WebAIM] Native or web?
Message-ID:
Content-Type: text/plain; charset="UTF-8"
Hi Barry,
You have mentioned:
"I was concerned that it
was an app written for IOS and probably uses java to emulate the gestures
used by a IOS device, but I'm concerned whether or not it will use the VO
gestures."
It is highly recommended to test with screen reader turned on to
verify that there are no custom gestures created, the gestures are not
interfering with the VO gestures and finally all the actions can be
performed without the specific gestures when screen reader is turned
off as per WCAG 2.1 SC 2.5.1:
2.5.1 Pointer Gestures:
All functionality that uses multipoint or path-based gestures for
operation can be operated with a single pointer without a path-based
gesture, unless a multipoint or path-based gesture is essential.
(Level A)
Note:
This requirement applies to web content that interprets pointer
actions (i.e. this does not apply to actions that are required to
operate the user agent or assistive technology).
Thanks & Regards,
Mohith B. P.
On 1/30/19, Jonathan Avila wrote:
> One trick I use to see if something is a webview or not is to look at the
> Voice Over rotor settings in iOS when focused on the content in question and
> see if there are HTML type rotor settings for links, lists, form controls,
> table, etc. If so you are in a webview.
>
> Jonathan
>
> Jonathan Avila, CPWA
> Chief Accessibility Officer
> Level Access
> = EMAIL ADDRESS REMOVED =
> 703.637.8957 office
>
> Visit us online:
> Website?|?Twitter?|?Facebook?|?LinkedIn?|?Blog
>
> Looking to boost your accessibility knowledge? Check out our free webinars!
>
> The information contained in this transmission may be attorney privileged
> and/or confidential information intended for the use of the individual or
> entity named above. If the reader of this message is not the intended
> recipient, you are hereby notified that any use, dissemination, distribution
> or copying of this communication is strictly prohibited.
>
> -----Original Message-----
> From: WebAIM-Forum On Behalf Of
> Patrick H. Lauke
> Sent: Tuesday, January 29, 2019 9:35 AM
> To: = EMAIL ADDRESS REMOVED =
> Subject: Re: [WebAIM] Native or web?
>
> CAUTION: This email originated from outside of the organization. Do not
> click links or open attachments unless you recognize the sender and know the
> content is safe.
>
>
> On 29/01/2019 13:37, Barry Hill wrote:
>> If an app is written using html ostensibly for IOS use only, which
>> guidelines would be most appropriate, WCAG 2.1 or mobile accessibility
>> guidelines? I think the pertinent question is, is it a native or a web
>> app?
>
> The more pertinent question here would be: when you say it's written using
> HTML, do you mean it's then packaged/cross-compiled, running inside a native
> app shell with a webview, or literally loaded in Safari?
> If the latter two, it's still web content shown by a web user agent (in the
> case of the webview, a very cut-down one in terms of user controls, but a
> user agent nonetheless). If it's cross-compiled and packaged (using
> something like PhoneGap), the lines get a bit more blurred (though I believe
> fundamentally it's still running inside a webview for the most part, so
> still web content).
>
> Also note that there aren't really separate/different mobile accessibility
> guidelines per se. There is guidance on how to apply/interpret WCAG 2.0 (not
> sure if there's a 2.1 version out yet) for mobile apps, but fundamentally
> the (tech agnostic) success criteria remain 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
> > > http://webaim.org/discussion/archives
> > > > > >
------------------------------
Message: 5
Date: Thu, 31 Jan 2019 09:44:21 +0000
From: Isabel Holdsworth
To: WebAIM Discussion List
Subject: Re: [WebAIM] Using required attribute with a star mark VS
Marking as optional
Message-ID:
Content-Type: text/plain; charset="UTF-8"
Hi,
The best implementation of marking up optional fields that works for
me personally is to somehow have the word "optional" in the label
belonging to each optional field. This could be inserted as an
aria-label or as the alt text of a graphic.
This is purely personal opinion.
Cheers, Isabel
On 31/01/2019, Graham Armfield wrote:
> Hi Ramakrishnan,
>
> My own view is that it doesn't matter which way you do it as long as users
> know what's going on.
>
> The 'convention' of indicating required fields with a * goes back at least
> to the early 2000s when I started building web things professionally. As
> far as I am aware all screen readers announce the asterisk (*) as 'Star'
> when in a page in English, but best to include it in the element
> though. And it's also a good idea to have a message at the top of the form
> that reads "Required data is marked with *" or similar.
>
> Lately, probably as a result of the onset of greater scrutiny around
> privacy, online forms are asking only for the data they really need. So the
> tendency is much more that most input fields are required. So the reverse
> approach of saying "All data fields are required, unless indicated." at the
> top of the form seems much more common now.
>
> Using the 'required' attribute does mean that screen readers announce the
> field as required. However, I'm not a big fan of the default error messages
> generated by browsers. In Firefox the "Please fill out this field" message
> (and screen reader announcement) is just not specific enough - especially
> if there are multiple required fields that have not been completed.
>
> So I favour the use of aria-required="true" on the inputs, and some more
> robust client-side validation that generates more meaningful error
> messages, and also adds aria-invalid="true" to the input element if errors
> are detected.
>
> The challenge comes around radio button groups where the error might be
> that the user hasn't selected one of the options, rather than the
> individual options themselves. Is aria-required appropriate there I wonder?
> Maybe a required message in the ?
>
>
> Regards
> Graham Armfield
> coolfields.co.uk www.coolfields.co.uk/="">
> M:07905 590026
> T: 01483 856613
> @coolfields
> > > > >
------------------------------
Message: 6
Date: Thu, 31 Jan 2019 09:50:35 +0000
From: Isabel Holdsworth
To: WebAIM Discussion List
Subject: Re: [WebAIM] Accessible, flexible select box
Message-ID:
Content-Type: text/plain; charset="UTF-8"
Thanks Birkir. No, it's just a plain old select box that we need, but
one that can be styled.
I'll file a bug now. Thanks again.
On 30/01/2019, Birkir R. Gunnarsson wrote:
> Wait, are you trying to implement a listbox (a dropdown of options) or
> a combobox (a text field that you can type in with an attached list of
> options / auto complete suggestions)?
> See the ARIA Authoring Practices patterns (section 3) for description
> and examples
> http://www.w3.org/TR/wai-aria-practices-1.1/
> We have implemented a custom listbox based on this example from the
> Authoring Practices
> http://www.w3.org/TR/wai-aria-practices-1.1/examples/listbox/listbox-collapsible.html
> If it is an auto complete you may want to code it so that the
> suggestions appear as buttons in responsive mode, I did a presentation
> of an accessible auto complete for iOS with an old friend of mine way
> back when. The presentation along with the examples can still be found
> at
> http://whenpush.a11yideas.com
>
> If iOS does not support correctly implemented ARIA listboxes, make
> sure to file a bug. They can afford to fix that.
> We can't keep telling developers not to do something that is
> technically valid because the software vendors who create assistive
> technologies aren't doing their bit. To become accessible everyone
> must chip in.
> It's that fine balance between making it usable today and making
> accessibility achievable tomorrow.
>
>
>
> On 1/30/19, Isabel Holdsworth wrote:
>> Hi Sean,
>>
>> That's a major piece of work you guys have done! It works pretty well
>> in Chrome with JAWS too.
>>
>> With respect, two reasons why I wouldn't advocate its use from an
>> accessibility perspective:
>>
>> 1. The custom select identifies itself as an edit field even though
>> it's not editable. There's plenty of information available for
>> screenreader users about how to navigate and select its content, but
>> being a purist I'm still uncomfortable about using elements that
>> identify as one form field type but behave like another. Do you know
>> if a selection can be made using speech input technologies such as
>> Dragon Naturally Speaking?
>>
>> 2. Using VoiceOver on iOS, I wasn't able to make a selection, nor even
>> in desperation enter any content into a field that identified itself
>> as an edit box. If this element were part of a form that I was filling
>> in on my phone, and the field was required, I wouldn't be able to
>> complete the form.
>>
>> Very nice work, but IMO it needs a few tweaks to be considered accessible.
>>
>> The search continues...
>>
>> Cheers, Isabel
>>
>> On 29/01/2019, Sean Curtis wrote:
>>> Hi Isabel,
>>>
>>> I helped improve the accessibility of the recent v2 release of
>>> react-select
>>> (https://react-select.com). Native selects are great up to a certain
>>> point:
>>> more than a couple of hundred options, especially when those options
>>> contain
>>> similar entries (like users with the same name) and the experience goes
>>> down
>>> the toilet.
>>>
>>> When digging into making this component accessible we initially went full
>>> semantics and aria. It felt ?right?, but we hit a wall after getting the
>>> simple stuff working. Things like aria-posinset/setsize just didn?t
>>> announce
>>> consistently, activedescendant was promising but AT support was extremely
>>> patchy, announcing a loading state when fetching new options after typing
>>> had no real aria attribute (aria-loading sounded right but didn?t do what
>>> it
>>> says on the box). The examples I?ve seen worked for selecting single
>>> values
>>> too, not for handling multi selects. We tried a mix of aria roles and
>>> live
>>> regions, but things got a bit muddled. It was difficult to predict things
>>> from a dev perspective.
>>>
>>> We ended up using live regions (we had to have 2 to reliably announce
>>> things, and this seems a common approach). The live region approach is
>>> the
>>> same route we took for react-beautiful-dnd, which is an incredibly
>>> performant yet also accessible drag-and-drop library. It?s the same
>>> approach
>>> that the Downshift Select component uses also. Having one
>>> approach/implementation made it very straightforward to develop and test.
>>> This is very important for ongoing maintainability and avoiding
>>> regressions.
>>>
>>> The downside is that as a dev you now need to provide internationalized
>>> strings for the various prompts ? not a huge ask but it?s something you?d
>>> get for free if you were just using html+aria. It was a trade off we were
>>> happy with.
>>>
>>> I believe there are some mobile optimized styles and touch interactions
>>> for
>>> react-select out of the box. It?s highly customizable as well (you can
>>> replace various components within it).
>>>
>>> Have a go and let me know how it performs. We?re building upon it for our
>>> design system components at Atlassian and it?s been a solid choice. It?s
>>> open source so fixing it is just a PR away :)
>>>
>>> Cheers,
>>>
>>> Sean
>>>
>>>> On 30 Jan 2019, at 3:53 am, glen walker wrote:
>>>>
>>>> Here are a few useful blogs:
>>>>
>>>> Short note on the accessibility of styled form controls
>>>>
>>>> Inclusive Considerations When Restyling Form Controls
>>>>
>>>> Accessible Styled Form Controls
>>>>
>>>> Styling a Select Like It?s 2019
>>>> www.filamentgroup.com/lab/select-css.html="">
>>>>
>>>> However, most of them talk about the native element as a>>>> combobox>>>> and not as a listbox.>>>>>>>> Glen>>>> ion/archives> flexible enough. Very frustrating!
On 29/01/2019, glen walker wrote:
> Here are a few useful blogs:
>
> Short note on the accessibility of styled form controls
>
> Inclusive Considerations When Restyling Form Controls
>
> Accessible Styled Form Controls
>
> Styling a Select Like It?s 2019
> www.filamentgroup.com/lab/select-css.html="">
>
> However, most of them talk about the native element as a combobox> and not as a listbox.>> Glen> one that can be styled.I'll file a bug now. Thanks again.On 30/01/2019, Birkir R. Gunnarsson wrote:> Wait, are you trying to implement a listbox (a dropdown of options) or > a combobox (a text field that you can type in with an attached list of > options / auto complete suggestions)?> See the ARIA Authoring Practices patterns (section 3) for description > and examples http://www.w3.org/TR/wai-aria-practices-1.1/>; We have implemented a custom listbox based on this example from the > Authoring Practices > http://www.w3.org/TR/wai-aria-practices-1.1/examples/listbox/listbox-c>; ollapsible.html If it is an auto complete you may want to code it so > that the suggestions appear as buttons in responsive mode, I did a > presentation of an accessible auto complete for iOS with an old friend > of mine way back when. The presentation along with the examples can > still be found at http://whenpush.a11yideas.com>;> If iOS does not support correctly implemented ARIA listboxes, make > sure to file a
bug. They can afford to fix that.> We can't keep telling developers not to do something that is > technically valid because the software vendors who create assistive > technologies aren't doing their bit. To become accessible everyone > must chip in.> It's that fine balance between making it usable today and making > accessibility achievable tomorrow.>>>> On 1/30/19, Isabel Holdsworth wrote:>> Hi Sean,>>>> That's a major piece of work you guys have done! It works pretty well >> in Chrome with JAWS too.>>>> With respect, two reasons why I wouldn't advocate its use from an >> accessibility perspective:>>>> 1. The custom select identifies itself as an edit field even though >> it's not editable. There's plenty of information available for >> screenreader users about how to navigate and select its content, but >> being a purist I'm still uncomfortable about using elements that >> identify as one form field type but behave like another. Do you know >> if a selection can be made using sp
eech input technologies such as >> Dragon Naturally Speaking?>>>> 2. Using VoiceOver on iOS, I wasn't able to make a selection, nor >> even in desperation enter any content into a field that identified >> itself as an edit box. If this element were part of a form that I was >> filling in on my phone, and the field was required, I wouldn't be >> able to complete the form.>>>> Very nice work, but IMO it needs a few tweaks to be considered accessible.>>>> The search continues...>>>> Cheers, Isabel>>>> On 29/01/2019, Sean Curtis wrote:>>> Hi Isabel,>>>>>> I helped improve the accessibility of the recent v2 release of >>> react-select (https://react-select.com). Native selects are great up >>> to a certain>>> point:>>> more than a couple of hundred options, especially when those options >>> contain similar entries (like users with the same name) and the >>> experience goes down the toilet.>>>>>> When digging into making this component accessible we initially went >>> full semantics and a
ria. It felt ?right?, but we hit a wall after >>> getting the simple stuff working. Things like aria-posinset/setsize >>> just didn?t announce consistently, activedescendant was promising >>> but AT support was extremely patchy, announcing a loading state when >>> fetching new options after typing had no real aria attribute >>> (aria-loading sounded right but didn?t do what it says on the box). >>> The examples I?ve seen worked for selecting single values too, not >>> for handling multi selects. We tried a mix of aria roles and live >>> regions, but things got a bit muddled. It was difficult to predict >>> things from a dev perspective.>>>>>> We ended up using live regions (we had to have 2 to reliably >>> announce things, and this seems a common approach). The live region >>> approach is the same route we took for react-beautiful-dnd, which is >>> an incredibly performant yet also accessible drag-and-drop library. >>> It?s the same approach that the Downshift Select component uses
>>> also. Having one approach/implementation made it very >>> straightforward to develop and test.>>> This is very important for ongoing maintainability and avoiding >>> regressions.>>>>>> The downside is that as a dev you now need to provide >>> internationalized strings for the various prompts ? not a huge ask >>> but it?s something you?d get for free if you were just using >>> html+aria. It was a trade off we were happy with.>>>>>> I believe there are some mobile optimized styles and touch >>> interactions for react-select out of the box. It?s highly >>> customizable as well (you can replace various components within it).>>>>>> Have a go and let me know how it performs. We?re building upon it >>> for our design system components at Atlassian and it?s been a solid >>> choice. It?s open source so fixing it is just a PR away :)>>>>>> Cheers,>>>>>> Sean>>>>>>> On 30 Jan 2019, at 3:53 am, glen walker wrote:>>>>>>>> Here are a few useful blogs:>>>>>>>> Short note on the accessibility o
f styled form controls >>>> >>>> -accessibility-of-styled-form-controls/>>>>> Inclusive Considerations When Restyling Form Controls >>>> >>>> rm-controls/>>>>> Accessible Styled Form Controls>>>> >>>> />>>>> Styling a Select Like It?s 2019>>>> www.filamentgroup.com/lab/select-css.html="">>>>>>>>> However, most of them talk about the native element as a
>>>> combobox and not as a listbox.
>>>>
>>>> Glen
>>>> >>>> >>>> archives at http://webaim.org/discussion/archives
>>>> >>> >>> >>> archives at http://webaim.org/discussion/archives
>>> >>>
>> >> >> archives at http://webaim.org/discussion/archives
>> >>
>
>
> --
> Work hard. Have fun. Make history.
> > > archives at http://webaim.org/discussion/archives
> >
------------------------------
Message: 9
Date: Thu, 31 Jan 2019 12:34:27 +0000
From: Pat Reynolds
To: = EMAIL ADDRESS REMOVED =
Subject: [WebAIM] Colour contrast and blue light filters
Message-ID:
Content-Type: text/plain; charset="UTF-8"
Hello,
We are working on a major overhaul of colours on all our sites, to make
them AA compliant. Does anyone know how these filters might impact on
accessibility, and what we might do to mitigate that?
With thanks,
Pat
-
*- -*
*Dr Pat Reynolds*
Executive Director
Free UK Genealogy www.freeukgenealogy.org.uk/="">
A Charitable Incorporated Organisation registered in England and Wales,
number 1167484
VAT registration: 233 0105 70
+44 1723 362616 +44 7943 145387
Westwood House,Westwood, Scarborough YO11 2JD, UK
------------------------------
Message: 10
Date: Thu, 31 Jan 2019 12:45:23 +0000
From: "Patrick H. Lauke"
To: = EMAIL ADDRESS REMOVED =
Subject: Re: [WebAIM] Colour contrast and blue light filters
Message-ID: < = EMAIL ADDRESS REMOVED = >
Content-Type: text/plain; charset=utf-8; format=flowed
On 31/01/2019 12:34, Pat Reynolds wrote:
> We are working on a major overhaul of colours on all our sites, to make
> them AA compliant. Does anyone know how these filters might impact on
> accessibility, and what we might do to mitigate that?
I'm assuming that you mean you're going to ensure the colour contrast
ratios of all foreground/background colour combinations are AA compliant
- minimum 4.5:1 for "regular" text / 3:1 for "large" text (and, if doing
WCAG 2.1, also minimum 3:1 for meaningful non-text content).
It will depend on the specific blue light filter used (as I don't think
there's any particular standard way in which these work), but while
these filters generally result in a duller/less pronounced/lowered
contrast overall, following at least the minimum WCAG contrast ratios
should still result in a strong-enough contrast. To be on the safe side,
stronger contrasts (not just trying to squeak past the 4.5:1 ratio, for
instance) will be better and safer. If it's a major concern, you can
always run a simulated blue filter and test the contrast ratios AFTER
the filter was applied, and tweak to ensure that they're strong enough
even when the filter is on.
Of course, with regards to WCAG, you should also ensure that color alone
is not used as an indicator/to convey meaning, as this may also
otherwise cause problems for users that run a blue filter.
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
------------------------------
Message: 11
Date: Thu, 31 Jan 2019 13:32:37 +0000
From: Isabel Holdsworth
To: WebAIM Discussion List
Subject: Re: [WebAIM] Accessible, flexible select box
Message-ID:
Content-Type: text/plain; charset="UTF-8"
All done and dusted. JAWS and NVDA are aware of how many items are in
the list, which item is selected, etc. It works very well with
everything except VoiceOver on iOS. I don't like custom controls, but
this one is as good as it gets.
Thanks everyone for your thoughts, , links to articles etc. This issue
has been bubbling on for months and I'm glad to be done with it :-)
On 31/01/2019, = EMAIL ADDRESS REMOVED = wrote:
> Refer to the w3c aria 1.1 or 1.0 if you are going to do a custom list box.
> Many of the list boxes I have tested all break when they don't use the
> select.
>
> -----Original Message-----
> From: WebAIM-Forum On Behalf Of
> Isabel Holdsworth
> Sent: Thursday, 31 January 2019 8:51 PM
> To: WebAIM Discussion List
> Subject: Re: [WebAIM] Accessible, flexible select box
>
> Thanks Birkir. No, it's just a plain old select box that we need, but one
> that can be styled.
>
> I'll file a bug now. Thanks again.
>
> On 30/01/2019, Birkir R. Gunnarsson wrote:
>> Wait, are you trying to implement a listbox (a dropdown of options) or
>> a combobox (a text field that you can type in with an attached list of
>> options / auto complete suggestions)?
>> See the ARIA Authoring Practices patterns (section 3) for description
>> and examples http://www.w3.org/TR/wai-aria-practices-1.1/
>> We have implemented a custom listbox based on this example from the
>> Authoring Practices
>> http://www.w3.org/TR/wai-aria-practices-1.1/examples/listbox/listbox-c
>> ollapsible.html If it is an auto complete you may want to code it so
>> that the suggestions appear as buttons in responsive mode, I did a
>> presentation of an accessible auto complete for iOS with an old friend
>> of mine way back when. The presentation along with the examples can
>> still be found at http://whenpush.a11yideas.com
>>
>> If iOS does not support correctly implemented ARIA listboxes, make
>> sure to file a bug. They can afford to fix that.
>> We can't keep telling developers not to do something that is
>> technically valid because the software vendors who create assistive
>> technologies aren't doing their bit. To become accessible everyone
>> must chip in.
>> It's that fine balance between making it usable today and making
>> accessibility achievable tomorrow.
>>
>>
>>
>> On 1/30/19, Isabel Holdsworth wrote:
>>> Hi Sean,
>>>
>>> That's a major piece of work you guys have done! It works pretty well
>>> in Chrome with JAWS too.
>>>
>>> With respect, two reasons why I wouldn't advocate its use from an
>>> accessibility perspective:
>>>
>>> 1. The custom select identifies itself as an edit field even though
>>> it's not editable. There's plenty of information available for
>>> screenreader users about how to navigate and select its content, but
>>> being a purist I'm still uncomfortable about using elements that
>>> identify as one form field type but behave like another. Do you know
>>> if a selection can be made using speech input technologies such as
>>> Dragon Naturally Speaking?
>>>
>>> 2. Using VoiceOver on iOS, I wasn't able to make a selection, nor
>>> even in desperation enter any content into a field that identified
>>> itself as an edit box. If this element were part of a form that I was
>>> filling in on my phone, and the field was required, I wouldn't be
>>> able to complete the form.
>>>
>>> Very nice work, but IMO it needs a few tweaks to be considered
>>> accessible.
>>>
>>> The search continues...
>>>
>>> Cheers, Isabel
>>>
>>> On 29/01/2019, Sean Curtis wrote:
>>>> Hi Isabel,
>>>>
>>>> I helped improve the accessibility of the recent v2 release of
>>>> react-select (https://react-select.com). Native selects are great up
>>>> to a certain
>>>> point:
>>>> more than a couple of hundred options, especially when those options
>>>> contain similar entries (like users with the same name) and the
>>>> experience goes down the toilet.
>>>>
>>>> When digging into making this component accessible we initially went
>>>> full semantics and aria. It felt ?right?, but we hit a wall after
>>>> getting the simple stuff working. Things like aria-posinset/setsize
>>>> just didn?t announce consistently, activedescendant was promising
>>>> but AT support was extremely patchy, announcing a loading state when
>>>> fetching new options after typing had no real aria attribute
>>>> (aria-loading sounded right but didn?t do what it says on the box).
>>>> The examples I?ve seen worked for selecting single values too, not
>>>> for handling multi selects. We tried a mix of aria roles and live
>>>> regions, but things got a bit muddled. It was difficult to predict
>>>> things from a dev perspective.
>>>>
>>>> We ended up using live regions (we had to have 2 to reliably
>>>> announce things, and this seems a common approach). The live region
>>>> approach is the same route we took for react-beautiful-dnd, which is
>>>> an incredibly performant yet also accessible drag-and-drop library.
>>>> It?s the same approach that the Downshift Select component uses
>>>> also. Having one approach/implementation made it very
>>>> straightforward to develop and test.
>>>> This is very important for ongoing maintainability and avoiding
>>>> regressions.
>>>>
>>>> The downside is that as a dev you now need to provide
>>>> internationalized strings for the various prompts ? not a huge ask
>>>> but it?s something you?d get for free if you were just using
>>>> html+aria. It was a trade off we were happy with.
>>>>
>>>> I believe there are some mobile optimized styles and touch
>>>> interactions for react-select out of the box. It?s highly
>>>> customizable as well (you can replace various components within it).
>>>>
>>>> Have a go and let me know how it performs. We?re building upon it
>>>> for our design system components at Atlassian and it?s been a solid
>>>> choice. It?s open source so fixing it is just a PR away :)
>>>>
>>>> Cheers,
>>>>
>>>> Sean
>>>>
>>>>> On 30 Jan 2019, at 3:53 am, glen walker wrote:
>>>>>
>>>>> Here are a few useful blogs:
>>>>>
>>>>> Short note on the accessibility of styled form controls
>>>>>
>>>>> -accessibility-of-styled-form-controls/>
>>>>> Inclusive Considerations When Restyling Form Controls
>>>>>
>>>>> rm-controls/>
>>>>> Accessible Styled Form Controls
>>>>>
>>>>> />
>>>>> Styling a Select Like It?s 2019
>>>>> www.filamentgroup.com/lab/select-css.html="">
>>>>>
>>>>> However, most of them talk about the native element as a>>>>> combobox and not as a listbox.>>>>>>>>>> Glen>>>>> ://webaim.org/discussion/archives>> possible for them.On 1/31/19, Isabel Holdsworth wrote:> Hi,>> The best implementation of marking up optional fields that works for> me personally is to somehow have the word "optional" in the label> belonging to each optional field. This could be inserted as an> aria-label or as the alt text of a graphic.>> This is purely personal opinion.>> Cheers, Isabel>> On 31/01/2019, Graham Armfield wrote:>> Hi Ramakrishnan,>>>> My own view is that it doesn't matter which way you do it as long as>> users>> know what's going on.>>>> The 'convention' of indicating required fields with a * goes back at>> least>> to the early 2000s when I started building web things professionally. As>> far as I am aware all screen readers announce the asterisk (*) as 'Star'>> when in a page in English, but best to include it in the element>> though. And it's also a good idea to have a message at the top of the>> form>> that reads "Required data is marked with *" or similar.>>>> Lately, probably as a result of th
e onset of greater scrutiny around>> privacy, online forms are asking only for the data they really need. So>> the>> tendency is much more that most input fields are required. So the reverse>> approach of saying "All data fields are required, unless indicated." at>> the>> top of the form seems much more common now.>>>> Using the 'required' attribute does mean that screen readers announce the>> field as required. However, I'm not a big fan of the default error>> messages>> generated by browsers. In Firefox the "Please fill out this field">> message>> (and screen reader announcement) is just not specific enough - especially>> if there are multiple required fields that have not been completed.>>>> So I favour the use of aria-required="true" on the inputs, and some more>> robust client-side validation that generates more meaningful error>> messages, and also adds aria-invalid="true" to the input element if>> errors>> are detected.>>>> The challenge comes around radio button groups where
the error might be>> that the user hasn't selected one of the options, rather than the>> individual options themselves. Is aria-required appropriate there I>> wonder?>> Maybe a required message in the ?>>>>>> Regards>> Graham Armfield>> coolfields.co.uk www.coolfields.co.uk/="">>> M:07905 590026>> T: 01483 856613>> @coolfields >> ersMessage-ID:Content-Type: text/plain; charset="iso-8859-1"This is an interesting question and one that also comes up with invert colors as that changes the contrast ratios as well. From my experience with blue light filters is that they are a spectrum that the user can specify and typically remove blues and warm the colors with more reddish colors. So I'd imagine it would impact contrast of colors that have more blue in them -- but this only a guess since I am not an expert in color.Testing could be difficult if the filter is applied in such a way that the contrast tools can't get the value. You may need to apply the filter values to the colors first and then run them through a contrast checker -- depending on the configuration. There are both browser and platform level blue light filters so they may work differently.JonathanJonathan AvilaChief Accessibility OfficerLevel = EMAIL ADDRESS REMOVED = 703.637.8957 officeVisit us online:Website?|?Twitter?|?Facebook?|?LinkedIn?|?Blo
gLooking to boost your accessibility knowledge? Check out our free webinars!The information contained in this transmission may be attorney privileged and/or confidential information intended for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any use, dissemination, distribution or copying of this communication is strictly prohibited.-----Original Message-----From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Patrick H. LaukeSent: Thursday, January 31, 2019 7:45 AMTo: = EMAIL ADDRESS REMOVED = ject: Re: [WebAIM] Colour contrast and blue light filtersCAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.On 31/01/2019 12:34, Pat Reynolds wrote:> We are working on a major overhaul of colours on all our sites, to make> them AA compliant. Does anyone know ho
w these filters might impact on> accessibility, and what we might do to mitigate that?I'm assuming that you mean you're going to ensure the colour contrastratios of all foreground/background colour combinations are AA compliant- minimum 4.5:1 for "regular" text / 3:1 for "large" text (and, if doingWCAG 2.1, also minimum 3:1 for meaningful non-text content).It will depend on the specific blue light filter used (as I don't thinkthere's any particular standard way in which these work), but whilethese filters generally result in a duller/less pronounced/loweredcontrast overall, following at least the minimum WCAG contrast ratiosshould still result in a strong-enough contrast. To be on the safe side,stronger contrasts (not just trying to squeak past the 4.5:1 ratio, forinstance) will be better and safer. If it's a major concern, you canalways run a simulated blue filter and test the contrast ratios AFTERthe filter was applied, and tweak to ensure that they're strong enougheven when the f
ilter is on.Of course, with regards to WCAG, you should also ensure that color aloneis not used as an indicator/to convey meaning, as this may alsootherwise cause problems for users that run a blue filter.P--Patrick H. Laukewww.splintered.co.uk | https://github.com/patrickhlaukehttp://flickr.com/photos/redux/ | http://redux.deviantart.comtwitter: @patrick_h_lauke | skype: patrick_h_lauke n reach on = EMAIL ADDRESS REMOVED = = EMAIL ADDRESS REMOVED = tJeevanreddy------------------------------Subject: Digest Footer
From: Alan Zaitchik
Date: Fri, Feb 15 2019 1:42PM
Subject: Re: WebAIM-Forum Digest, Vol 167, Issue 12
← Previous message | No next message
FWIW the new HHS requirements are 4.5:1, no matter the font-size or font-weight.
Alan