Have you already started on this? I'm already working on a
more general change that will solve this, but if you've started
working please show me what you have.

From Joe @FS:
"I was just talking to a colligue about this issue. Regardless of how we do it, we have the issue of not including the non-editable marker in the offsets for Braille routing etc. We will need to know that we are in a list (perhaps an object attribute?) and how many characters to account for the list item at the beginning (another object attribute???) so that we can adjust the offsets for Braille routing and cursor tracking. Any time we have extra characters in the text which are non-navigable, we must somehow account for them so that the cursor blinks under the correct character. Whatever solution you come up with, will require work to ensure that the cursor is placed under the correct character when we output to Braille. Plese keep this in mind and let us know which route you take and how we can obtain the information necessary to keep cursor tracking correct.
For example, in a list item whose number is 100 folowed by a space before the main text of the line, the offset of the line really begins at 4 and the list item marker length is 4."

I was just going to implement a simple workaround in AXLayoutObject::nextOnLine that would return the ID of the first inline text box of the li element when the layout object was a list marker.
But if you are implementing something more comprehensive, I guess I shouldn't do that.

This is currently implemented. next_on_line_id on a list marker points to the first inline text box that comes after it.