sequential navigation, tabindex, and access key questions

I am working on tabindex and I am trying to be consistent with what is in
HTML5 but I have some questions:

   - Does the group want focus events that are not handled within the SVG
document to bubble up into a containing DOM (HTML) if they are not handled
within? I guess this would be the case for any events. We are sharing the
same DOM?
      - Same goes for an SVG element embedded in another SVG element.
   - Does the group want to support access keys? Personally I think they
are terrible and should never have been created. I am not a big fan of them
and I know of no IBM group that uses them. As we go to mobile I think they
will go the way of the bit bucket. (my 2 cents). Also, in general, people
in the accessibility field have been discouraging their use.
   - Do people agree the anchor element in SVG should be in the keyboard
navigation order like HTML, without requireing tabindex?
   - In terms of keyboard navigation, if we are being used inside of a
parent document that also supports tabindex I believe we should be included
in
   the sequential navigation order so at to have seamless navigation. Do
you all agree? This happens today with IFrames and is a good
   accessibility practice as it does not create an accessibility speed bump
where you would actively hit some other key(s) to navigate into the SVG
element. People want to just tab right into the IFrame.
   - Do folks want to go to the same degree of specification whereby we
dictate the processing of keyboard events like they do in HTML5?
   - When an element with tabindex receives focus and you can't see it
because it is zoomed out should we zoom into the element or give the author
the decision to make?

I will have lots more questions. I have not looked at integrating the
directional keyboard navigation from SVG Tiny yet.