[Docs] Add Menu ARIA Example

[X4]

Hi,

I think SemanticUI is great and while AlloyUI and AttlassionUI are the only frameworks I know that follow these http://www.w3.org/WAI/intro/aria.php Guidelines , it would be awesome if SemanticUI would add this feature, which I think separates a really serious UI Framework from a "prototyping only" Framework.

^{I believe any help in giving more access to the web to people who have been unluckily disabled is a good thing to do.}

[brigand]

@X4 I don't think that really makes sense. With some of those libraries, you start with this:

<input />

And then it does all sorts of crazy adding stuff to the DOM, and all that. With Semantic, I think the modal adding a dimmer to the page doesn't affect accessibility.

So, we could encourage people to create their sites with accessibility in mind, but other than in #246, we can't really do much.

[X4]

@brigand Eh? Sorry, I think you've responded to the wrong post. Happens, no worries. :) In case this is the post you wanted to respond to I cannot infer a relation to a dimmer or <input/>, there is also nothing added to the DOM.

[brigand]

@X4 haha nope. I intended to reply here.

Perhaps you can give examples of how the current behavior of Semantic-UI should change to comply with these guidelines?

[jlukic]

Thanks for posting X4. I appreciate your concern to ARIA accessibility.

Semantic focuses solely on class name semantics, and does not make any specific recommendation to tag/property level semantics, as this is the domain of machine-processing, and Semantic is specifically concerned with the parts of html that are used to create meaning for other developers.

Crawlers, and screen readers and things that rely on proper machine semantics are not specifically mentioned.because they are outside the scope of the project. ARIA accessibility standards, like aria-role or use of aria-invalid, aria-required on forms can all be used in tandem to the structure provided by the Semantic framework and should not directly conflict with anything since Semantic is tag ambivalent. It is the responsibility of developers to decide to what extend to implement these features.

[X4]

@brigand no problem :) then I think you just misunderstood how WAI-ARIA is implemented. @jlukic Here are tools that help to "accessify your code" and this is an UML class diagram of the WAI-ARIA taxonomy

But you're right. It just adds roles and other classifiers and actions for Screen Readers. It's actually not that hard, but takes some time to read.

I understand and really respect your decision knowing that you're not a big company with resources like Twitter, ZURB or Yahoo!, but maybe you can take a second look onto the docs for version 2.0 or 2.1. That tool and maybe some things can help adding a accessibility support to SemanticUI. I think it could even be scripted so that it would not only benefit you, but every project. I mean some shell/npm/php/ruby/python/.. script that scans the html for a list of class/id names and tags provided and automatically adds the aria-role="menubar" in example that would be dead easy.

[jlukic]

Hehe yes, the resources for the project might not match those of larger corporate backed OS projects, but at least less vested interests :)

Thanks for the UML diagram it helps clarify things.

I agree since class names are fairly explicit in semantic, it'd be relatively easy to create an accessibility UI Behavior (or a build script) that could use javascript to add accessibility features automatically based on the understood meaning from SUI.

[X4]

Thank you @jlukic for the quick reply. Highly appreciate it!

Offtopic: I don't know at which stage of growth you are currently, but looking a bit at what your competitors can't offer and adding what your client's need most (from an eagle's perspective) would give you a good boost in popularity. Also announcing the 2.0 upgrade on popular news sites wouldn't hurt (just prepare for massive load). A real reason, other than just for marketing purposes is much more effective. You could in example develop the accessibility generator and allow people to pay what they think it's worth (like on humble-indie bundle, or just add a donate button) There are some instantly useful scripts that you could easily style and add to your components list for 2.0:

https://github.com/h5bp/Effeckt.css.git https://github.com/kamisama/cal-heatmap.git https://github.com/enyo/dropzone.git https://github.com/madebymany/sir-trevor-js.git https://github.com/ichord/At.js

[deneuxa]

Woo there are some nice stuffs in the effeckt.css, thank for sharing. I like the modals animations and the scroll lists (but I don't know if there will be slow/usable on mobile device)

I just saw an extremely useful ressource on twitter too : http://pattle.github.io/simpsons-in-css/ :D, just kidding

[X4]

@brigand @jlukic What do you think about doing the same as Bootstrap and forking http://alloyui.com/ then combining YUI3 with SemanticUI? That way you could achieve accessibility + have a robust UI toolsuite fitting to enterprise users. It would save you integrating the addons I mentioned above for some time.

Just brainstorming, you know :)

[jlukic]

No plans to combine YUI with semantic. If someone is interested in this feel free to fork and will include in the integration wiki and readme for those requiring greater accessibility compatibility

[ryanflorence]

I don't think that really makes sense.

This is incredibly disappointing. Anybody using your framework is making the web a more frustrating place for the disabled.

I tried your website, its completely useless with a screen reader. Your buttons aren't even focusable.

Accessibility is not about kicking the crap out of an input tag. There are attributes and focus management techniques that let you make sense out of your components for screen readers and others. For example <div role="button" tabindex="0" /> and then of course add the proper key events to make it act like a button.

