On Thu, Dec 31, 2015 at 2:19 PM Richard Schwerdtfeger <[email protected]> wrote:
> What I mean by the DOM going away is accessibility test tools, today, > don't get access to the Web Components DOM. It is hidden. This is a gap. > Have you had an experience with a specific testing tool? If any testing tool uses a native accessibility API only, like MSAA/IAccessible2, then it will see the full "composed" DOM including the shadow DOM of all web components because that's what browsers expose. For example, if you open a webpage containing web components in Chrome and examine it using accProbe, you'll see the contents of all components just as if they were part of the DOM. In addition, any testing tool that's written in JavaScript and runs inside the webpage has full access to the shadow DOM of web components too. It's true that they need to use some newer APIs to dive inside of a component and some of them haven't been updated yet, but the APIs have been there since the beginning, so it's just a question of tools catching up with the times, not gaps in the spec or available APIs. > So, regarding API mappings you want to have the ATs control the browser > (move focus and have the browser load more content)? > Two separate things. For API mappings I just mean that we need to define how browsers are to implement things like aria-colcount and aria-rowcount using APIs like IAccessible2 and UIA. Nothing special there but it's not clear how we should do it. The second issue is that in order to implement things like spreadsheets, yes we do want a way for AT to be able to request that the browser load more content that isn't currently available. I think that's an important requirement, but I don't think it will be easy and I agree that ARIA 2.0 would be a good timeframe to talk about that. - Dominic > > > > Rich Schwerdtfeger > > [image: graycol.gif]Dominic Mazzoni ---12/31/2015 04:07:54 PM---On Thu, > Dec 31, 2015 at 1:51 PM Richard Schwerdtfeger <[email protected]> wrote: > > From: Dominic Mazzoni <[email protected]> > To: Richard Schwerdtfeger/Austin/IBM@IBMUS > Cc: IAccessible2 mailing list < > [email protected]>, > [email protected] > Date: 12/31/2015 04:07 PM > Subject: Re: [Accessibility-ia2] aria-colcount and aria-rowcount mapping, > again > > ------------------------------ > > > > > On Thu, Dec 31, 2015 at 1:51 PM Richard Schwerdtfeger <*[email protected]* > <[email protected]>> wrote: > > Hi Dominic, > > We can look at adding this work as part of ARIA 2.0 and the common > accessibility api work for browsers. > > > I don't think anything I'm asking for is a change in the ARIA spec. I'm > basically okay with what's in ARIA 1.1 now. However, we need to nail this > down as part of the User Agent Implementation Guide for ARIA 1.1. > > The need for this goes beyond screen readers. Alternative input > solutions will need this too. > > > Sure, of course. > > Also, the traditional DOM is going away with web components if that > takes off necessitating more work like this. > > > What makes you say the DOM is going away? Web components are just an > extension of the DOM by letting authors define their own elements, but > there's still a pretty well-defined "composed" DOM tree. Assistive > technology shouldn't know or care about whether there are web components or > not. I think some work is needed to address some gaps right now (for > example the IDREF issue that makes some ARIA attributes not work well with > web components) but there are workarounds. > > - Dominic > > > > > > Rich > > > Rich Schwerdtfeger > > [image: graycol.gif]Dominic Mazzoni via Accessibility-ia2 > ---12/30/2015 07:00:47 PM---Hi, This is a follow-up to a mail thread from > June on the correct mapping of > > From: Dominic Mazzoni via Accessibility-ia2 < > *[email protected]* > <[email protected]>> > To: IAccessible2 mailing list < > *[email protected]* > <[email protected]>> > Date: 12/30/2015 07:00 PM > Subject: [Accessibility-ia2] aria-colcount and aria-rowcount mapping, > again > Sent by: *[email protected]* > <[email protected]> > > ------------------------------ > > > > > Hi, > > This is a follow-up to a mail thread from June on the correct mapping > of aria-rowcount, aria-colcount, aria-rowindex, aria-colindex, etc. to > IAccessible2. > > The primary intended use case is when all of the rows and columns > can't be loaded, for performance reasons. > > The current spec does not solve the problem that screen readers need a > way to request that the page load more rows / columns. I agree this is > important and I'd be happy to discuss this in a separate thread, but I > think it's out of the scope of what can be done in ARIA and I don't see any > reason why we shouldn't move forwards with the current proposal in the > meantime. > > Jamie wrote: > > In order to do table navigation, screen readers need to be able to > navigate > from a given cell to the cell in the next column or the next row, > as > well as being able to fetch all cells in a given row or column. If > the > numbering is not sequential, we can't simply increase indexes to do > this. No API I know of supports something like this. > > Totally agreed that screen readers need to be able to navigate from > cell to cell and fetch rows at a time. Note that the spec requires the > numbering to be sequential, so you don't need to worry about that. > > I'd like to point out that in vanilla HTML it's quite common for > tables to have missing cells already. Here's a trivial example: > > <table> > <tr> > <td>1, 1</td> > </tr> > <tr> > > <td>1, 2</td>f > > > <td>2, 2</td> > </tr> > </table> > > In this table, there's no cell 2, 1 even though there are 2 columns > and 2 rows. When a screen reader calls IAccessibleTable2::cellAt(2, 2) it > returns null. > > Therefore my proposal is to do the same thing with a table that uses > ARIA to change its row and column indexes. The browser would do the work of > interpreting the ARIA and would present a virtual table via IAccessible2, > with some cells missing. Screen readers shouldn't have to do any extra work > to deal with most such tables because they already need to be able to > handle missing cells, so this wouldn't be any different. > > The obvious interpretation of aria-rowindex=-1 would be for the > browser to return an error from IAccessibleTable2::nRows. We'll have to > figure out what to do if that breaks existing screen readers. > > The alternative proposal seems to be to export the ARIA attributes > and/or use group position and have the screen reader announce the ARIA row > and column indexes but otherwise explore the table from the DOM. A couple > of downsides of this are: > > * Users wouldn't get any support at all if they use an older screen > reader > * Screen readers wouldn't be able to jump to a cell by row, column > index. (JAWS has a keystroke for this now.) > > - Dominic > > _______________________________________________ > Accessibility-ia2 mailing list > *[email protected]* > <[email protected]> > *https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2* > <https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2> > > >
_______________________________________________ Accessibility-ia2 mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2
