On Wed, Jan 8, 2014 at 4:14 PM, Guillaume "Louis-Marie" Delhumeau <[email protected]> wrote: > 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). I know that, but it was *so easy* to have a solution that degrades nicely when the JavaScript is disabled. > > 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? We should at least make the effort to investigate how easy/complex it is to have a solution that degrades nicely when JavaScript is disabled... > > > 2014/1/8 Marius Dumitru Florea <[email protected]> > >> 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 >> <[email protected]> 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 <[email protected]> >> 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 >> >> [email protected] >> >> http://lists.xwiki.org/mailman/listinfo/devs >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs >> > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
