Re: [tdf-discuss] Accessibility (was Java dependency)
Hi Jonathon! Am Mittwoch, den 03.11.2010, 06:47 -0400 schrieb Michael Meeks: > On Wed, 2010-11-03 at 02:08 +, jonathon wrote: [... Important Accessibility Stuff ...] Maybe helpful, maybe not ... there has been a talk about the current A11Y status within OOo at the OOoCon this year. Maybe interesting for some guys ... OOo Accessibility - past, present and future Malte Timmermann, Bing Yin http://www.ooocon.org/index.php/ooocon/2010/paper/view/217 > > Something I hadn't thought of earlier, was what the Libre Colour palette > > looked like to a person that was colour blind. My colour blind palette > > only covers the "websafe color palette". None of the colours are in that > > palette. > > Good thinking; it would be great to ping Christoph Noack on that > presumably he has thought at least a bit about it - the monochrome > outline is quite good I imagine. Pong! :-) Good points! Jonathan, a question to get a better understanding. With "Libre Colour palette", do you mean a) the default color palette within LibreOffice, or b) the LibreOffice Branding Colors [1] (not shipped with LibO)? If the latter, then you are right - when presenting the first "beta" version of the colors, I skipped some color testing as mentioned here [2]. And as Michael already mentioned, we currently go for high "luminance" contrast which avoids problems right from the start (although people sometimes find it a bit boring). We really don't perform that bad - as you can see here [3]. It might even require some minutes rendering time - it is a "Colorblind Filter" I use from time to time. On the right side, there will be a "control box" that lets you chose different . Currently we refine the colors to make it easier to work with. Some people already added their ideas at [4]. From the "branding" perspective, it is just difficult to use standard palettes (branding means usually being rather unique). Thus, I plan to do some basic simulation (e.g. with The Gimp) before we finalize the colors. This helps a bit, but ... ... from experience it is known that we have to be careful with colors - not only color blindness, but also cultural differences in what color means to people. However, did that address some of your concerns? I'm happy to hear your opinion and - maybe - some proposals how we can get further improvements. Especially since the colors should be finalized as soon as possible (other related items are stalled at the moment). Thanks! Bye, Christoph [1] http://wiki.documentfoundation.org/Marketing/Branding#Color_Table [2] http://luxate.blogspot.com/2010/10/united-colors-of-liberty.html [3] http://colorfilter.wickline.org/?a=1;r=;l=0;j=1;u=www.documentfoundation.org;t=p [4] http://wiki.documentfoundation.org/Marketing/Ideas#Refined_LibreOffice_Branding_Colors -- Unsubscribe instructions: Email to discuss+h...@documentfoundation.org Posting guidelines: http://netmeister.org/news/learn2quote.html Archive: http://www.documentfoundation.org/lists/discuss/ *** All posts to this list are publicly archived ***
Re: [tdf-discuss] Accessibility (was Java dependency)
On Wed, 2010-11-03 at 02:08 +, jonathon wrote: > > Is there a better alternative for Windows users? > > Roughly five years ago, IBM promised to deliver a better A11Y solution > for Windows to OOo. AFAIK, that hasn't yet happened. Agreed - this will be the best solution in the end. Novell (with Oracle, and RedHat) initially wrote-out the Java dependency for a11y on Linux, in favour of a native atk+ bridge - which (for all its troubles) performs better, and is actually widely deployed (giving us lots of nice bug reports). Clearly we need the same for Mac and Windows. Writing such a native bridge is not -that- hard, and I'm not aware of a better sol'n than java for Mac - if anyone is interested in doing a bit of socially useful hacking, here they need to read: vcl/unx/gtk/a11y/* and: http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/Accessibility/cocoaAXIntro/cocoaAXintro.html And get in touch :-) > Basically, you have to throw away _all_ of the existing code, and > rewrite it from scratch, with i18n, l10n, and a11y as the core > requirements. [Retrofitting a11y, i18n, or l10n always requires more > time and effort that starting from the beginning, with no code at all.] Nah - it is not this bad; there is a reasonable internal a11y structure: it has several obvious weaknesses, but perhaps we can fix some of them if we are past the religion of eternal UNO API stability in this area. > Something I hadn't thought of earlier, was what the Libre Colour palette > looked like to a person that was colour blind. My colour blind palette > only covers the "websafe color palette". None of the colours are in that > palette. Good thinking; it would be great to ping Christoph Noack on that presumably he has thought at least a bit about it - the monochrome outline is quite good I imagine. Anyhow - a really good write-up; if you want to get involved hacking on this, it'd be much appreciated. ATB, Michael. -- michael.me...@novell.com <><, Pseudo Engineer, itinerant idiot -- Unsubscribe instructions: Email to discuss+h...@documentfoundation.org Posting guidelines: http://netmeister.org/news/learn2quote.html Archive: http://www.documentfoundation.org/lists/discuss/ *** All posts to this list are publicly archived ***
Re: [tdf-discuss] Accessibility (was Java dependency)
T. J. Brumfield wrote: I'm moving this into another thread. Jonathon suggested that LibO fails at accesibility requirements. Doing a few quick Google searches, it seems that OOo and thusly LibO uses the Java Accessibility API to enable the use of screen readers and braille devices. This is primarily used for Windows. On Mac OSX, the built-in screen reader in the OS is used. On Linux, the Gnome Accessiblity tools are used. Yet the OOo wiki suggests the reason you must use the Java Accessiblity API is that it is multi-platform, yet OOo doesn't appear to be using it on two of their platforms. When OOo was a Sun project I think the use of Java was a case of what is called dog-fooding. With LO there is no longer any compelling reason to use Java. -- Unsubscribe instructions: Email to discuss+h...@documentfoundation.org Posting guidelines: http://netmeister.org/news/learn2quote.html Archive: http://www.documentfoundation.org/lists/discuss/ *** All posts to this list are publicly archived ***
Re: [tdf-discuss] Accessibility (was Java dependency)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/02/2010 07:56 PM, T. J. Brumfield wrote: > LibO uses the Java Accessibility API to enable the use of screen readers and > braille devices. Screen reading is not the only thing that that API can be used for. > Is there a better alternative for Windows users? Roughly five years ago, IBM promised to deliver a better A11Y solution for Windows to OOo. AFAIK, that hasn't yet happened. > And how can LibO be made more accessible in general for all users? Basically, you have to throw away _all_ of the existing code, and rewrite it from scratch, with i18n, l10n, and a11y as the core requirements. [Retrofitting a11y, i18n, or l10n always requires more time and effort that starting from the beginning, with no code at all.] Full accessibility has several mutually conflicting requirements. However, if the following criteria are met, most of the conflicting requirements are negated: * All input can be done by voice; * All input can be done by a joystick; * All input can be done by a Perkins Keyboard; * All input can be done by a mouse; * All input can be done using an 78 key keyboard; * All input can be done on a touchpad; * All input can be done using a virtual keyboard; The program must be able to accept simultaneous input from each device; * All output can be read on a Braille display monitor; * All output is in an audio format; * All output can be read on either a CRT or LCD monitor; * All output can be felt on a touchpad; The program must be able to simultaneously output to those devices; The user must be able to change: * The display size of the data that is presented to them: ** This includes screen magnification on CRT or LCD monitors; ** This includes screen magnification on touchpads; ** This includes all tactile devices; * The audio volume of the data that is presented to them: ** This includes screen readers; ** This includes self-voicing functionality; ** This includes all audio output devices; * The colours that are used: ** Icons must be changeable both individually, and as a group; ** Colours used anywhere in the program must be user changeable; The program must be able to print to: * A Moon Printer; * An audio file; * A Braille printer; * A "normal" printer: ** Ink jet printer; ** Dot matrix printer; ** Laser printer; ** Thermal ink printer; In an ideal world, the user could select any of those, and the program would automatically print out the data on the requested printer, without any more user intervention. There is an extension that tries to do output to Braille. The major issue with it, is that it only works for one or two languages. I've read about an extension that outputs a text document to mp3 format. I do not know how far it progressed. Arguably, A11Y also requires the program to be able to print out the following file formats: * Plain text: ** ANSI/ASCII; ** UTF-8; ** UTF-16; ** UTF-32; ** Other common plain text character encodings; * eBook file formats: ** PDF; ** Postscript; ** Mobi; ** ePub; ** HTML 5.0; ** DAISY; ** DjVu; ** AZW (Kindle); ** PDB (eReader); ** Other common eBook file formats; * Graphical file formats; ** PNG; ** SVG; ** JPG; ** Other common graphical file formats; I think that most of these could be done as extensions that the user installs, if they want/need/require the specific output capability. Some of these, involve file formats that are patented, trademarked, under copyright, or otherwise blemished. # For full accessibility, the best option, from the user's point of view, is for each component of an office suite to be a single program, written for a set of specific accessibility requirements. This option is also the most expensive for developers to implement. Some aspects of a11y can be provided as extensions to LibO. # - From my POV, the major point of failure, of the ODF specifications, in terms of A11Y requirements, is that the style does not define the writing system that is used. This is one "custom extension" of the specification that LibO could make, that should not break in other software that can utilize the ODF file formats. (My understanding of the XML criteria, is that unknown XML markup is ignored.) The importance of including the writing system, is so that text in Braille, Moon, ASL, and other a11y orientated writing systems can be directly created and edited within LibO. I am acutely aware of the issues involved in making LibO capable of editing documents in Moon. I'm even more aware of the issues involved in printing documents in Moon. It is hard task. It is very non-trivial to implement. But full # Something I hadn't thought of earlier, was what the Libre Colour palette looked like to a person that was colour blind. My colour blind palette only covers the "websafe color palette". None of the colours are in that palette. jonathon -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.moz
[tdf-discuss] Accessibility (was Java dependency)
I'm moving this into another thread. Jonathon suggested that LibO fails at accesibility requirements. Doing a few quick Google searches, it seems that OOo and thusly LibO uses the Java Accessibility API to enable the use of screen readers and braille devices. This is primarily used for Windows. On Mac OSX, the built-in screen reader in the OS is used. On Linux, the Gnome Accessiblity tools are used. Yet the OOo wiki suggests the reason you must use the Java Accessiblity API is that it is multi-platform, yet OOo doesn't appear to be using it on two of their platforms. Is there a better alternative for Windows users? And how can LibO be made more accessible in general for all users? jonathon wrote: >For those that have accessibility requirements, the Java is mandatory. >OTOH, even with Java, LibO is not an accessible program. On the gripping >hand, all office suites fail accessibility requirements. -- "I'm questioning my education Rewind and what does it show? Could be, the truth it becomes you I'm a seed, wondering why it grows" -- Pearl Jam, Education -- Unsubscribe instructions: Email to discuss+h...@documentfoundation.org Posting guidelines: http://netmeister.org/news/learn2quote.html Archive: http://www.documentfoundation.org/lists/discuss/ *** All posts to this list are publicly archived ***
