[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[libreoffice-accessibility] Fwd: Re: [libreoffice-design] APP/Online LibreOffice
- Subject: [libreoffice-accessibility] Fwd: Re: [libreoffice-design] APP/Online LibreOffice
- From: Christophe Strobbe <Christophe.Strobbe@esat.kuleuven.be>
- Date: Fri, 21 Oct 2011 22:54:41 +0200
- To: <firstname.lastname@example.org>
At the LibreOffice Conference in Paris, Michael Meeks demonstrated a prototype of LibreOffice Online. A video is available on YouTube: <http://www.youtube.com/watch?v=CVR7HqDokmA>.
This prototype is being discussed on the Design mailing list (see <http://listarchives.libreoffice.org/global/design/msg03216.html>).
Since this is relevant to accessibility, I am forwarding the message I sent to that mailing list.
-------- Original Message --------
Subject: Re: [libreoffice-design] APP/Online LibreOffice
Date: Fri, 21 Oct 2011 22:43:30 +0200
From: Christophe Strobbe <Christophe.Strobbe@esat.kuleuven.be>
On Fri, 21 Oct 2011 21:53:40 +0200, Astron wrote:
As it was explained at the conference, the code used in one will be used in
the other, so we won't have two suites. As for UI improvements we need to
make them in an incremental way. No one will change the UI overnight, it
simply is not realistic.
The problem is that mobile platforms use completely different UI
toolkits and also have completely different UI needs etc.
Did you attend Michael Meeks' presentation at the conference?
Michael said that LibreOffice Online (LOOL) uses HTML5 Canvas to display the user interface, in other words, it does not use a user interface toolkit.
Some background on HTML5 Canvas for those who are not familiar with it:
"The canvas element provides scripts with a resolution-dependent bitmap canvas, which can be used for rendering graphs, game graphics, or other visual images on the fly.
Authors should not use the canvas element in a document when a more suitable element is available. For example, it is inappropriate to use a canvas element to render a page heading: if the desired presentation of the heading is graphically intense, it should be marked up using appropriate elements (typically h1) and then styled using CSS and supporting technologies such as XBL.
When authors use the canvas element, they must also provide content that, when presented to the user, conveys essentially the same function or purpose as the bitmap canvas. This content may be placed as content of the canvas element. The contents of the canvas element, if any, are the element's fallback content."
HTML5 Canvas accessibility (i.e. lack of accessibility) has been heavily discussed on W3C mailing lists.
HTML5 spec editor Ian Hickson has stated that creating an editor in Canvas makes no sense: <http://lists.w3.org/Archives/Public/public-canvas-api/2010JulSep/0024.html>. If I remember correctly, he used this as an argument for not making Canvas accessible.
However, specification editors cannot prevent HTML5 authors from doing such things, and Richard Schwerdtfeger (IBM) used this as an argument for making Canvas accessible: <http://lists.w3.org/Archives/Public/public-canvas-api/2010JulSep/0040.html>.
Issues and discussions around Canvas accessibility have also been collected at <http://www.w3.org/html/wg/wiki/AddedElementCanvas> (a wiki used by the HTML5 Working Group).
When I asked Michael Meeks at the conference if LOOL was going to be made accessible, part of his response was a question whether I knew any Canvas-based applications that are accessible. Of course, I didn't. So Michael is aware of the accessibility problem that Canvas represents.
Using a UI toolkit instead of Canvas would at least allow some level of accessibility to screen readers: accessibility support is being added or has been added to such libraries as JQuery UI, YUI, Mootools and a few others. I believe that work on accessibility in UI toolkits for mobile applications has also started, but I think this is far from mature.
For now, the
best I could imagine on mobile platforms would be a capable ODF
document viewer (unlike the existing viewers for Android).
Anyway, on the whole I'd agree to the notion that we need a mobile,
touch-oriented version of LibreOffice to stay afloat. (...)
Work on making touch-based interfaces accessible is also under way, if I am not mistaken.
K.U.Leuven - Dept. of Electrical Engineering - SCD
Research Group on Document Architectures
Kasteelpark Arenberg 10 bus 2442
tel: +32 16 32 85 51
Unsubscribe instructions: E-mail to email@example.com
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/accessibility/
All messages sent to this list will be publicly archived and cannot be deleted
|Re: [libreoffice-accessibility] Fwd: Re: [libreoffice-design] APP/Online LibreOffice||Astron <firstname.lastname@example.org>|
- Prev by Date: [libreoffice-accessibility] sorry for the spam messages
- Next by Date: Re: [libreoffice-accessibility] Fwd: Re: [libreoffice-design] APP/Online LibreOffice
- Previous by thread: [libreoffice-accessibility] sorry for the spam messages
- Next by thread: Re: [libreoffice-accessibility] Fwd: Re: [libreoffice-design] APP/Online LibreOffice