Re: [w3ctag/design-reviews] Review ARIA in HTML specification (prior to CR transition) (#156)

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>
> .
>


-- 
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-297966359