One comment @travisleithead noticed, in our breakout session at the TAG meeting, is that the "Kind of content" column in the first table in 3. Allowed ARIA roles, states and properties said "(work in progress)", which didn't quite seem right for something that's about to go to CR. However, we then noticed that this column is no longer present in the Editor's Draft, and concluded that it made more sense to review the editor's draft.

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?

Thanks for the feedback,

Important to note -

Abstract

This specification defines the web developer rules (author conformance requirements) for the use of [wai-aria-1.1 http://w3c.github.io/html-aria/#bib-wai-aria-1.1] attributes on [HTML51 http://w3c.github.io/html-aria/#bib-HTML51] elements. It also defines requirements for Conformance Checking tools.

The ARIA in HTML spec does not define the role/state/property mappings/implementations in browsers, these are defined in HTML Accessibility API Mappings 1.0 https://w3c.github.io/html-aam/

as a consequence many of the comments provided are relevant to that specification, not to ARIA in HTML which confines itself to authoring requirements (which are expressed in conformance checking tools)

--

Regards

SteveF Current Standards Work @W3C http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/

On 28 April 2017 at 10:40, cynthia notifications@github.com wrote:

CC: @LJWatson https://github.com/LJWatson, @stevefaulkner https://github.com/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 https://github.com/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 were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3ctag/design-reviews/issues/156#issuecomment-297955095, or mute the thread https://github.com/notifications/unsubscribe-auth/AAzBEybFr1PnhmswTjM3ff1HekH7eZxfks5r0bQMgaJpZM4MZh42 .

Something we've hit on in further discussion about this (with @travisleithead @cynthia), we note that the HTML Accessibility API Mapping table and the ARIA in HTML notes many elements do not have corresponding roles.

HTML ARIA should view these omissions as a bug to be fixed and introduce roles and states as necessary to completely describe the behavior of the built-in elements. Without this, it is impossible to build Custom Elements to extend the behavior of many built-ins.

On 29 April 2017 at 04:06, Alex Russell notifications@github.com wrote:

Something we've hit on in further discussion about this (with @travisleithead https://github.com/travisleithead @cynthia https://github.com/cynthia), we note that the HTML Accessibility API Mapping table https://w3c.github.io/html-aam/ and the ARIA in HTML https://www.w3.org/TR/2017/WD-html-aria-20170323/#docconformance notes many elements do not have corresponding roles.

right and that is being worked on in the ARIA working group for ARIA 1.2, refer to role parity issues https://github.com/w3c/aria/issues?q=is%3Aissue+is%3Aopen+label%3A%22ARIA+1.2%22

Regards

SteveF Current Standards Work @W3C http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/

Agreed to close at London F2F. No further substantive feedback