ACTION-219: Review Section 3 structure of HTML5
Review Section 3 structure of HTML5
- Simon Harper
- Due on:
- August 6, 2009
- Created on:
- July 30, 2009
- Related emails:
- Minutes - User Agent Working Group Telecon - 20 Aug 2009 (from email@example.com on 2009-08-20)
- User Agent Working Group Telecon - 30 Jul 2009 (from firstname.lastname@example.org on 2009-07-30)
So my action item was to look at section 3 'Semantics, structure, and APIs of HTML documents' of the HTML5 spec and flag anything I thought may be important for us to discuss. I don't intend to go through the posts to UAWG which look at keyboard control. My method was to run through the section following any link I thought may affect things and so some of my flags maybe from different sections.
So looking at this further, I see that in 7.6 list-item 2 and 3.3 of the HTML5 spec on accesskeys, that only a single key is allowed as opposed to multiple sequential keys, however, when you add this to the concept of the context menu in 184.108.40.206 it seems that the general model of interaction, and importantly exploration of the interface, becomes broken as a single keystroke without a modifier key cannot be allocated. While this follows on the mac OS, the intuitive sequential keystrokes of Windows and Linux will break. In this case what about a caveat that if the context menu is in focus then a single keystroke without a modifier key is sufficient?
7.10.5 Draggability. I have no idea how this can be addressed, while selection can be easy, understanding the location on a page for a drop/release may be problematic without some form of browser based auditory feedback?
220.127.116.11 Embedded Links to Non-Visible Data - this could be really useful and a great accessibility feature, but as there is no concept of interoperability beyond the site (as it is site bespoke) then we need to ensure that this kind of data is readable by the AT and maybe even the semantics of the interaction expressed in someway.
3.3.5 Orphan Nodes in Content Models - this could be problematic if the node cannot be accessed by AT, especially if it is going to modify the DOM based on a user event, but there is no way of telling what that modification will be.
18.104.22.168.6 and .7 Embedded and Interactive Content - activation behaviour and pre-click activation - there are too many opportunities for some accessibility nightmare here so it maybe worth reading these points and then discussing them.
3.2.4 There are many references to mutation events 'firing as appropriate', but without knowing when that is - UAs can make interpretations about what and when an event will fire - indeed some sections state that no mutation events will fire.
As a side issue, there are elements which are VERY VERY GOOD and the HTML5 crew should be congratulated from the nice explicit semantics of menu and the like. However, they then mess it up with elements such as 'small' - convenient for a visual rendering, good for the designer, but without a concept of the semantics of the thing it encloses - it does not say what the thing is. Would it not be better to enable overloading of an element and style combination into an element that is good for the designer, but because its base element type is known (and this has explicit semantics) AT gets a better idea of what the thing actually is as opposed to how it should be rendered?
In addition, I've not seen a good definition of quirks or limited-quirks modes.
Finally, It seems to me we are going to need far better validation and conformance tools to check that possible DOM modifications in the scripts are accessible - otherwise an html page - containing pretty much nothing will validate as OK, but there may be a huge amount of scripting which will enact inaccessible DOM updates on the client.
Display change log.