W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > October to December 2017

Re: progressbar role

From: Michael A. Peters <mpeters@domblogger.net>
Date: Wed, 15 Nov 2017 00:46:01 -0800
To: w3c-wai-ig@w3.org
Message-ID: <08ec0387-4049-9091-c9a6-9625f2bba509@domblogger.net>
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

This archive was generated by hypermail 2.3.1 : Wednesday, 6 December 2017 16:04:47 UTC