[Accessibility] Re: [Accessibility-atspi] DRAFT: ATSPI 5/25/05 meeting minutes

Janina Sajka janina at freestandards.org
Wed Jun 1 18:32:55 PDT 2005


As we discussed on today's call, now that we have clarifications for the
minutes of May 25 from Andres, we're on last call for approving the
minutes.

Any additions or corrections yet outstanding should be submitted by
email to the list no later than midnight (UTC), on Friday, June 3.

If no additional edits are received by that time, we have agreed that
the minutes are approved.

Andres Gonzalez writes:
> Hi George and all:
> 
> Thank you for the notes. Just wanted to clarify the point that you captured
> as:
> 
> > Andres: I have trouble with these statements.
> 
> The two issues I'm referring to here are:
> 1. The need for the API to provide a mechanism to retrieve a list of objects
> of a certain arbitrary type (collection), e.g., list of links, forms,
> headings, paragraphs, annotations... This mechanism would probably need to
> be in the lines of an asynchronous enumeration, since the cost of the task
> depends on the length of the document. We perhaps can discuss in more
> details this mechanism in a separate thread.
> 2. When concerned with collections, CSS attributes for text objects is not
> nearly enough to convey the whole spectrum of interesting collections in a
> complex document. Moving forward it would be good to keep in mind that the
> ADoc API needs to be independent of the underlying document markup, which
> can be as varied as RTF, HTML, XForms, tagged PDF, or even a combination of
> markups on what is known as compound documents.
> 
> Thanks again,
> 
> --Andres.
> 
> -----Original Message-----
> From: accessibility-atspi-bounces at base3.freestandards.org
> [mailto:accessibility-atspi-bounces at base3.freestandards.org] On Behalf Of
> George Kraft
> Sent: Wednesday, June 01, 2005 6:44 AM
> To: accessibility-atspi at freestandards.org
> Subject: [Accessibility-atspi] DRAFT: ATSPI 5/25/05 meeting minutes
> 
> 
> ATSPI 5/25/05 Meeting Minutes
> 
> ATTENDEES
> 
> Bill Haneman
> Gunnar Schmidt
> Will Walker
> Peter Korn
> Janina Sajak
> Cathy Laws
> Larry Weiss
> Pete Brunet
> George Kraft
> Peter Parente
> Andres Gonzales
> Randy Horwitz
> 
> ATSPI MEETING
> 
> Bill asked where we should start the meeting, and George suggest resuming
> the meeting where we left off at item #2 in Cathy's use case list.
> 
> http://freestandards.org/pipermail/accessibility-atspi/2005-May/000034.html
> 
> http://freestandards.org/pipermail/accessibility-atspi/2005-April/000020.htm
> l
> 
> 
> 2. Get a list of the types of elements in number 1. Consider how long this
> task would take for a large Web page with lots of controls and event
> handlers that have tabindex values.
> 
> Bill: On a 1.3 GHz system, 8000 AT-SPI calls can be made per second. For
> optimum performance, the AT would have to restrict the list of elements to
> the visible area. If you try to get a list for the whole document, the user
> will have to wait a while.
> 
> Cathy: We already discussed the use of CSS attributes to know when an
> element is a heading.
> 
> Andres: I have trouble with these statements.
> 
> Bill: In HTML, headings show up as textual objects even if they do not
> contain a non-text element. I'm not sure of an example.
> 
> Andres: What about annotations in documents. They look like icons.
> 
> Bill: Those are expressed as hypertext.
> 
> Andres: Cannot have an interface for different kinds of objects. But I don't
> want to mix annotations and real links.
> 
> Peter: XHTML 2.0 is working to distinguish annotations. We are addressing 2
> questions here: how to do something in AT-SPI and what's wrong with the
> current AT-SPI.
> 
> Andres: Not wrong, just want to improve the existing AT-SPI.
> 
> Bill: We want to present our solutions.
> 
> Andres: I want to point out areas that need improvement.
> 
> Peter: We need to understand how AT-SPI addresses questions first.
> 
> Cathy: If a different tab order is specified in a document, if it were
> possible with AT-SPI to detect, would cause an AT to take longer to collect
> the list of links and controls than following document order.
> 
> Peter: We do not yet have an answer for how AT-SPI should handle two
> different orders, tab versus document. Maybe Relations would work.
> 
> Bill: I doubt Relations would work. I don't have any idea yet how to address
> taborder.
> 
> Janina: We also want to do hierarchical navigation, like jump over a navbar.
> 
> Bill: AT should do that. We can implement all kinds of navigation in the AT,
> but the AT also needs to know the order known by the user agent for the
> document. We've not yet demonstrated the time is real, just theoretical.
> User agent could provide these views. Aren't there already views (lists)
> like this in Mozilla?
> 
> Cathy: The University of Illinois (Jon Gunderson) provides prototype
> extensions for Mozilla to produce these views (lists) of elements, but they
> are not available as part of the Mozilla user agent directly.
> http://cita.rehab.uiuc.edu/software/mozilla/
> 
> Bill: Maybe we could add APIs to do these lists.
> 
> 
> 3. Read the expansion (title attribute) for an acronym or abbreviation.
> 
> Bill: Use the ATKText interface to get this - through the attributes.
> 
> Peter: How does one extract the string for the title attribute?
> 
> Bill: Name = title, value = content.
> 
> 
> 4. Read the long description for an image.
> 
> Bill: For long description, we don't have a notation, but maybe we should
> provide this.
> 
> Cathy: Can we get it through an attribute like the title attribute for
> acronyms?
> 
> Bill: Images are different. They don't have attributes, they have state
> information. Binary objects have state info. Let me double check to see if
> we have a hole. No, it's not missing. There's an image description and an
> object description. That's where long description goes. Alt = object name,
> title = object description, long description = image description. Then use
> streamable content to get the image filename. Can also ask for object mimne
> type. Streamable content could be useful for documents.
> 
> Peter: Nothing is implementing streamable content today.
> 
> Bill: Could be used for SVG and other docuement types, too.
> 
> Peter: AT developers haven't been prepared to use it, so application
> developers didn't implement it.
> 
> Larry: Chicken and egg problem. We need application developers to implement
> it first before AT developers can use it.
> 
> Bill: We could do it in one or two places (applications) to get good
> results.
> 
> Larry: If a reference implementation existed, it would serve as a model.
> 
> Bill: ATK doclink for streamable content. The documentation is very terse -
> one sentence. When documentation is terse, check the gnome site. Some
> documentation, presentations, and article on making applications accessible
> and on how to test accessibility are there.
> 
> Janina: No one else has this deep knowledge that Bill has. This is a
> problem.
> 
> Bill: We need to have a tutorial, or a presentation at a conference.
> 
> Janina: Maybe we should lock ourselves in a hotle room to get it properly
> documented. It might be useful.
> 
> Bill: Agree.
> 
> 
> 5. Determine that the contents of a Web page changed and where.
> 
> Bill: AT-SPI handles when content changes and where, when objects change
> state, new objects appear, if objects change size (bounce), visible data
> change events for any node in any document. it handles insertions,
> deletions. If editing, the AT receives notifications about insertions and
> deletions, like the delta string inserted with indication of start and stop
> offsets. It also handles notifications of selections.
> 
> Larry: Where is this documented?
> 
> Bill: RegisterGlobalEventListener. Events are enumerated. There are specific
> APIs, like pass in event and get encapsulated info. Like get a reference to
> a child object, etc. Out documentation is very weak here, insufficient.
> needs work. If you need to know more, just ask me. As we add to the
> documentation, we may realize where our intentions are not complete.
> 
> Bill: Changes either appear as a new child or ? You know when objects change
> state or are selected.
> 
> 6. Change the author's meta refresh rate.
> 
> Cathy: Meta refresh is specified as an attribute in seconds on the META
> element in the HEAD of a Web page. You can turn on and off meta refresh in
> Internet Explorer, for example, using the security internet options. But the
> user agent doesn't let you change the automatic refresh or redirect rate, so
> to comply with the W3C UAAG requirements, the AT must implement it. HPR has
> this setting. It changes the rate by writing a new value for the refresh
> attribute to the IE DOM.
> 
> Peter: AT-SPI doesn't allow this.
> 
> Bill: AT-SPI can expose objects not on the screen. You could expose it
> through Accessible Component.
> 
> Peter: We could classify these requests in 3 ways. 1) Things AT-SPI does
> easily. 2) Things that could be done in AT-SPI but are cumbersome. 3) Things
> that are holes, like tabindex.
> 
> Bill: Maybe a 4th bucket.
> 
> Cathy: Things today that user agents should do but they are not doing them,
> so ATs are trying to compensate. Subjective.
> 
> 7. Search for accessible content text that was spoken (like alt, title, or
> table summary text).
> 
> Peter: Real challenge. One argument for accessible documen theory. To what
> extent are we requiring non-visual? Cumbersome but possible. It is above and
> beyond what is expected today by 508 to do more than what a sighted user can
> do. It is advanced and not high on the priority list at this time.
> 
> Janina: This is the difference between accessible and usable. 508 only
> requires what sighted people do.
> 
> Peter: If looking at a page with my eyes, I'm paging down. To duplicate this
> using AT-SPI in an AT, then find the search string in what is visible and
> then Page Down.
> 
> Cathy: Sighted users can find any search text in any part of a Web page, not
> just in what is visible, using the Find dialog. I'm only saying that a blind
> user should be able to search the accessible content, their "spoken view" of
> a Web page, to find any word that is in that Web page.
> 
> Peter: Star-Office AT-SPI implementation is only for the visible, so an AT
> can't search the not visible portion of the document.
> 
> Peter: Web pages are not usually as large as word processing or PDF
> documents.
> 
> Janina: Daisy documents are viewed as one large document even though
> physically there may be multiple documents. It is easier to read one large
> document than go back and forward between documents.
> 
> Cathy: That's why headings are important. From our usability studies, we
> found that blind users prefer large documents over lots of small one for
> documentation because of the search capability. Is there an index in Daisy?
> 
> Bill: Search can be done. Is currently limited to what sighted users can do
> and AT-SPI still exceeds what sighted users can do.
> 
> Cathy: Not ideal.
> 
> Peter. Not ideal for sighted users either.
> 
> Bill: Not a need specific to blind users is how rapidly one can search a
> document.
> 
> 
> 
> 8. Select, save, or print all the accessible content that you hear for a
> large, complex Web page. Consider how long this task will take.
> 
> Bill: If I select HTML and then paste it into a new HTML document...
> 
> Cathy: But that's not what accessible content is. Accessible content is a
> mixture of what a sighted user sees as the Web page, plus accessibility
> attributes like alt and title text and table summaries, plus meta text
> describing the state and role of each element. The user might want to print
> the accessible content to a file to review using another AT, or to a Braille
> display. Or a Web developer might want to select all accessible content and
> paste it into a report to analyze a bug or their HTML accessibility
> enablement. Ideally, the document application developer should create the
> accessible content view of a document and provide that view through AT-SPI
> to the AT. That's what one component of HPR does. Provide a service of an
> accessible content view of an HTML document for any AT to speak, print,
> display, etc.
> 
> Janina: I would not want to lose speech characteristics.
> 
> Bill: The AT should create the accessible view of the document. HPR is
> different. It is an AT. The accessible view should not be a part of the user
> agent. In our world, it is not something we would put in the user agent.
> 
> Andres: Adobe Reader 7 has a new feature - save as accessible text.
> 
> Peter: To what extent...?
> 
> Andres: It may be costly to get the whole document and save it. The user
> agent could do it so much faster.
> 
> Peter: Accessible streamable content in AT-SPI allows the AT to get plain
> text. The user agent could implement this API to expose content in different
> mime types. Then the AT would have less work. If the application presents a
> text view, then they either need to implement an accessible document or
> accessible streamable interface. Implementing accessible streamable is much
> easier.
> 
> Cathy: In summary, the biggest need it seems is the AT-SPI documentation,
> which is documenting everything Bill knows.
> 
> Janina: We need an event to flesh this out. I'm really pleased with this
> discussion.
> 
> Janina: Next week we will leave some time to review any new questions. Also,
> we will talk with the director of the FSG next week? Talk about the message
> on boxes? And something about the LSB. (I didn't catch all the agenda items
> that will be discussed next week.)
> 
> -- 
> George (gk4)
> 
> 
> 
> _______________________________________________
> Accessibility-atspi mailing list Accessibility-atspi at mail.freestandards.org
> http://mail.freestandards.org/mailman/listinfo/accessibility-atspi
> 
> 
> _______________________________________________
> Accessibility-atspi mailing list
> Accessibility-atspi at mail.freestandards.org
> http://mail.freestandards.org/mailman/listinfo/accessibility-atspi

-- 

Chair, Accessibility Workgroup		Free Standards Group (FSG)
janina at freestandards.org		http://a11y.org

Janina Sajka				Phone: +1.202.494.7040
Partner, Capital Accessibility LLC	http://www.CapitalAccessibility.Com

Bringing the Owasys 22C screenless cell phone to the U.S. and Canada. Go to http://www.ScreenlessPhone.Com to learn more.





More information about the Accessibility mailing list