- From: Joseph Scheuhammer <clown@alum.mit.edu>
- Date: Mon, 29 Jun 2015 13:13:01 -0400
- To: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>, W3C WAI Protocols & Formats <public-pfwg@w3.org>
Hi Bryan, Thanks for the review. On 2015-06-29 12:39 PM, Bryan Garaventa wrote: > One question though, would it be disruptive to apply the same to progressbar? Yes, since some progress bars are indeterminate, meaning, all that is known is that progress has started. It's unknown how far along the task has progresssed. A common visual cue is animated diagonal stripes, like a barber pole. All the user gets is that progress is under way, but not how much is left to do. When the task is done, the progress bar goes solid. For most of its life, aria-valuenow and aria-valuemax are unknown quantities for an indeterminate progress bar. This is why they are not required for the progressbar role, in general. > E.G It's easy to make a progressbar that is not accessible by not including these attributes, but in order to make it accessible, these attributes would be required for the AT to process. Yes, they should be present for a determinate progress bar, which is what the current text associated with the progressbar role says (my emphasis): " The author //SHOULD supply values for aria-valuenow, aria-valuemin, and aria-valuemax, *unless the value is indeterminate, in which case the aauthor //SHOULD omit the aria-valuenow attribute." [1] (Aside: note the misspelling of "author" as "aauthor") [1] https://rawgit.com/w3c/aria/ACTION-1493/aria/aria.html#progressbar -- ;;;;joseph. 'Array(16).join("wat" - 1) + " Batman!"' - G. Bernhardt -
Received on Monday, 29 June 2015 17:13:31 UTC