[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office-accessibility] Minutes: February 10 Accessibility SubteamMeeting
Greetings, I think one way to do this is to have some sort of accessibility validation turned on by default in ODF apps. So long as it isn't too heavy-weight or user intrusive (though of course it *has* to be somewhat user intrusive). What we've learned from PDF (and HTML) is that guidelines alone aren't enough. Further, what we've learned from PDF is that having an accessibility validator buried in the menus means that most authors won't use it. I daresay even the checkbox right in the SO/OOo "Save as PDF" dialog to do PDF tagging may be insufficiently "in the user's face" (because it is turned off by default). Striking a balance between "on by default", and "pestering the user when it isn't there by default", and the general usability and happiness of mainstream users who don't want the larger file size (esp. for PDF where tagging adds a lot to the size) and annoyance, is a very difficult thing to do. But clearly where we've put the dividing line in the past (esp. with PDF) has really failed for accessibility. Regards, Peter Korn Accessibility Architect, Sun Microsystems, Inc. > Indeed. > > I think it worth noting that encouraging good word processor habits is > good all around. Of course it will always be possible to do things > inaccessibly, we need to focus on making it easy to do things right. > Everyone benefits if implementations are smart enough to trap usages > that impede accessibility because what we're asking for is proper > labeling. > > In other words, it's helpful to catch the instance when someone spaces > five times to indent a paragraph and educate them to use the indent > function instead. > > Mike Paciello writes: > >> Chiming in here: >> >> 1. The earlier we begin educating key ODF adopters/implementers, the better >> chance we have of avoiding the PDF accessibility situation. >> 2. It's true that we can't completely control the ways and means of the >> implementors. But if the specification's end result is based on sound >> principles, a rich set of rules, and tools that promote (through mechanisms >> like contextual prompting), I believe we'll come out way ahead of what >> either Adobe or MS has done in less than 1/10th of the time. >> >> - Mike >> >> Mike Paciello >> TPG >> +1 603.882.4122 ext 103 >> >> >> _____ >> >> From: Nathaniel S Borenstein [mailto:nborenst@us.ibm.com] >> Sent: Monday, February 13, 2006 1:05 PM >> To: Peter Korn >> Cc: janina@rednote.net; mike paciello; >> office-accessibility@lists.oasis-open.org; Richard Schwerdtfeger >> Subject: Re: [office-accessibility] Minutes: February 10 Accessibility >> Subteam Meeting >> >> >> >> This is worth discussing, but I'm a little bit afraid of mandating the >> impossible. If it is possible to use an ODF tool to produce a >> non-accessible document, it will happen from time to time, and I'm not sure >> to what extent we can completely prevent it. But we can definitely raise >> the bar and educate the tool vendors to try to make this as rare an >> occurrence as possible. I think a very clear set of guidelines for >> implementors is our best bet; an ODF conformance specification/logo might >> help, but I've not been very impressed in the past with the effectiveness of >> such certifications in general. -- Nathaniel >> >> >> >> >> Peter Korn <Peter.Korn@Sun.COM> >> >> >> 02/13/2006 12:27 PM >> >> >> To >> Nathaniel S Borenstein/Concord/IBM@IBMUS >> >> cc >> Richard Schwerdtfeger/Austin/IBM@IBMUS, janina@rednote.net, mike paciello >> <mpaciello@paciellogroup.com>, office-accessibility@lists.oasis-open.org >> >> Subject >> Re: [office-accessibility] Minutes: February 10 Accessibility Subteam >> Meeting >> >> >> >> >> >> >> Hi Nathaniel, >> >>> Just to be crystal clear: Keyboard navigation per se is not in scope >>> because it is a user interface feature, not an attribute of the >>> document standard. What definitely IS in scope, however, is making >>> sure that the document format provides enough information to permit >>> and facilitate keyboard navigation. >>> >>> What this seems to mean in practice, so far, is that we need to define >>> the mechanism that allows pointers into and out of embedded objects. >>> Those pointers would of course facilitate keyboard navigation, but >>> they'd similarly facilitate voice navigation, eyeblink navigation, >>> direct brain-machine interface, and so on. Our job is to ensure that >>> it is possible to access an ODF document using any of those methods, >>> but not to define precisely the user interface for any of them. -- >>> Nathaniel >>> >> Is there not a group formed, or forming, that is looking at guidelines >> for ODF implementors? If so, this is a topic we should engage them on. >> As we've seen with PDF, much of the problem in PDF accessibility is >> getting the PDF generators to insert proper tagging (with the result >> that while the PDF/A format formally has everything that is needed for >> accessibility, the format itself is largely shunned by the blindness >> community because in practice the PDF files that are out there "in the >> wild" are inaccessible). >> >> We must avoid following the path of PDF accessibility. We will need to >> push hard on the ODF implementors to do the right thing. In fact, one >> tool to consider (and that has worked fairly well with Microsoft) is >> logo requirements. An ODF generating app cannot get some ODF-compliant >> logo unless they do right by, among other things, accessibility. Food >> for discussion for our next meeting? >> >> >> Peter Korn >> Accessibility Architect, >> Sun Microsystems, Inc. >> >>> >>> >>> >>> *Richard Schwerdtfeger/Austin/IBM@IBMUS* >>> >>> 02/11/2006 10:08 AM >>> >>> >>> To >>> Peter Korn <Peter.Korn@Sun.COM> >>> cc >>> janina@rednote.net, mike paciello >>> >> <mpaciello@paciellogroup.com>, >> >>> office-accessibility@lists.oasis-open.org >>> Subject >>> Re: [office-accessibility] Minutes: February 10 >>> >> Accessibility Subteam >> >>> Meeting >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Yes, keyboard navigation of ODF readers was discussed in my kickoff >>> yesterday. See my minutes from the last post. In particular, this is a >>> critical for presentations. ... should we have declarative markup to >>> define keyboard navigation? >>> >>> What is the status of Clark? >>> >>> >>> Rich Schwerdtfeger >>> Distinguished Engineer, SWG Accessibility Architect/Strategist >>> Chair, IBM Accessibility Architecture Review Board >>> blog: _http://www-106.ibm.com/developerworks/blogs/dw_blog.jspa?blog=441_ >>> >>> "Two roads diverged in a wood, and I - >>> I took the one less traveled by, and that has made all the >>> difference.", Frost >>> >>> Inactive hide details for Peter Korn <Peter.Korn@Sun.COM>Peter Korn >>> <Peter.Korn@Sun.COM> >>> >>> *Peter Korn <Peter.Korn@Sun.COM>* >>> >>> 02/10/2006 07:10 PM >>> >>> >>> >>> To >>> >>> Richard Schwerdtfeger/Austin/IBM@IBMUS >>> >>> cc >>> >>> office-accessibility@lists.oasis-open.org, mike paciello >>> <mpaciello@paciellogroup.com>, janina@rednote.net >>> >>> Subject >>> >>> Re: [office-accessibility] Minutes: February 10 Accessibility Subteam >>> Meeting >>> >>> >>> >>> >>> >>> >>> >>> Hi Rich, gang, >>> >>> Sorry I was unable to attend this meeting. Mike - welcome to our group! >>> >>> A quick question: is Jerry Berrier now a formal member, and on the >>> alias? If not, shouldn't he be included on the e-mail distribution? >>> >>> Re: keyboard navigation for ODF readers: is that in scope of this >>> subcommittee? If not, is there a group for whom it is in scope? >>> >>> Re: CSUN - Janina and I have been discussing this for a while, and PJ at >>> IBM has also been involved. Rich & Mike - please include me in those >>> discussions as well... >>> >>> >>> Regards, >>> >>> Peter Korn >>> Accessibility Architect >>> Sun Microsystems, Inc. >>> >>>> Members Present: >>>> >>>> Mike Paciello >>>> Rich Schwerdtfeger >>>> Janina Sajka >>>> Nathaniel Borenstein >>>> Chieko Asakawa >>>> Hironobu Takagi >>>> >>>> Rich: Introduction: Raising the Bar with ODF ( Goals and Objectives) >>>> >>>> ODF is the first truly open document format where we can all raise the >>>> accessibility bar >>>> - Regardless of ODF's future - Raising the bar will drive all document >>>> access to improve >>>> - This is an end user effort as much as it is a technical effort - Use >>>> Cases are Critical >>>> - We must consider a total solution (Application, AT interoperability, >>>> Author assistance) >>>> - We must execute in a timely fashion >>>> >>>> Objectives >>>> - Support DAISY standards for talking books (allow for XSLT >>>> >>> transformation >>> >>>> - Fill basic gaps between existing Office formats and ODF >>>> - Follow existing W3C accessibility standards and markup features >>>> (WCAG, XForms, etc.) >>>> - Enhance Braille support where possible >>>> - Improve Access to Presentations >>>> - Improve Keyboard navigation (Can we benefit from Declarative markup >>>> for Keyboard navigation?) >>>> - Facilitate platform API interoperability (support emerging Dynamic >>>> Web Access Standards) >>>> - Solutions should be usable! >>>> >>>> Expected community involvement >>>> - Use Cases, Use Cases, Use Cases - You don't need to be a techy, you >>>> need to be a consumer >>>> - Feedback >>>> - Technical expertise in DAISY, W3C specifications are welcome >>>> >>>> >>>> Page 21 of gap analysis - Chieko Asakawa >>>> >>>> Chieko: There are 2 types of objects OLE and ODF. On the left side you >>>> cans see a list of files and one OLE object. On the right you have a >>>> list ODF object. There is an embedded OLE object. Bottom is an example >>>> of an ODF object. >>>> >>>> Hiro: XML based AT can handle the embedded objects. >>>> >>>> Rich: is there anything we can do to assist in providing the >>>> navigation in and out of the embedded objects? >>>> >>>> Hiro: Don't have an idea on how to tell the browser how to improve >>>> keyboard accessibility for embedded objects. >>>> Hiro: Can't peform accessibility checking on embedded objects - unless >>>> they are ODF. >>>> Hiro: Recommend that not use OLE objects because we cannot validate. >>>> >>>> Rich: Do we leave it up to the user agent on how we navigate in and >>>> out of an embedded document. >>>> Rich: Is there any keyboard specification in the ODF Spec. >>>> Nathaniel: no, we need to address sequencing and the strategies for >>>> processing that. >>>> Chieko: Z order would be my preference. - Depth. >>>> Rich: how does workplace deal with embedded ODF docs >>>> Nathaniel: We should not concentrate on just Worklace >>>> Mike Paciello: Can we get Harvey Bingham to help as he worked on DAISY? >>>> Rich: what is the procedure? >>>> Mike Paciello: I can check with Harvey as he lives close. >>>> Nathaniel: we need to make sure there are no IPR issues. >>>> *Action Item: Mike Paciello to contact Harvey regarding use cases from >>>> a DAISY perspective on how to address navigation in and out of >>>> embedded object (OLE, ODF) >>>> Hiro: Flash can navigate using the down arrow to enter a Flash plugin. >>>> Nothing to get out. >>>> Hiro: For Microsoft Office this does not work. If we are reading a >>>> powerpoint slide an enter key is used to get into the embedded object. >>>> escape to exit. >>>> MIke: I believe there is a keyboard sequence to get out. >>>> *ACTION: Nathaniel investigate whether a parent ODF document may >>>> reference an embbeded ODF document as this could impact the navigation >>>> sequence. >>>> *ACTION: I will pursue use cases in Navigation. >>>> *ACTION: Rich to get with Dave Pawson and Janina on getting meta data >>>> for DAISY support >>>> *ACTION: Hiro and Chieko to provide use cases for navigation documents >>>> and in particular presentations as well as sucggestions on how to >>>> improve markup to remove the guessing/historises >>>> Hiro: SMIL animations are very difficult >>>> Hiro: Office has an exporting function to the animation function >>>> *ACTION: Hiro and Chieko to provide issues on presentations related to >>>> last action item in 2 weeks. >>>> Mike: I am particularly sensitive to the value presentation for having >>>> an ODF speciification >>>> Rich: We need to address value proposition/messaging for CSUN >>>> *ACTION: Rich get with Mike Paciello and Janina Sajka on a first pass >>>> of messaging >>>> >>>> Next meeting is in 2 weeks: >>>> >>>> - Use Cases Mike Paciello on DAISY navigation suggestions >>>> - Chieko/Hiro Issues/Use cases for Presentations navigation/processing >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Rich Schwerdtfeger >>>> Distinguished Engineer, SWG Accessibility Architect/Strategist >>>> Chair, IBM Accessibility Architecture Review Board >>>> blog: >>>> >>> _http://www-106.ibm.com/developerworks/blogs/dw_blog.jspa?blog=441_ >>> >>>> "Two roads diverged in a wood, and I - >>>> I took the one less traveled by, and that has made all the >>>> difference.", Frost >>>> >>>> >>> >> >> > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]