+1 to officially drop support for non-javascript-enable clients (browsers). Ideally it shouldn’t show an error (not even sure we need to go to that level) but the feature is allowed to not be present when javascript is not enabled. Thanks -Vincent On 7 Jan 2014 at 15:29:04, Guillaume Louis-Marie Delhumeau ( gdelhumeau(a)xwiki.com) 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 _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

+1 Of course we always have to move cautiously and remember that DOM structure, even if js generated, can be very important to vision impaired users. Thanks, Caleb On 01/07/2014 03:30 PM, vincent(a)massol.net wrote: _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

+1 Of course we always have to move cautiously and remember that DOM structure, even if js generated, can be very important to vision impaired users. Thanks, Caleb On 01/07/2014 03:30 PM, vincent(a)massol.net wrote: (browsers). level) but the feature is allowed to not be present when javascript is not enabled. gdelhumeau(a)xwiki.com) wrote: should _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

For information, we have some some key features that can not work without JS right now: - livetable - the top menu bar and maybe more... So if we decide to enable non-javascript navigation, it means we must also write non-javascript version of these features to be consistent. 2014/1/7 Caleb James DeLisle <cjd(a)hyperboria.ca> not fact link _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

On 01/07/2014 09:28 AM, Guillaume "Louis-Marie" Delhumeau wrote: -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

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: wrote: fact link should _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

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.