Accessibility review process

2020-11-11 Thread James Teh
(Also cross-posting to firefox-dev.)

Hi all,

Tl;dr: The Mozilla Accessibility Release Guidelines outline what is needed
to make user interfaces accessible to people with disabilities. If you
would like help from the accessibility team to determine whether your
change is accessible, you can now set the a11y-review flag on a bug in
Bugzilla and fill in the comment template.

While the accessibility team has always performed accessibility reviews,
the process around this has hitherto been very ad hoc and unclear. To
address this, we have now formalised the process for requesting an
accessibility review. You can find it documented here:

https://firefox-source-docs.mozilla.org/bug-mgmt/processes/accessibility-review.html

For convenience, I've included the text at the bottom of this email.

This process references the Mozilla Accessibility Release Guidelines, which
have existed for a while but haven't been widely publicised. Among other
things, you can use these as a checklist to guide you in what to consider
to ensure an accessible user interface, whether that be during design,
development or determining shipping readiness. That document is here:

https://wiki.mozilla.org/Accessibility/Guidelines

If you have any questions or feedback, please feel free to reach out to me
directly.

Thanks!

jamie
--
Accessibility Review Introduction

At Mozilla, accessibility is a fundamental part of our mission to ensure
the internet is "open and accessible to all," helping to empower people,
regardless of their abilities, to contribute to the common good.
Accessibility Review is a service provided by the Mozilla Accessibility
team to review features and changes to ensure they are accessible to and
inclusive of people with disabilities.
Do I Need Accessibility Review?

You should consider requesting accessibility review if you aren't certain
whether your change is accessible to people with disabilities.
Accessibility review is optional, but it is strongly encouraged if you are
introducing new user interface or are significantly redesigning existing
user interface.
When Should I Request Accessibility Review?

Generally, it's best to request accessibility review as early as possible,
even during the product requirements or UI design stage. Particularly for
more complex user interfaces, accessibility is much easier when
incorporated into the design, rather than attempting to retro-fit
accessibility after the implementation is well underway.

The accessibility team has developed the Mozilla Accessibility Release
Guidelines  which
outline what is needed to make user interfaces accessible. To make
accessibility review faster, you may wish to try to verify and implement
these guidelines prior to requesting accessibility review.

The deadline for accessibility review requests is Friday of the first week
of nightly builds for the release in which the feature/change is expected
to ship. This is the same date as the PI Request deadline.
How Do I Request Accessibility Review?

You request accessibility review by setting the a11y-review flag to
"requested" on a bug in Bugzilla and filling in the template that appears
in the comment field. For features spanning several bugs, you may wish to
file a new, dedicated bug for the accessibility review. Otherwise,
particularly for smaller changes, you may do this on an existing bug. Note
that if you file a new bug, you will need to submit the bug and then edit
it to set the flag.
Questions?

If you have any questions, please don't hesitate to contact the
Accessibility team:

   - #accessibility on Matrix
   

   or Slack
   - Email: accessibil...@mozilla.com
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Intent to Ship : HTML5 element (Nightly Only)

2020-06-24 Thread James Teh
While this doesn't need to block shipping in Nightly, I think we should
consider advocating for the focus behaviour to be changed (and changing it
in Firefox if we can get it into the spec) before we ship to release.

The currently specified behaviour (and what both Firefox and Chrome
implement) is to focus the first focusable element in the dialog. However,
there are a few major problems with this, including:
1. This means a tabindex="-1" element could get focus, which is focusable
but not in the tab order. That's particularly strange if this gets focus in
preference to something which *does* participate in the tab order.
2. The first focusable element could be a long way down the page; e.g. a
dialog with a lot of preamble text and a form field or button after that
text. That is particularly problematic for screen reader users because that
will direct their reading cursor to the focused control, so they will
potentially not realise they're missing content above it. It might even
cause the page to scroll visually.

What I (and others in the accessibility community) am proposing is that the
dialog element itself should get focus, unless something within the dialog
has autofocus set, in which case we should focus that. There's a spec issue
for this, but it stalled:
https://github.com/whatwg/html/issues/1929

Another concern is that when the dialog is dismissed, focus gets thrown
back to the document. Instead, I think it should be returned to the element
which had focus before the dialog was shown, which is the recommended
pattern for good accessibility of dialogs. I don't think there is a spec
issue for this yet.

Jamie

On Thu, Jun 25, 2020 at 6:04 AM Sean Feng  wrote:

