2014/1/8 Sergiu Dumitriu <[email protected]> > On 01/08/2014 09:14 AM, Guillaume "Louis-Marie" Delhumeau 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). > > That means that the content is accessible. A non-JS implementation > doesn't have to look and behave exactly the way it does with JS, just > that the content can be accessed one way or another. > > > 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). > > The object editor works perfectly fine. You can get to it from the URL. >
Because you know it. I also know the URL to see the activity stream of a subwiki ;) > You can see it in a text browser. You can see it with stylesheets > disabled. The fact that the menu is not accessible is a different story, > we know about it, just that nobody had the time to work on it. > That is precisely the point. Just to clarify my position: I am not strongly against having a non-js version of XWiki for the core features, and I will change my previous commit since the Marius proposition is so simple that it is a shame to not do it. I am sensitive to that problem of accessibility, and I would like to have an Internet where the disparities of the real-world does not exist. But maybe we should decide a clear rule about that and decide what should be the "scope" of that accessibility, and keep in mind that it has an extra cost for our little team. LM > > > So we should provide a non js solution for that too. > > > > Do we want to make that effort? > > > > > > 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
