Re: Floating Action Buttons

Clarification: My comments apply to the Mobile equivalents. I definitely
resonate with the comments applied to the Web portions.

Material design is a SUPER mobile centric topic. I may be assumed some
context :). My comments apply heavily to mobile stuff... FABs are a super
mobile inspired pattern. On desktop... highly resonate with other comments!

On Thu, Jul 2, 2020 at 6:03 PM Chris McMeeking <chris.mcmeeking@deque.com>
wrote:

> Mike,
>
> There are roughly two types of Floating Actions Buttons:
>
> - Super Valuable ones that are similar to H1 level content... that also
> are controls (Gmail: Send Message)
> - Super NOT Valuable ones that are a distraction (Chat Bots)
>
> Let's assume the more valuable type.
>
> Floating Action Buttons are at the bottom of the screen, because your
> thumb is at the Bottom of the Screen. This can make people who don't
> understand the way users actually use Mobile Devices think that focusing
> such buttons "Last" or even "never" is sensible.
>
> Also, because of this, Mobile Device users tend to consume information on
> a screen in a very different way. They glance at the bottom of the screen
> seeking for context that is similar to the context you might get if you're
> looking around a website at the Heading Structure.
>
> The above truths, which I research in conjunction with folks at the
> University of Michigan, lead to a very logical AND simple to implement fix
> for the Floating Action Button pattern.
>
> - Focus the Floating Action Button First.
> - Or at least... very close to first. Maybe after a
> ViewController/Activity Title
>
> Chris
>
> PS: Please ignore most everyone else's advice on this. It's really far off
> base ;). The comments on making sure it is available in the "Controls" menu
> are useful... but in actuality off topic from the broader concerns.
> Particularly those that acknowledge the value of Floating Action Buttons
> being valuable contextual information.
>
> On Thu, Jul 2, 2020 at 11:57 AM Mike Elledge <melledge@yahoo.com> wrote:
>
>> Thanks, Jonathan and Sukriti!
>>
>> Jonathan, when you suggested using a keystroke did you mean assigning an
>> access key or something else? If it is a dedicated key, which would be best?
>>
>> Thanks again,
>>
>> Mike
>>
>> On Jul 1, 2020, at 9:50 PM, Sukriti Chadha <sukriti1408@gmail.com> wrote:
>>
>> 
>> Hi all,
>>
>> I am a new member and excited to be part of this group. I designed and
>> launched audio charts on Yahoo finance mobile apps and was a mobile
>> developer before focusing on a11y and product management. Thank you!
>>
>> Looking forward to getting to know everyone in the next meeting!
>>
>> Some thoughts and possible solution for FAB accessibility :
>>
>> The intent as I understand from material guidelines for a FAB is the
>> primary action a user would take on a given page. One example of this on
>> the gmail app on Android is that the FAB (compose) is only accessible in
>> the *controls *setting on TalkBack if accessed from it's original
>> position. That one is a pretty limited, and IMO unpleasant experience since
>> it doesn't allow navigation backwards or forwards unless the setting is
>> changed from controls to headings or something else.
>>
>> The part that works reasonably well is when screenreader (TalkBack) is
>> on, the compose button appears on the search bar on top - it is not there
>> when TalkBack is off.
>>
>> To generalize the recommendation, if we think this is a reasonable
>> approach we could say -
>>
>> The primary action should be available with other site navigation such as
>> search bar or navigation drawers on the page for screenreader users
>>
>> Screenshots of Gmail app with and without TalkBack attached
>>
>> Best,
>> Sukriti
>>
>> On Wed, Jul 1, 2020, 9:08 PM Jonathan Avila <jon.avila@levelaccess.com>
>> wrote:
>>
>>> My recommendation is to have multiple ways to reach:
>>>
>>>    - Keystroke
>>>    - Semantic role such as region where screen reader users could
>>>    navigate to and also understand bounds
>>>    - Skip to link on page such as at the top so the user can quickly
>>>    jump to it and also make it’s presence known
>>>
>>>
>>>
>>> Jonathan
>>>
>>>
>>>
>>> *From:* Mike Elledge <melledge@yahoo.com>
>>> *Sent:* Wednesday, July 1, 2020 5:55 PM
>>> *To:* w3c-wai-gl@w3.org
>>> *Subject:* Floating Action Buttons
>>>
>>>
>>>
>>> *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.
>>>
>>>
>>>
>>> Hi Everyone--
>>>
>>>
>>>
>>> I've been asked if there is a way to implement accessible floating
>>> action buttons (FAB) as in Google Material Design.
>>>
>>>
>>>
>>> An example would be a floating map button that provides directions.
>>> Another would be a floating link that takes the user to the top of a page
>>> (leaving aside the potential confusion if it is styled like a button).
>>>
>>>
>>>
>>> There are pros and cons to using them, but it would seem to be a problem
>>> wrt accessibility.  In particular, how would a keyboard or screen reader
>>> user navigate to an object without a fixed location?  I thought of
>>> accesskeys, but their use is frowned on because of potential conflicts with
>>> shortcut keys.  Having an FAB appear after a number of keystrokes, time, or
>>> sentences sounds intrusive and arbitrary.  Putting them in a fixed position
>>> on a page seems to defeat their purpose.  I also thought of claiming
>>> equivalence if there is an existing keystroke that accomplishes the same
>>> thing, but that doesn't feel right.
>>>
>>>
>>>
>>> Am I missing something?
>>>
>>>
>>>
>>> Any help would be greatly appreciated.  Thanks!
>>>
>>>
>>>
>>> Mike Elledge
>>>
>> <Screenshot_20200701-214617.png>
>> <Screenshot_20200701-214554.png>
>>
>>