Spend a day learning how to use a screen reader. If you're on a mac, you've already got voice over + safari. Then spend a week learning WAI ARIA.

[brigand]

@rpflorence the point is that if you do <div class="ui button" /> you have sui and no accessibility, and if you do <div class="ui button" role="button" tabindex="0"> you have sui and accessibility.

In what way would you change Semantic? Automatically go around to buttons and dropdowns and add these attributes and emitting events for various div based elements? You can do that with a 3rd party jQuery plugin. It doesn't make sense to me because I don't see the actionable part of this request.

If someone writes up a real actionable proposal, that'd clear up my confusion.

[elucify]

Semantic is tag ambivalent...

I hope you mean tag agnostic:

ambivalent: having mixed feelings or contradictory ideas about something or someone.

agnostic: denoting or relating to hardware or software that is compatible with many types of platforms or operating systems.

Does that mean I can use the same classnames on a as on a

, and it will look the same?

@brigand, have you ever used a screen reader? Semantic UI may be tag-agnostic, but screen readers have definite opinions about what markup means. Screen readers assume that buttons are buttons, though you can use ARIA roles to bring the kind of semantics to the screen reader that Semantic UI brings to CSS. (In fact, there's a missed opportunity here--there's quite a bit of overlap between ARIA role taxonomy and Semantic UI class names).

I think @brigand makes a good point: maybe a jquery plugin to support ARIA based on Semantic-UI class names is just the ticket. Fortunately, this is an open-source project, so such a plugin could be written by any third parties, and coordinated with Semantic UI releases.

[jlukic]

@elucify I agree completely with your assessment about tags. Agnostic makes more sense. Some of that copy was written hastily a year ago, and I wouldn't say I'm so much a snoot to stand behind my writing word-by-word in all cases.

Although SUI would like to be completely tag agnostic, browsers implementations aren't as much so with regards to layout. Some issues with using <button> with ui button are caused by browsers somewhat skewed implementation of certain tags. There are also some peculiarities with <input type="button"> as well, although even since the library came out originally a year or so ago, surprisingly, the situation has already improved.

[ryanflorence]

Being "tag agnostic" means "a11y aggressive"

On Tuesday, November 25, 2014, Jack Lukic notifications@github.com wrote:

@elucify https://github.com/elucify I agree completely with your assessment about tags. Agnostic makes more sense. Some of that copy was written hastily a year ago, and I wouldn't say I'm so much a snoot to stand behind my writing word-by-word in all cases.

Although SUI would like to be completely tag agnostic, browsers implementations aren't as much so with regards to layout. The only issues with using with ui button are caused by browsers somewhat skewed implementation https://github.com/Semantic-Org/Semantic-UI/issues/967 of certain tags. There are also some peculiarities with <input type="button"> as well, although even since the library came out originally a year or so ago, the situation has improved.

— Reply to this email directly or view it on GitHub https://github.com/Semantic-Org/Semantic-UI/issues/348#issuecomment-64488088 .

[samueljseay]

I hope no one minds me adding my 2 cents here, but a good example of where Semantic UI falls short on accessibility (and why my company has had to turn down using it despite it being one of the nicest most comprehensive frameworks) is things like setting aria-expanded role on widgets like accordion.

I shouldn't have to add that functionality because in the end to maintain those aria attributes properly is a responsibility of the JS widget, not something I want to patch or modify.

I hope this feedback helps the discussion. :)

[LauraLalune]

+1 for all the accessibility issues here. I've switched to foundation a couple of years ago: I'm getting disappointed by their lack of support (and I need some more element to play with). So I was thinking about semantic: I've been following the growth of your project and now that I'm starting a new project of mine I'm really considering accessibility issues.

Something like foundation does would be enough for me to decide and adopt semantic UI, and I guess it would be the same for other developers/UI specialists: (scroll down to "Accessibility") http://foundation.zurb.com/docs/components/accordion.html

Consider this also from a strategy perspective: if people concerned about accessibility could use your framework, they realistically would adopt it easily. More people who use it -> more support and community discussions -> best framework. Isn't it?

[balexandre]

I'm all in with helping developers know what WIA-ARIA is and how can help the end user/customer when visiting their content, but I also understand that this has nothing to do with the CSS Framework we choose as I can see @X4 is trying to make it as-one.

We, third-party developers, could easily develop a plugin that would add missing ARIA tags like:

$(".ui.menu").attr("role", "menubar")
$(".ui.menu a, .ui.menu li").attr("role", "menuitem")

but then again, how can we know that we should also add

aria-haspopup="true" aria-expanded="false" aria-labelledby="fileLabel"

that is also important, as well so many other examples that will come with experience.

ARIA should be taken seriously from the developer, not the CSS Framework, though, as said before, we could make something to help the ones that have a rough idea what ARIA is, but have no idea what should be done and what those tags represent and make that plugin to provide really basic stuff like @samueljseay says about the accordion ...

