Re: [webkit-dev] question about accessibility
There is ongoing work to implement the Web Speech API ( http://www.w3.org/community/speech-api/) in WebKit. Speech recognition works in Chromium, speech synthesis is mostly implemented on Mac OS X (but it's not enabled by default yet). In both cases, the actual runtime libraries aren't part of WebKit, they depend on the platform. - Dominic On Sun, Mar 10, 2013 at 1:46 AM, Ivano Arrighetta berserk82...@gmail.comwrote: hello everyone. I just wonder if webkit will include some runtime libraryes for accessibility like text to speech, ocr and speech recognition. this may sound silly, but there are many application examples of how this could be useful for accessibility. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Feature Announcement: WebSpeech - Speech Synthesis
On Sun, Jan 13, 2013 at 2:10 PM, Benjamin Poulain benja...@webkit.orgwrote: On Sun, Jan 13, 2013 at 2:12 AM, Chris Fleizach cfleiz...@apple.com wrote: I'm planning on implementing the speech synthesis aspect of the WebSpeech API Specification https://dvcs.w3.org/hg/speech-api/raw-file/tip/speechapi.html#tts-section [...] Let me know if you have any questions. Completely out of curiosity: How does the voiceURI attribute works? Is there some kind of standard for voices? There's no standard (yet). A client is supposed to call getVoices() to get a list of possible voices, and the voiceURI is a unique identifier for each one. - Dominic ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] A Media Element ie: Audio or video, without tabindex cannot be selected with keyboard (TAB Key). BUG: 67190
I agree - a media element with controls ought to be keyboard-accessible by
default. Right now it doesn't appear that you can even make an audio or
video element play in WebKit even if it is focused.
Firefox seems to treat the whole set of controls as one focusable element -
you can use the spacebar to play/pause and the arrow keys plus modifiers to
skip around. I couldn't figure out a way to access the volume control.
An alternative approach would be to make each individual subcontrol
focusable - the play/pause button, the seek slider, and the volume slider,
plus potentially other controls for video.
- Dominic
On Tue, Sep 13, 2011 at 12:04 PM, Deepak Sherveghar bpw...@motorola.comwrote:
Hi All,
As with current Webkit behavior, only media elements with tab-index
attribute specified can be focused with keyboard (TAB key).
From a usability as well as accessibility perspective, we should be able to
focus (via keyboard using TAB key)
media elements that have controls attribute specified but do not have a
tab-index attribute specified.
ie: video controls src=../media/content/test.mp4/video //should be
focused by tabbing.
This would help in making the media element keyboard accessible.
Firefox and Opera both support this behavior ie: focus media element by
tabbing without the need for tab-index.
you can verify this using the link :
http://yves.vg/testcases/webkit/video.html
I have already implemented this and uploaded my patch in BUG 67190.
My approach to support this is as follows:
In HTMLMediaElement.cpp., add
bool HTMLMediaElement::supportsFocus() const
{
// Return true if control attribute present else If no controls
specified, we should still be able to focus the element if it has tabIndex.
return controls() || HTMLElement::supportsFocus();
}
Antonio Gomes suggested that since my patch would be changing a general
behavior of all webkit based browsers
(and according to the spec it is up to the UA to implement that or not), we
could have a discussion in webkit-dev mailing list first.
Also Ian 'Hixie' Hickson is of the opinion that:
Whether something is interactive content or not has no bearing on
whether it is focusable or not: the definition of focusable doesn't
refer to whether something is interactive content:
http://www.whatwg.org/specs/web-apps/current-work/complete.html#focusable
Whether something should be focusable or not is essentially up to the
browser vendor (you). I would recommend making it possible
to focus video controls if they are present, of course. But that's not a
spec conformance matter, it's a usability matter.
According to me, making media element focusable without tab-index (but
control attribute specified), would be first step in making the
media element keyboard accessible which would further help us make the
media element 'Interactive
(W3C Draft categorizes video and audio in Interactive Content) using
keyboard (ie play/pause media using space bar)
Need suggestion or feedback on this.
Whether we should go ahead with this or follow any other approach
Also a bug on second aspect of media element ie: to make it interactive
using keyboard is already being filled by Yves Van Goethem :
BUG: 31786 : https://bugs.webkit.org/show_bug.cgi?id=31786. I have marked
31786 bug as dependent on BUG: 67190.
Thanks in advance.
-Deepak Sherveghar
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Accessibility Object Searching
Hi Sam, I'm one of Chrome's accessibility developers. I think this is a really great idea, I think the ability for WebKit to do the searching rather than the screen reader could be a big performance win for users. In order to take advantage of this feature on multiple platforms, we'd need to add some new APIs to the platform accessibility APIs like NSAccessibility and IAccessible2 - could you give us an idea of what you had in mind for those APIs? It might be nice to get some feedback from those communities too, as the design of the high-level API might impact how the low-level webkit changes might work. It seems to me that not just searching for the next instance of a role (like link or table), but being able to more quickly search for text that might appear in an object's accessible title or description, would be perhaps the biggest win for users. Perhaps that's already part of what you had in mind. - Dominic On Tue, Jun 21, 2011 at 4:30 PM, Samuel White samuel_wh...@apple.com wrote: Hey everybody, I'm new to the list and thought it would be a good idea to get some feedback on an accessibility feature before filing a bug or submitting anything. Currently, no functionality exists in WebKit to search through AccessibilityObjects using basic search criteria like next link or next table internally. Screen readers and other access devices often must instead probe WebKit and build up their own internal representation of a page before they can begin searching for what they are after. This presents two big problems for the users of access technology. First, pages such as the HTML 5 working doc have a massive number of DOM elements and building up an external representation can be a very expensive and slow task. Secondly, maintaining an accurate external representation of a site can become difficult if that site has a large amount of dynamic content and users may not be accessing relevant information. I would like to make a few small changes to the AccessibilityObject class that adds the functionality I've mentioned. I think these small but important additions will allow existing access technologies to rely much more on WebKits representation of a page and thus eliminate the problems I've described above. I appreciate any feedback and look forward to helping out. Thanks Sam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Accessibility Object Searching
I just had another thought: how would this work in a multi-process browser? As you may know, Chrome runs an instance of webkit in a separate renderer process for each tab, but the GUI and all accessibility handling happens in the main browser process. Because accessibility calls are synchronous, we cache accessibility information in the browser process and respond to queries from that cache, rather than sending an IPC to the renderer process and getting a response. I realized that we wouldn't be able to use this search function very easily as you've proposed it. If NSAccessibility gets such an API, we'd have to write our own implementation that could run in Chrome's browser process. My understanding was that WebKit2 and Safari are moving to a multi-process model as well. Is this design going to be compatible with this? - Dominic ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Accessibility Object Searching
On Wed, Jun 22, 2011 at 4:21 PM, Chris Fleizach cfleiz...@apple.com wrote: I think this is one drawback of Chrome's approach, the inability to retrieve dynamic information. I suspect Chrome has similar issues for the NSAccessibilityParameterizedAttribute attributes, and that it doesn't support the AXTextMarker APIs that Safari does for the same reason. To support this (along with the other things I mentioned) Chrome would need to synchronously called into WebCore, wait for the answer, and then return that information. Yes, we're open to doing this where necessary. Yes, WebKit2 works with accessibility. You'll be able to see the code to support that strewn throughout WebKit2. Let me know if you need more pointers. I'll take a closer look, thanks. - Dominic ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
