Interesting Firefox behavior in 126. Things that formerly exposed to the screen reader as "tabs" are now Links, as things that used to show as "menu items" are now "buttons". Nothing in release notes. Intended behavior?
@nick Ah, actually, we did tighten up contextual roles to match the spec. For example, it is a spec violation to have a menuitem outside of a menu or a tab outside of a tablist. Previously, Firefox didn't validate that, but it does now. But that was always a spec violation by the author; Firefox just chose to ignore it previously, which is itself a spec violation. Personally, I'm not a big fan of the spec enforcing this on browsers, but that's what it currently says.
@jcsteh@nick If you were to go back to technically violating the spec on this, while making spec-violating sites more accessible in practice, I don't thinka nyone could reasonably blame you. Aside from the failed XML-ization of HTML, browsers have always gone out of their way to do what the author meant even if the author didn't comply with the letter of the spec. That approach should go double for accessibility.
@jcsteh@nick If you were to go back to technically violating the spec on this, while making spec-violating sites more accessible in practice, I don't think anyone could reasonably blame you. Aside from the failed XML-ization of HTML, browsers have always gone out of their way to do what the author meant even if the author didn't comply with the letter of the spec. That approach should go double for accessibility.
@matt It's a tricky one because the spec specifically requires user agents to enforce this, and there are web platform tests we fail if we don't. It is not just an author requirement; it is also a UA requirement. @nick
@matt That said, there is a bit of a debate going on about this at the moment. Mozilla originally protested implementing this, then went ahead and did it anyway assuming in good faith that the spec was written like this for a good reason. But now Apple, after initially agreeing with the spec, are contesting it as well. So there might be scope to get this struck from the spec. @nick
@jcsteh@nick I've now discarded a couple of possible replies. The fact that some stupid spec requirement can stop you from doing what's best for actual accessibility in practice, because failing web platform tests would make you look bad, makes me angry. I can't blame you for bowing to that pressure, but still...
@matt Whether it's good for accessibility is debatable in this case. A menuitem without a parent menu isn't going to behave as one might expect and will possibly behave inconsistently across screen readers. @nick
@jcsteh@nick Sure, but the first rule of AT is that you make the best of the half-broken crap that the application or content author implemented, because we all know that very few will go to the trouble to get it exactly right.
@matt Also, to be clear, we conceded in this case because we didn't have any evidence that this would hurt users and there is some validity in trying to ensure a consistent experience across assistive technology products. We can and do push back on spec requirements when we believe they are problematic, and generally, given a sufficiently strong case and no strong counter-arguments, these things get changed. The spec groups are a lot more pragmatic these days and I do believe that everyone wants to do the best thing for the web as a whole. @nick
Add comment