Re: progressbar role

For keys I have +/- 7 seconds, +/- 10 seconds, +/- a minute

I might though do something like you ask but maybe not a "slider" 
control per se but a user with a mouse can click anywhere on the 
progress bar and it will seek to that point. That I could do fairly easily.

I already have a different progress bar used for mobile devices where I 
wouldn't want that (accidental seeking when trying to touch something 
else) but I could put it in the desktop progress indicator.

Thank you for the suggestion, and I guess that would make it a candidate 
for role="slider".

On 11/15/2017 12:04 AM, Michiel Bijl wrote:
> Hi Michael,
>
> Any particular reason the player can’t have both a slider that supports
> both mouse control (dragging an indicator, or clicking on, on the
> slider) /and/ the current keyboard support?
>
> I generally dislike buttons for seeking as they’re imprecise.
>
> — Michiel
>
> On 14 Nov 2017, at 20:45, Michael A. Peters <mpeters@domblogger.net
> <mailto:mpeters@domblogger.net>> wrote:
>
>> I'm not actually using it as a slider. I have buttons for seeking
>> forward and back and access keys to seek forward and back in various
>> increments. I don't much like sliders, they can be hard for people
>> without fine motor control. It really just shows the progress.
>>
>> On 11/14/2017 11:31 AM, Shane Anderson wrote:
>>> Progressbar is the incorrect role. Slider is the role you're looking for.
>>>
>>> Regards
>>> Shane Anderson
>>>
>>>
>>> On Tue, Nov 14, 2017 at 1:32 PM, Michael A. Peters
>>> <mpeters@domblogger.net <mailto:mpeters@domblogger.net>
>>> <mailto:mpeters@domblogger.net>> wrote:
>>>
>>>    https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_progressbar_role
>>>    <https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_progressbar_role>
>>>
>>>    I have custom html5 media player, with a custom progress bar.
>>>
>>>    According to the mozilla page, it says that user agents should read
>>>    the the progress every time it updates - but when the progress is
>>>    for how much of the media has played it seems that would compete
>>>    with the audio from the media itself.
>>>
>>>    Should I not use role="progressbar" in the context of media with
>>>    audio, or is there maybe a way to tell it to be quiet unless the
>>>    user asks it for the current progress?
>>>
>>>    I am wondering if the context of a media player is maybe wrong for
>>>    that particular role.
>>>
>>>    I currently update the title attribute of the progress bar to
>>>    identify the percentage of the media that has played, is that good
>>>    enough or do I really need to give it a progressbar role?
>>>
>>>    Thank you for suggestions.
>>>
>>>    I'm not using a native html5 progress tag because I need a few
>>>    things it doesn't support.
>>>
>>>
>>
>>

Received on Wednesday, 15 November 2017 08:46:27 UTC