Use ARIA roles to designate semantic markup with behaviour

[naasking]

Instead of using classes, mini.css could make any site that uses it more accessible CSS by default if you use ARIA roles to identify tabs, buttons, alerts, menus and navbars, etc.

The CSS selectors then change from class selectors, to attribute selectors like [role~="tab"] { ... }. This is CSS 2.1 IIRC, so it already has broader browser support than mini.css's latest version.

[Chalarangelo]

This will be implemented in a later patch thanks for the help. :)

[naasking]

I've been reading up on the ARIA roles with the goal of writing a small JS library that would take a role-annotated document and insert the necessary markup for mini.css's components to implement the dynamic behaviour.

Tabs would be a problem, because mini.css currently assumes the clickable tabs (role="tab") precede the tab content (role="tabpanel"), where ARIA assumes the tabs are all grouped together in a list (role="tablist"). Accordians are a little more flexible and would work with the current setup.

[Chalarangelo]

Oh, wow, a JS library already. That sounds great @naasking !

About the tabs, is there a way I could roll out some different structure that would make things easier and more compatible? I am planning to introduce quite a few changes in v2.1 based on suggestions and feedback. If you have any ideas on how tabs could be updated to be better for working with your JS library, please fork and submit a pull request with said updates (provided you have the time and want to undertake said project).

[naasking]

The old ARIA practices document has links to working examples of markup with JavaScript-driven behaviour, so you can see what markup their tabbed interface expects.

The accordian example should work just fine with mini.css's approach.

I've just scratched the surface of ARIA though, as it's quite comprehensive. It's simple for me to provide clean semantic markup and mini.css to do the heavy lifting after JS enhancement, but I'm not yet sure this is the right approach. See for instance, this article which tests this markup with real users, and surprisingly, non ARIA-annotated markup turned out to be better. I'll have to bang my head against this a little more before I get a proper handle on it

[Chalarangelo]

If the accordion is fine, why not deal with tabs the same way as accordions? After all, they are the same component essentially!

[naasking]

Their accordian provides checkbox-like semantics, ie. many "tabs" visible at a time, and their tab interface provides radio input-like semantics, ie. only one "tab" visible at a time, where your accordians can have either semantics. I'm honestly not sure if this actually matters to screen readers that expect a tabbed interface.

[naasking]

Here's a nice link demonstrating what can be done with CSS and ARIA annotations, although I believe they use some JS at some points.

[Chalarangelo]

I originally designed tabs to be accessible, by simply not registering as tabs at all for screenreaders, so that all of their content gets displayed as normal content on screenreaders. However, I understand that this could prove to be a problem in a few nieche situations, but, when that is the case, there will most likely be other problems with the website's design and content, apart from the tabs themselves. This is a tricky situation and I honestly do not know what is the best way to proceed with this. I'll try to do some research later and see if I come up with anything interesting.

[Chalarangelo]

I am going to be implementing the changes discussed above in the next weeks. I am trying to compile a comprehensive list of things to be changed. So far, I have come up with these:

• input_control module's button semantics can be easily switched over to ARIA button role, in combination with the current class-based system.
• input_control module's checkbox and radio semantics (which are based off of labels) might be possible to be switched over to an ARIA-based build system (checkbox and radio). I could use a few good examples for this, if you have found any, so that they are built properly. Cancelled.
• tab module's tab and accordion system could be based on ARIA roles, I will see what I can do. I also need examples for this, if you have any good ones. Postponed until a later update.
• progress module's spinner would benefit from the usage of the ARIA progressbar role. This can be added in the documentation, but no changes can be made to the component itself.
• grid module's systems could use ARIA roles like grid, but I think this is a bit unnecessary. Cancelled.
• navigation module's <header> and its links could be defined as ARIA menubar and menuitem, but I am not sure if they should be. The default roles assigned suffice, cancelled.
• contextual module's alerts might benefit from being implemented using the ARIA alert or alertwindow role.

