Re: [xwiki-devs] [Brainstorming] Do we still want to be accessible without javascript

I fully agree with Sergiu on this. Whenever I work on UI I first look for a clean and lightweight non-JavaScript solution (even if it's a partial solution). Then I see how this can be enhanced with JavaScript. The entire web page can be generated on the client side with JavaScript. So my worry is that saying "we don't need support the navigation without javascript in 2014" will lead to using JavaScript even where it's not really needed (e.g. using click listener to focus an input element in an HTML form instead of the label element with the 'for' attribute set). I think navigation should work as much as possible without JavaScript. Thanks, Marius On Wed, Jan 8, 2014 at 8:00 AM, Sergiu Dumitriu <sergiu(a)xwiki.com> wrote: > On 01/07/2014 09:28 AM, Guillaume "Louis-Marie" Delhumeau wrote: >> Hi devs, >> >> In a recent pull request >> (https://github.com/xwiki/xwiki-platform/pull/254), I have "fixed" a >> bug reported by the accessibility validator by hiding a >> link if javascript is not enabled on the browser. It didn't fix the fact >> that the feature is unavailable without javascript, but at least the link >> was not there. >> >> I did it because I have the feeling that some committers think we don't >> need support the navigation without javascript in 2014. >> >> Now, it seems that we do not all agree about this. >> >> That is why I think we should talk about this to decide what rule we should >> put in place for the next years. >> >> Thanks, in advance, for your opinions. >> >> Louis-Marie > > -1 (non binding since this isn't a vote). > > But it really depends on how do we see XWiki. > > If it's an enterprise application, then yes, we can drop support for > accessibility. > > If it's a wiki, then -1, any wiki should be all-inclusive, as a content > authoring tool; but that doesn't mean that EVERYTHING must work without > scripts, just that at least basic navigation and content authoring > should work even from a text-based or voice-based browser. > > Same answer if it's a generic web content authoring tool, not just a > wiki. However, if it's a specific data entry tool with a specific target > (i.e. a custom application for somebody's intranet), then it's up to the > customer to decide if accessibility is a must. > > If it's a web application development framework, then it doesn't > necessarily have to be accessible, although it would be better (anybody > can write Java code in an accessible editor, why not XWiki code?), but > the resulting application (and the navigation around it) may be required > to be accessible. > > > Anyway, asking the devs is pointless, we can write whatever kind of > XWiki we want, but that doesn't mean that end users are going to be > happy about it. The users are the ones that should voice their opinion. > > FWIW, in the past a few XWiki users did choose XWiki because it was > accessible, and XWiki SAS did sign a contract for providing and > maintaining XWiki accessible, where "accessible" is defined as "passing > the Dutch webrichtlijnen validation". I don't know if that contract is > still in effect or not. > > -- > Sergiu Dumitriu > http://purl.org/net/sergiu > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs