profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/mattgarrish/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Matt Garrish mattgarrish Nova Scotia I write a lot.

w3c/epubcheck 1136

Validation tool for EPUB

tobie/specref 136

An open-source, community-maintained database of Web standards & related references.

w3c/publ-a11y 13

Accessibility related discussions of the Publishing@W3C Groups

daisy/epub-revision-a11y 6

DAISY's work area for accessibility-related additions to EPUB 3.1

mattgarrish/thorium-reader 1

A cross platform desktop reading app, based on the Readium Desktop toolkit

mattgarrish/epub-specs 0

Shared workspace for EPUB 3 specifications.

mattgarrish/specref 0

An open-source, community-maintained database of Web standards & related references.

mattgarrish/validator 0

Nu Html Checker – Helps you catch problems in your HTML/CSS/SVG

w3c/a11y-discov-vocab 0

Repository for the maintenance of the schema.org accessibility property values for discoverability.

push eventw3c/epub-specs

Matt Garrish

commit sha 38472a5ec31057914d1aaab5aad435239e6fb72a

additional typo/grammar fixes

view details

push time in an hour

pull request commentw3c/epub-specs

Reformat examples to avoid scrolling

So some cases > became > but not all same for < became <

Oh, yes, I hate trying to read the source code examples when the closing brackets have been converted to greater than entities. It makes it headache to decipher the tags when you have stuff like &amp;lt;/a&amp;gt;, so I switched all those back to the actual '>' character.

You can't do the same with opening brackets as then they denote new tags within the pre element. I have to live with the lt entities for those.

mattgarrish

comment created time in 2 hours

pull request commentw3c/epub-specs

Reformat examples to avoid scrolling

I did notice a few < and > that looked like they were missed?

Do you mean the tags are missing? Could you point me to a specific case?

Also wondering why the I18N info was removed?

This branch was created last week before I integrated the i18n section. Merging it won't remove the changes that have already been integrated. (I could force a merge from main on the branch to get the latest commits to appear, but it's extra work for no appreciable gain.)

mattgarrish

comment created time in 3 hours

issue commentw3c/epub-specs

A11y 1.1 - Permalinks missing accessible name

I don't think the visual indication of the link being a greater than symbol conveys that this is a permalink to non-AT users either.

This is a relic of the IDPF specifications. I don't believe W3C adds permalinks to list items, or at least I don't see how it can be handled in respec (there's some custom javascript code that runs in a post-processing step to add these).

I wonder if we really need the permalinks on the conformance requirements, as I can't think of an easy way to add context to all the bullets, but this would potentially affect all our specifications. Any thoughts on this @iherman @dauwhe @wareid @shiestyle ?

In other cases the section character is used, but its accessible name is not descriptive (it is the § character):

Yes, these are coming from the respec code. The issue effects all W3C specifications including the current drafts of WCAG. They must have patched the source for the REC document if there are different attributes.

This case is probably less difficult to handle in a post-processing step, though, since it shouldn't be too hard to grab the text content of the heading and repurpose it into the attributes WCAG uses. I'll see if I can wire up something similar.

A better solution, though, would be to get this integrated into respec, or whoever is responsible for the "addPermalinks" option so it's not an issue everywhere. (I can't find that function documented in the respec docs, so maybe this is specific to W3C?)

anevins12

comment created time in 3 hours

delete branch w3c/epub-specs

delete branch : a11y/issue-1790

delete time in 3 hours

push eventw3c/epub-specs

Matt Garrish

commit sha 84d292fc76610e613dd8dc9614fec443fdd355c8

add section on internationalization and techniques

view details

Matt Garrish

commit sha c96f30b8646bb6d42e67129692756a7c55286be7

add link to epub requirement for utf-8/16; add change log entry

view details

Matt Garrish

commit sha 8622ab5f4196bfe76d8e66d0027a199ae1acdb12

rerun ipr check

view details

Matt Garrish

commit sha 5e1e86dadb55756449c2528eef015f297a8f32c1

updated last paragraph per discussions

view details

Matt Garrish

commit sha 4c37273eaad3ef1ae7a30b1afddf37745ba51e47

additional clarification to the text on unicode support

view details

Matt Garrish

commit sha 2fae88cc72110e97246e166ffb9c22874b67ca19

Merge pull request #1820 from w3c/a11y/issue-1790 Add section on internationalization and techniques

view details

push time in 3 hours

PR merged w3c/epub-specs

Reviewers
Add section on internationalization and techniques

As discussed on the call today, here's what I'm thinking in terms of addressing internationalization.

The PR adds a basic subsection to the existing success techniques section that explains that there will be differences in the best practices necessary to make content accessible in any given language, but that it's an expected part of how the guidelines are crafted.

I don't think we need to go deeper than this for the accessibility specification, but it opens the door to adding more specific details to the techniques.

I've worked in mention that Unicode is a requirement of EPUB, @avneeshsingh, but not exactly in the way you may have imagined. I can always look at rewriting it if you think the point you're trying to get across might not be fully captured.

Fixes #1790

+26 -0

10 comments

1 changed file

mattgarrish

pr closed time in 3 hours

issue closedw3c/epub-specs

Informative note for Unicode in EPUB accessibility

Using Unicode text is many times considered as implicit requirement. Furthermore it does not effect English speaking countries. But the fact is that you can find non-Unicode web content in non-English speaking parts of the world. The problem is even more in E-Publications because you can embed fonts in the publications. So, we should at least have an informative text in EPUB Accessibility specifications which remind the publishers to use Unicode text.

closed time in 3 hours

avneeshsingh

PR opened w3c/epub-specs

