Yes, it is - it's all just part of the markup.  What's not accessible is the *meaning* of the visual formatting, but that's inherent to this sort of thing, and there's a note in the spec about this already.

(In reply to comment #1)
> Yes, it is - it's all just part of the markup.  What's not accessible is the
> *meaning* of the visual formatting, but that's inherent to this sort of thing,
> and there's a note in the spec about this already.

If the visual formatting is pertinent to understanding the meaning of the content though, there's a gap for people who use screen readers. The text in the spec acknowledges this, but it doesn't really offer any practical advice.

Could an example be included that highlights this, and which demonstrates a potential solution? Perhaps some Python code, with the suggestion that the code be made available for download (allowing a screen reader user to open it in a text editor where the indentations would be honoured)?

(In reply to comment #2)
> Could an example be included that highlights this, and which demonstrates a
> potential solution? Perhaps some Python code, with the suggestion that the code
> be made available for download (allowing a screen reader user to open it in a
> text editor where the indentations would be honoured)?

I'm confused.  The indentations are honored in <pre> just as well as they'd be in a text editor.

If a screen reader somehow reads the indentations of Python code better in a text editor than in <pre>, that's probably a bug in the screen reader.  Do you have any examples of something like this?

The difference is that in an application window, a screen reader can calculate the distance between the window edge and the start of the line. When content contained within <pre></pre> appears on a page, there isn't a fixed point from which to measure the indentation. Screen readers rely almost exclusively on the HTML (rather than the CSS) to convey information to the user.

I can see a screen reader picking up headers, lists, graphics etc., but have not heard it picking up preformatted text. Wonder how that is going to be like.

With apologies. This bug was filed against the wrong component. Now filed against the HTML5 spec, specifically section 4.5.3 the pre element:
http://www.w3.org/html/wg/drafts/html/master/grouping-content.html#the-pre-element

The section acknowledges the potential inaccessibility of pre-formatted content for certain users:

"Note: Authors are encouraged to consider how preformatted text will be experienced when the formatting is lost, as will be the case for users of speech synthesizers, braille displays, and the like. For cases like ASCII art, it is likely that an alternative presentation, such as a textual description, would be more universally accessible to the readers of the document."

The suggestion to include an alternative presentation is helpful, but could be made more so by extending it to include an additional commonplace use of the pre element:

"Note: Authors are encouraged to consider how preformatted text will be experienced when the formatting is lost, as will be the case for users of speech synthesizers, braille displays, and the like. An alternative presentation would be more universally accessible to readers of the document. For example a textual description of ASCII art, or a downloadable text file containing code examples."

Bug in implementations - browsers should make it possible for the screen reader to get the spacing information, and screen readers should report that as appropriate.