18 Nov
2010
18 Nov
'10
11:56 a.m.
On Thu, Nov 18, 2010 at 12:40, Ecaterina Moraru (Valica)
<valicac(a)gmail.com>wrote;wrote:
On Wed, Nov 17, 2010 at 20:45, Vincent Massol <vincent(a)massol.net> wrote:
Actually this is described at:
http://www.w3.org/TR/WCAG20-TECHS/G14.html
What we need to add is the active state for the syntax chooser, that is
marked now using background-images bullets.
Hi Caty,
On Nov 17, 2010, at 5:39 PM, Ecaterina Moraru (Valica) wrote:
I think this feature is already covered by the TOC.
The main reasons I like it in the current form are:
+ the toc gives you a way to navigate to the desired section and this is
accessible/visible since the beginning of the page. We could improve here by
grouping into some categories (text editing, development, multimedia) and
also using some numbers to show the hierarchy 1., 1.1, etc. (makes it much
easier to follow the nesting) ;
+ if you want to browse the content, learn the syntax or just see XWiki
syntax capabilities, is much easier to do this by scrolling than segmenting
the content and needing to click each time.
- the negative part about the current model is when you want to access two
non-sequential categories: you either scroll until you find it, or go top
and use another anchor.
The generic solution for this problem (and this targets all pages, which is
much nicer than building something custom just for the Syntax page) is the
option to select to have a following TOC (the way we have now the page
related action menu).
Hi,
This is a proposal for compacting the way we show XWiki Syntaxes
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/SyntaxExperiments
Feedback is welcomed.
It looks good.
I have some questions:
* I think it would be good to have a menu on the left listing all the
syntax "domains": text formatting, tables, sections, etc and when you click
on "domains" you get the doc for that domain (without reloading the whole
page if possible)
* We need to ensure that this syntax help page is
accessible for people
with deficiencies (ie it must pass WCAG) since some of them won't be able to
use the WYSIWYG editor they'll need to use the wiki editor and thus know how
to write in wiki syntax. How could we make the syntax chooser work nicely
for WCAG?
About WCAG:
- the main problem with generated tables from wiki markup is that they lack
summary attr. We can fix this by creating a macro that creates the table
header, and we need one because the header will need to specify the syntaxes
available for the specific feature (some features will be available just for
syntax 2.0 and 2.1 for example).
- we will improve the syntax chooser to conform with Link guidelines (will
have underline, be marked as links and have title attr);
- because of the comparison feature between syntaxes, various syntax code
is mixed. For people that use screen readers will have hidden markup that
will mark each line, and also have final total code written (not visible for
the others), Example:
<dt>term2</dt>
:; term2
<dd>definition2</dd>
:: definition2
will be marked:
[Syntax 1.0]
<dt>term2</dt>
<dd>definition2</dd>
[Syntax 2.0]
:; term2
:: definition2
[Comparison]
[Syntax 1.0] <dt>term2</dt>
[Syntax 2.0] :; term2
[Syntax 1.0] <dd>definition2</dd>
[Syntax 2.0] :: definition2
Please tell me if there are other WCAG problems. I will improve the
proposal to show the hidden markup.
Thanks,
Caty