@naasking I would really like your feedback and help with this one to narrow down the exact specifics of the implementation of the changes.

This list is not final and I would like as much feedback as possible while changing these components and modules. Also, if you know of any tools that actually show what a screenreaders sees or how the page is read out by one, please provide me with a link.

[naasking]

I think the aria roles should only be used when the HTML markup isn't already semantic, so you could dispense with grid I think. In principle, classes should be used only for visual styling IMO, like colours, font, etc., so using classes to decorate tables makes perfect sense because isn't meaningful information for the vision impaired.

Same applies to the progressbar, since you already recommend using the element, I think that's enough. There's also the problem of mandatory attributes to track the state of the progress bar, which you can't do with CSS alone.

A good tab example is on the page I linked previously.

For navigation, the top navbar should probably use the "banner" role, since that's intended for site-wide navigation options. Here's a breakdown of their recommendations for navigation.

I'm not sure whether you should use roles for checkbox/radio inputs, because the aria-checked attribute seems mandatory and must change with checked state.

Button role seems to have no mandatory attributes, so that's fine.

Edit: Since mini.css is CSS-only, some of the ARIA stuff gets tricky due to mandatory attributes, and the input tricks you use to do everything in CSS might not map well to dynamic ARIA roles. I also worry about causing confusion by requiring roles some places, and classes elsewhere, but I'm sure that's already on your mind.

[Chalarangelo]

Ok, so buttons and progress spinners (which are indeterminate progress bars) can easily be tweaked to use ARIA roles, the header will be kept as-is and I will try to change alerts to use ARIA. Tabs and accordions are a lot of work and I will get to them in a later update, if ever.

[Chalarangelo]

The ARIA role implementation list described in one of my previous comments has been updated. The specifics of the implementation are described below:

• buttons will be based on either a class or the ARIA role button or both, based on Sass flags. The rest of the button styling will be based on the classes, as before. The ARIA option will be included in the mini-default flavor as of v2.1.0, the old option will not be deprecated.
• spinners will be based on either a class or the ARIA role progressbar or both, based on Sass flags. The rest of their styling will be done as before. Will be included in the v2.1.0 mini-default flavor, old naming will not be deprecated.
• alerts will be based on either a class or the ARIA role alert or both, based on Sass flags. The rest of the styling will be done as before. Will be included in the v2.1.0 mini-default flavor, old naming will not be deprecated.

I tried to deal with the issue, without creating too many breaking changes, while easing people into the syntax. Later versions will eventually break support for the class system in the mini-default flavor, however this will be done when ARIA support is a lot higher. Accessibility is going to be one of the main focuses in the next few releases.

[Chalarangelo]

Update (final): There is a lot of conflict between how things are done when using pure ARIA roles and there is a lot of controversy surrounding the way certain things are supposed to be implemented. The decision as of now is the following:

• button elements will in fact support the [role="button"], as well as a class BY DEFAULT. This means that instead of a class, the ARIA role can be used.
• No other element will implement an ARIA role as of now, more components and modules will be updated gradually to incorporate ARIA roles.
• The documentation (aka Github pages) will be updated to include a little bit more in terms of ARIA examples, such as labeling and the likes, wherever possible. Again, this will be done gradually, so some things might be added in later patches or minor updates.
• The new tooltip component that will be added will not utilize an ARIA role (aka role="tooltip"), but will use an aria-label for its content, making it somewhat more accessible.

This issue will be considered resolved as soon as the changes described in this comment are added to the working branch. Bear in mind that new issues can and will be opened for more things related to accessibility.

P.S.: @naasking I am after all one person and I have a lot of work to do for the framework and a lot of other things I am working on. If you or anybody else wishes to work on the ARIA role support, I'd be glad to collaborate. After all, mini.css could use the involvement of more people. Thank you very much for all the feedback and sorry for not being able to deal with all of it yet. I'll try my best both in this release and in the future to make the framework the best it can be.