Hi. Some random notes on James comment. 1. aria-describedby shouldn't override any DESCRIBED_BY relations, it should append one more relation target. 2. I would say aria-describedby can be used to link header cells and data cells, otherwise there is no way to expose heading information for complex grids in ARIA. Therefore it might not be needed to introduce new IA2 relations. If IA2 would introduce new relations for heading info then ARIA should introduce new attribute to expose these relations. 3. It's hard to expose IA2 header tables for complex cases. 4. I still can't keep in mind when header table is more useful than array of header cells from point of view AT implementation. 5. We can't change accNavigate because of backward compatibility if I get right.
Alex. On Thu, Jun 4, 2009 at 12:00 PM, James Teh <[email protected]> wrote: > Hi all, > > On further thought, if we do use relations, I'm thinking that new > relations should be created for column header and row header. Described > by can be overridden using ARIA. Also, we don't want the content of the > header cell ending up in the accessible description, which might be > inconsistent with the current use of described by. Also, a description > is normally handled somewhat differently to a header cell by ATs. While > I still think relations might be a bit nicer than the table rowHeader > and columnHeader methods, described by/description for is problematic > for these reasons. > > Arguments supporting the relations approach: > * rowHeader/columnHeader acts on the table, rather than the current > cell. Normally, one probably wants to ask for the row/column headers for > a given cell, rather than for the whole table. > * It possibly requires less work on the application side. Having to > expose virtual tables just to provide header information when an array > of header cells could have been returned in the first place seems overly > complicated to me. > > Arguments supporting the rowHeader/columnHeader approach: > * If there are already other implementations of this (Lotus Symphony?), > we probably should conform to this interface to avoid major differences > between implementations. I still think it is awkward, but perhaps we'll > have to wait until a future version of IA2 to address this. > * IAccessibleRelation itself is a bit awkward. One potentially has to > iterate through all possible relations to find the desired relation, > rather than being able to retrieve a particular relation directly. > Mozilla shortcuts this by using accNavigate, but this is non-standard > and can only return one target. If we do use IAccessibleRelation, we > possibly eliminate one awkward interface from the equation and introduce > another. > > Sidenote: Could accNavigate return an IEnumVariant in order to support > multiple relation targets? This would eliminate the second argument, > assuming people are happy for that to become part of the specification > given that it doesn't require an interface change. > > On 4/06/2009 12:26 PM, Alexander Surkov wrote: >> Hi. >> >> I up to dated table headers implementation proposal >> https://wiki.mozilla.org/Accessibility/TableHeaders. I included >> several examples of heading information and tried to overview two >> possible approaches how to expose heading information to AT. Feedback >> is needed. >> >> Thank you. >> Alex. > > -- > James Teh > Email/MSN Messenger/Jabber: [email protected] > Web site: http://www.jantrid.net/ > _______________________________________________ > Accessibility-ia2 mailing list > [email protected] > https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2 > _______________________________________________ Accessibility-ia2 mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2
