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

In that specific case, I agree I could have made an other decision. Actually I wanted to include the results of the other page in the current page (not only a link to that other page).

Anyway, the problem is more generic that this. I agree that having at least a content editor tool accessible would be great. But we already have not this. To me, the Space Index is a mandatory feature to navigate trought the wiki and it does not work without javascript. You can not use the object editor without js neither (just try to click on the object editor link without js).

So we should provide a non js solution for that too. Do we want to make that effort? 2014/1/8 Marius Dumitru Florea <mariusdumitru.florea(a)xwiki.com> > I've looked at what Guillaume did and adding support for > non-JavaScript is just a matter of putting the right URL in the href > attribute of the anchor.. We're not talking about fancy stuff here, > just basic navigation which is enhanced by AJAX. > > On Wed, Jan 8, 2014 at 10:46 AM, Marius Dumitru Florea > <mariusdumitru.florea(a)xwiki.com> wrote: >> 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.