Action Item HTML5 Section 3

Hi there,
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 4.11.5.3 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?

3.3.3.8 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.

3.3.5.1.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.

Cheers
Si.

=======================

Simon Harper
University of Manchester (UK)

Human Centred Web Lab: http://hcw.cs.manchester.ac.uk

My Site: http://hcw.cs.manchester.ac.uk/people/harper/

My Diary (Web): http://hcw.cs.manchester.ac.uk/people/harper/ 
phpicalendar/week.php
My Diary (Subscribe): http://hcw.cs.manchester.ac.uk/diaries/harper/ 
SimonHarper.ics

Received on Wednesday, 5 August 2009 15:00:08 UTC