-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support linked data (e.g. for physical accessibility) #130
Comments
I wonder if we can minimize the amount of A11Y specific information and have a list of general properties each feature should contain. Information such as accessible sidewalks, and ramps, for example, would be useful for more than just those with wheelchairs. Anyone who is lugging a giant suitcase from the airport to their hotel can attest to this. |
Thanks for these comments. As a way of protecting the future project from problems due to intellectual property considerations, please consider joining the W3C Maps for HTML Community Group, which requires certain IP grants from you to the community for the purpose of standardizing ideas like these. We'll then send you a GitHub invitation to join other contributors here. You and your contributions are most welcome! That said, I believe that the markup skeleton that you are setting up with <feature>
<properties>... any 'regular' HTML goes here... </properties>
<geometry> ... would it be useful to semantically mark up geometry elements (including embedded <a href>...</a>?... </geometry
</feature> So, your example might look like but would not be restricted to the following markup: <feature vocab="https://schema.org" typeof="Hotel">
<properties>
<span property="name">An awesome hotel 🏨</span>
<div property="amenityFeature" typeof="LocationFeatureSpecification">
<span property="name">Wheelchair-accessible Sauna</span>
<span property="value">True</span>
</div>
<!--
a standardized Linked Data vocabulary for accessibility does not exist yet, but a
standardization of physical a11y is going to be part of schema.org soon.
[A11yJSON](https://a11yjson.org) is an example how such a schema could look like.
So we're just brainstorming here, but again instead of non-standard meta elements, just use HTML FTW:
-->
<div typeof="a11y:AnimalPolicy">
<span property="a11y:allowsGuideDogs">True</span>
</div>
</properties>
<geometry> ... would it be useful to semantically mark up geometry elements (including embedded <a href>...</a>?... </geometry
</feature> Re: script, we have so far shied away from specifying that |
Thanks for your feedback! I’ve joined the Maps4HTML CG + GItHub org. Re which accessibility attributes to include: the proposal aims to enable authors to link data in any vocabulary, no matter how complex or lightweight - also vocabularies that have nothing to do with accessibility. Likely, there will soon be different vocabularies for accessibility with varying levels of detail. schemaorg/schemaorg#254 is a GitHub issue showing such a discussion for schema.org. The example above was using a fictional vocabulary ( Re where to put the elements: True, for my example case, it makes more sense to put the tags into the properties. Other examples where adding semantics can make sense:
As this list is not exhaustive, I think if we choose RDFa as the first supported syntax for Linked Data, the format should allow the new RDFa properties on all elements, as it does in HTML. Re Re So… Should we include RDFa directly in the standard? If so, which version? https://www.w3.org/TR/rdfa-lite/? |
I strongly endorse the minimum viable complexity that will work for your use cases approach, so rdfa-lite looks reasonable. A key first step will be describing a map-based use case or category of use cases that shows us the way for how the rdfa markup could be used by the UA. Then I guess we'll need to extend the schema to include the attributes, so that they can potentially be "validated". I don't know how much RDF-A the W3C validator supports, but I suppose we could use that to see what we might be aiming at. I think the idea of the validator was originally to use schematron to validate constraints, but I believe that has ended up with implementing custom constraint validation in java. It's not all about validation, we need to probably implement/prototype some behaviour? @kmcglinn is interested in linked building data. Maybe we should set up a call in the near future to explore pathways forward? |
As visible above, I've added a use case idea that's hopefully simple enough to get started. |
Just an observation: The HTML If <map ...>
<layer src="map-markup.mapml"></layer>
<layer src="a11y.json" kind="metadata"></layer>
</map>
...
<geometry>
<point>
<coordinates>2.376757 48.898991</coordinates>
</point>
</geometry>
{
"geometry": { "type": "Point", "coordinates": [2.376757, 48.898991] },
"properties": {
"category": "cinema",
"name": "Ciné XY",
"accessibility": {
"entrances": [
{ "name": "30th St", "isMainEntrance": true, "isLevel": false },
{ "name": "Side gate", "hasFixedRamp": true }
],
"accessibleWith": {
"wheelchair": true
},
"animalPolicy": {
"allowsGuideDogs": true
}
}
}
} This obviously separates the metadata from the map markup (not saying that the map markup couldn't provide metadata inline in addition), which I suppose could have both pros and cons. |
@Malvoz Good idea. I think in the end we should have both, RDFa and external JSON-LD (which I'd prefer over using A11yJSON directly, as A11yJSON is no Linked Data standard). For a user agent to make sense of this, there would have to be references to the single map elements for this to work. schema.org does something similar with the |
In the "Physical accessibility data in maps" workshop, we presented an idea to extend MapML with a way to semantically mark the physical accessibility of a displayed place.
This proposal would allow to add any semantics via Linked Data, for example via microformats, RDFa, or as JSON-LD snippet.
It would enable screenreaders and other accessibility assistants to make sense of MapML content, and add a whole new infrastructure for accessibility/navigation browser plugins, and could even create a new economic incentive to improve real-world accessibility.
You could use this to link:
Example browser features / extensions that this proposal would enable
@speakable
for voice assistantsExample 1: RDFa lite
Here is one example how the syntax could look, using RDFa Lite:
RDFa lite would add the following attributes:
vocab
,typeof
,property
,resource
, andprefix
. It would make use of the existingmeta
element.Using schema.org's
sameAs
property, this would also allow linking external APIs to let a user agent request semantic data with extra HTTP requests.Example 2: JSON-LD /
script
An alternative could be to allow JSON-LD
script
elements (example copied from https://schema.org/Hotel):src
attribute@speakable
, via a CSS or XPath selector<link href="">
If you have a sensible idea how to use the existing
<link href="">
element for linking a data set, please leave your idea here :)The text was updated successfully, but these errors were encountered: