- From: Alexander Surkov <surkov.alexander@gmail.com>
- Date: Thu, 28 Jan 2016 10:52:59 -0500
- To: Joseph Scheuhammer <clown@alum.mit.edu>
- Cc: James Teh <jamie@nvaccess.org>, Richard Schwerdtfeger <schwer@us.ibm.com>, "wai-xtech@w3.org" <wai-xtech@w3.org>, public-aria@w3.org
- Message-ID: <CA+epNseJ+SJsCz=RYnbsEcRVmWqza9HnHcZ0owEyaxcM9+75EA@mail.gmail.com>
On Thu, Jan 28, 2016 at 10:03 AM, Joseph Scheuhammer <clown@alum.mit.edu> wrote: > On 2016-01-28 8:06 AM, Alexander Surkov wrote: > >> Everything that is a text should be accessible via text interface (like >> IAccessibleText in IA2) and should be navigable by the user. role="text" >> providing a text doesn't meet these criteria. If we could require the >> browsers to support text interface for the role, but it seems we can do >> nothing about the second part. It's just one extra step towards to >> semantics disconnected from UI like aria-hidden true/false. >> > > We (the AAPI task force), discussed that last fall, and I wrote (Fri, Oct > 16, 2015 at 11:33 AM): > Oh, right. As for any controversial thing the discussions on this stuff goes on and on :) and we all repeating ourselves from time to time as time goes. I'm sorry though for making a blast from the past. > ... >> We spent the better part of one of our AAPI meetings on whether >> role="text" should support IA2 and ATK's AccessibleText interfaces. The >> problem was that the character/word information is problematic in >> certain cases, e.g., >> >> <span role="text" aria-label="3 of 5 stars">★★★☆☆︎</span></p> >> >> The string "3 of 5 stars" has four words and 13 characters, whereas >> "★★★☆☆︎" is one (?) word with five characters. >> >> Joanie's suggestion was along the lines of stating that role="text" >> might implement an accessible text interface, with the caveat that it >> may not make sense in all cases. (I'm certain I've not captured >> Joanie's thoughts accurately here). >> > > Jamie replied: > > Right. However, I see that there are cases where it *might* make sense, >> such as this example from the spec: >> <div role="text"> >> <p>I</p> >> <p>like</p> >> <p>turtles</p> >> </div> >> In that case, the accessible *does* need IAccessibleText. And now things >> get confusing: should the AT expect IAccessibleText or not for this role? >> Where IAccessibleText is present, an AT certainly shouldn't just use the >> name. >> >> FWIW, NVDA should handle either case with no problems as it is. >> > > If ATs can handle both cases (caret navigation makes sense vs. it doesn't > make sense), then we are good to go. But, I remain uncertain. > Yeah, this is controversial. Anyway why UIA mapping is different? Is it on purpose? > > You wrote: > >> Then, if we do the statictext role which is a leaf, then I'm not clear >> how we proceed with <p role="text">Oh, yeah, this is a whole paragraph</p>. >> We may want to require the browsers to be smarter, stating that either 1) >> role is ignored or 2) text container role is applied in cases where >> role="text" is used on complex content. >> > > One effect of using of role="text" is to flatten the content, or, remove > the structure. Using the turtle example that Jamie cited, the result is > the string "I like turtles". That again leads to a disconnect between > caret navigation within the browser vs. what the AT is given. In the > browser window, the words "I", "like", and "turtles" are vertically > stacked, and users can move among them using up/down arrows. That vertical > arrangement is lost when the text of flattened, and only left/right works. > Is this a bad thing? > > Here is an even more disturbing case: <table role="text"> ... many rows, > columns, and cells ... </table>. That means all the text in the table > becomes one long flat string. Or, is this a case where the spec states > that authors MUST NOT do this? I guess I would go with the approach to ignore the role in such cases, as it wasn't present at all. Was there any agreement on this topic (I may be missing some of past discussions)? > > > -- > ;;;;joseph. > > 'Die Wahrheit ist Irgendwo da Draußen. Wieder.' > - C. Carter - > >
Received on Thursday, 28 January 2016 15:53:29 UTC