Reviewers
Add captions to the a11y property definition tables

Fixes #1828

+3 -0

0 comment

1 changed file

pr created time in 3 hours

push eventw3c/epub-specs

Matt Garrish

commit sha e73441b87da51824d58e67e754c8e62ad36c8308

add captions to the a11y property definition tables

view details

push time in 3 hours

create barnchw3c/epub-specs

branch : a11y/issue-1828

created branch time in 3 hours

PR opened w3c/epub-specs

Reformat examples to avoid scrolling

Fixes #1822

+602 -271

0 comment

2 changed files

pr created time in 4 hours

push eventw3c/epub-specs

Matt Garrish

commit sha 3362b629634b8afb6632a906117e8138b97ff1e5

reformat examples for zooming and add word breaking for code tags

view details

push time in 4 hours

pull request commentw3c/wai-about-wai

Add ARIA Authoring Practices, remove DPub ARIA TF

The description is really dated, since we've already published v. 1.0 of the DPUB-ARIA module and are working on 1.1 now. We're not comparing structural semantics or creating lists, but that was the TF that developed the module.

The TF page is also dated, as we're just running the maintenance work through github now.

So I don't know if the TF formally still exists, or if we're just something like an activity of the WG now, but if it does that page certainly needs some updating.

jnurthen

comment created time in a day

create barnchw3c/epub-specs

branch : a11y/issue-1822

created branch time in 3 days

PR opened w3c/epub-specs

Typo fixes

Fixes the first two typos identified in #1823. Will leave this open until the issue is finalized.

Fixes #1823

+3 -3

0 comment

1 changed file

pr created time in 3 days

push eventw3c/epub-specs

Matt Garrish

commit sha e9313ff98e375a940683f678accf88c92c0d1c26

typo fixes

view details

push time in 3 days

create barnchw3c/epub-specs

branch : a11y/issue-1823

created branch time in 3 days

pull request commentw3c/epub-specs

Update list of optimized publications and faq

Put the wrong extension in the last post: https://cdn.statically.io/gh/w3c/epub-specs/a11y/issue-1819/docs/optimized-pubs/index.md

The only difference from the wiki is an extra sentence in the overview disclaiming that it is not actually a registry. (You'll only get the raw markdown until we merge.)

mattgarrish

comment created time in 3 days

pull request commentw3c/epub-specs

Update list of optimized publications and faq

I've moved the guide to a markdown file.

But I'm still uncomfortable with the section being normative. Why are we requiring a URL, for example, when we don't use them ourselves. We can keep all the guidance on what you should be doing, but having it normative is problematic.

mattgarrish

comment created time in 3 days

push eventw3c/epub-specs

Matt Garrish

commit sha fbb0e65dde754a12e21bf1d8b2ec9728e1236c4a

change link to optimizations guide and add md file

view details

push time in 3 days

pull request commentw3c/epub-specs

Update list of optimized publications and faq

My only worry is to use the Wiki for this rather the same content in a markdown file that can also be pointed to via github.io.

The wiki worries me less than why the whole discussion of optimized publications isn't informative...

Should we define rules for how to identify conformance to specifications that we don't control?

I look at this section and strongly wonder why our guidance is normative, as all we originally set out to do in this section is say that just because you don't claim conformance to our standard doesn't mean the publication is inaccessible. We can informatively note how you would use the same element for other standards, but what is the end goal of having this section be normative?

If we make the section informative, I don't see why we need to maintain a list. The only entry in that document is the same standard we use in the example, so it's not like we're losing anything.

To go back to the discussions yesterday, what other standards you might conform to could well just be a topic for best practice sites like the DAISY KB.

mattgarrish

comment created time in 3 days

issue commentw3c/epub-specs

A11y 1.1 - Scrolling in 2 dimensions caused by long metadata

Thanks for the report. I'll take a look at the formatting as we usually do try to split long tags/attributes across lines whenever we can. I'll have to see how respec reformats the source when it pretty prints the markup to see what can be done about word breaking, though.

anevins12

comment created time in 3 days

issue commentw3c/epub-specs

A11y 1.1 - Grammar improvements

Thanks, I'll have a look at these later today.

anevins12

comment created time in 3 days

push eventw3c/epub-specs

Matt Garrish

commit sha a0c63b9b32ecd981bcfde265d05fdacb37f3b20e

remove custom js calls

view details

push time in 3 days

pull request commentw3c/epub-specs

Update list of optimized publications and faq

I must admit, I am not a fan of using this wiki page.

It should look pretty informal given that it's not central to the specification or the work of the group. There was concern about this document looking too much like a registry when it's just intended as an informative list.

The whole concept of optimized publications only exists to avoid the problem of not conforming to the spec leading people to think the content isn't accessible to anyone.

mattgarrish

comment created time in 3 days

pull request commentw3c/epub-specs

Update link to the list of optimized publications

Hm, looks like I forgot to switch branches for the faq, but then these are tied together so I'm going to leave both in this one PR.

mattgarrish

comment created time in 3 days

push eventw3c/epub-specs

Matt Garrish

commit sha 70ba2048a1b77cd450e28dd081811c8418d68fd1

add faq document; update link in a11y specification

view details

push time in 3 days

create barnchw3c/epub-specs

branch : a11y/issue-1817

created branch time in 3 days

PR opened w3c/epub-specs

Reviewers
Update link to the list of optimized publications

As discussed on the telecon yesterday, I've moved the list of optimization standards to a wiki page. This PR updates the specification to link to the new page and drops "registry" from the name since that's not technically what we have.

Fixes #1819

+3 -3

0 comment

1 changed file

pr created time in 3 days