search

cloudbearings / ez-access-web

Automatically exported from code.google.com/p/ez-access-web
0 stars 0 forks source link

<img> behavoir #19

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
I am proposing that an <img /> should be treated similarly to a 
<span>...</span>. This means that an image should not ordinarily be 
highlightable and its alt-text should be included along with other content of 
its parent.

For example, if a paragraph has an embedded image, EZ Access will highlight the 
entire paragraph (including the image) and read the paragraph's content along 
with the alt text of the image.

If <img> has no alt-text, then I think it is okay to announce the presence of 
the image by just replacing it in speech with the word "Image."

If <img> has null alt-text (<img alt="" ... />), then nothing should be read, 
just as if there was no content there. If such an image were the only child of 
a <p>, it should behave as if the paragraph is blank (does that mean it gets 
skipped in the navigation order??).

If (img> has alt-text, then the speech reads that.

If my memory serves me (XHTML 1.0 days), the <img /> tag was inline content 
that could only be used inside block level content (such as <div>, <p>, etc.). 
It seems that maybe HTML 5 has relaxed some of those restrictions. We may wish 
to have a special case where if there is an <img> in the root (i.e., body), 
then it is navigable.

Original issue reported on code.google.com by jbjor...@gmail.com on 3 May 2013 at 8:49

GoogleCodeExporter commented 8 years ago 
This is a sketchy area. I know many sites use images as a 'home' button. Or 
dedicated image 'back' buttons.

It seems like a screen reader would would to incorporate this ability, but EZ 
Access isn't a screen reader. You can, however, customize it with a grouping, 
or make it not focusable. Is it better to try and predict what the developer 
wants or allow them to modify it if they want changes from a consistent base? 
I'd go with the latter. Are you sure that you want this implemented?

Maybe implementing this would be better... I'll try and see.

Original comment by aeharding on 3 May 2013 at 9:52

GoogleCodeExporter commented 8 years ago 
Remember the parsing in Issue 27 when working on this.

Basically, first look to see if an element is "display: none". If so, you don't 
need to parse any descendants and can skip to the next node.

Original comment by jbjor...@gmail.com on 28 May 2013 at 9:24

GoogleCodeExporter commented 8 years ago 
So, are we parsing the <img> tag? Any further thoughts on this?

Original comment by aeharding on 12 Jun 2013 at 7:27

GoogleCodeExporter commented 8 years ago 
Let's make it "inline" so it gets grouped by default with its parent element. 
This means that if a <p> or other tag contains an <img>, you will need to 
change the function where you get the content/inner HTML to also include the 
alt text of images.

If an <img> is used as a home page link, it will be in a <a href> or a button, 
which is navigable.

Ideally, if there is something like a <span> or an <img> as a direct child of 
the <body>, then they should be navigable (simply because there isn't a 
navigable parent). In the <span> case, there might be navigable children. The 
<img> cannot have children.

Original comment by jbjor...@gmail.com on 13 Jun 2013 at 2:41

GoogleCodeExporter commented 8 years ago 
This has been fixed in previous revision, but it hadn't been marked as such. 
<img> tags are treated as inline content.

Original comment by jbjor...@gmail.com on 5 Aug 2013 at 3:25