> Intent to Ship (Nightly Only) : Dialog Element
> ​
> Hi All,
> ​
> In bug 1645046 , I
> intend to turn html5  element on by default in Nightly. It has
> been developed behind the dom.dialog_element.enabled preference.
> ​
> Meta Tracking Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=840640
> ​
> This is Nightly only because two things needs adjustment in our
> implementation.
> ​
> 1. The inert element isn't supported (bug 921504 -
> https://bugzilla.mozilla.org/show_bug.cgi?id=921504).
>
>   - For modal dialog, elements that are not part the dialog should be
> mark as inert, so these elements gain the inert-ness and can't be
> focused. Since we don't have inert supported yet, users could use tab to
> move focus out of the dialog, which is not expected.
>
>   - Next Step: The implementation of inert element is going to be
> started soon (I think), and we can also discuss to support the
> inert-ness without the supporting of inert element
> ​
> 2. We currently use a temporary solution for the layout of modal dialog.
> (bug 1637310 - https://bugzilla.mozilla.org/show_bug.cgi?id=1637310).
>
>- Currently the spec defines modal dialog as an absolute element,
> along with some weird calculation requirement to make the element
> centered. This modal dialog layout felt like a hack to us, so we didn't
> follow it, and instead, we used a temporary solution
> (https://bugzilla.mozilla.org/show_bug.cgi?id=1642364) to make the modal
> dialog as a centered fixed element.
>
>- Next Step: The CCSWG agreed to switch modal dialog to be a centered
> fixed element
> (https://github.com/w3c/csswg-drafts/issues/4645#issuecomment-642130060),
> which is the same as the temporary solution we applied in bug 1642364.
> So the temporary solution may become a permanent solution after things
> have been finalized in spec.
> ​
> *Status in other browsers*
> Chrome has it enabled by default since Release 37
> https://www.chromestatus.com/feature/5770237022568448
>
> *web-platform-tests*:
>
> https://github.com/web-platform-tests/wpt/tree/master/html/semantics/interactive-elements/the-dialog-element,
>
> We have them all enabled and passing except for those layout and inert
> related ones.
>
> *Spec* - https://html.spec.whatwg.org/multipage/#the-dialog-element
>
> This feature was previously discussed in
>
> https://groups.google.com/d/msg/mozilla.dev.platform/vTPGW1aJq24/JnEnoH3BEAAJ
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Proposal: remove support for running desktop Firefox in single-process mode (e10s disabled) anywhere but in tests

2020-06-10 Thread James Teh
In general, this obviously makes a lot of sense. However, because there is
so much extra complication for accessibility when e10s is enabled, I find
myself disabling e10s in local opt/debug builds to isolate problems to the
core a11y engine (vs the a11y e10s stuff). The ability to do this was
instrumental in some of the perf work I've been doing lately. For example,
it allowed me to determine that some of the perf problems I had originally
attributed to the a11y e10s layer were actually problems in the core a11y
engine. I'm sure there's some way I could have achieved that with e10s
enabled, but it probably would have taken me weeks longer.

All of that said, I realise this is an obscure case and I don't want to
stand in the way of progress; I'm well aware legacy has to die eventually.
Nevertheless, I thought I'd at least flag this concern.

Btw, the need to isolate the core a11y engine from the a11y e10s stuff is
also why some of our a11y tests still run with e10s disabled in automation.

Jamie

On Thu, Jun 11, 2020 at 4:56 AM David Major  wrote:

> I agree that it's a bad idea for users to be running permanently with this
> setting on their daily driver browsers.
>
> But the environment variable has been a huge productivity enhancer to
> reduce my mental load when setting up an extra-hairy debug session or
> taking system traces.
>
> I wish we could have a way to allow this for one-off cases but not
> long-term usage. Unfortunately I can't settle for a proposal like "allow it
> only in debug or only in nightlies" because I often need to debug actual
> user-facing builds. Is there any way we could build some auto-expiration
> into this setting, like maybe you'd have to set the env var equal to the
> build ID or today's date?
>
>
>
> On Wed, Jun 10, 2020 at 2:44 PM Dave Townsend 
> wrote:
>
> > Non-e10s is such a different environment that I don't think we have any
> > hope of keeping it working without running the full test suite in that
> mode
> > and I don't think anyone wants to do that. Now that this has started
> > breaking I think it is actively harmful to our users for us to allow them
> > to disable e10s.
> >
> > On Wed, Jun 10, 2020 at 11:30 AM Gijs Kruitbosch <
> gijskruitbo...@gmail.com
> > >
> > wrote:
> >
> > > (Copied to fx-dev; Replies to dev-platform please.)
> > >
> > > Hello,
> > >
> > > Just over a year ago, I started a discussion[0] about our support for
> > > disabling e10s. The outcome of that was that we removed support for
> > > disabling e10s with a pref on Desktop Firefox with version 68, except
> > > for use from automation. We kept support for using the environment
> > > variable. [1]
> > >
> > > Last week, we released Firefox 77, which turned out to break all
> > > webpages sent using compression (like gzip) if you had disabled e10s
> > > using this environment variable. [2]
> > >
> > > So here we are again. I'd like to propose we also stop honouring the
> > > environment variable unless we're running tests in automation. We
> > > clearly do not have sufficient test coverage to guarantee basic things
> > > like "the browser works", it lacks security sandboxing, and a number of
> > > other projects require it (fission, gpu process, socket process, ...),
> > > so I think it's time to stop supporting this configuration at all.
> > >
> > > I hope to make this change for the 79 cycle. I'm open to arguments
> > > either way about what to do for 78 esr (assuming the patch for 79 turns
> > > out to be simple; the work to remove the pref had a number of annoying
> > > corner-cases at the time).
> > >
> > > Please speak up if you think that this plan needs adjusting.
> > >
> > > ~ Gijs
> > >
> > >
> > > [0]
> > >
> > >
> >
> https://groups.google.com/d/msg/mozilla.dev.platform/cJMzxi7_PmI/Pi1IOg_wCQAJ
> > > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1548941
> > > [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1638652
> > > ___
> > > firefox-dev mailing list
> > > firefox-...@mozilla.org
> > > https://mail.mozilla.org/listinfo/firefox-dev
> > >
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> >
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Intent to prototype and ship: ARIA annotations

2020-02-27 Thread James Teh
In Firefox 75, we intend to enable ARIA annotations by default.

Summary: This adds two new ARIA roles, a new aria-description attribute and
expands aria-details. These changes are needed to support screen reader
accessibility of comments, suggestions and other annotations in published
documents and online word processing scenarios such as Google Docs, iCloud
Pages, and MS Office Online. This is not currently possible without
resorting to live region hacks, which are not as reliable as semantics and
do not work well with Braille displays. As a result, screen reader users
have non-optimal support for collaboration features of online word
processors.
Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1608975
Standard: Incorporated into ARIA 1.3 editor's draft. Explainer with links
to pull requests: https://github.com/aleventhal/aria-annotations
Platform coverage: desktop
Preference: None. Because this simply exposes new values to accessibility
clients using existing accessibility APIs, we do not anticipate any
problems.
DevTools bug: None. Both the DOM inspector and accessibility inspector will
reflect this new information without any additional work.
Other browsers: Chrome shipping enabled by default in version 82:
https://chromestatus.com/feature/4666935918723072
web-platform-tests: None. ARIA WPT is still somewhat of a work in progress
and hasn't been updated for ARIA 1.2 yet, let alone 1.3. We will have Gecko
tests, though.
Secure contexts: Not restricted to secure contexts, consistent with the
rest of ARIA.
Is this feature enabled by default in sandboxed iframes?: Yes; has no
impact on sandboxed iframes.
Link to standards-positions discussion:
https://github.com/mozilla/standards-positions/issues/253
How stable is the spec: The spec is straightforward and has been reviewed
and approved by stakeholders across the accessibility industry. We do not
anticipate any fundamental changes.

Jamie
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Proposed W3C Charters: Accessibility (APA and ARIA Working Groups)

2018-07-27 Thread James Teh
A final clarification:

On Fri, Jul 27, 2018 at 4:36 PM, Tantek Çelik 
wrote:

> Even if we (Mozilla) are delayed with implementation, we can
> still champion this stuff. We can still nominate someone to
> participate in the WG with subject matter expertise to help guide what
> we think will be more implementable features.
>
1.  Superficially (I haven't dug into it in detail), I don't believe
anything proposed in ARIA 1.1 or 1.2 is likely to be "not implementable" or
even "costly to implement" for browser vendors. It's more that the Mozilla
accessibility team currently doesn't have anyone who can devote time to
working on new spec things. To put it melodramatically, with current
resourcing, it's likely to take us months to even get to reading the spec
or implement the simplest of spec additions. I really hope this does not
remain the case for too long, but that's how it is right now.
2. For the same reason, we also don't have anyone with subject matter
expertise that's able (due to tie constraints) to participate meaningfully
in the WG.

Jamie
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Proposed W3C Charters: Accessibility (APA and ARIA Working Groups)

2018-07-26 Thread James Teh
TL;DR: Thanks for the further explanation/clarification. I (reluctantly)
agree that these concerns make sense and have nothing else to add as far as
the response goes.

On Fri, Jul 27, 2018 at 2:33 PM, Tantek Çelik 
wrote:

> > The only thing worth
> > noting is that while you say there's no need to delay for years, that may
> > well be what ends up happening, and Mozilla will essentially be "blocking
> > progress" on this front.
>
> If there were only two browser vendors (including Mozilla) then yes
> your statement would be correct.
>
> However, we have (at least) four major browser vendors, and thus it is
> incorrect to assert that Mozilla alone could be "blocking progress"
> when any 2 of the other 3 browser vendors could implement something
> and have it exit CR.
>
That's fair. I suppose there's some (now irrelevant) historical context
here: it used to be that Mozilla championed this stuff and drove others to
push accessibility forward. At present, that is not the case, and I'm
concerned it'll now be very hard to make much progress in accessibility.
Still, while that's kind of sad, I take your point that this is irrelevant
to the requirements of the charter.


> > We want "limited resources" to drive better
> > standards, yet with our resources in accessibility as limited as they
> are at
> > this point, it's entirely likely we won't get around to implementing new
> > ARIA stuff for years.
>
> That may well be. If that is your assessment, we should add that to
> our Charter response and be quite upfront that we are unlikely to
> implement new ARIA stuff for (a few?) years, and perhaps ask
> (non-F.O.) for the WG to be postponed accordingly.
>
Honestly, there is a lot of uncertainty at this point; I certainly couldn't
give any "formal" statement concerning what we might or might not
implement. FWIW, I believe Mozilla *should* implement this stuff, but that
all depends on me convincing leadership that we should provide more
resources for accessibility. :) Again, irrelevant to our charter response.


> In addition per your note about "still haven't implemented parts of
> ARIA 1.1, let alone ARIA 1.2.", if you know of any features in those
> specs which *no browser implements* we should call those out, and ask
> that the Charter explicitly dictate dropping them in the next version
> of ARIA for failure to get uptake.
>
I'd say there's at least one implementation (probably two) of most ARIA 1.1
stuff. I'm not sure about ARIA 1.2; I haven't even had a chance to look at
it yet.

Jamie
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Proposed W3C Charters: Accessibility (APA and ARIA Working Groups)

2018-07-26 Thread James Teh
That all seems reasonable from a process perspective. The only thing worth
noting is that while you say there's no need to delay for years, that may
well be what ends up happening, and Mozilla will essentially be "blocking
progress" on this front. We want "limited resources" to drive better
standards, yet with our resources in accessibility as limited as they are
at this point, it's entirely likely we won't get around to implementing new
ARIA stuff for years. At that point, we have a conflict: we have Mozilla
objecting to the minimum implementation exception, while at the same time
not resourcing accessibility sufficiently to make any reasonable progress
at all. I'm not sure we can have it "both ways".

Jamie

On Fri, Jul 27, 2018 at 11:27 AM, Tantek Çelik 
wrote:

> On Thu, Jul 26, 2018 at 6:04 PM, James Teh  wrote:
> > On Fri, Jul 27, 2018 at 2:09 AM, L. David Baron 
> wrote:
> >
> >> So some comments on the ARIA charter at
> >> https://www.w3.org/2018/03/draft-aria-charter :
> >> ...
> >> I guess it seems OK to have only one implementation
> >> if there's really only going to be one implementation on that
> >> platform... but allowing it in general (i.e.,  seems less than ideal,
> >
> > It is. However, the problem is that accessibility in general is severely
> > lacking in resources across browser vendors (especially Mozilla!; we're
> > currently working with just 2 engineers). Even where browser vendors
> agree
> > on how something *should* be done, it often takes months or years before
> it
> > gets implemented, primarily due to the aforementioned resource shortage.
> We
> > (Mozilla) still haven't implemented parts of ARIA 1.1, let alone ARIA
> 1.2.
> > The reality is that if multiple implementations were required for
> sign-off,
> > it'd probably delay the process for years.
>
> Respectfully, I disagree with that use of process, and those
> unimplemented parts of ARIA 1.1, let alone ARIA 1.2 should probably
> have been dropped and/or postponed to future versions.
>
> The reality is that if a standard does not reflect what is
> implemented/implementable (and yes, economic constraints / costs,
> resource are a legitimate reason to criticize something as not being
> implementable), then it should not be in the standard.
>
> A better answer when something lacks multiple implementations is:
> 1. if there is only one implementation, move it to an informative
> (non-normative) appendix
> 2. if there are zero implementations, cut it and postpone it to the
> next +0.1 version
>
> By following such a methodology, there is no need to delay "for
> years". You ship the spec (go to PR) with what happens to be supported
> as of that point in time, then work on the next +0.1 version to ship
> the next year and repeat, hopefully increasing the number of features
> that are interoperable implemented.
>
> > and
> >> allowing only 75% of mappings to be implemented to count as
> >> success seems pretty bad.
> >>
> > Same issue as above regarding limited resources.  Still, this one is a
> > little more concerning because it raises questions about whether the
> > remaining 25% will *ever* be implementable.
>
> Right, same issue with implementability, and same answer (1, 2 above).
>
> We (especially Mozilla) want "limited resources" to be a forcing
> function to drive better standards, simpler to implement, test, debug,
> secure, etc.
>
> No user benefits from unimplemented standards.
>
> If anything, such "specifiction" causes harm in that it can cause
> false expectations of what "works", wasting web developer time and
> resources.
>
> Tantek
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Proposed W3C Charters: Accessibility (APA and ARIA Working Groups)

2018-07-26 Thread James Teh
On Fri, Jul 27, 2018 at 2:09 AM, L. David Baron  wrote:

> So some comments on the ARIA charter at
> https://www.w3.org/2018/03/draft-aria-charter :
> ...
> I guess it seems OK to have only one implementation
> if there's really only going to be one implementation on that
> platform... but allowing it in general (i.e.,  seems less than ideal,

It is. However, the problem is that accessibility in general is severely
lacking in resources across browser vendors (especially Mozilla!; we're
currently working with just 2 engineers). Even where browser vendors agree
on how something *should* be done, it often takes months or years before it
gets implemented, primarily due to the aforementioned resource shortage. We
(Mozilla) still haven't implemented parts of ARIA 1.1, let alone ARIA 1.2.
The reality is that if multiple implementations were required for sign-off,
it'd probably delay the process for years.

and
> allowing only 75% of mappings to be implemented to count as
> success seems pretty bad.
>
Same issue as above regarding limited resources.  Still, this one is a
little more concerning because it raises questions about whether the
remaining 25% will *ever* be implementable.

Also, the two references to a deliverable of the SVG working group
> when the SVG working group isn't currently chartered seems
> problematic.
>
Ah, yes, that does seem like a problem.

Jamie
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Proposed W3C Charters: Accessibility (APA and ARIA Working Groups)

2018-07-12 Thread James Teh
I (and others in the accessibility team) think we should support these
charters. The ARIA working group is especially important in the future
evolution of web accessibility. I have some potential concerns/questions
regarding the personalisation semantics specifications from APA, but
they're more spec questions at this point and I don't think they need to be
raised with respect to charter. Certainly, cognitive disabilities is an
area that definitely needs a great deal more attention on the web, and the
APA are seeking to do that.

Thanks.

Jamie

On Wed, Jul 11, 2018 at 3:57 PM, L. David Baron  wrote:

> The W3C is proposing revised charters for:
>
>   Accessible Platform Architectures (APA) Working Group
>   https://www.w3.org/2018/03/draft-apa-charter
>
>   Accessible Rich Internet Applications (ARIA) Working Group
>   https://www.w3.org/2018/03/draft-aria-charter
>
>   https://lists.w3.org/Archives/Public/public-new-work/2018Jun/0003.html
>
> Mozilla has the opportunity to send comments or objections through
> Friday, July 27.
>
> The changes relative to the previous charters are:
> https://services.w3.org/htmldiff?doc1=https%3A%2F%
> 2Fwww.w3.org%2F2015%2F10%2Fapa-charter=https%3A%
> 2F%2Fwww.w3.org%2F2018%2F03%2Fdraft-apa-charter
> https://services.w3.org/htmldiff?doc1=https%3A%2F%
> 2Fwww.w3.org%2F2015%2F10%2Faria-charter=https%3A%
> 2F%2Fwww.w3.org%2F2018%2F03%2Fdraft-aria-charter
>
> Please reply to this thread if you think there's something we should
> say as part of this charter review, or if you think we should
> support or oppose it.
>
> -David
>
> --
> 턞   L. David Baron http://dbaron.org/   턂
> 턢   Mozilla  https://www.mozilla.org/   턂
>  Before I built a wall I'd ask to know
>  What I was walling in or walling out,
>  And to whom I was like to give offense.
>- Robert Frost, Mending Wall (1914)
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform