Open Bug 764118 Opened 12 years ago Updated 2 years ago

svg element role is diagram

Categories

(Core :: Disability Access APIs, enhancement, P3)

Product:
Core
Component:
Disability Access APIs
Version:
14 Branch
Platform:
x86
Windows Vista
Type:
enhancement

Tracking

()

People

(Reporter: faulkner.steve, Unassigned)

References

(Blocks 1 open bug)

Details

checked <svg> element role value with an API inspect tool, found it is mapped to 'diagram' role = "Represents a graphical image used to diagram data. " does not seem to be right role for <svg>. SVG elements can contain any graphical informations not just diagrams. Suggest changing to role=graphic https://developer.mozilla.org/en/Accessibility/AT-APIs/Gecko/Roles/ROLE_GRAPHIC (also mapped as graphic by IE)
Sound reasonable but there's a problem. The graphic role doesn't have children historically, svg can contain text that might be interesting for ATs.
(In reply to alexander :surkov from comment #1)
> Sound reasonable but there's a problem. The graphic role doesn't have
> children historically, svg can contain text that might be interesting for
> ATs.

Ok will think about it some more :-)
surkov, did some testing may be of interest: https://dl.dropboxusercontent.com/u/377471/SVG/adobesimplesvgtest1.html
(In reply to alexander :surkov from comment #1)
> Sound reasonable but there's a problem. The graphic role doesn't have
> children historically, svg can contain text that might be interesting for
> ATs.

actually image map has children and exposed as graphic role on MSAA layer. I think we can switch to graphic role for svg.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Jamie, do you have objections on the change?
Flags: needinfo?(jamie)
(In reply to alexander :surkov from comment #4)
> (In reply to alexander :surkov from comment #1)
> > Sound reasonable but there's a problem. The graphic role doesn't have
> > children historically, svg can contain text that might be interesting for
> > ATs.
> 
> actually image map has children and exposed as graphic role on MSAA layer. I
> think we can switch to graphic role for svg.

the change will mean that svg is recognised by AT at least without having to add ARIA
(In reply to steve faulkner from comment #6)

> the change will mean that svg is recognised by AT at least without having to
> add ARIA

oh, so DIAGRAM is rather a hindrance, ok good.

(In reply to steve faulkner from comment #3)
> surkov, did some testing may be of interest:
> https://dl.dropboxusercontent.com/u/377471/SVG/adobesimplesvgtest1.html

btw, thank you for doing this
I don't have any huge objections; it should work for NVDA. However:
1. I don't quite follow the argument that "SVG elements can contain any graphical informations not just diagrams". I guess I thought of a diagram just as a compound graphical representation.
2. I know image maps have children, but this has always struck me as odd anyway. I've always thought a graphic shouldn't have children. I guess I think of a graphic as a single piece of image data that can't be broken down any further for accessibility purposes, so having graphics as children of a diagram makes sense to me.

Requesting feedback from Mick, since he's worked with SVG significantly more than I have.
Flags: needinfo?(jamie) → needinfo?(mick)
Btw, the fact that NVDA (and other screen readers) doesn't handle the diagram role in browse mode should probably be considered a bug. Imo, that isn't sufficient reason to implement this if there are reasonable objections.
(In reply to James Teh [:Jamie] from comment #8)
> I don't have any huge objections; it should work for NVDA. However:
> 1. I don't quite follow the argument that "SVG elements can contain any
> graphical informations not just diagrams". I guess I thought of a diagram
> just as a compound graphical representation.
> 2. I know image maps have children, but this has always struck me as odd
> anyway. I've always thought a graphic shouldn't have children. I guess I
> think of a graphic as a single piece of image data that can't be broken down
> any further for accessibility purposes, so having graphics as children of a
> diagram makes sense to me.

fwiw I think I agree with this.
(In reply to James Teh [:Jamie] from comment #8)
> I don't have any huge objections; it should work for NVDA. However:
> 1. I don't quite follow the argument that "SVG elements can contain any
> graphical informations not just diagrams". I guess I thought of a diagram
> just as a compound graphical representation.

for me a diagram means something technical like graphics. If svg was used to draw an image from child cartoon movie then would be ok to call it a diagram?
from recent testing of SVG I really think the way SVG and its sub tree is represented in the accessibility tree needs to be reviewed. complex SVG can have hundreds of graphic elements, many of which may or may not be best represented as graphics (text for example) also it may be more useful to have their role represented as the shape they convey. for example role=circle, it very much depends on the context.
(In reply to steve faulkner from comment #12)
> from recent testing of SVG I really think the way SVG and its sub tree is
> represented in the accessibility tree needs to be reviewed. complex SVG can
> have hundreds of graphic elements, many of which may or may not be best
> represented as graphics (text for example) also it may be more useful to
> have their role represented as the shape they convey. for example
> role=circle, it very much depends on the context.

afaik Firefox exposes stuff that have a meaning like elements having title or desc. Exposing shaping should be nice. Role is probably not a best mechanism for this though. Anyway, is it related to root svg element role?
(In reply to alexander :surkov from comment #11)
> for me a diagram means something technical like graphics.
I realise you probably just used the wrong term there, but I can't help but point out that "graphic" also refers to "graphics". :)

> If svg was used to
> draw an image from child cartoon movie then would be ok to call it a diagram?
It's certainly a stretch. Wiktionary would seem to agree with you:
> 1. A plan, drawing, sketch or outline to show how something works, or show the relationships between the parts of a whole.
> 2. A graph or chart.

I still feel there really should be a distinction between compound and leaf graphics like there is between documents and paragraphs, but perhaps you're right that diagram isn't the right term.
(In reply to James Teh [:Jamie] from comment #14)
> (In reply to alexander :surkov from comment #11)
> > for me a diagram means something technical like graphics.
> I realise you probably just used the wrong term there, but I can't help but
> point out that "graphic" also refers to "graphics". :)
> 
> > If svg was used to
> > draw an image from child cartoon movie then would be ok to call it a diagram?
> It's certainly a stretch. Wiktionary would seem to agree with you:
> > 1. A plan, drawing, sketch or outline to show how something works, or show the relationships between the parts of a whole.
> > 2. A graph or chart.

you know I still translate :) hoping that english to russian and back still makes sense :) good know it works sometimes :)

> I still feel there really should be a distinction between compound and leaf
> graphics like there is between documents and paragraphs, but perhaps you're
> right that diagram isn't the right term.

a primary point I think is the spec should point what role is in use. If it's diagram then we should convince IE (or at least to state clearly why) it's preferable over graphic role.

(but I share the point that graphic as a container doesn't look a right match)
(In reply to alexander :surkov from comment #13)
> (In reply to steve faulkner from comment #12)
> > from recent testing of SVG I really think the way SVG and its sub tree is
> > represented in the accessibility tree needs to be reviewed. complex SVG can
> > have hundreds of graphic elements, many of which may or may not be best
> > represented as graphics (text for example) also it may be more useful to
> > have their role represented as the shape they convey. for example
> > role=circle, it very much depends on the context.
> 
> afaik Firefox exposes stuff that have a meaning like elements having title
> or desc. Exposing shaping should be nice. Role is probably not a best
> mechanism for this though. Anyway, is it related to root svg element role?

no me just going off into weeds
(In reply to alexander :surkov from comment #15)
> (In reply to James Teh [:Jamie] from comment #14)
> > (In reply to alexander :surkov from comment #11)
> > > for me a diagram means something technical like graphics.
> > I realise you probably just used the wrong term there, but I can't help but
> > point out that "graphic" also refers to "graphics". :)
> > 
> > > If svg was used to
> > > draw an image from child cartoon movie then would be ok to call it a diagram?
> > It's certainly a stretch. Wiktionary would seem to agree with you:
> > > 1. A plan, drawing, sketch or outline to show how something works, or show the relationships between the parts of a whole.
> > > 2. A graph or chart.
> 
> you know I still translate :) hoping that english to russian and back still
> makes sense :) good know it works sometimes :)
> 
> > I still feel there really should be a distinction between compound and leaf
> > graphics like there is between documents and paragraphs, but perhaps you're
> > right that diagram isn't the right term.
> 
> a primary point I think is the spec should point what role is in use. If
> it's diagram then we should convince IE (or at least to state clearly why)
> it's preferable over graphic role.

on windows 'diagram' is only used by firefox, IE uses graphic, Chrome does not expose. On Mac chrome/safari use 'image'. The only current reliable way to get browser across OS to recognise SVG is to use ARIA role=img
(In reply to steve faulkner from comment #17)
> (In reply to alexander :surkov from comment #15)
> > (In reply to James Teh [:Jamie] from comment #14)
> > > (In reply to alexander :surkov from comment #11)
> > > > for me a diagram means something technical like graphics.
> > > I realise you probably just used the wrong term there, but I can't help but
> > > point out that "graphic" also refers to "graphics". :)
> > > 
> > > > If svg was used to
> > > > draw an image from child cartoon movie then would be ok to call it a diagram?
> > > It's certainly a stretch. Wiktionary would seem to agree with you:
> > > > 1. A plan, drawing, sketch or outline to show how something works, or show the relationships between the parts of a whole.
> > > > 2. A graph or chart.
> > 
> > you know I still translate :) hoping that english to russian and back still
> > makes sense :) good know it works sometimes :)
> > 
> > > I still feel there really should be a distinction between compound and leaf
> > > graphics like there is between documents and paragraphs, but perhaps you're
> > > right that diagram isn't the right term.
> > 
> > a primary point I think is the spec should point what role is in use. If
> > it's diagram then we should convince IE (or at least to state clearly why)
> > it's preferable over graphic role.
> 
> on windows 'diagram' is only used by firefox, IE uses graphic, Chrome does
> not expose. On Mac chrome/safari use 'image'. The only current reliable way
> to get browser across OS to recognise SVG is to use ARIA role=img

sorry that is incorrect the mappings are as in the results : https://dl.dropboxusercontent.com/u/377471/SVG/adobesimplesvgtest1.html

It seems there's been some work in this area I wasn't aware of. Apparently, svg is now mapped to ARIA role graphics-document, which in turn maps to document roles on various platforms. I'm not aware of this being implemented anywhere, though. In any case, we're going to need to figure out what to do here in light of these changes.

Note that NVDA does now support the diagram role in browse mode. I'm not sure about JAWS or Orca, though.c

Type: defect → enhancement
Component: Disability Access → Disability Access APIs
Flags: needinfo?(mick)
Priority: -- → P3
Product: Firefox → Core
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.