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. 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. > 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
