Consider using <button> element

[albell]

One of the bragging points of Paypal’s new html5 player is semantic markup. I think they have a point there. Best practice is to mark up a button as a <button>, and we’re currently not doing that. Given that we have proper ARIA roles, this is less of a concern. But <button>s get authors lots of accessibility goodness right out of the box, and I think they help to cover some edge cases, especially with screen readers. This would require a bit of an overhaul. Right now the menus are inside the button <div>s, and in the default skin they get hidden and shown with descendant selectors:

.vjs-default-skin .vjs-menu-button:hover .vjs-menu {display: block;}

The idea would be to switch to markup like:

<div class="subtitles-wrapper>
    <button class=“vis—menu-button”>Subtitles</button>
    <div class=“vjs-menu”></div>
</div>

and switch to adjacent selectors in the CSS:

.vjs-default-skin .vjs-menu-button:hover + .vjs-menu {display: block;}

Thoughts?

[mmcc]

I think anchor tags vs button tags for this use case is a bit pedantic (much like most of the things they're touting as features, but that's almost certainly just my curmudgeon opinion), but what additional "accessibility goodness" do they provide out of the box? If there are clear benefits beyond "semantic" then we should absolutely continue the conversation.

[albell]

curmudge away! :)

First where are the anchor tags? As far as I can see it’s <div>s all the way down in VJS. (If they were <a href=“#”> tags, that would be misleading because it sends screen readers on a goose chase to a non-existent resource.)

So VJS is all divs. But the WAI-ARIA spec advises against the current VJS pattern of heaping ARIA roles onto divs:

It is not appropriate to create objects with style and script when the host language provides a semantic element for that type of objects. While WAI-ARIA can improve the accessibility of these objects, accessibility is best provided by allowing the user agent to handle the object natively. For example, it's better to use an h1 element in HTML than to use the ‘heading’ role on a div element.

General advice. Okay. The main reason seems to be that screen readers announce the name of an element when it gains focus. Hearing “Div” is distinctly unhelpful. Also, VJS hasn’t given the buttons a “name”, which makes voice commands hard. For a serious rant on this topic, see:

http://www.karlgroves.com/2013/05/14/links-are-not-buttons-neither-are-divs-and-spans/

And MDN’s article "Using the Button Role" hammers it home:

https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_button_role

Where possible, it is recommended to use native HTML buttons (, and) rather than the button role, as native HTML buttons are more widely supported by older user agents and assistive technology. Native HTML buttons also support keyboard and focus requirements by default, without need for additional customization.

and (to my mind) the clincher:

Buttons need to be operable by mouse users as well as keyboard users. For native HTML buttons, the button's onclick event will fire both for mouse clicks and when the space key is pressed while the button has focus. If role="button" is used to create a custom button, the onclick event will only fire when clicked by the mouse cursor. Because of this, the developer will have to explicitly add a separate key event handler to the element so that the button can be triggered when the space key is pressed.

See also:

http://css-tricks.com/use-button-element/

So at a certain point, patch on top of patch, you’re dressing up a dog as a cat. Why don’t you just go to the pound, trade in your dog, and get a cat? :)

Have you guys ever tested VJS with screen readers? I agree that pedantry about semantics can be tedious, but it seems significant that everyone involved in this area feels strongly about semantic markup, and that consistent, usable patterns and behaviors are currently emerging.

[mmcc]

You're totally right, brain fart on the anchor tags. I don't disagree with any of these points, but I really want to because this isn't a trivial change. :)

That being said, I'm not opposed to making the switch, but let's table this conversation until @heff gets back from vacation. I vaguely remember having a conversation with him along these lines and there were other complications involved. Nothing insurmountable, but given the scope of transitioning from cat to dog (who would transition the other way, anyway), it'd be nice to make sure we weren't missing any relevant details.

[mmcc]

Done! Kind of, but aside from Menu buttons, vanilla buttons are now buttons.