- From: cynthia <notifications@github.com>
- Date: Fri, 28 Apr 2017 02:40:28 -0700
- To: w3ctag/design-reviews <design-reviews@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3ctag/design-reviews/issues/156/297955095@github.com>
CC: @LJWatson, @stevefaulkner Thanks you for submitting the review request. Apologies for taking so much time to look into this, hope this isn't too late for the deadline. Pre-warning: This was reviewed by @travisleithead and me during Tokyo F2F, both not being the most literate about the dependency spec ARIA. There might be misunderstandings about what the original intention is - we did not have time to read the entire ARIA spec throughly before doing this review. The first pass review comment list is a bit long, so we're providing it in bulletpoint format to make it a bit easier to follow. 1. We think it would be better to remove `keygen`. This is a element that we have discussed in the past and decided to obsolete. 2. `input type=datetime` has not been well received, so we would like to suggest replacing that with `datetime-local` which has better implementation support. 3. Following item 2, `input type=datetime-local` should have probably be a `grid` role, with each data component being maybe a `spinbutton`? We aren't sure this would be the best option, since some of the input is text - but the behavior of the individual data fields behave closer to a `spinbutton` in the implementations we have tested on, which is the rationale for this suggestion. `input type="date"`, `input type="month"`, `input type="week"`, and `input type="time"` most likely fall under the same rule. 4. `a element without a href` should be a bit more specific. When this is used as a anchor (for page internal navigation, using the name property) this is probably something that should have a `landmark` role. 5. The likelihood of SVG being a graphic component is probably higher than it being a `application` or `document` from the user's perspective, so would it make sense to use `img` as the implicit role? 6. `img with alt=""` might be better suited under a `presentation` role. 7. `meter` seems to match the `progressbar` role reasonably well, any reason why this was not chosen? 8. `input type=submit` has navigation behavior (although it depends on it being in a `form`) - this seems inconsistent with `button` element's role definition. Link might be needed as as potential role. 9. It seems like `input type=range` can also be a `spinbutton`. 10. Are we okay with not having any roles `input type=password` for password and `input type=color` for color? Password seems like it will happen in ARIA 2.0 so the dependency stands. Also, `input type=file` has no role, are we fine with this? 11. `hr role=separator` has the role `presentation`. Should only be implicit seperator in the event it is focusable, as per ARIA definition? 12. `input type=range` could be a spintbutton too. It seems to qualify against the rules defined there, at least based on some quick testing. 13. `input type=hidden` is not covered by the hidden property entry at the bottom of the table, and should probably get a `aria-hidden`. 14. Small nit: possibly to make the table a bit shorter `input type=text, with no list attribute`, `input type=tel, with no list attribute`, `input type=url with no list attribute` could be merged to make the table length a bit more bearable. 15. `input type=number` might not be spinbutton. The bit that concerns me is that spinbutton assumes discrete values, but number does floats with no limit by default. That is not particularly discrete unless min, max, and ideally step is specified. (IEEE754 does have a precision limit so no stepping is still discrete up to the precision the underlying floating point type allows) Notes about ARIA: 1. Unless `spinbutton` is a name that needs to stay for legacy reasons, there might be slightly more friendlier options in terms of naming. 2. Combobox doesn't quite match any web widget's behavior, is there a necessity for keeping this? Legacy reasons? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3ctag/design-reviews/issues/156#issuecomment-297955095
Received on Friday, 28 April 2017 09:41:10 UTC