Disallow role of textbox on img elements

[ZoeBijl]

The ARIA in HTML specification already imposes this limitation on img-elements without an alt-attribute. Unless someone can come up with a good example of where this would be useful, I think it makes sense to disallow the textbox-role from being used on img-elements with an alt-attribute, too.

As an example of potential usability, @stevefaulkner mentioned a read-only textbox. If that were indeed a valid (and valuable) situation to cater to it might be worth requiring aria-readonly when setting the textbox role on an img.

[scottaohara]

i'd agree with this and venture to say there are other roles that make no sense to be allowed on an image element. however, to keep this issue focused, the only addition to this that i'd suggest is also disallowed would be searchbox.

[ZoeBijl]

Would you like me to open another issue for the other roles? Essentially anything that requires children with roles of their own—like a listbox or radiogroup—doesn’t make any sense since you can’t add those children in the DOM.

[scottaohara]

yeh, those sorts of roles are exactly what i was thinking, and then was like "well what if someone uses aria-owns" which made me realize i can imagine some pretty horrible situations...

[scottaohara]

So the way the table is setup right now, excluding roles from the element is largely done by indicating what roles are allowed.

Here is the listing of the ARIA roles (from the ARIA 1.2 WD) I've come up with that could/should be allowed (note this would need to be revised further once more roles land in the latest published version. it'd also possibly warrant a note saying "the img must also be focusable" to be allowed on many, but not all, of these roles.):

• button
• checkbox
• link
• menuitem
• menuitemcheckbox
• menuitemradio
• option
• progressbar
• radio
• scrollbar
• separator
• slider
• switch
• tab
• treeitem
• figure

Separating out a bit more, I think there could be an argument for these. However, allowing would not help in discouraging images of text:

• blockquote
• caption
• cell
• columnheader
• definition
• group
• heading
• listitem
• note
• paragraph
• rowheader
• term
• tooltip

For comparative purposes, these are the roles that should be excluded:

• gridcell (not allowed because it can be editable)
• tabpanel
• searchbox
• spinbutton
• textbox
• combobox
• grid
• listbox
• menu
• menubar
• radiogroup
• tablist
• tree
• treegrid
• application
• article
• directory
• document
• feed
• list
• math
• none / presentational (already noted as excluded)
• row
• rowgroup
• table
• toolbar
• banner
• complementary
• contentinfo
• form
• main
• navigation
• region
• search
• alert
• log
• marquee
• status
• timer
• alertdialog
• dialog

more than happy to get other opinions / thoughts on this current breakdown.

I was trying to be generous in the "this could be allowed" category... though I personally find even some of those allowances to be suspect in reasonable practicality. Also, the more I think on this, I'm thinking more roles really should fall into the not allowed category...especially those that would typically consist of a lot of text, as it'd stand to reason to try and veer people away from practices that would be bad for accessibility in general (images of text being masked as content that should allow for zooming w/out loss of quality, for example)

[stevefaulkner]

@scottaohara wondering about group

[ZoeBijl]

Was doing the same thing. I guess a group doesn’t need children to be valid. But that’s not the same as it making some sort of sense.

[Jesuke]

Sorry @scottaohara , but why not banner?

[ZoeBijl]

The ARIA spec says the following about the banner role:

A region that contains mostly site-oriented content, rather than page-specific content.

Site-oriented content typically includes things such as the logo or identity of the site sponsor, and a site-specific search tool. A banner usually appears at the top of the page and typically spans the full width.

What part of that do you think an img element could fulfil?

[Jesuke]

Hi @ZoeBijl, I think fits perfectly: "Site-oriented content typically includes things such as the logo or identity of the site sponsor". Banners have historically been an image or flash object. Although you can find some HTML5 pieces now.

[scottaohara]

includes (see: contains) is different than is.

as @ZoeBijl mentioned, a banner typically includes logo/identity information. A banner also typically includes other global elements or components that appear across multiple pages/screens of the site or application. As the quoted text indicates, like a "search tool" but a global navigation would typically go into a banner as well.

[Jesuke]

Hi @scottaohara I understand your point but it's talking about a region, which is not even an element, it's just a way of talking to include several cases, including a single element or a set of them.

On the other hand I think there is concept misunderstanding here. One thing is the definition of "Site-content" which is the one that includes things such as search tools (forms), and other different is a banner, which is defined as Site-content, but obviously not as a search tool.

Talking about search tools, I think that if role="search" can be applied to a form, role="banner" can perfectly be applied to an img.

That said, I totally agree with you that all those other roles that you propose to be exclude do not make any sense on an img, in my undestanding.

[ZoeBijl]

To make sure we’re all talking about the same thing: with the banner-role we mean the equivalent of the HTML header-element; not the visual concept.

As an example, the top bar of GitHub which includes its logo, a search form, some links, and the profile menu is a header-element (which happens to also have the banner-role set). I don’t see how you could include all of that in an img-element.

Am I missing something?

[Jesuke]

However guys, don't get me wrong. I'm not saying that your assertion is wrong, in fact I've been looking for a little more info and I found this:

By default, the HTML5 <header> element has an identical meaning to the banner landmark, unless it is a descendant of <aside>, <article>, <main>, <nav>, or <section>.

https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/Banner_role

Also the W3C reference says:

Within any document or application, the author SHOULD mark no more than one element with the banner role.

So yes, banner role does not fit the banner concept which I was used to: a site sponsor image.

Thanks

[Jesuke]

Thanks @ZoeBijl , now it's clear ;)