[webkit-dev] Exposing WebKit/Safari's unique full keyboard access setting to web applications
WebKit Dev, Safari is unique among desktop browsers in that full keyboard access (FKA) is off by default, and the Tab key moves focus only to textfields and select elements. You can modify this behavior using a system-wide setting (System Prefs Keyboard Shortcuts All Controls) and/or a Safari-specific setting (Safari Prefs Advanced Press Tab to…). If you change both settings, you'll have a keyboard focus behavior that is similar to that of other desktop browsers, such that every focusable control appears in the sequential Tab order. Many JavaScript UI libraries capture default Tab behavior for a variety of reasons, and maintain their own concept of a first responder. In these cases, we need to expose the user's FKA setting so that keyboard behavior can be appropriately managed by web applicationk according to the user's expectations. We've been discussing a number of solutions internally with WebKit engineers, and externally with other browser developers and standards bodies. One of the proposed solutions is to expose a new property and change event on the Navigator object: var fbSetting = navigator.webkitFocusBehavior; navigator.addEventListener(webkitfocusbehaviorchanged, handleFocusBehaviorChanged); Another solution is to implement this as a vendor-prefixed key in the userSetting interface of the IndieUI User Content ED: https://dvcs.w3.org/hg/IndieUI/raw-file/default/src/indie-ui-context.html var fbSetting = window.userSetting(-webkit-focus-behavior); window.addSettingListener(-webkit-focus-behavior, handleFocusBehaviorChanged); Despite this behavior being unique to Safari, we do not believe the setting is unique to WebKit or Safari, so either implementation may be proposed for standardization to the various W3C working groups. For example, focus behavior setting may be useful in mobile contexts, where the concept of focus is not necessarily related to a keyboard interface or the Tab key. Are there objections to implementing either proposal behind a flag? Are there preferences for or comments on either approach? Thanks, James Craig ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Exposing WebKit/Safari's unique full keyboard access setting to web applications
WebKit Dev, Safari is unique among desktop browsers in that full keyboard access (FKA) is off by default, and the Tab key moves focus only to textfields and select elements. You can modify this behavior using a system-wide setting (System Prefs Keyboard Shortcuts All Controls) and/or a Safari-specific setting (Safari Prefs Advanced Press Tab to…). If you change both settings, you'll have a keyboard focus behavior that is similar to that of other desktop browsers, such that every focusable control appears in the sequential Tab order. Many JavaScript UI libraries capture default Tab behavior for a variety of reasons, and maintain their own concept of a first responder. In these cases, we need to expose the user's FKA setting so that keyboard behavior can be appropriately managed by web applicationk according to the user's expectations. We've been discussing a number of solutions internally with WebKit engineers, and externally with other browser developers and standards bodies. One of the proposed solutions is to expose a new property and change event on the Navigator object: var fbSetting = navigator.webkitFocusBehavior; navigator.addEventListener(webkitfocusbehaviorchanged, handleFocusBehaviorChanged); Another solution is to implement this as a vendor-prefixed key in the userSetting interface of the IndieUI User Content ED: https://dvcs.w3.org/hg/IndieUI/raw-file/default/src/indie-ui-context.html var fbSetting = window.userSetting(-webkit-focus-behavior); window.addSettingListener(-webkit-focus-behavior, handleFocusBehaviorChanged); Despite this behavior being unique to Safari, we do not believe the setting is unique to WebKit or Safari, so either implementation may be proposed for standardization to the various W3C working groups. For example, focus behavior setting may be useful in mobile contexts, where the concept of focus is not necessarily related to a keyboard interface or the Tab key. Are there objections to implementing either proposal behind a flag? Are there preferences for or comments on either approach? Thanks, James Craig ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] dump accessibility tree
Check out dumpAccessibilityChildren() in: ./LayoutTests/accessibility/aria-hidden-false-works-in-subtrees.html Also look in: ./Tools/WebKitTestRunner/InjectedBundle/Bindings/AccessibilityUIElement.idl ./Tools/WebKitTestRunner/InjectedBundle/Bindings/AccessibilityController.idl On Apr 23, 2014, at 1:49 PM, Chris Fleizach cfleiz...@apple.com wrote: A few of the layout tests have something like this where it can iterate every object. Although usually, the platform AX trees are pretty accurate representations of what in the WebCore AX tree On Apr 23, 2014, at 12:34 PM, Jarek Czekalski ja...@jarek.katowice.pl wrote: Hi All! I'm trying to discover the way accessibility works in webkit and maybe fix some orca blockers. There is a renderer tree, that I can dump using DumpRenderTree. There is also atk tree, that I can inspect with python scripts and accerciser. But there is also a layer inbetween, something like WebCore Accessibility Tree. Is there a way to dump the tree for a given page? Or maybe there are other useful tools or tricks, to use when I see a broken atk tree, like in bug #131933 [1]? Thanks in advance Jarek [1] https://bugs.webkit.org/show_bug.cgi?id=131933 ___ 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Adding flag to optionally run check-webkit-style as part of prepare-Changelog and svn-create-patch
Thanks to Brendan, Alexey, Zoltan, and Daniel for the feedback on this, which I've addressed. Any more comments? Thanks. r? On Apr 4, 2014, at 12:14 AM, James Craig jcr...@apple.com wrote: I sometimes forget to run the check-webkit-style script before uploading patches, so I put a patch up for review that adds a --style and --no-style flags to prepare-Changelog and svn-create-patch. Alexey suggested I make it the default, which I've done for prepare-Changelog, but not in svn-create-patch due to cross-references that cause a loop when it't the default. (I just added the --style flag to my local bash alias.) Any concerns or suggestions? Thanks. http://webkit.org/b/131115 ___ 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
[webkit-dev] Adding flag to optionally run check-webkit-style as part of prepare-Changelog and svn-create-patch
I sometimes forget to run the check-webkit-style script before uploading patches, so I put a patch up for review that adds a --style and --no-style flags to prepare-Changelog and svn-create-patch. Alexey suggested I make it the default, which I've done for prepare-Changelog, but not in svn-create-patch due to cross-references that cause a loop when it't the default. (I just added the --style flag to my local bash alias.) Any concerns or suggestions? Thanks. http://webkit.org/b/131115 ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Adding flag to optionally run check-webkit-style as part of prepare-Changelog and svn-create-patch
Yes, but not everyone uses the webkit-patch script in their workflow. On Apr 4, 2014, at 7:27 AM, Brendan Long s...@brendanlong.com wrote: Doesn't 'webkit-patch upload' already do that? On 04/04/2014 02:14 AM, James Craig wrote: I sometimes forget to run the check-webkit-style script before uploading patches, so I put a patch up for review that adds a --style and --no-style flags to prepare-Changelog and svn-create-patch. Alexey suggested I make it the default, which I've done for prepare-Changelog, but not in svn-create-patch due to cross-references that cause a loop when it't the default. (I just added the --style flag to my local bash alias.) Any concerns or suggestions? Thanks. http://webkit.org/b/131115 ___ 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] Adding flag to optionally run check-webkit-style as part of prepare-Changelog and svn-create-patch
On Apr 4, 2014, at 9:08 AM, Zoltan Horvath zol...@webkit.org wrote: Hi there, prepare-Changelog: - The style checker script runs on the ChangeLogs as well, and it gives warning if the bug number or the tests' line are not filled. I consider this an expected behavior. If you don't include --bug=12345 parameter when running prepare-Changelog, your diff is currently in a state that would fail style checks. Having the Terminal output immediately tell you that detail is useful. - I think the best behavior for this case would be to abort the change log creation, if there are errors on the actual code check. (Then you can fix those, and when you rerun prepare-Changelog, it puts the recent things into the change log. [e.g. you've got a lower/uppercase function naming warning, and the function name appears in the change log]) I don't think this is right. If we aborted the change log creation, you'd never be able to run prepare-Changelog without the --bug parameter, unless you specifically disabled the style check with --no-style. svn-create-patch: - Add it! It's a good idea. Cheers, Zoltan On Fri, Apr 4, 2014 at 7:41 AM, James Craig jcr...@apple.com wrote: Yes, but not everyone uses the webkit-patch script in their workflow. On Apr 4, 2014, at 7:27 AM, Brendan Long s...@brendanlong.com wrote: Doesn't 'webkit-patch upload' already do that? On 04/04/2014 02:14 AM, James Craig wrote: I sometimes forget to run the check-webkit-style script before uploading patches, so I put a patch up for review that adds a --style and --no-style flags to prepare-Changelog and svn-create-patch. Alexey suggested I make it the default, which I've done for prepare-Changelog, but not in svn-create-patch due to cross-references that cause a loop when it't the default. (I just added the --style flag to my local bash alias.) Any concerns or suggestions? Thanks. http://webkit.org/b/131115 ___ 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 ___ 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] Adding flag to optionally run check-webkit-style as part of prepare-Changelog and svn-create-patch
On Apr 4, 2014, at 1:33 PM, Zoltan Horvath zol...@webkit.org wrote: On Fri, Apr 4, 2014 at 12:43 PM, James Craig jcr...@apple.com wrote: On Apr 4, 2014, at 9:08 AM, Zoltan Horvath zol...@webkit.org wrote: Hi there, prepare-Changelog: - The style checker script runs on the ChangeLogs as well, and it gives warning if the bug number or the tests' line are not filled. I consider this an expected behavior. If you don't include --bug=12345 parameter when running prepare-Changelog, your diff is currently in a state that would fail style checks. Having the Terminal output immediately tell you that detail is useful. - I think the best behavior for this case would be to abort the change log creation, if there are errors on the actual code check. (Then you can fix those, and when you rerun prepare-Changelog, it puts the recent things into the change log. [e.g. you've got a lower/uppercase function naming warning, and the function name appears in the change log]) I don't think this is right. If we aborted the change log creation, you'd never be able to run prepare-Changelog without the --bug parameter, unless you specifically disabled the style check with --no-style. I'd avoid running the style-checker on the change logs themselves since these're being created when running prepare-Changelog, and abort changelog creation, if the _rest of the code_ have coding style violation since fact of violation is our interest at this point. What if we file another bug for that part of the work? It seems like a nice-to-have, but not necessary for this patch. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] AX: Implement CSS -webkit-alt property (text alternative for generated content pseudo-elements ::before and ::after)
On Oct 8, 2013, at 1:02 AM, Dirk Schulze dschu...@adobe.com wrote: I hope you understand that I am not particularly concerned about Apples screen reader solution. It is one implementation. I would like to know if JAWS, NVDA, Dolphin and other are aboard. Withe the exception of NVDA, the other screen reader vendors are typically uninvolved in the standards process, so I would not expect feedback. As for NVDA, none of the other browsers expose even plain text generated content, so this likely just represents a problem that they don’t know they have yet. I did discuss this solution in the PF working group before proposing it to CSS. That said, this change would not require the screen readers (including VoiceOver) to do anything special. It just changes the way the UAs expose a bit of text (or an image text alternative) to the accessibility APIs, so I don’t think buy-in from screen reader vendors is critical. This is a browser issue, and all the browser vendors have representatives in CSS. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] AX: Implement CSS -webkit-alt property (text alternative for generated content pseudo-elements ::before and ::after)
Follow-up question: Since this hasn’t made it into the CSS4 spec yet, should
we temporarily use “-webkit-alt” for the property name? I know there has been a
push to move away from vendor prefixes lately, so if there are no objections, I
propose we use the unprefixed version.
On Sep 30, 2013, at 10:08 PM, James Craig jcr...@apple.com wrote:
AX: Implement CSS -webkit-alt property
https://bugs.webkit.org/show_bug.cgi?id=120188
This is blocking 20+ bugs on one of our higher profile content sites and we’d
like to start work on it. To clarify, the problem is that with CSS generated
content in pseudo-elements like this:
.expandable::before { content: \25BA; /* a.k.a. ► */ }
…there is no way to prevent VoiceOver from speaking the literal character
description, “right pointing black pointer.” If this were an actual DOM node,
we could hang some ARIA attributes on it, but there is no node for
pseudo-elements, so the property has to be defined in CSS.
The CSS Working Group discussion indicates the editors (Tab from Google, and
Elika from Mozilla) are generally on board with the concept of accessible
text alternatives for CSS generated content and Tab suggested the property
name. It is not in a CSS4 draft yet, but some usage examples are below.
Rendering a decorative disclosure triangle on a collapsed” ARIA treeitem:
[aria-expanded=false”]::before {
content: \25BA; /* a.k.a. ► , literally “right pointing black
pointer” */
alt: ; /* aria-expanded=false already in DOM, so this
pseudo-element is decorative */
}
And this, where a style indicates new content, screen readers can speak “New”
instead of “shadowed white star”:
[data-new]::after {
content: \2730”; /* a.k.a. ✰ , literally “shadowed white star”
*/
alt: attr(data-new); /* allows for localized content from the
DOM, e.g. @data-new=New! */
}
Any questions or concerns?
Thanks,
James
PS. Related to this one is bug 122138, where the “alt” can be specified
inline after url() image content:
AX: WebKit does not expose text alternative of CSS generated image content
https://bugs.webkit.org/show_bug.cgi?id=122138
.new::after {
content: url(./star.png), New!;
}
___
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
[webkit-dev] AX: Implement CSS -webkit-alt property (text alternative for generated content pseudo-elements ::before and ::after)
AX: Implement CSS -webkit-alt property
https://bugs.webkit.org/show_bug.cgi?id=120188
This is blocking 20+ bugs on one of our higher profile content sites and we’d
like to start work on it. To clarify, the problem is that with CSS generated
content in pseudo-elements like this:
.expandable::before { content: \25BA; /* a.k.a. ► */ }
…there is no way to prevent VoiceOver from speaking the literal character
description, “right pointing black pointer.” If this were an actual DOM node,
we could hang some ARIA attributes on it, but there is no node for
pseudo-elements, so the property has to be defined in CSS.
The CSS Working Group discussion indicates the editors (Tab from Google, and
Elika from Mozilla) are generally on board with the concept of accessible text
alternatives for CSS generated content and Tab suggested the property name. It
is not in a CSS4 draft yet, but some usage examples are below.
Rendering a decorative disclosure triangle on a collapsed” ARIA treeitem:
[aria-expanded=false”]::before {
content: \25BA; /* a.k.a. ► , literally “right pointing black
pointer” */
alt: ; /* aria-expanded=false already in DOM, so this
pseudo-element is decorative */
}
And this, where a style indicates new content, screen readers can speak “New”
instead of “shadowed white star”:
[data-new]::after {
content: \2730”; /* a.k.a. ✰ , literally “shadowed white star”
*/
alt: attr(data-new); /* allows for localized content from the
DOM, e.g. @data-new=New! */
}
Any questions or concerns?
Thanks,
James
PS. Related to this one is bug 122138, where the “alt” can be specified inline
after url() image content:
AX: WebKit does not expose text alternative of CSS generated image content
https://bugs.webkit.org/show_bug.cgi?id=122138
.new::after {
content: url(./star.png), New!;
}
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Removing DIALOG_ELEMENT for now
I'd like to see support for @inert subtrees prioritized if dialog is going to be postponed. So many web authors are faking this behavior now, which is problematic for full keyboard access and accessibility. On Aug 29, 2013, at 10:50 AM, Ryosuke Niwa rn...@webkit.org wrote: While I'd like to see us eventually supporting it, it seems sensible to remove it from the code base if no port is planning to enable it by default in the near future. - R. Niwa ___ 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] Removing DIALOG_ELEMENT for now
On Aug 29, 2013, at 12:56 PM, Darin Adler da...@apple.com wrote: On Aug 29, 2013, at 12:44 PM, James Craig jcr...@apple.com wrote: I'd like to see support for @inert subtrees prioritized if dialog is going to be postponed. I don’t think dialog is being postponed; just that no one has immediate plans to use the implementation in the tree that is not being compiled. Which of these two do you think we should give higher priority to, though? Not sure how to answer… @inert represents a subset of the implementation of dialog so I don't know how dialog could be prioritized *over* @inert, but it would be possible to implement @inert without finishing a complete implementation of dialog. From an accessibility perspective, we already have a dialog role (which is extremely easy for authors to implement), so the dialog element and convenience methods associated with it are not as high a priority. The place where most web authors fall down with regards to dialog implementation is with focus management (moving keyboard and screen reader focus into the dialog) and not hiding the background contents (preventing keyboard and AT users from tabbing through the background contents behind a modal dialog), and I believe @inert would solve a lot of that. There isn't a practical way to achieve this behavior now, which is why ~99.9% of web authors are doing this in a way that falls short for keyboard and screen reader users. James ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Heads up: changing default for selectionIncludesAltImageText
I wanted to give the list a heads up because the related issue was somewhat controversial last time. To give some context, this is about whether image alt text should be included in the plain text pasteboard. Most everyone is of the opinion that it should, but several of us feel that it should be delimited to some degree so that it's more clear this came from an image and was not originally presented as plain text. Here is the original thread and bug that resulted in this feature being implemented but left disabled by default: https://bugs.webkit.org/show_bug.cgi?id=11200 The discussion also resulted in an HTML defect filed to clarify this portion of the spec. https://www.w3.org/Bugs/Public/show_bug.cgi?id=21403 While I still feel there is room to explore some delimiting options, the HTML spec has since been updated to be less ambiguous in this area, and the other main browsers support the behavior, so I think it's reasonable to enable it by default until such time as 1) this is shown to be problematic, or 2) a better solution is proposed. Here's the new bug for the settings change. https://bugs.webkit.org/show_bug.cgi?id=115283 ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Adding main element to WebCore
IMO, the following represents enough evidence to land the patch as soon as the last layout test failure is resolved. https://bugs.webkit.org/show_bug.cgi?id=103172 1. Sam Ruby, as Chair declared this passing the HTML WG vote, With no objections and ample support, this resolution passes. http://lists.w3.org/Archives/Public/public-html/2012Nov/0232.html 2. Representatives from another rendering engine vendor (Mozilla) have expressed support for this feature and a willingness to implement it. 2a. David Bolter, said, …this [main] is a good thing! http://lists.w3.org/Archives/Public/public-html/2012Dec/0073.html 2b. Henri Sivonen: I think we should implement it because… (Gecko patch pending) https://bugzilla.mozilla.org/show_bug.cgi?id=820508 3. And finally, main already landed in the HTML 5.1 spec about a week ago. http://www.w3.org/html/wg/drafts/html/master/grouping-content.html#the-main-element ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Adding main element to WebCore
On Nov 29, 2012, at 7:19 PM, Alex Russell slightly...@google.com wrote: My object is somewhat different. I think it's useful for the readability use-case (and the other proposed solutions are mostly bad jokes), but it doesn't strike me that this give you much default UI and doesn't plumb through any new low-level capability. In that vein, I wonder why it's not being proposed as an ARIA role instead? 'main' is already one of the subclass roles of landmark[1], many of which have have direct 1:1 default role mappings to new HTML5 elements (e.g. nav[role=navigation], footer[role=contentinfo]) and the proposal is, in part, to have an element on which to hang the default semantics of the 'main' landmark role. The accessibility role default is one important argument, but there were several others raised in favor of the element, including the semantic clarity or heuristic ease for readability/reader that you mentioned, as well as CSS hooks, script hooks, and other organizational benefit for content authors. 1. http://www.w3.org/TR/wai-aria/complete#landmark ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Adding main element to WebCore
On Nov 26, 2012, at 2:01 PM, Steve Faulkner faulkner.st...@gmail.com wrote: I have submitted a patch [1] to add main element support to webkit and would appreciate your consideration. You should also add a layout test. From an accessibility perspective, the main element is an easy win. There is currently no element on which to hang the landmark, so expert web authors are forced to use ARIA on top of HTML5 div role=main, and non-experts miss an opportunity that would make their web content more accessible div id=main (semantically meaningless). On top of the major accessibility win, it's another organizational hook for scripts or CSS, like header or nav. I respond to some of the other comments in each sub-thread. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Adding main element to WebCore
On Nov 27, 2012, at 4:22 PM, Ian Hickson i...@hixie.ch wrote: ARIA is used by very few authors, and those authors are, by and large, much more competent than average. ARIA therefore tends to be used to a much higher level of quality than most elements. Yet this is part of the problem. One of the reasons most of the Web is not very accessible is because you have to be an expert in order to code an accessible site. Part of the goal of HTML 5 (and WebKit for that matter) should be to make it easy for authors to include accessibility support without having to think about it. [main] would probably be used about as well, maybe a little less well than [article, header, aside] because the idea of what is main varies from author to author (e.g. in the sites you analysed on the WHATWG list, as well as in many that others have mentioned before, id=main and id=content often include things like some navigation, some headers, some sidebars, some footers). This is valid, but if that's the worst case scenario, it's still exactly as good as the best-case scenario when there is no main element, so I don't really consider this to be much of an opposition. Besides, the scooby doo method could apply in those cases. If a main element contains article, header, aside or otherwise non-main content, browsers can it from what constitutes the main content. More importantly, the main element gives us a node on which to hang the landmark AXSubrole: AXApplicationMain which enables landmark navigation in supporting screen readers like VoiceOver. The use case for e.g. header is mainly one of maintenance and styling: lots of people style their headers very specifically. In general it doesn't matter if one author marks his navigation as being part of his header and another marks his navigation using nav; the result is the same: they are clearly marked in the source, they can be styled, and they can be skipped. If one author doesn't use it, or even if most authors use it incorrectly, it doesn't mean that other authors can't use it. The use case for main is accessibility navigation. It isn't true that the *only* use case is for accessibility. main is just as useful as a organizational maintenance and CSS styling hook as the header or nav elements. If authors use it incorrectly, the feature *doesn't work*. The element becomes pointless. This is also not true. Whether or not the main element contained other non-main content, the end effect is more or less the same. Screen reader users using landmark navigation would jump to the beginning of the first piece of content in the main element. Nested landmarks work fine, too. I don't think this argument is valid. This is like the difference between a href= and img longdesc=. Please don't dredge that one up. I'm a vocal opponent of @longdesc, but this is nothing like @longdesc. If many authors use longdesc= incorrectly, however, it means users who try to use the feature quickly stop expecting it to work and they give up and even pages that use it correctly lose out. Regarding @longdesc, I agree, but relating this problem to main is FUD. Main is not some external content to be forgotten; it's just a tag surrounding the main contents of the page. Even if there are slightly differing views of what constitutes the main content, you still get mostly useful semantic, styling, and accessibility benefits from main James ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Adding main element to WebCore
Snipping somewhat for brevity… On Nov 27, 2012, at 8:02 PM, Ian Hickson i...@hixie.ch wrote: Sites have been quite happily working with a skip past navigation link Happily? Begrudgingly? For what it's worth, landmark navigation should not be confused with skip nav links. Think of it more like a hierarchical navigation, similar to jumping by heading, but with more semantics and at a higher level. , and HTML has an explicit nav element that makes this more likely to happen even for sites that don't provide a link, and ATs have all kinds of page navigation tools for users that let them jump around looking for whatever it is they want to read Landmark navigation is now one of these tools, why prevent authors from explicitly using it for main content? (which isn't necessarily the main content; e.g. on youtube.com you probably want the search box, not the stream, in many cases). That seems very subjective, and possibly off-topic. But secondly, how do you think main will do anything to make authors aware of anything? To authors who hear about the element, it's just going to be met with ah, a way to replace my id=main element ID with an element instead, just like header and nav. And if they do, that's fine, and we're still left with the main content via the scooby doo method. main nav … /nav p first bit of main content /p footer … /footer /main …but if they get it right, heuristics get even better. nav … /nav main p first bit of main content /p /main footer … /footer In either case, explicit landmark navigation to main could move the screen reader cursor to the first bit of main content… Without a main element, this is ambiguous: nav … /nav p first bit of main content /p p not main content /p footer … /footer Correct use clarifies the structure: nav … /nav mainp first bit of main content /p/main p not of main content /p footer … /footer And incorrect use frequently turns out fine anyway, and does not negatively affect use on other pages: main nav … /nav p first bit of main content /p p not main content /p !-- it might not be the main main content, but it doesn't make the feature useless as you've stated -- footer … /footer/main /main As you've pointed out, incorrect use of @alt on one page does not prevent other pages from using @alt correctly. Likewise incorrect use of main would not prevent a user from using other navigation mechanisms on this page, and does not deter a user from using it on other pages, and in many case, incorrect use of main would still work as a reasonable landmark. And thirdly, since when are awareness campaigns appropriate ways to do language design? We design to solve real problems, we try to make the platform intuitive. We don't design the language to teach people. That's the job of tutorials, advocacy, etc. No argument here. main is pretty intuitive, and the penalty for misunderstanding its use is next to nothing. Note that if it's misused even as much as the other semantic elements, that's enough to make it useless, unlike with those other elements. Again, I don't follow your logic. Even misused, it's still just as good as the scooby doo method, and misuse does not make it useless. I think we need to let go of the idea that main will replace id=main and id=content, because it's not the point of main. That's how authors will use it. That it's not the point of main is *exactly* the reason main is a bad design. That's how *some* authors *may* use it, but that's okay, even if they do. Ultimately, we always have the accessibility users as the testers for this feature and they can register bugs where the main element is leading to the wrong place. How well did that work for longdesc=? Irrelevant. @longdesc isn't implemented well due to other significant design problems. Heck, how well did it work for alt=? Pretty well actually. When a screen reader user hears an unlabeled button or image, they know exactly what is wrong, and what to report. Accessibility users complaining doesn't lead to sites getting fixed. We fix user-reported accessibility complaints all the time. So does your company, and many others. There are scores of blog posts and podcasts from indie iOS app developers talking about how they'd never heard of accessibility until a few vocal users of their apps spoke up, and these developers were able to fix their bugs with minimal effort, thanks to the fact that they were made aware of the problem by their loyal customers. In conclusion: A. Authors don't test their pages in a way that would detect this feature. Agreed, but they don't (and shouldn't) have to. B. Authors won't understand this feature. Disagree, but the cost of misunderstanding is negligible. C. If this feature is misused to any significant extent by a subset of authors, then the purpose of the feature is lost for all users on all sites. Disagree strongly, and I'd argue that you're
Re: [webkit-dev] Adding main element to WebCore
On Nov 28, 2012, at 12:43 AM, Maciej Stachowiak m...@apple.com wrote: role=main can achieve this, but sectioning elements take care of the other landmark roles, and it seems strange to have this be the odd one out. In my own judgment, this outweighs risk of misuse. I agree. On the other hand, this element does not add material functionality over what section role=main or div role=main would do, so the benefit is fairly small, compared to an element that does something authors couldn't do otherwise. (2) The implementation cost is pretty low, so the main consideration is whether this would benefit the Web. The significant benefit here is that we'll get a lot more more authors using main correctly, than we ever will using div role=main and that's a win for the accessibility of the Web as a whole. James ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Adding main element to WebCore
On Nov 29, 2012, at 6:19 PM, James Robinson jam...@google.com wrote: This is an interesting standards debate but as many people have noted it does not belong on the webkit-dev list, which is for coordinating the development of WebKit. Please take this over to whatwg@ or some other appropriate standards list. I think it's valid to discuss here because this thread started as a request for comments on a patch. 1. This patch is valid for consideration because there is already an extension specification for HTML 5 that was approved for publish by consensus of the HTML Accessibility Task Force. 2. My feedback to Steve was that I supported the addition but he should include a layout test. 3. The patch discussion, however, was derailed IMO by misinformation about assistive technologies and how they are used in conjunction with WebKit, so I wanted a chance to contradict the misinformation at its source. James ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Adding main element to WebCore
On Nov 29, 2012, at 6:33 PM, James Craig jcr...@apple.com wrote: On Nov 29, 2012, at 6:19 PM, James Robinson jam...@google.com wrote: This is an interesting standards debate but as many people have noted it does not belong on the webkit-dev list, which is for coordinating the development of WebKit. Please take this over to whatwg@ or some other appropriate standards list. I think it's valid to discuss here because this thread started as a request for comments on a patch. 1. This patch is valid for consideration because there is already an extension specification for HTML 5 that was approved for publish by consensus of the HTML Accessibility Task Force. One minor correction. This extension specification was approved with no objections and ample support by the main HTML Working Group, not just by the task force. http://lists.w3.org/Archives/Public/public-html/2012Nov/0232.html Which I believe means inclusion of the patch should be accepted once it gets reviewer approval, no? 2. My feedback to Steve was that I supported the addition but he should include a layout test. 3. The patch discussion, however, was derailed IMO by misinformation about assistive technologies and how they are used in conjunction with WebKit, so I wanted a chance to contradict the misinformation at its source. James ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Adding main element to WebCore
On Nov 29, 2012, at 7:10 PM, Ryosuke Niwa rn...@webkit.org wrote: I don't see a harm in waiting another couple of weeks or months until standards discussion settles assuming that the main element doesn't become the longdesc of the next decade. Don't confuse the two. The argument over the @longdesc extension is not even close to unanimous even within the accessibility development circles. Major objections to @longdesc came from several of us working full-time on accessibility. The main element, in contrast, appears to have near unanimous support amongst the accessibility development community, and is a 1:1 semantic match with role=main which is being used on many major websites. I think we'll see quick author adoption of main once this patch ships. James ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] W3C Proposal: User Interface Independence for Accessible Rich Internet Applications
On Nov 10, 2010, at 3:40 PM, Ojan Vafai wrote: Heh. There's clearly still a good deal of confusion about what the intended behavior here is. Well, I'm confused anyways. :) On Fri, Nov 5, 2010 at 9:32 PM, James Craig jcr...@apple.com wrote: Ojan Vafai wrote: How is [ DOMAttributeChangeRequestEvent ] any different than DOMAttrModified? The spec claims it doesn't have the problems that DOMAttrModified has, but I don't see how that's the case. DOMAttrModified is a notification, but DOMAttributeChangeRequestEvent is a request. The reason these all inherit from UIRequestEvent is because they are all requests, not notifications. For example, the following sequences may occur in a real user scenario. I think this is the core of my confusion. In some cases I get that these events are requests. In this case, it's a request to change an attribute. But there are other cases where it seems like they have a default action. For example, when the user scrolls, we fire a UISrollRequest and if the web page does nothing, then the page scrolls, right? And if they user hits the delete key, we fire a DeleteRequest and delete if the web page doesn't cancel it. But then the AT software can also fire a DeleteRequest that does nothing if the web page doesn't cancel it? Am I misunderstanding? If the events are always requests with no default action, calling these request events might make sense, but then it seems that these would only be for AT software and should be named appropriately. From another email to the list (On Nov 5, 2010, at 7:29 PM, James Craig wrote): The primary need is for assistive technology, but there are several cases where this is appropriate in a mainstream user agent. For example, some mobile devices have a scroll to top feature if you click on the status bar chrome just outside the web content view. For web apps with custom scroll views (e.g. those that accept touchstart and touchend), it may be appropriate for the user agent to fire a single UIScrollRequest with a scrollType value of TOP_LIMIT. http://lists.w3.org/Archives/Public/wai-xtech/2010Aug/att-0079/UserInterfaceIndependence.html#UIScrollRequestEvent My first intuition is that we should not try to do AT specific events *if* we can avoid it because web developers will largely ignore them, but I'd like to understand the current proposal first. I agree, but even if these were AT-specific events, I don't think we could avoid them. There is currently no good way for assistive technology to control a web application. The existing de facto approaches are a crappy workaround at best. That's what the problem description is about: http://lists.w3.org/Archives/Public/wai-xtech/2010Aug/att-0079/UserInterfaceIndependence.html#problem DOMAttrModified I took your dollar. By the way, my dad and granddad are probably gonna some cash from you, too. DOMAttributeChangeRequestEvent Path 1: Can I have a dollar? No? Okay. Path 2: Can I have a dollar? Yes? Sweet. Heh. I see they these are different. DOMAttributeChangeRequestEvent is not actually a notification that something changed or that something is about to change? Correct. It's up to the web application to make any requested changes. In this case, to hand out the cash… or not. James ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] W3C Proposal: User Interface Independence for Accessible Rich Internet Applications
On Nov 2, 2010, at 12:48 PM, Ojan Vafai wrote: On Oct 27, 2010, at 2:57 PM, James Craig wrote: James Craig responded: The main difference seems to be that our Undo and Redo *request* allows the web application to determine what (if anything) should be undone, or redone, where the HTML5 undo manager requires that the user agent make the change directly to the DOM or editable content. The UIRequestEvent interface allows the app to determine the outcome of the events based on the business logic of the app, which the browser does not know about. I don't really understand how putting request in the name of the event is useful. There are plenty of existing events that allows the app to determine the outcome of the events based on the business logic of the app but aren't request events. The best explanation I have for it now is the following paragraph, or the intro section in the proposal. The reason these are all called 'request' events is because they don't change anything. They only send a 'request' to the web application (not to the user agent) to make a change on the user's behalf. The web application can then intercept or ignore the event as needed. If ignored (if the web app hasn't registered that event listener, or if the event is not canceled with preventDefault) then the user agent or assistive technology can fall back to whatever behavior is deemed appropriate, including then using the HTML5 undo manager. Back to Tony's email: Ojan also proposed renaming the textInput event to just beforeInput because it seems like it can apply to more than just text (e.g., undo'ing the insertion of an image). Do you think the use of textInput/beforeInput would meet the use cases needed by UIRequestEvent? In some cases, it may be appropriate, but my response to the previous question may provide additional understanding of why textInput/beforeInput is not sufficient, and why these two proposals are not mutually exclusive, even if they do overlap in some places. I still don't see why beforeInput would not be sufficient. It might be more clear if you enumerated the list of things you expect to have UIRequestEvents for. There are several examples in the proposal, including: Users, wanting to change the value of a custom range widget (ARIA slider, ARIA media progressbar, etc.) in a web application, can indicate their intent a number of ways, including pressing various keys (up, down, left, right, pageup, pagedown, home, end) on most keyboard-controlled interfaces, and through gestures on many touch-enabled interfaces. User agents understanding this intent should initiate a ValueChangeRequest event. Web authors who have registered for this event, should process the event to determine whether to cancel the event. If the value change action is understood in the context of the web application, web authors should change the value of the associated widget by an amount determined via the changeType argument, and cancel the event using the event object's ---() method. If the event is not cancelled by the web author, user agents may pass the literal interaction event to the web application; in this case, in the form of a keypress event. We plan to include more examples in a later draft. As I stated in the bug tracker comments, the W3C DOM and PF working groups discussed this, and the outcome was to work on a standalone specification as a joint effort of the two groups. The initial document editors will likely be Doug Schepers (W3C staff contact for www-dom) and me. From the teleconference discussions, these will be an add-on to DOM 3 Events and/or ARIA 1.0, because both of those documents are currently in Last Call. The only major change to the proposal so far that we're discussing a new method to the Event object (perhaps 'suppressEvents' or 'suppressRelatedEvents') so that we don't have to cancel the event by overloading the original use of the preventDefault method. What's the difference between preventDefault and suppressEvents? preventDefault only prevents the default action of the current event. supressEvents would allow the author to inform the user agent that any remaining events for the same user interaction are no longer relevant. For example, if the user pressed either Delete key and the application intercepted the DeleteRequest event, it could call Event.suppressEvents() (or whatever we call it) to indicate that the related events (keydown, keyup, keypress) are no longer needed, and the user agent should not fire them. Also, earlier in this thread, you said that you don't know of anything that requires these events to be synchronous, but that seems to contradict James's point above and the patch in question fires the events synchronously. The spec text all also implies that the event fires, then application has the chance to prevent it and then the action happens. So, unless I'm misreading, the events
Re: [webkit-dev] W3C Proposal: User Interface Independence for Accessible Rich Internet Applications
Sorry for the delayed response, Tony. My answers inline. On Sep 3, 2010, at 9:35 AM, Tony Chang wrote: I'm curious what elements the UIRequestEvents apply to. Does it fire at the document level or does it fire for specific elements like textareas? Focused element (or AX-focused element) where appropriate. Document body otherwise. For example, the scroll request events should be fired on the focused node so they can bubble up the DOM tree, so any node that needs to intercept it can. An example of when this may be inappropriate to fire on a lower-level node DOM is in the case of a browsing context that does not have a focus model where something always has focus; e.g. many touch-screen mobile devices do not have a focused element unless a form element is selected, or an assistive technology application is running on top of the rendering engine. In this case, firing at the document level would be appropriate. The addition of undo/redo is similar to the proposal to add this to the textInput event. There was some discussion of that here: http://lists.w3.org/Archives/Public/www-dom/2010AprJun/0082.html This may be answered my response to Doug Schepers' related question in this email from the www-dom list. http://lists.w3.org/Archives/Public/www-dom/2010OctDec/0051.html Quoting from that thread: Doug Schepers wrote: Note also that HTML5 defines editing actions and APIs [6], specifically the UndoManager interface [7]. [7] http://www.w3.org/TR/html5/dnd.html#undomanager James Craig responded: The main difference seems to be that our Undo and Redo *request* allows the web application to determine what (if anything) should be undone, or redone, where the HTML5 undo manager requires that the user agent make the change directly to the DOM or editable content. The UIRequestEvent interface allows the app to determine the outcome of the events based on the business logic of the app, which the browser does not know about. The reason these are all called 'request' events is because they don't change anything. They only send a 'request' to the web application (not to the user agent) to make a change on the user's behalf. The web application can then intercept or ignore the event as needed. If ignored (if the web app hasn't registered that event listener, or if the event is not canceled with preventDefault) then the user agent or assistive technology can fall back to whatever behavior is deemed appropriate, including then using the HTML5 undo manager. Back to Tony's email: Ojan also proposed renaming the textInput event to just beforeInput because it seems like it can apply to more than just text (e.g., undo'ing the insertion of an image). Do you think the use of textInput/beforeInput would meet the use cases needed by UIRequestEvent? In some cases, it may be appropriate, but my response to the previous question may provide additional understanding of why textInput/beforeInput is not sufficient, and why these two proposals are not mutually exclusive, even if they do overlap in some places. As I stated in the bug tracker comments, the W3C DOM and PF working groups discussed this, and the outcome was to work on a standalone specification as a joint effort of the two groups. The initial document editors will likely be Doug Schepers (W3C staff contact for www-dom) and me. From the teleconference discussions, these will be an add-on to DOM 3 Events and/or ARIA 1.0, because both of those documents are currently in Last Call. The only major change to the proposal so far that we're discussing a new method to the Event object (perhaps 'suppressEvents' or 'suppressRelatedEvents') so that we don't have to cancel the event by overloading the original use of the preventDefault method. Thanks for your questions. We realize the proposal may not be clear unless the reader knows a lot about 1) screen readers and 2) WAI-ARIA, but we hope to improve the understandability of the document in future iterations. Cheers, James Craig ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] W3C Proposal: User Interface Independence for Accessible Rich Internet Applications
On Sep 3, 2010, at 12:13 PM, Adam Barth wrote: Sorry for not reading the document in detail, but are these events fired synchronously or asynchronously? Since it's all client-side communication between the web app and local user agent, I don't have a preference. Chris may. Do you? ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] W3C Proposal: User Interface Independence for Accessible Rich Internet Applications
On Sep 3, 2010, at 5:25 AM, Mike Marchywka wrote:
Certainly an ability to zoom text is well known, but a text to
speech facility or re-rendering from web author's original
intent ( text to audio conversion) could be of general interest.
[ I guess this also motivates another general rant I have on
structured data documents versus display formats like PDF which
may be larger while being less adaptable due to loss of information
( removing text to send bitmapped characters for example, former could
reasonably by converted to audio with a reader technology but not the
latter).]
Did you see the TBD Speech Interface at the end of the document? We knew speech
would have a lot of potential in the AT and mainstream market, but we focused
on AT for vision impairments (screenreader and magnifier interfaces) for the
initial proposal.
http://lists.w3.org/Archives/Public/wai-xtech/2010Aug/att-0079/UserInterfaceIndependence.html#identification
4. Assistive Technology Identification and Notification
…
Interface Speech
The speech attribute of the Accessibility interface must return an instance of
the Speech interface:
interface Speech {
// TBD, placeholder for speech-controlled user agents or assistive technology
// may need speech.synthesis and speech.recognition; each could have
name/version/engine, etc.
// potential method: speech.synthesis.speak() to trigger TTS from web app
// potential method: speech.recognition.updateDictionary() to capture correct
pronunciation of uncommon or app-specific words
};
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
