[Webkit-unassigned] [Bug 160223] AX: Media controls accessibility improvement

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=160223

--- Comment #15 from Nan Wang <n_wang at apple.com> ---
Comment on attachment 284671
  --> https://bugs.webkit.org/attachment.cgi?id=284671
patch

View in context: https://bugs.webkit.org/attachment.cgi?id=284671&action=review

>> Source/WebCore/Modules/mediacontrols/mediaControlsApple.js:424
>> +        timeline.step = 1;
> 
> While 1 will be a better value than .01 for some movies, it will be much worse for very short files, and it still won't be great for long files. Can you set it to a percentage of the duration in updateDuration instead? You may want to vary the percentage based on duration, e.g. 1% of a 90 second file is almost a second but 1% of a 90 minute is almost a minute, but a I'll bet you can come up with reasonable values with some experimentation.

We have come up with some cases that, let me know your thought:
1. If video is less then 10sec we do 0.5 second step
2. If video is between 10sec to 1min we do 1 second step
3. If video is between 1min to 10min we do 10 second step
4. If video is between 10min to 60min we do 30 second step
5. If video is more than 60min we do 60 second step.

>> LayoutTests/media/audio-controls-timeline-in-media-document.html:21
>> +        setTimeout("testTimeLineValue()", 1000);
> 
> This test now takes a full second, which is a long time for a simple test like this. Additionally, the timeout is likely to make the test flaky. This won't be necessary if you don't always use a 1 second step value.

I think the test video is 6 seconds long so based on the above cases, this will result into a .5 second step. Do you think it's acceptable for a 0.5 second test? Problem here is that from accessibility perspective, 0.01 step is not reasonable for a keyboard user as well. If the 0.5 second timeout is still not good, can you suggest us with a better way of modifying the test?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20160727/9a3254c8/attachment.html>