But no mater what road is taken, the developer needs to understand ARIA and add the missing tags...

Other example, could start from the docs, just like Bootstrap does in some examples, and add the ARIA code in the example itself creating aware in developers...

[jlukic]

Balexandre thanks for sharing your perspective. I couldn't agree more with everything you're saying.

I think a good place to start is to add an example of using ARIA tags in menu, as you suggested, to give people an idea of how they may work with ARIA tags.

[viridia]

I just discovered this thread and I'd like to weigh in on the discussion. I'm interested in the topic because my previous job involved a lot of ARIA-related work and in particular interfacing with my company's accessibility team.

My opinion is that it is not reasonable to expect application developers to add ARIA properties to the DOM, because this is a complex task that involves many subtleties, even for simple widgets. While it's possible for the average developer to make this "sort of" work, making an accessible experience that is seamless and polished takes a lot of expertise.

A classic example of this is 'focus trapping' in modal dialogs, which is a recommended practice for the WAI-ARIA standard. This means that when a user is tab-navigating between fields in a modal dialog, when the focus gets to the last field in the dialog it should wrap around to the first field, not go off and focus some random part of the page. (Almost all of the existing JS widget libraries get this wrong, Polymer is one of the few that even tries to get it right.) Doing this correctly is not obvious (especially if you want to support autofocus), and should ideally be a part of the standard model dialog behavior, something that comes for free when you use a widget library, not something the application developer cobbles up themselves.

Other examples, BTW, include things like radio button focus behavior, dynamic states for selection and highlighting, handling disabled items in a way that allows them to be discoverable by a blind user, and just generally making the whole UI able to be keyboard-driven.

To say that "we only supply the visuals, behavior is up to you" is basically to say that your library is incomplete. In general, only 3rd party library developers have the time and expertise to make robust, seamless behaviors that work for many kinds of input methods and devices; to leave that to the application developer, who is generally only focused on short-term feature goals, is a recipe for chaos.

[X4]

Hi,

it's been a while, but I've been actively following the very interesting and constructive discussion here. I'm greeting everyone involved in this thread :squirrel:

I think the most sensible solution to all parties involved is to delegate the issue in a way that it doesn't interfere with the Semantic-UI Framework itself, but is also not pushed into the hands of the regular developer that is not 100% fond of the standard.

Therefore the best solution is to provide a visual or declarative language that can generate the required or specified WAI-ARIA meta-data accordingly. I think forking a good Bootstrap Editor/Generator or GUI would be a more integrated and direct solution than compromising on generic defaults that may or may not apply depending on the use by the developer.

Ninja Edit: Modularizing Content-Assitive and Meta-Data marking elements into a seperate Semantic-Org project as described would help to solve this issue. It would also allow developers to create plugins for forms, modals and other visuals that enhance their capabilities by ie. "word suggestion or spell-checking".

[MoritzGiessmann]

I just discovered Semantic-UI and I think it may be worth it to invest in accessibility. I mean you have a very fine framework here and for example Bootstrap also wasn’t accessible from the beginning, but they improved very much. It would be a big step forward for Semantic-UI and the effort it would take is manageable. :)

[govindrai]

@jlukic Any update on this?

[TonyBogdanov]

+1 to investing in accessibility.

I agree that for the time being a lot of ARIA stuff can be done manually in the DOM, but what I'm concerned most with are things that (can't be, and) require hacking the JS widgets.

A concrete example would be, say, radio buttons. Whatever you do in the DOM, the actual input element is hidden and ignored by the browser, thus there's no way to interact with it in any way whatsoever, unless you use a mouse.

The lib already looks better than most of the competition, so if you'd also invest some time in under-the-hood functionality, it will definitely be an awesome and complete package.

[James1x0]

Just chiming in on this issue from 2013, in hopes that it doesn't die. Accessibility support is extremely important and something that a visual framework should just have. That's not only my opinion, it's our responsibility as developers when we produce something for the public to make things accessible. SUI makes this extremely hard when it comes to modules.

Is there any plan or champion to bring aria enhancements to SUI?

[lpar]

I'd just like to note that lack of accessibility is a massive legal minefield in the US, thanks to case law regarding the Americans with Disabilities Act. So I don't see how Semantic-UI can honestly be described as "Enterprise Ready" (as per the home page) until its accessibility issues are fixed.

[iamareebjamal]

@lpar You're looking at an abandoned repo. Please check Fomantic-UI

[lpar]

OK

[lubber-de]

A classic example of this is 'focus trapping' in modal dialogs, which is a recommended practice for the WAI-ARIA standard. This means that when a user is tab-navigating between fields in a modal dialog, when the focus gets to the last field in the dialog it should wrap around to the first field, not go off and focus some random part of the page.

We added support for that "only allow tabbing within current modal" in the community fork Fomantic-UI by https://github.com/fomantic/Fomantic-UI/pull/2036